--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-17 08:08 ---
In
lhs.var = collapse_rest_of_var (lhs.var);
rhs.var = collapse_rest_of_var (rhs.var);
rhs.var points into the middle of lhs.var chain, so the first call sets
collapsed_to to lhs.var and the
--- Comment #20 from Joey dot ye at intel dot com 2009-02-17 09:18 ---
(In reply to comment #19)
> Just for the record, here is an unsuccessful attempt to avoid stack
> realignment
> just because of DImode for -m32 or because of DFmode at -m32 -Os. This patch
> unfortunately caused a h
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-17 09:29 ---
Unless you consider that option being -mpreferred-stack-boundary=2. By default
stack boundary is bigger and so DImode is aligned naturally, it is only when
you want very compat code that you use this option.
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-17 10:41 ---
This warning is only emitted if points-to analysis pruned the points-to set
to empty. Thus, the pointer as far as PTA is concerned does not point to
anything. On alias-improvements branch this results in stores and
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-17 10:42 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-17 10:53
---
Thanks Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39207
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-17 10:59 ---
Ok, that was easy. I thought I had fixed that already... what happens is
that we warn if we pruned the points-to set to { NULL } as well (I have a
patch for emitting 'dereferencing NULL pointer', but that triggers
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-17 11:04 ---
This is perfectly valid C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39205
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-17 11:09 ---
Try newer GCC or disable address-space randomization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-17 11:14 ---
This is how the ABI works and virtual inheritance is implemented. The lowest
bit is used as a discriminator, so at least 16bit alignment is required.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-17 11:06
---
Yeah...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-17 11:17 ---
Looks like a dup of PR36439.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39210
--- Comment #3 from pgrealis at yahoo-inc dot com 2009-02-17 11:20 ---
(In reply to comment #1)
> This is perfectly valid C++.
I never claimed anything different. Is your argument that no warning should be
issued for "perfectly valid C++"?
"(int)1.5" is perfectly valid C++, yet -Wold-
--- Comment #3 from james at jamesmolloy dot co dot uk 2009-02-17 11:28
---
Resolved. Thanks to both of you - pointing me at the other bug report made me
realise I wasn't aligning properly, and the second comment confirmed it.
The ELF loader wasn't handling section alignment constraint
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-17 11:29 ---
Reducing on the a-i branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-17 11:32
---
Refute? This is not philosophy. If the maintainers believe there is nothing
wrong here - and other extremely high-quality C++ front-end agree, by the way -
the issue is closed.
--
paolo dot carlini at oracl
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-17 12:17 ---
Created an attachment (id=17309)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17309&action=view)
reduced testcase
More reduced testcase. Still sensitive to UID changes.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-17 13:02 ---
Fixed for 4.4.0 and 4.3.4. Not planning to work on a backport to 4.2 branch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-17 13:11 ---
The change that the UID variations cause is ordering of two PHI-nodes which
result in
Value numbers:
-line_37 = line_18
+line_18 = line_37
from
:
# line_23 = PHI
# line_32 = PHI
:
# line_37 = PHI
# li
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-17 13:00 ---
Subject: Bug 35446
Author: jsm28
Date: Tue Feb 17 13:00:40 2009
New Revision: 144227
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144227
Log:
PR c/35446
* c-parser.c (c_parser_braced_init): C
--- Comment #2 from jd at ts dot ray dot fi 2009-02-17 12:52 ---
ok. this solved the problem:
echo 0 > /proc/sys/kernel/randomize_va_space
--
jd at ts dot ray dot fi changed:
What|Removed |Added
---
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-17 13:23 ---
This happens to fix it:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 144226)
+++ tree-ssa-pre.c (working copy)
@@ -3537,7 +3537,10
--- Comment #2 from baldrick at gcc dot gnu dot org 2009-02-17 13:36
---
If I unsupress checks in System.Regexp.Compile.Create_Secondary_Table,
then I get
"raised CONSTRAINT_ERROR : s-regexp.adb:1161 index check failed"
here:
1160for Column in 0 .. Alphabet_Size loop
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-17 13:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-17 13:38
---
Subject: Bug 39207
Author: rguenth
Date: Tue Feb 17 13:38:06 2009
New Revision: 144228
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144228
Log:
2009-02-17 Richard Guenther
PR tree-optimizatio
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-17 13:39 ---
Unfortunately it doesn't, it seems to fix just the rh485708.3.3.3.3.3.i
testcase, but not the rh485708.i testcase, nor the original one. I'll attach
the full testcase soon.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-17 13:45 ---
Created an attachment (id=17310)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17310&action=view)
rh485708.orig.i
Original, unreduced, testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39204
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-17 13:47
---
Or rather
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 144227)
+++ tree-ssa-pre.c (working copy)
@@ -1704,7 +1704,7 @@ phi_transl
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-02-17 13:49
---
This one seems to fix it
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 144227)
+++ tree-ssa-pre.c (working copy)
@@ -1707,6 +1707,
--- Comment #7 from espindola at gcc dot gnu dot org 2009-02-17 14:26
---
Subject: Bug 39010
Author: espindola
Date: Tue Feb 17 14:25:46 2009
New Revision: 144231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144231
Log:
2009-02-16 Rafael Avila de Espindola
PR 3901
--- Comment #22 from hjl dot tools at gmail dot com 2009-02-17 14:52
---
-mpreferred-stack-boundary=2 can also be used to generate psABI
conforming code. I think we need a new option to align DImode
to 4 byte on stack if we want to change DImode alignment on stack.
--
http://gcc.g
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-02-17 14:54 ---
This is because we merged ggg.f1.fff and ggg.f2.ccc into a single non-pointer
field. In the end we should fix the structure copy constraint generation
more properly, but I have a patch that keeps collapse_rest_of_va
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-02-17 15:01
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-17 15:02
---
Subject: Bug 39204
Author: rguenth
Date: Tue Feb 17 15:01:40 2009
New Revision: 144233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144233
Log:
2009-02-17 Richard Guenther
PR tree-optimizatio
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-17 15:16 ---
looks obvious, I'll take care of it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-17 15:20 ---
Subject: Bug 39214
Author: rguenth
Date: Tue Feb 17 15:20:18 2009
New Revision: 144234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144234
Log:
2009-02-17 Richard Guenther
PR middle-end/39214
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-17 15:20 ---
Subject: Bug 39214
Author: rguenth
Date: Tue Feb 17 15:20:18 2009
New Revision: 144234
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144234
Log:
2009-02-17 Richard Guenther
PR middle-end/39214
I have an internal compiler error: Segmentation fault
with gcc trunk (rev. 144201).
In a huge example it occurs in line 440 of gcc/langhooks.c that
'block' is NULL, and that causes this SegFault in 'TREE_CODE (block)'.
Instead of shrinking this huge example down, I propose following
patch. Can s
--- Comment #23 from jakub at gcc dot gnu dot org 2009-02-17 15:25 ---
I guess I can live with a switch, the kernel folks will just need to add it.
Now, should that switch be about disabling all dynamic stack realignments, or
do that for DImode only, or decrease DImode alignment when on
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-17 15:40
---
(In reply to comment #23)
> I guess I can live with a switch, the kernel folks will just need to add it.
> Now, should that switch be about disabling all dynamic stack realignments, or
> do that for DImode only, or
--- Comment #5 from sebor at roguewave dot com 2009-02-17 15:48 ---
(In reply to comment #0)
> I can't think of a scenario where one would want to write x.f() over X::f()
> when f() is static. I'd like a warning for this so I can catch with -Werror.
FWIW, I've seen x.y when y is a stat
--- Comment #6 from paolo dot carlini at oracle dot com 2009-02-17 15:51
---
Thanks Martin ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39205
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-17 16:02 ---
Subject: Bug 39202
Author: rguenth
Date: Tue Feb 17 16:01:53 2009
New Revision: 144235
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144235
Log:
2009-02-17 Richard Guenther
PR tree-optimization/
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-17 16:02 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from kurt at garloff dot de 2009-02-17 16:09 ---
Some more info:
HEAD seems to be much faster here (10m30s).
The author uses -fno-tree-pre in gmic (which has a lot of the same code),
not sure whether it helps significantly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #7 from kurt at garloff dot de 2009-02-17 16:13 ---
And yes, this looks like a dup to PR36439 to me as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39210
--- Comment #1 from dnovillo at gcc dot gnu dot org 2009-02-17 16:15
---
I think the easiest way to handle this would be for the driver to disable
-fwhole-program when the IL is being generated. Otherwise, all the symbols are
privatized.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot
|dot org
This comment ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150#c1 ) says:
"How is this major, this is an enhancement to the build system.
i386-solaris is a multi arch target so it includes the x86_64
solaris target also."
Attempts to run the Testsuite in 'Multilib-Mode' on the Target
"i386-p
--- Comment #25 from hjl dot tools at gmail dot com 2009-02-17 17:29
---
Created an attachment (id=17311)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17311&action=view)
A patch to add a new -malign-long-long= option
Here is a patch to add a new option, -malign-long-long=.
--
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2009-02-17
17:36 ---
John,
Doesn't this also fix g++.dg/special/conpr-3.C as well? Are you planning to
submit this to gcc-patches so we can get it into gcc 4.4 before the branch?
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-17 17:38 ---
Created an attachment (id=17312)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17312&action=view)
gcc44-pr36922.patch
Patch that fixes this for me. I'm going to bootstrap/regtest it now.
--
http://gcc.gnu
--- Comment #2 from hubicka at ucw dot cz 2009-02-17 17:43 ---
Subject: Re: LTO and -fwhole-program do not play along well
Hi,
functions are brought local in function_and_variable_visibility that
needs to be scheduled after LTO is read in.
The pas computes externaly_visible flags that
--- Comment #3 from dnovillo at google dot com 2009-02-17 17:55 ---
Subject: Re: LTO and -fwhole-program do not play
along well
On Tue, Feb 17, 2009 at 12:43, hubicka at ucw dot cz
wrote:
>
>
> --- Comment #2 from hubicka at ucw dot cz 2009-02-17 17:43 ---
> Subject:
--- Comment #4 from hubicka at ucw dot cz 2009-02-17 18:01 ---
Subject: Re: LTO and -fwhole-program do not play along well
> > Hi,
> > functions are brought local in function_and_variable_visibility that
> > needs to be scheduled after LTO is read in.
> > The pas computes externaly_vis
--- Comment #5 from rguenther at suse dot de 2009-02-17 18:01 ---
Subject: Re: LTO and -fwhole-program do not
play along well
On Tue, 17 Feb 2009, dnovillo at google dot com wrote:
> > --- Comment #2 from hubicka at ucw dot cz 2009-02-17 17:43 ---
> > Subject: Re: LTO and -
--- Comment #6 from dnovillo at google dot com 2009-02-17 18:04 ---
Subject: Re: LTO and -fwhole-program do not play
along well
On Tue, Feb 17, 2009 at 13:02, rguenther at suse dot de
wrote:
> Well, of course. Just the idea that -flto can be used easily without
> too much m
--- Comment #7 from dnovillo at google dot com 2009-02-17 18:05 ---
Subject: Re: LTO and -fwhole-program do not play
along well
On Tue, Feb 17, 2009 at 13:01, hubicka at ucw dot cz
wrote:
> This is intended behaviour.
Agreed.
> -fwhole-program essentially hides everything
contrib/gcc_update doesn't touch generated files in lto-plugin.
As the result, autoconf/automake are needed for gcc build.
--
Summary: [LTO]: gcc_update doesn't touch generated files in lto-
plugin
Product: gcc
Version: lto
Status:
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-17 18:23 ---
Created an attachment (id=17313)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17313&action=view)
fix to get_symbol_constant_value (untested)
The bug is not in binds_local_p: binds_local_p returns true if the r
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-17 18:25 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00781.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from jason at gcc dot gnu dot org 2009-02-17 18:27 ---
Subject: Bug 38950
Author: jason
Date: Tue Feb 17 18:27:32 2009
New Revision: 144239
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144239
Log:
PR c++/38950
* pt.c (unify)[TEMPLATE_PARM_INDEX]:
--- Comment #7 from jason at gcc dot gnu dot org 2009-02-17 18:27 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from hjl dot tools at gmail dot com 2009-02-17 18:29
---
Will this also fix PR 35501?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #8 from hubicka at ucw dot cz 2009-02-17 18:34 ---
Subject: Re: LTO and -fwhole-program do not play along well
> > -fwhole-program essentially hides everything except for main and
> > functions/variables explicitly marked via attribute, so this is
> > exepcted. You need to
--- Comment #2 from hjl at gcc dot gnu dot org 2009-02-17 18:38 ---
Subject: Bug 39216
Author: hjl
Date: Tue Feb 17 18:38:29 2009
New Revision: 144241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144241
Log:
2009-02-17 H.J. Lu
PR lto/39216
* gcc_update: Adj
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-17 18:40
---
This may have caused bootstrap memory requirements for insn-recog to go up
significantly enough to cause
cc1: out of memory allocating 4064 bytes after a total of 660041728 bytes
make[3]: *** [insn-recog.o] Error
--- Comment #24 from hjl dot tools at gmail dot com 2009-02-17 18:45
---
(In reply to comment #23)
> This may have caused bootstrap memory requirements for insn-recog to go up
> significantly enough to cause
>
> cc1: out of memory allocating 4064 bytes after a total of 660041728 bytes
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-17 18:48
---
Well, certainly binds_local_p is used for exactly this semantic. Maybe
mis-used. A grep over the tree optimizers is in oder to check that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #13 from hjl dot tools at gmail dot com 2009-02-17 18:51
---
binds_local_p is very weak and fragile. See PR 35513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #9 from dnovillo at google dot com 2009-02-17 18:51 ---
Subject: Re: LTO and -fwhole-program do not play
along well
On Tue, Feb 17, 2009 at 13:34, hubicka at ucw dot cz
wrote:
> Essentially yes, but since we are restarting the pass queue from later
> time, won't
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-17 18:54 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-02-17 18:54
---
It won't "fix" PR35501, as if there is a DECL_INITIAL we do not care about
visibility or binding in that case in get_symbol_constant_value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
I'm testing some autoparallelization on my mactel running g++4.3.3 which I
downloaded from macports.
In every other run, I see my code hang, though I cannot find an error in gdb.
Through a long series of cout-debugging steps, have traced it to the beginning
of an omp loop. The code does not hang
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2009-02-17 18:56
---
TREE_STATIC && DECL_EXTERNAL doesn't make sense for a VAR_DECL as per tree.h:
/* In a VAR_DECL, nonzero means allocate static storage.
#define TREE_STATIC(NODE) ((NODE)->base.static_flag)
* In a VAR_DECL or FUN
$ cc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/gcc
Thread model: posix
gcc version 4.3.3 (GCC)
$ echo 'void f(void) { char buf[50]; g(buf); }' > 1.c
$ echo 'void f(void) { int buf[50]; g(buf); }' > 2.c
$ cc -fstack-protector -c 1.c # protects
$ cc -f
--- Comment #25 from rguenther at suse dot de 2009-02-17 19:00 ---
Subject: Re: [4.3/4.4 Regression] x86_64 red zone
violation
On Tue, 17 Feb 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #24 from hjl dot tools at gmail dot com 2009-02-17 18:45
> ---
> (In reply
--- Comment #6 from janis at gcc dot gnu dot org 2009-02-17 19:03 ---
The original testcase is from outside IBM and is probably run by many library
implementors. That doesn't necessarily mean that many implementations pass
this test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-17 19:08 ---
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Optimize-Options.html#index-fstack_002dprotector-764
Hmm:
Emit extra code to check for buffer overflows, such as stack smashing attacks.
This is done by adding a guard var
According to the documentation:
The deprecated attribute results in a warning if the type is used anywhere
in the source file.
The following test case shows that when applied to an enum definition the
attribute has no such effect (this is in contrast to applying the attribute
to a class de
--- Comment #13 from mrs at apple dot com 2009-02-17 19:18 ---
Ok to add that to darwin.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-17 19:20 ---
Would you mind providing preprocessed source for gcc?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-17
19:49 ---
Subject: Re: gcc.dg/initpri1.c fails on *-apple-darwin
> John,
> Doesn't this also fix g++.dg/special/conpr-3.C as well? Are you planning
> to
> submit this to gcc-patches so we can get it into gcc 4
--- Comment #26 from rguenther at suse dot de 2009-02-17 19:50 ---
Subject: Re: [4.3/4.4 Regression] x86_64 red zone
violation
On Tue, 17 Feb 2009, Richard Guenther wrote:
> On Tue, 17 Feb 2009, hjl dot tools at gmail dot com wrote:
>
> > --- Comment #24 from hjl dot tools at gm
According to the GCC manual -fprofile-generate is equivalent to:
-fprofile-arcs -fprofile-values -fvpt
Similarly -fprofile-use is equivalent to:
-fbranch-probabilities -fvpt -funroll-loops -fpeel-loops -ftracer
However if I use -fprofile-generate the .gcda/.gcno files are not generated in
t
--- Comment #1 from jeremy at jeremybennett dot com 2009-02-17 20:01
---
Created an attachment (id=17314)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17314&action=view)
This is the trivial demonstrator and script
Use this script as described in the original report to demonstrat
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-17 20:08 ---
cp_parser_enum_specifier ignores attributes unless they trailing
attributes. But GNU extensions:
GNU Extensions:
enum-key attributes[opt] identifier [opt] enum-base [opt]
{ enumerator-list [opt] }att
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-17 20:14 ---
~/.ccache.
That sounds like a bug with ccache and not with GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39220
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-17 20:23 ---
This is a ccache bug and not a GCC bug as it works correctly if gcc is not a
wrapper.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-17 20:29 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00790.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-17 20:48 ---
(In reply to comment #5)
> This looks target-dependent, isn't it?
It might be but the older RA was able to handle this better. Look at the patch
and the decision that follows.
--
http://gcc.gnu.org/bugzilla/sh
ACATS cxf3a01 fails on mipsel-linux where it is the only ACATS test to fail:
,.,. CXF3A01 ACATS 2.5 09-02-17 22:07:04
CXF3A01 Check that the Valid function from package
Ada.Text_IO.Editing returns False for strings that fail
to comply with the composition cons
--- Comment #18 from burnus at gcc dot gnu dot org 2009-02-17 20:58 ---
Created an attachment (id=17315)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17315&action=view)
Complex (A)TAN(H), (A)COSH, (A)SINH, without no-C99 fallback & w/o tests
"Implementation" of the run-time versi
--- Comment #4 from sebor at roguewave dot com 2009-02-17 21:00 ---
Thanks for looking into so quickly!
In addition to the missing warnings mentioned in the initial report I would
expect a warning for each of the references to e below (i.e., on lines 3, 9,
and 15), analogously to those
GNU C (GCC) version 4.4.0 20090217 (experimental) [trunk revision 144226]
(x86_64-suse-linux-gnu)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 4.2.3, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler
--- Comment #1 from aj at gcc dot gnu dot org 2009-02-17 21:10 ---
Created an attachment (id=17316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17316&action=view)
insn-recog.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39222
--- Comment #2 from jsm28 at gcc dot gnu dot org 2009-02-17 21:18 ---
Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-17 21:38 ---
Should attribute work on enum constants?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39219
--- Comment #10 from dnovillo at gcc dot gnu dot org 2009-02-17 21:38
---
Subject: Bug 39203
Author: dnovillo
Date: Tue Feb 17 21:38:05 2009
New Revision: 144248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144248
Log:
2009-02-17 Diego Novillo
PR 39203
* c
1 - 100 of 140 matches
Mail list logo
