If the constructor of a class does not match the class name, the compiler dies
with a segfault.
I'll attach an example program.
running
> g++ test.cc
test.cc:6: internal compiler error: Segmentation fault
will already trigger the bug.
The source code is not valid code, but with previous versio
This is from [1], ICE
Running target unix/-fstack-protector
FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (internal compiler error)
FAIL: gcc.c-torture/compile/limits-blockid.c -O0 (test for excess errors)
$cc1 -fstack-protector -O0 limits-blockid.c
q9_func
limits-blockid.c: In function
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
/* { dg-do compile } */
/* { dg-options "-O2" } */
/* { dg-options "-O2 -mtune=cell -mminimal-toc" { target { powerpc*-*-* && lp64
} } } */
struct A
{
char *a;
unsigned int b : 1;
unsigned int c : 31;
};
struct B
{
struct A *d;
};
void
foo (struct B *x, unsigned long y)
{
if (x->d[y].c
--- Comment #1 from christi at uni-hd dot de 2009-02-18 07:55 ---
Created an attachment (id=17319)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17319&action=view)
example to trigger the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39225
--- Comment #2 from ubizjak at gmail dot com 2009-02-18 07:15 ---
The commit you are referring to just hit the nail on the road and gets over
your memory threshold. The blockage insertion is enabled only for
-fno-omit-frame-pointer.
Even if we revert this patch (very unlikely, since it
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-18 06:45 ---
I think long double on w64 is the same as double. I am not sure if
gcc.dg/callabi/func-1.c is a valid test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39224
On Linux/x86-64, revision 144258 gave
FAIL: gcc.dg/callabi/func-1.c execution test
ABI attribute doesn't work with long double.
--
Summary: ABI attribute doesn't work with long double
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severit
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-18 06:20 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from hjl at gcc dot gnu dot org 2009-02-18 06:18 ---
Subject: Bug 38891
Author: hjl
Date: Wed Feb 18 06:17:52 2009
New Revision: 144258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144258
Log:
gcc/
2009-02-17 Xuepeng Guo
PR target/38891
* co
--- Comment #2 from regehr at cs dot utah dot edu 2009-02-18 04:59 ---
Created an attachment (id=17318)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17318&action=view)
asm displaying volatile bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
--- Comment #1 from regehr at cs dot utah dot edu 2009-02-18 04:58 ---
Created an attachment (id=17317)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17317&action=view)
failure-inducing C program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
This bug is seen using the avr-gcc that is built using the script that comes
with FemtoOS 0.88.
Compile the attached program like this:
avr-gcc -O -mmcu=atmega128 small.c -S
It can be seen that func_45() unconditionally loads from volatile g_54. That
is wrong, since in the C code the load is
--- Comment #22 from rakdver at gcc dot gnu dot org 2009-02-18 04:47
---
(In reply to comment #21)
> Subject: Re: loop number of iterations analysis not working
>
> > If the program terminates before i would wrap, then the number of
> > iterations was not MAXINT.
> > And since it can'
--- Comment #9 from hjl dot tools at gmail dot com 2009-02-18 04:40 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2009-02-18
04:11 ---
Subject: Re: loop number of iterations analysis not working
> If the program terminates before i would wrap, then the number of
> iterations was not MAXINT.
> And since it can't wrap, it is not infinite i
--- Comment #20 from dberlin at gcc dot gnu dot org 2009-02-18 02:54
---
Subject: Re: loop number of iterations analysis
not working
If the program terminates before i would wrap, then the number of
iterations was not MAXINT.
And since it can't wrap, it is not infinite in any
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-02-18
02:49 ---
Fixed in current gcc trunk.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
-
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38617
--- Comment #8 from hjl at gcc dot gnu dot org 2009-02-18 02:16 ---
Subject: Bug 39082
Author: hjl
Date: Wed Feb 18 02:16:03 2009
New Revision: 144257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144257
Log:
gcc/
2009-02-17 H.J. Lu
PR target/39082
* c.opt
--- Comment #19 from jason at gcc dot gnu dot org 2009-02-18 02:03 ---
I suppose it's a question of what "module" means.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39179
--- Comment #12 from hubicka at ucw dot cz 2009-02-18 01:42 ---
Subject: Re: LTO and -fwhole-program do not play along well
> I believe we should be set already. During LTO read, we execute
> ipa_passes, which runs all_small_ipa_passes. So,
> pass_ipa_function_and_variable_visibility
--- Comment #12 from jsm28 at gcc dot gnu dot org 2009-02-18 01:32 ---
GCC now properly gives errors for fixed-point in C++ and fixed-point in C
on targets that don't support it after Jakub's patch for bug 39059. So
there is no longer a C front-end bug here. That most targets don't sup
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-18 01:14 ---
For a long time glibc has used __builtin_huge_val in this definition which
avoids this problem. fixincludes has fixed the definitions from old
glibc to avoid this problem since:
2005-09-15 Joseph S. Myers
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-18 01:05 ---
This bug doesn't state the target used, but it looks like this was one of
the problems for targets not supporting fixed point that was fixed by
Jakub's patch for bug 39059; certainly the compiler now gives errors
witho
--- Comment #19 from rakdver at gcc dot gnu dot org 2009-02-18 00:50
---
> Smaller testcase:
>
> void bar();
> void foo(int i1)
> {
> int i;
>
> for (i=0; i<=i1; ++i)
> bar();
> }
What the # of iterations analysis does is the following:
-- the number of iterations is i1, unles
--- Comment #4 from jsm28 at gcc dot gnu dot org 2009-02-18 00:41 ---
Fixed for 4.4.0; not fixing on prior release branches because the fragility of
this area of error recovery means there's a risk of changing one ICE-on-invalid
to another which would be inappropriate there.
--
jsm28
--- Comment #3 from jsm28 at gcc dot gnu dot org 2009-02-18 00:38 ---
Subject: Bug 35447
Author: jsm28
Date: Wed Feb 18 00:38:28 2009
New Revision: 144256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144256
Log:
PR c/35447
* c-parser.c (c_parser_compound_statem
--- Comment #17 from danglin at gcc dot gnu dot org 2009-02-18 00:31
---
*** Bug 38441 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
--- Comment #1 from danglin at gcc dot gnu dot org 2009-02-18 00:31 ---
*** This bug has been marked as a duplicate of 34587 ***
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from danglin at gcc dot gnu dot org 2009-02-17 23:50
---
Fixed on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
--- Comment #15 from danglin at gcc dot gnu dot org 2009-02-17 23:43
---
Subject: Bug 34587
Author: danglin
Date: Tue Feb 17 23:42:44 2009
New Revision: 144251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144251
Log:
PR target/34587
* config/darwin.h (SUPPORTS
--- Comment #18 from jakub at gcc dot gnu dot org 2009-02-17 23:40 ---
/* True if EXP names an object for which name resolution must resolve
to the current module. */
If something uses it to find if it binds to current TU, then it is using it
incorrectly.
--
http://gcc.gnu.org/
--- Comment #12 from jakub at gcc dot gnu dot org 2009-02-17 23:37 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2009-02-17 23:21 ---
Subject: Bug 36922
Author: jakub
Date: Tue Feb 17 23:21:23 2009
New Revision: 144250
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144250
Log:
PR tree-optimization/36922
* tree-data-ref.c (in
--- Comment #17 from jason at gcc dot gnu dot org 2009-02-17 23:01 ---
I will note that the C++ front end has been setting TREE_STATIC and
DECL_EXTERNAL on the same variables for many, many years, so changing that
isn't going to be simple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #16 from jason at gcc dot gnu dot org 2009-02-17 22:56 ---
(In reply to comment #12)
> Well, certainly binds_local_p is used for exactly this semantic.
Perhaps I'm wrong then, and it does mean "binds to a definition in this
translation unit."
The default definition does che
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Summary|[4.4 Regression]|Preprocessor I
--- Comment #11 from dnovillo at gcc dot gnu dot org 2009-02-17 21:40
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00796.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
-
--- 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
--- 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 #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 #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
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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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
$ 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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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=.
--
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
--
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
--- 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
--- 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 #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 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 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 #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 #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
1 - 100 of 140 matches
Mail list logo
