http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #11 from I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #117 from Markus Trippelsdorf
2011-10-11 07:39:43 UTC ---
"-flto=4 -fno-fat-lto-objects -fprofile-use -fprofile-correction" breaks
at js/src/xpconnect/src/dombindings.cpp:
...
In file included from
/var/tmp/mozilla-central/js/src/xp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
--- Comment #11 from Nick Clifton 2011-10-11
07:49:11 UTC ---
Author: nickc
Date: Tue Oct 11 07:49:04 2011
New Revision: 179787
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179787
Log:
PR middle-end/49801
* compare-elim.c (find_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #2 from Richard Guenther 2011-10-11
08:58:45 UTC ---
And provide a prototype of strtof/strtod that does not return int.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #8 from Richard Guenther 2011-10-11
09:05:54 UTC ---
(In reply to comment #6)
> I saw the note that PR/49911 is fixed and thought that might mean this one is
> fixed also. Unfortunately testing shows that is not the case, at least no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50608
Mikael Pettersson changed:
What|Removed |Added
CC||ebotcazou at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #9 from Richard Guenther 2011-10-11
09:09:21 UTC ---
(In reply to comment #7)
> Re comment 5, does "works by luck" mean that I should not look in trunk for a
> fix to backport because nothing was actually fixed?
The bug is quite hard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #3 from Andreas Schwab 2011-10-11 09:11:11
UTC ---
That won't help anyway since ",+1.0E-06," does not start with a valid
floating point number and will always be parsed as 0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687
Lassi Tuura changed:
What|Removed |Added
CC||lat at cern dot ch
--- Comment #1 from Lass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50608
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687
Giulio Eulisse changed:
What|Removed |Added
Severity|blocker |normal
--- Comment #2 from Giulio Euliss
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687
Paolo Carlini changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
--- Comment #4 from Tobias Burnus 2011-10-11
09:59:22 UTC ---
Author: burnus
Date: Tue Oct 11 09:59:18 2011
New Revision: 179794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179794
Log:
2011-10-11 Tobias Burnus
PR fortran/502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713
Paulo J. Matos changed:
What|Removed |Added
CC||Paulo.Matos at csr dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713
--- Comment #5 from Paolo Carlini 2011-10-11
10:40:33 UTC ---
As the home page says, 4.4.x is the oldest maintained branch..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
--- Comment #20 from paolo at gcc dot gnu.org
2011-10-11 10:57:45 UTC ---
Author: paolo
Date: Tue Oct 11 10:57:40 2011
New Revision: 179797
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179797
Log:
2011-10-11 Paolo Carlini
PR c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #8 from Richard Guenther 2011-10-11
11:02:08 UTC ---
(In reply to comment #6)
> > 2011-10-07 Tom de Vries
> >
> > PR middle-end/50527
> > * tree.c (build_common_builtin_nodes): Add local_define_builtin for
> > * builti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33067
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #15 from Paolo Carlini 2011-10-11
11:05:02 UTC ---
Andreas, can I have your feedback about this? Is it safe or not to compare s390
pointers with memcmp?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50658
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz changed:
What|Removed |Added
CC||jojelino at gmail dot com
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50685
--- Comment #6 from Barry Matheney 2011-10-11
11:11:22 UTC ---
Thanks David for all of your insight and info. I will forward this info to our
sysadmins to further investigate this assembler issue.
(In reply to comment #5)
> AIX 5.3 TL10 (as wel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
Paolo Carlini changed:
What|Removed |Added
Version|4.6.1 |4.7.0
--- Comment #3 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
--- Comment #4 from Jakub Jelinek 2011-10-11
11:20:47 UTC ---
The reduced testcase yes. But please try the original testcase in 4.6, whether
your patch fixes it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #9 from Eric Botcazou 2011-10-11
11:20:41 UTC ---
> It would be nice to know whether this particular FAIL is the failure
> of some checking mechanism or a genuine wrong-code bug. I suppose
> it's the former, and for -fstack-check we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
--- Comment #5 from Paolo Carlini 2011-10-11
11:35:42 UTC ---
I see. It does, anyway.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
--- Comment #6 from Paolo Carlini 2011-10-11
11:40:38 UTC ---
I mean, fixes the ICE both in mainline and in 4_6-branch. Indeed, the latter
seems more serious, because otherwise for the original testcase we produce no
useful diagnostics at all.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #16 from Andreas Krebbel 2011-10-11
11:41:12 UTC ---
(In reply to comment #15)
> Andreas, can I have your feedback about this? Is it safe or not to compare
> s390
> pointers with memcmp?
On s390 with 31 bit addressing the uppermost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40713
--- Comment #6 from Paulo J. Matos 2011-10-11
11:48:08 UTC ---
(In reply to comment #5)
> As the home page says, 4.4.x is the oldest maintained branch..
Right! Sorry for the noise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204
--- Comment #10 from Richard Guenther 2011-10-11
11:57:28 UTC ---
Author: rguenth
Date: Tue Oct 11 11:57:23 2011
New Revision: 179799
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179799
Log:
2011-10-11 Richard Guenther
PR tree-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50687
--- Comment #4 from Lassi Tuura 2011-10-11 12:00:47 UTC ---
Right, as far as I can tell at the moment visibility option is somewhat
peripheral to the issue. The main difference you see with LTO vs. no LTO
appears to be whether code for the type is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
--- Comment #9 from dave.anglin at bell dot net 2011-10-11 12:06:25 UTC ---
On 10-Oct-11, at 5:45 PM, paolo.carlini at oracle dot com wrote:
> I honestly don't understand how such a warning would look like: like
> warning
> for any snippet of co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
CC|bernds at codesourcery dot |
|com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #118 from Markus Trippelsdorf
2011-10-11 12:18:21 UTC ---
Probably a Mozilla bug. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=693563
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #4 from Marc Glisse 2011-10-11
12:24:18 UTC ---
And anyway 10^-6 is not representable exactly as a double.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
--- Comment #5 from Tobias Burnus 2011-10-11
12:33:26 UTC ---
Author: burnus
Date: Tue Oct 11 12:33:22 2011
New Revision: 179800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179800
Log:
2011-10-11 Tobias Burnus
PR fortran/502
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50273
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #20 from paolo at gcc dot gnu.org
2011-10-11 12:39:23 UTC ---
Author: paolo
Date: Tue Oct 11 12:39:18 2011
New Revision: 179801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179801
Log:
2011-10-11 Emil Wojak
PR c++/50
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
--- Comment #10 from Jason Merrill 2011-10-11
13:08:19 UTC ---
Namespace-scope objects aren't the problem; we've always handled them fine.
The problem is with function-local statics, which aren't constructed until the
function is called, so we c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
--- Comment #8 from paolo at gcc dot gnu.org
2011-10-11 13:08:09 UTC ---
Author: paolo
Date: Tue Oct 11 13:08:05 2011
New Revision: 179803
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179803
Log:
2011-10-11 Paolo Carlini
PR c++/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
--- Comment #7 from paolo at gcc dot gnu.org
2011-10-11 13:07:55 UTC ---
Author: paolo
Date: Tue Oct 11 13:07:52 2011
New Revision: 179802
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179802
Log:
2011-10-11 Paolo Carlini
PR c++/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50611
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50074
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #12 from David Edelsohn 2011-10-11
14:06:34 UTC ---
Because the vectorizer analysis occurs fairly early, I guess there is not a lot
of opportunity to clean up the control flow.
Should GCC have a memset peephole pass like LLVM?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #13 from Richard Guenther 2011-10-11
14:13:11 UTC ---
(In reply to comment #12)
> Because the vectorizer analysis occurs fairly early, I guess there is not a
> lot
> of opportunity to clean up the control flow.
>
> Should GCC have a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #14 from Paolo Carlini 2011-10-11
14:14:24 UTC ---
A memcmp too?!? (see also the discussion part of libstdc++/50661).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
--- Comment #11 from dave.anglin at bell dot net 2011-10-11 14:18:52 UTC ---
On 10/11/2011 9:08 AM, jason at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
>
> --- Comment #10 from Jason Merrill 2011-10-11
> 13:08:19 U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #15 from Richard Guenther 2011-10-11
14:34:47 UTC ---
Note that it doesn't handle memset though, and the convoluted loop wouldn't be
easy to detect either.
size_t i = 0;
bool loop_cond = i < n;
while (loop_cond) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #16 from Richard Guenther 2011-10-11
14:35:17 UTC ---
(In reply to comment #14)
> A memcmp too?!? (see also the discussion part of libstdc++/50661).
No, only memset with zero.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27692
--- Comment #12 from Jason Merrill 2011-10-11
14:38:42 UTC ---
(In reply to comment #11)
> what I'm suggesting is building the list of destructors dynamically for
> executables and shared libraries.
That sounds a lot like __cxa_atexit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #17 from David Edelsohn 2011-10-11
14:40:09 UTC ---
LLVM appears to be able to recognize memset of any value, not just zero. And
apparently performs control flow simplification before attempting to recognize
the idiom, so it can expo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
Richard Guenther changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #19 from Richard Guenther 2011-10-11
14:45:22 UTC ---
(In reply to comment #17)
> LLVM appears to be able to recognize memset of any value, not just zero. And
> apparently performs control flow simplification before attempting to rec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
vries at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |ada
--- Comment #10 from vries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #20 from Jakub Jelinek 2011-10-11
14:50:51 UTC ---
(In reply to comment #17)
> LLVM appears to be able to recognize memset of any value, not just zero. And
> apparently performs control flow simplification before attempting to recogn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50565
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965
--- Comment #12 from Eric Botcazou 2011-10-11
15:37:29 UTC ---
This is a fallout of the merge of the cond-optab branch in the 4.5 series.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50667
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #11 from Iain Sandoe 2011-10-11 15:57:05
UTC ---
Created attachment 25465
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25465
asm for c52104y
changing the number of args doesn't seem to fix the problem (off a stage3
bubble + re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #21 from Alex Gaynor 2011-10-11
16:02:56 UTC ---
Given the concern for preserving labels for debugging, perhaps allowing the
merging of basic blocks that eliminate labels could be conditional on either a
new function attribute or comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #22 from vincenzo Innocente
2011-10-11 16:12:18 UTC ---
in reference to jakub comment #8
actually there was this patch proposing a "ivdep macro" (identical to INTEL's
one!) that never made to mainline
http://gcc.gnu.org/ml/gcc-patche
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39427
Tobias Burnus changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
--- Comment #16 from Peter Bergner 2011-10-11
16:59:09 UTC ---
Author: bergner
Date: Tue Oct 11 16:58:59 2011
New Revision: 179808
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179808
Log:
gcc/
PR c++/44473
* mangle.c (write_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
--- Comment #17 from Peter Bergner 2011-10-11
17:02:51 UTC ---
Author: bergner
Date: Tue Oct 11 17:02:42 2011
New Revision: 179809
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179809
Log:
gcc/
PR c++/44473
* mangle.c (write_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
--- Comment #18 from Peter Bergner 2011-10-11
17:17:49 UTC ---
Author: bergner
Date: Tue Oct 11 17:17:43 2011
New Revision: 179810
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179810
Log:
gcc/
PR c++/44473
* mangle.c (write_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
--- Comment #19 from Peter Bergner 2011-10-11
17:24:39 UTC ---
Author: bergner
Date: Tue Oct 11 17:24:27 2011
New Revision: 179811
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179811
Log:
gcc/
PR c++/44473
* mangle.c (write_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
Bug #: 50696
Summary: [x32] Unnecessary lea
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855
--- Comment #5 from Jason Merrill 2011-10-11
17:53:19 UTC ---
Author: jason
Date: Tue Oct 11 17:53:07 2011
New Revision: 179813
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179813
Log:
PR c++/49855
PR c++/49896
* cp-tree.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896
--- Comment #9 from Jason Merrill 2011-10-11
17:53:20 UTC ---
Author: jason
Date: Tue Oct 11 17:53:07 2011
New Revision: 179813
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179813
Log:
PR c++/49855
PR c++/49896
* cp-tree.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696
--- Comment #1 from H.J. Lu 2011-10-11 17:59:50
UTC ---
It is generated by expand_compound_operation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690
--- Comment #1 from tkoenig at netcologne dot de
2011-10-11 18:03:56 UTC ---
To me, the right strategy appears to be to mark the temporary
variable as threadprivate if we are within an OMP block.
Does this sound right?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896
--- Comment #10 from Jason Merrill 2011-10-11
18:18:35 UTC ---
Author: jason
Date: Tue Oct 11 18:18:25 2011
New Revision: 179815
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179815
Log:
PR c++/49855
PR c++/49896
* call.c (pe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855
--- Comment #6 from Jason Merrill 2011-10-11
18:18:35 UTC ---
Author: jason
Date: Tue Oct 11 18:18:25 2011
New Revision: 179815
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179815
Log:
PR c++/49855
PR c++/49896
* call.c (per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49855
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49896
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50447
--- Comment #5 from Georg-Johann Lay 2011-10-11
18:28:52 UTC ---
Author: gjl
Date: Tue Oct 11 18:28:49 2011
New Revision: 179816
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179816
Log:
PR target/50447
* config/avr/avr.md (cc):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216
Jason Merrill changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50458
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690
--- Comment #2 from Tobias Burnus 2011-10-11
18:34:01 UTC ---
(In reply to comment #1)
> To me, the right strategy appears to be to mark the temporary
> variable as threadprivate if we are within an OMP block.
To me it sounds like the right solu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216
Jason Merrill changed:
What|Removed |Added
CC||z0sh at sogetthis dot com
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #12 from Iain Sandoe 2011-10-11 18:45:39
UTC ---
Created attachment 25466
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25466
test of -fstack-check
a simple test program for Darwin ..
.. AFAICT this DTRT under 'c' on {powerpc,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #23 from pcarlini at gmail dot com 2011-10-11 19:01:02 UTC ---
>
> that never made to mainline
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01560.html
> what about it?
Eh, bisognerebbe ricostruire, ma mi sa che รจ stato proprio nel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #10 from Paul Koning 2011-10-11
19:03:24 UTC ---
Created attachment 25467
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25467
Tentative patch against 4.6.1
I chased the issue for a while, using 4.6.1 as the test version.
The p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #5 from rickyrockrat 2011-10-11
19:05:28 UTC ---
>+1.0E-06," does not start with a valid
>floating point number and will always be parsed as 0.
I don't know what 'always will be', nor who exactly is doing the parsing, but
strtof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
rickyrockrat changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50661
--- Comment #24 from Paolo Carlini 2011-10-11
19:10:12 UTC ---
:) Sorry about the italian chattering between me and Vincenzo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690
Thomas Koenig changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #7 from rickyrockrat 2011-10-11
19:25:10 UTC ---
I removed the ','at the beginning of the string (which was not there in the
original test case), and I now get
Bug!!4.074850E+05
In any case, it should return 0, if +1.xxE-6 is an inv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #8 from rickyrockrat 2011-10-11
19:33:47 UTC ---
Created attachment 25469
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25469
stdlib.h
Tar for string.h, stdlib.h, and stdio.h on the system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933
schaiba at gmail dot com changed:
What|Removed |Added
CC||schaiba at gmail dot com
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #9 from rickyrockrat 2011-10-11
19:38:51 UTC ---
One further note, with stdio.h, string.h and using strtod, I get the correct
answer suggested by Andreas Schwab:
Bug!!0.00E+00
If I put stdio.h, string.h, and stdlib.h, I get
Nobug
1 - 100 of 122 matches
Mail list logo
