https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005
Ozkan Sezer changed:
What|Removed |Added
Attachment #58144|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005
--- Comment #4 from Ozkan Sezer ---
(In reply to Ozkan Sezer from comment #3)
> > There is a jump threading there handling n==0 (aka numbits==-1u) and that is
> > causing the warning.
>
> The thing is, n==0 is not guarding against numbits==-1u:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005
--- Comment #3 from Ozkan Sezer ---
> There is a jump threading there handling n==0 (aka numbits==-1u) and that is
> causing the warning.
The thing is, n==0 is not guarding against numbits==-1u: it is guarding
against 0 members of fetch_16bit[]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115005
--- Comment #1 from Ozkan Sezer ---
Created attachment 58145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58145&action=edit
preprocessed original source
Assignee: unassigned at gcc dot gnu.org
Reporter: sezeroz at gmail dot com
Target Milestone: ---
Created attachment 58144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58144&action=edit
reduced C source exhibiting the issue
The attached C source emits bogus -Warray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973
--- Comment #4 from Ozkan Sezer ---
(In reply to Richard Biener from comment #2)
> This a different incarnation of PR114931, fixed on trunk as well already (I
> just checked).
>
> *** This bug has been marked as a duplicate of bug 114931 ***
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971
--- Comment #7 from Ozkan Sezer ---
(In reply to Sam James from comment #6)
> Please check if trunk works, as a fix for that PR was committed not long ago.
Confirmed that trunk has it fixed.
Fix hopefully gets backported soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973
--- Comment #3 from Ozkan Sezer ---
(In reply to Richard Biener from comment #2)
> This a different incarnation of PR114931, fixed on trunk as well already (I
> just checked).
>
> *** This bug has been marked as a duplicate of bug 114931 ***
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973
--- Comment #1 from Ozkan Sezer ---
Created attachment 58120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58120&action=edit
stderr output
iority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sezeroz at gmail dot com
Target Milestone: ---
Created attachment 58119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58119&action=edit
preprocessed source
Happens while compiling mikmod p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971
--- Comment #5 from Ozkan Sezer ---
(In reply to Richard Biener from comment #2)
> likely a duplicate of PR114931
I guess -std=gnu23 is the key, then yes, likely a dup.
Waiting for a resolution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971
--- Comment #4 from Ozkan Sezer ---
Created attachment 58118
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58118&action=edit
output from a fourth ICE at the same place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971
--- Comment #3 from Ozkan Sezer ---
Created attachment 58117
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58117&action=edit
output from a third ICE at the same place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971
--- Comment #1 from Ozkan Sezer ---
Created attachment 58116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58116&action=edit
-freport-bug output from another ICE
Attached a -freport-bug output from another source ICE'ing at the same plac
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sezeroz at gmail dot com
Target Milestone: ---
Created attachment 58115
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58115&action=edit
-freport-bug output
Output from -freport-bug attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65307
--- Comment #15 from Ozkan Sezer ---
(In reply to Richard Biener from comment #14)
> Fixed.
By which commit was this fixed? Is the fix applicable to the now-closed
4.9 branch at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61546
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130
Ozkan Sezer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130
--- Comment #2 from Ozkan Sezer ---
(In reply to Jakub Jelinek from comment #1)
> That is a warning, not the reason for bootstrap failure.
Well it eventually results in an error:
In file included from
../../../../gcc49.r210278/libsanitizer/ubsan
Assignee: unassigned at gcc dot gnu.org
Reporter: sezeroz at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
$ ../gcc49.r210278/configure --enable-checking=yes --enable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50040
--- Comment #12 from Ozkan Sezer 2012-01-03 16:54:00
UTC ---
(In reply to comment #10)
> It's also questionable to cause new warnings to appear on the branch if
> you consider code using -Werror.
gcc-4.4 used to warn (see bug 50950), therefore i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50950
--- Comment #3 from Ozkan Sezer 2011-11-02 11:29:20
UTC ---
(In reply to comment #2)
> A dup actually (fixed on trunk):
>
Thank you. Can we expect a backport of the fix to 4.5 and 4.6?
> t.c: In function 'f0':
> t.c:14:5: warning: 'x' is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50950
Bug #: 50950
Summary: warning missed when OR'ing to an uninitialized
variable
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48035
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
--- Comment #21 from Ozkan Sezer 2011-08-01 15:31:01
UTC ---
Can we expect this bug to be fixed in 4.4? If not, is the 4.5.x commit in
comment #18 safe to apply to 4.4.x for private use? Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47626
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596
--- Comment #7 from Ozkan Sezer 2011-04-17 09:07:24
UTC ---
Possibly related: PR target/47626. This doesn't seem mingw-specific and is
_incorrectly_ marked as WORKSFORME.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48639
Summary: pthread.h fixinclude test failure with 4.4.6
Product: gcc
Version: 4.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45998
Ozkan Sezer changed:
What|Removed |Added
CC||sezeroz at gmail dot com
--- Comment #1
--- Comment #18 from sezeroz at gmail dot com 2010-09-18 20:51 ---
Are 4.4 and 4.5 going to be fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45234
--- Comment #27 from sezeroz at gmail dot com 2010-09-18 20:51 ---
Are 4.4 and 4.5 going to be fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #18 from sezeroz at gmail dot com 2010-07-14 14:05 ---
(In reply to comment #15)
> I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
>
This case fails with 4.4 on i686-linux too, printing 16, 16, 14, 14 instead of
16, 15, 14, 13 which 4.
--- Comment #17 from sezeroz at gmail dot com 2010-07-14 14:02 ---
(In reply to comment #16)
> This is also the wrong result with MinGW gcc 3.4.5.
> I'm expecting that all component of v will be 2500.
>
> 4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.
--- Comment #25 from sezeroz at gmail dot com 2010-05-07 17:44 ---
(In reply to comment #23)
> My build log seems to be clean (i686-pc-linux-gnu).
> Is this PR still needed?
>
The commit from comment #14 (as inlined in comment #9) introduces a new warning
of "passing
--- Comment #9 from sezeroz at gmail dot com 2010-04-14 18:59 ---
(In reply to comment #8)
> +/* { dg-require-effective-target lp64 } */
Adding llp64 to that would be helpful, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43662
--- Comment #1 from sezeroz at gmail dot com 2010-03-28 20:12 ---
Happens on x86_64-pc-linux-gnu, too. Segfaults with gcc-4.3.0 and 4.3.2 (as
shipped by fedora), but runs fine with 3.3.6, 3.4.6 and my custom 4.4.4.
--
sezeroz at gmail dot com changed:
What|Removed
--- Comment #1 from sezeroz at gmail dot com 2010-03-28 15:49 ---
Happens with 4.3.0 and 4.4.4 on i686-pc-linux, too. Reproduced the problem with
g++ only at -O0. -O1 and higher output the wanted result.
--
sezeroz at gmail dot com changed:
What|Removed
--- Comment #29 from sezeroz at gmail dot com 2010-03-25 08:54 ---
The testcase fails with gcc-4.4 at -O1 and higher, too (x86_64-pc-linux-gnu,
with or without -m32.) It would be nice to have the fix backported to 4.4.
--
sezeroz at gmail dot com changed:
What
--- Comment #1 from sezeroz at gmail dot com 2010-03-19 06:51 ---
Happened on x86_64-pc-linux and my gcc-4.4 was affected too, gcc-3.4.6 seemed
fine.
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #1 from sezeroz at gmail dot com 2010-03-14 06:37 ---
gcc-4.4 seems affected, too.
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #11 from sezeroz at gmail dot com 2010-03-10 14:17 ---
The testcase fails with 4.4 with -Ox -ftree-loop-distribution and the patch
does not apply to 4.4. Will there be a gcc-4.4 backport of this?
--
sezeroz at gmail dot com changed:
What|Removed
--- Comment #5 from sezeroz at gmail dot com 2010-02-10 14:29 ---
(In reply to comment #4)
[...]
> > > > FAIL: gcc.c-torture/compile/pr42705.c -Os (test for excess errors)
> > >
> > > It passed for me on Linux/x86.
> > >
> >
&g
--- Comment #3 from sezeroz at gmail dot com 2010-02-08 21:18 ---
(In reply to comment #2)
> > FAIL: gcc.c-torture/compile/pr42705.c -O1 (internal compiler error)
> > FAIL: gcc.c-torture/compile/pr42705.c -O1 (test for excess errors)
> > FAIL: gcc.c-torture/comp
--- Comment #14 from sezeroz at gmail dot com 2010-01-15 20:59 ---
For me, the testcase doesn't abort or exit successfully,
it just segfaults (i686, x86_64, gcc-4.3, 4.4).
$ gcc44 -g -O2 -Wall -W pr42691.c
$ gdb ./a.out
GNU gdb Fedora (6.8-24.fc9)
[...]
Program received signal SI
--- Comment #4 from sezeroz at gmail dot com 2010-01-13 12:56 ---
gcc-3.4.6, 4.3.2 and 4.4.3 always print 1 with or without -m32 for both -O1 and
-O2 on x86_64 (fedora 10). On i686 (fedora 9), gcc-3.3.6 and 3.4.6 always
prints 1, gcc-4.3.0 (as shipped by fedora) always prints 0, and
--- Comment #15 from sezeroz at gmail dot com 2010-01-06 08:55 ---
Can we expect a 4.4 backport for this, at least in the ix86/4.4 branch if not
in the main 4.4 branch?
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #11 from sezeroz at gmail dot com 2009-10-31 07:50 ---
(In reply to comment #10)
>
> Author: hjl
> Date: Fri Oct 30 16:04:41 2009
> New Revision: 153759
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153759
> Log:
> 2009-10-30
--- Comment #6 from sezeroz at gmail dot com 2009-10-19 11:11 ---
(In reply to comment #5)
> function is left, so chances are you are refering to a variable later on even
> after it went out of scope.
By a closer look, the function is called twice, first by its argument set to
t
--- Comment #4 from sezeroz at gmail dot com 2009-10-19 09:01 ---
Created an attachment (id=18825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18825&action=view)
good asm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
--- Comment #3 from sezeroz at gmail dot com 2009-10-19 09:01 ---
Created an attachment (id=18824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18824&action=view)
failing asm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
--- Comment #2 from sezeroz at gmail dot com 2009-10-19 09:00 ---
Created an attachment (id=18823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18823&action=view)
good preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
--- Comment #1 from sezeroz at gmail dot com 2009-10-19 08:59 ---
Created an attachment (id=18822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18822&action=view)
failing preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown
--- Comment #5 from sezeroz at gmail dot com 2009-10-16 19:49 ---
Any chance for a backport to 4.4 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40654
--- Comment #5 from sezeroz at gmail dot com 2009-10-16 19:45 ---
Any progress on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40983
--- Comment #10 from sezeroz at gmail dot com 2009-09-07 11:27 ---
(In reply to comment #6)
> (In reply to comment #2)
> > Janne, I think the warning about "unix.c:750:15: warning:
> > �statbuf.st_mode� may
> > be used uninitialized" is spurious, but can
--- Comment #7 from sezeroz at gmail dot com 2009-09-04 06:26 ---
fixed on the trunk now.
--
sezeroz at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #67 from sezeroz at gmail dot com 2009-09-03 12:47 ---
Will the fix for this bug be backported to the 4.4 branch?
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #3 from sezeroz at gmail dot com 2009-09-03 10:10 ---
The discussion thread at
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00778.html still haven't provide a
solution for this one even after the recent build system changes.. Will md5.h,
splay-tree.h and sha1.h be mod
--- Comment #17 from sezeroz at gmail dot com 2009-08-14 12:28 ---
Thank you all for your hard work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #14 from sezeroz at gmail dot com 2009-08-12 18:20 ---
anything new on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #12 from sezeroz at gmail dot com 2009-08-02 09:32 ---
(In reply to comment #11)
> This is the simplest patch that can possibly work:
>
A quick testing shows that the proposed patch, applied to rev.150333, cures the
ICE for me with -march=i386, i486, i586 and c3.
--- Comment #8 from sezeroz at gmail dot com 2009-08-01 23:11 ---
(In reply to comment #7)
> Hmm, Pentium is not a cmove target and it doesn't like sahf, so
For the record, the ICE happens with -march=i[3|4|5]86, but not for i686 or
better.
--
http://gcc.gnu.org/
--- Comment #3 from sezeroz at gmail dot com 2009-08-01 20:26 ---
Some further info: The problem is specifically related to the -ffast-math
option. Only by removing it, the compilation succeeds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #2 from sezeroz at gmail dot com 2009-08-01 20:12 ---
Created an attachment (id=18283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18283&action=view)
generated *s file
(generated *.s file)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #1 from sezeroz at gmail dot com 2009-08-01 20:11 ---
Created an attachment (id=18282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18282&action=view)
preprocessed source
(Preprocessed source. Exact command line was:
gcc45 -c -march=i586 -O2 -Wall -DNDEBUG
d at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- Comment #16 from sezeroz at gmail dot com 2009-07-31 18:16 ---
(In reply to comment #15)
> Created an attachment (id=18279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18279&action=view) [edit]
> [ __attribute__((optimize("0"))) difference ]
>
>
--- Comment #15 from sezeroz at gmail dot com 2009-07-31 18:07 ---
Created an attachment (id=18279)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18279&action=view)
[ __attribute__((optimize("0"))) difference ]
Hmm, __attribute__((optimize("0"))) does s
--- Comment #13 from sezeroz at gmail dot com 2009-07-31 16:46 ---
(In reply to comment #12)
> noinline attributes would be better I think.
>
noinline for the inline functions??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
--- Comment #11 from sezeroz at gmail dot com 2009-07-31 16:02 ---
(In reply to comment #10)
> Filed MingW bug here:
> https://sourceforge.net/tracker/?func=detail&aid=2830386&group_id=2435&atid=102435
>
Wrong project tracker. Please go to
https://sourceforge.
--- Comment #9 from sezeroz at gmail dot com 2009-07-31 09:59 ---
Interesting that the problem occurs only with the inlined version: if the test
object is linked with a non-inline version in a separate *.a file, the test
behaves correctly.. BTW, neither 4.4 nor 4.5 complains even with
--- Comment #7 from sezeroz at gmail dot com 2009-07-31 06:30 ---
Besides my question in comment #6, I wonder why is this actually considered an
aliasing violation? The only difference between struct stat and struct
_stat64i32 is the time fields: _stat64i32 has __time64_t and stat has
--- Comment #6 from sezeroz at gmail dot com 2009-07-30 19:30 ---
(In reply to comment #5)
> Yep:
>
> extern __inline__ int __attribute__((__cdecl__)) stat(const char
> *_Filename,struct stat *_Stat) {
> return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
>
--- Comment #2 from sezeroz at gmail dot com 2009-07-30 09:58 ---
Hmm, with gcc-4.4.2 (branch rev. 150249), I always get "mode = 81ff" reported
on the console with both -O0 and -O2 compiled exes from t.c test. This is with
mingw-w64 headers and crt revision 1101, the
--- Comment #5 from sezeroz at gmail dot com 2009-07-23 13:46 ---
Compiled my same toolchain on linux-x86_64 and compiled the test for
x86_64-pc-mingw32, the resulting exe prints 369 on Vista-SP2-x64 and exits
normally.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
--- Comment #3 from sezeroz at gmail dot com 2009-07-23 12:40 ---
I cross-compile from i686-linux to x86_64-pc-mingw32. (I can also try
cross-compiling from x86_64-linux to x86_64-pc-mingw32, if you want.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40837
--- Comment #1 from sezeroz at gmail dot com 2009-07-23 11:10 ---
Curious. As a data point, can't reproduce this with 4.4 (svn rev.149965).
--
sezeroz at gmail dot com changed:
What|Removed |
--- Comment #2 from sezeroz at gmail dot com 2009-07-19 09:33 ---
Problem also exists in 4.4.0/4.4.1.
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 ---
This bug may result in unreliable binary outputs, why is it targeted for fixing
in 4.4.2 and not in 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #2 from sezeroz at gmail dot com 2009-07-14 17:16 ---
Also happens with i686-pc-linux-gnu with gcc-4.4.1 (gcc-4_4-branch, r149543).
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #9 from sezeroz at gmail dot com 2009-07-08 11:37 ---
Will there be a backport of this to the branches 4.3 and 4.4?
--
sezeroz at gmail dot com changed:
What|Removed |Added
warning
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC target triplet: i686-pc-min
--- Comment #6 from sezeroz at gmail dot com 2009-04-13 11:55 ---
(In reply to comment #4)
> The fix may have broken cross compiling:
>
> http://gcc.gnu.org/ml/gcc/2009-03/msg00525.html
>
PR39503 has already been closed for some fime, so this one should be closed,
too.
--- Comment #4 from sezeroz at gmail dot com 2009-03-19 23:27 ---
Regarding that the former type was int instead of DWORD, my suggest would be
replacing DWORD by unsigned int, like:
--- gcc/gcc/libgcc2.c.orig
+++ gcc/gcc/libgcc2.c
@@ -2068,7 +2068,7 @@ getpagesize (void)
int
mprotect
--- Comment #5 from sezeroz at gmail dot com 2009-03-19 17:49 ---
The prototype for VirtualProtect() is known but the definition of DWORD is
not??
Hrmph. In any case, it should be fixed easily by changing DWORD into unsigned
int
which is what a DWORD is always defined as.
--
http
--- Comment #1 from sezeroz at gmail dot com 2009-03-08 01:51 ---
Created an attachment (id=17416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17416&action=view)
libiberty pid_t patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC host triplet: x86_64-pc-mingw32
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
--- Comment #4 from sezeroz at gmail dot com 2009-02-21 08:06 ---
Created an attachment (id=17337)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17337&action=view)
intptr_t type check patch for libiberty configure
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
--- Comment #3 from sezeroz at gmail dot com 2009-02-02 22:59 ---
(In reply to comment #2)
> You should put the new code in a #ifdef HAVE_STDINT and use the old code
> otherwise. Else, any platforms without stdint.h would not compile.
>
I would do that and it would be easy,
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:03 ---
Created an attachment (id=17225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17225&action=view)
DO_GLOBAL_CTORS_BODY win64 uintptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:00 ---
Created an attachment (id=17224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17224&action=view)
libiberty hashtab.c intptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC target triplet: x86_64-pc-mingw32
http://gcc.g
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:57 ---
Created an attachment (id=17223)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17223&action=view)
libiberty md5.h win64 patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
needs uintptr_t
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sezeroz at gmail dot com
GCC target triplet: x86_64-pc
1 - 100 of 105 matches
Mail list logo
