https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109555
--- Comment #2 from niXman ---
(In reply to Andrew Pinski from comment #1)
> Note branchless might be worse.
really?
could you explain please?
> Anyways there is a duplicate of this bug
> already. I think I filed it.
thank you!
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
hello!
the example:
#include
int main(int argc, char **argv) {
return std::memcmp(argv[0], "MCRYF"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #18 from niXman ---
tested on i686 and x86_64 mingw-w64 - works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #17 from niXman ---
(In reply to niXman from comment #15)
> (In reply to Jakub Jelinek from comment #13)
> > Fixed now on the trunk. I'd wait a little bit with backports, though I
> > think the gmp-param.h change doesn't need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #16 from niXman ---
trying to build x86_64-mingw-w64 and check...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #15 from niXman ---
(In reply to Jakub Jelinek from comment #13)
> Fixed now on the trunk. I'd wait a little bit with backports, though I
> think the gmp-param.h change doesn't need backporting.
unfortunately, the bug is still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #14 from niXman ---
(In reply to Jakub Jelinek from comment #13)
> Fixed now on the trunk. I'd wait a little bit with backports, though I
> think the gmp-param.h change doesn't need backporting.
Thank you Jakub!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #35 from niXman ---
and the rights to edit my comments too =)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #34 from niXman ---
(In reply to Bill Zissimopoulos from comment #33)
> Now that we have a potential patch what are the steps to get it included
> into the gcc codebase?
great question!
I think the best option is to give me rights
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204
niXman changed:
What|Removed |Added
CC||i.nixman at autistici dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #8 from niXman ---
(In reply to boot...@163.com from comment #7)
> After a lg compile, I get the same error on my Ubuntu WSL. but I think
> it might be a problem with the WSL VM.
there is nothing unusual in your instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #16 from niXman ---
(In reply to nightstrike from comment #15)
> Someone on irc (jakub?) suggested just changing all of the aborts to
> gcc_unreachable. Is that a viable option?
I like that idea, I'm not sure it will be accepted...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #11 from niXman ---
Created attachment 54301
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54301=edit
patch
(In reply to niXman from comment #9)
> although I think these two bugs have the same cause...
right, it was the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #32 from niXman ---
> Thanks. Your Windows related changes look good to me.
great, thanks!
> FYI, I am unsure about the need to change all backslashes to slashes and
> wonder if this is a backwards incompatible change for users
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #10 from niXman ---
(In reply to Jakub Jelinek from comment #8)
> As Joseph wrote, there were lots of strtod_l.c fixes since 2011 and most of
> them weren't incorporated into libquadmath (unlike most of the math/
> functions which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #9 from niXman ---
although I think these two bugs have the same cause...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #7 from niXman ---
(In reply to niXman from comment #5)
> because it's MinGW specific:
I will paraphrase:
this report is for MinGW.
but another one - 87204, looks like NOT. but im unsure... will work on it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #6 from niXman ---
(In reply to niXman from comment #3)
> BTW, I have fixed it for x86_64-mingw32. trying to rebuild for i686-mingw32
> for check.
yeah, it's fixed.
works on x86_64 and i686 MinGW.
will check it on Linux host too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #5 from niXman ---
because it's MinGW specific:
> Demo strtoflt128 error with some subnormals on Windows
but another one - 87204, looks like NOT. but im unsure... will work on it too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #3 from niXman ---
BTW, I have fixed it for x86_64-mingw32. trying to rebuild for i686-mingw32 for
check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #2 from niXman ---
guys, how can I add that
report(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87204) as duplicate of this
report?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #1 from niXman ---
unfortunately, this bug is still present on the master branch...
trying to deal with it..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #18 from niXman ---
Created attachment 54291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54291=edit
confirmation
it works for me. please look at attachment screenshot.
for GCC-master, configured as x86_64-w64-mingw32,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #4 from niXman ---
> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.
please provide the step-by-step instruction you used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #3 from niXman ---
> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.
what GCC version was used on the host?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395
niXman changed:
What|Removed |Added
CC||i.nixman at autistici dot org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #6 from niXman ---
I think you don't understand me.
with your patch after preprocessing the `unlink_if_ordinary()` will look like:
```
int
unlink_if_ordinary (const char *name)
{
if (stricmp (name, "nul") == 0)
return 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
--- Comment #9 from niXman ---
looks like it's fixed for x86_64-w64-mingw32.
I used the test from the: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
I run it on bash loop for the night and it successfully executed for ~179k
times.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #29 from niXman ---
Created attachment 54285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54285=edit
patch
another version of the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #4 from niXman ---
(In reply to niXman from comment #2)
> I don't think the patch is correct because for WIN32 platform `unlink()`
> will never be called even for non-"nul" files.
moreover, according to the man:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #28 from niXman ---
in rebuilding stage...
one more issue: when the symlink called `gcc.exe` and I exec it as `gcc.exe
a.c` - all works as it should, but when I exec it as `gcc a.c` - I get the same
result as before - `fatal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
--- Comment #7 from niXman ---
> The implementation is completely different on linux, so that would require
> some code changes at least.
I didn't think so...
I think conceptually the solution looks the same for all platforms...
OK, got it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #27 from niXman ---
ah, got it.
thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
--- Comment #5 from niXman ---
(In reply to niXman from comment #4)
> I don't think it is mingw/windows related.
> can't the example be checked using thread sanitizer?
... on Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101037
niXman changed:
What|Removed |Added
CC||i.nixman at autistici dot org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #25 from niXman ---
updated patch there:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610029.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #3 from niXman ---
and I propose to use `strcasecmp()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #2 from niXman ---
@Himal
```
+#ifdef _WIN32
+if (stricmp (name, "nul") == 0)
+ return 1;
+#else
struct stat st;
if (lstat (name, ) == 0
&& (S_ISREG (st.st_mode) || S_ISLNK (st.st_mode)))
return unlink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #24 from niXman ---
BTW, I have no ideas how can I test the patch for UNC ('\\?\UNC' prefixed) ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #23 from niXman ---
Created attachment 54280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54280=edit
patch
looks like I have finished!
boostrapped successfully as x86_64-mingw-w64.
@Bill Zissimopoulos, @Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #21 from niXman ---
another strange problem is that `CreateFile()` is able to open the special file
`nul` for reading, but `GetFinalPathNameByHandle()` cannot get the full name of
this file and returns 0 and setting `last error` to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #16 from niXman ---
Created attachment 54264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54264=edit
patch
the patch for `lrealpath()` for win32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #15 from niXman ---
> There is no way to resolve a hardlink to a "real" path, all hardlinked paths
> are "real".
according to this link:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #13 from niXman ---
I figured out the building problem.
it seems to work as it should for symlink, but it doesn't work for hardlink.
will dive into docs...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #11 from niXman ---
even with a downgraded host toolchain to that which uses mingw-w64 rt-v9 I get
the same error...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #10 from niXman ---
it is strange, but for some reason I can't build master nor 12.2.0 because of
error:
```
{
/c/mingw-builds/x86_64-1220-win32-seh-msvcrt-rt_v10-rev0/build/gcc-12.2.0/./gcc/nm
-pg _chkstk_s.o _chkstk_ms_s.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #8 from niXman ---
> Yes, or them together: `FILE_NAME_NORMALIZED | VOLUME_NAME_DOS`.
>
> - `FILE_NAME_NORMALIZED` is needed to actually perform the symbolic link
> resolution.
>
> - `VOLUME_NAME_DOS` is needed to translate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #6 from niXman ---
> I would use `FILE_NAME_NORMALIZED` and `VOLUME_NAME_DOS`.
together? OR'ed?
or should I try for the first, and for the second one? or...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #4 from niXman ---
> FYI `GetFinalPathNameByHandle` is known to fail on drives that are created
> via `DefineDosDevice` (e.g. via the SUBST command). So I recommend using
> `GetFullPathName` as a fallback if you find that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #3 from niXman ---
(In reply to Bill Zissimopoulos from comment #2)
> (In reply to niXman from comment #1)
> > > The most straightforward fix is to change `lrealpath` to use
> > > `GetFinalPathNameByHandle` instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350
--- Comment #1 from niXman ---
> FIX
>
> The most straightforward fix is to change `lrealpath` to use
> `GetFinalPathNameByHandle` instead of `GetFullPathName`.
thanks for the investigation!
will do it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #13 from niXman ---
could it be because now as host toolchain used a version which contains the
changes LIU Hao is talked about?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #12 from niXman ---
guys, does anyone have an idea why I faced with the error on gcc-12.2.0 ?
```
../../../../src/gcc-12.2.0/libcpp/system.h:404:30: error: expected identifier
before string constant
404 | #define abort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #7 from niXman ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Jonathan Yong :
>
> https://gcc.gnu.org/g:902c755930326cb4405672aa3ea13c35c653cbff
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108313
--- Comment #3 from niXman ---
(In reply to Andrew Pinski from comment #2)
> Dup of bug 108300
>
> *** This bug has been marked as a duplicate of bug 108300 ***
ah, got it. thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108313
--- Comment #1 from niXman ---
file/line to the buggy line:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libcpp/system.h;h=e80cf029d88fcb74db5515b4b2915d72df0974dc;hb=refs/heads/master#l404
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
hello,
I'm just trying to build master branch as I done before many times, but now I
faced with strange error:
```
../../../../src/gcc-trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
--- Comment #8 from niXman ---
(In reply to Jonathan Wakely from comment #7)
> Probably a dup of PR 108225 i.e. expecting --enable-threads=win32 to provide
> std::mutex without _WIN32_WINNT >= 0x0600
yep, sure!
> But it isn't provided,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
--- Comment #6 from niXman ---
(In reply to niXman from comment #5)
> (In reply to niXman from comment #4)
> > (In reply to nightstrike from comment #2)
> > > Is this before or after this patch set was applied?
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
--- Comment #5 from niXman ---
(In reply to niXman from comment #4)
> (In reply to nightstrike from comment #2)
> > Is this before or after this patch set was applied?
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
--- Comment #4 from niXman ---
(In reply to nightstrike from comment #2)
> Is this before or after this patch set was applied?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
I think it can be so because of unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210
--- Comment #3 from niXman ---
(In reply to cqwrteur from comment #0)
> /home/cqwrteur/toolchains_build/gcc/libstdc++-v3/src/c++20/tzdb.cc:565:5:
> error: 'mutex' does not name a type; did you mean 'minutes'?
> 565 | mutex infos_mutex;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #10 from niXman ---
yes, fixed for the `master`.
```
foo:
.LFB6604:
.cfi_startproc
movdqu (%rdi), %xmm1
movdqa .LC0(%rip), %xmm0
pcmpgtb %xmm1, %xmm0
ret
.cfi_endproc
.LFE6604:
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107546
--- Comment #9 from niXman ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 53842 [details]
> gcc13-pr107546.patch
>
> Untested fix.
many thanks!
will test, will report back.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
Hello,
this code sample(https://godbolt.org/z/TnGMsfMs6):
```
#include
auto foo(const char *p) {
const auto substr = _mm_loadu_si128((const __m128i *)p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107497
--- Comment #10 from niXman ---
(In reply to Andrew Macleod from comment #7)
> (In reply to niXman from comment #6)
> > just now faced with the bug as well on x86_64-w64-mingw32 target.
>
> Does the committed patch not fix it?
fixed! thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107497
--- Comment #8 from niXman ---
(In reply to Andrew Macleod from comment #7)
> (In reply to niXman from comment #6)
> > just now faced with the bug as well on x86_64-w64-mingw32 target.
>
> Does the committed patch not fix it?
checking...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107497
--- Comment #6 from niXman ---
just now faced with the bug as well on x86_64-w64-mingw32 target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870
--- Comment #10 from niXman ---
(In reply to Jonathan Wakely from comment #9)
> There's a patch at https://gcc.gnu.org/ml/libstdc++/2017-02/msg00041.html
>
> I haven't reviewed or tested it yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820
--- Comment #6 from niXman ---
Created attachment 40970
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40970=edit
patch
done.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820
--- Comment #4 from niXman ---
(In reply to Jonathan Wakely from comment #3)
> and it also needs to be done on line 275.
why?
line 275:
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/io/basic_file_stdio.cc?view=markup#l275
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79820
--- Comment #2 from niXman ---
Created attachment 40966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40966=edit
patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71958
--- Comment #1 from niXman ---
s/But compiled ok/The same error occurs/
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
This code:
void
bar(int v)
{
short w[v];
}
produces the following error if compiled using gcc-6.1.0:
bar.c: In function 'bar':
bar.c:5:8: internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864
--- Comment #3 from niXman ---
(In reply to Markus Trippelsdorf from comment #2)
> I cannot reproduce the problem on gcc-6 branch or trunk.
Try to use this build:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864
--- Comment #1 from niXman ---
This error does not occur if '-Og' is excluded. Also this error does not occur
when '-O0' is used.
rmal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
#include
__attribute__ ((__sysv_abi__))
int foo(__m128i a)
{
return(0);
}
This error occurs when this code comp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
I'm trying to build MinGW-W64(i686-sjlj) based on GCC-5.1.0 and faced with
this errors:
http://pastebin.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60244
--- Comment #2 from niXman i.nixman at autistici dot org ---
(In reply to Kai Tietz from comment #1)
Hmm, can't reproduce it. I will do today some additional tests for it.
How can I help you?
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
configure options:
../../../src/gcc-trunk/configure \
--host=i686-w64-mingw32 \
--build=i686-w64-mingw32 \
--target=i686-w64-mingw32
80 matches
Mail list logo
