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
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
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=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=edit
reduced C source exhibiting the issue
The attached C source emits bogus -Warray-bounds warni
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 ***
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 ***
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=edit
stderr output
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=edit
preprocessed source
Happens while compiling mikmod player source with -
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=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=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=edit
-freport-bug output from another ICE
Attached a -freport-bug output from another source ICE'ing at the same place
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=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 sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
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=61130
--- Comment #2 from Ozkan Sezer sezeroz at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61130
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54895
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50040
--- Comment #12 from Ozkan Sezer sezeroz at gmail dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50950
--- Comment #3 from Ozkan Sezer sezeroz at gmail dot com 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
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 sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
--- Comment #21 from Ozkan Sezer sezeroz at gmail dot com 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=47596
--- Comment #7 from Ozkan Sezer sezeroz at gmail dot com 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=47626
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47596
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45998
Ozkan Sezer sezeroz at gmail dot com changed:
What|Removed |Added
CC||sezeroz at gmail
--- 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-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 #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.0-1 of MinGW were
--- 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.3 does
--- 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 argument 2
--- 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 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 #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 #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.
Fails for me both on i686- and x86_64-linux.
What are the error
--- 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/compile/pr42705.c -O2
--- 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 SIGSEGV
--- 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
--- 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=gccview=revrev=153759
Log:
2009-10-30 H.J. Lu hongjiu...@intel.com
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 #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=18822action=view)
failing preprocessed source
--
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=18823action=view)
good preprocessed source
--
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=18824action=view)
failing asm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
--- 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=18825action=view)
good asm output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41751
--- 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
true
--- 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 #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 #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:
#65533;statbuf.st_mode#65533; may
be used uninitialized is spurious, but can you have a look?
Yes
--- 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 modified
--- 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. Didn't do
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 #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=18282action=view)
preprocessed source
(Preprocessed source. Exact command line was:
gcc45 -c -march=i586 -O2 -Wall -DNDEBUG -ffast-math
--- 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=18283action=view)
generated *s file
(generated *.s file)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40934
--- 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 #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/bugzilla
--- 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 #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
--- 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=detailaid=2830386group_id=2435atid=102435
Wrong project tracker. Please go to
https://sourceforge.net/tracker/?group_id=202880
--- 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 #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=18279action=view)
[ __attribute__((optimize(0))) difference ]
Hmm, __attribute__((optimize(0))) does seem to disable inlining
--- 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=18279action=view) [edit]
[ __attribute__((optimize(0))) difference ]
Hmm, __attribute__((optimize(0
--- 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 exes cross-compiled
--- 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);
}
that isn't going
--- 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 |Added
--- 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 #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 #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
: 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-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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 #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
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 #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=17416action=view)
libiberty pid_t patch
--
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=17337action=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, but then one
: P3
Component: other
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=39062
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:47 ---
Created an attachment (id=17221)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17221action=view)
libssp alloca patch for mingw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
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=39063
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
--- 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=17223action=view)
libiberty md5.h win64 patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
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.gnu.org/bugzilla
--- 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=17224action=view)
libiberty hashtab.c intptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
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:03 ---
Created an attachment (id=17225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17225action=view)
DO_GLOBAL_CTORS_BODY win64 uintptr_t fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
1 - 100 of 102 matches
Mail list logo
