[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-02 07:54 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-02 07:52 --- Subject: Bug 19031 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-02 07:52:31 Modified files: gcc: ChangeLog c-decl.c c-lang.c cgraph.c

[Bug tree-optimization/19224] Endless loop compiling simple file: Bug in tree-scalar-evolution.c (instantiate_parameters_1)?

--- Additional Comments From aj at gcc dot gnu dot org 2005-01-02 07:45 --- Created an attachment (id=7861) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7861&action=view) Preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19224

[Bug tree-optimization/19224] New: Endless loop compiling simple file: Bug in tree-scalar-evolution.c (instantiate_parameters_1)?

On one of my x86_64-linux systems with GCC CVS from 20041231, the testcase uses in a minute all available memory and therefore the process is killed. This happens not only on x86_64 but also on ia64 and ppc - it seems to work on i386. On my other x86_64-linux system with GCC CVS from 20050101

[Bug debug/19192] [4.0 Regression] Current development gcc generates incorrect line info for example code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 06:08 --- With TER: [t.c : 8] D.1144 = [t.c : 8] add2 (3, 4); [t.c : 13] printf (&"%d\n"[0], D.1144 + 2) [tail call]; [t.c : 14] return; Without: [t.c : 8] D.1144 = [t.c : 8] add2 (3, 4); [t.c : 8] D.1124 =

[Bug java/19110] Simple java program does not work properly

--- Additional Comments From amodra at bigpond dot net dot au 2005-01-02 04:28 --- This also works with current 3.4 branch. My guess is that somehow the wrong libgcj.so is being used. -v -Wl,-v,-t are useful in checking which objects are linked. Also LD_DEBUG=files ./hello to see whic

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-02 03:46 --- Subject: Bug 19221 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-02 03:46:22 Modified files: gcc: ChangeLog function.c Log message:

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 03:46 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/16792] [4.0 regression] ICE in gen_subprogram_die, at dwarf2out.c:11267

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 02:55 --- It was caused by this part of the patch: * name-lookup.c (pushdecl): When a local extern shadows a file-scope declaration of the same object, give both DECLs the same DECL_UID. the t

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From gschafer at zip dot com dot au 2005-01-02 02:41 --- Like I said, fairynuff. But users will definitely notice slower bootstraps, thus further contributing to the perceived feeling that GCC is forever getting slower. It will be a shame IMHO. If the extra ass

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 02:34 --- (In reply to comment #4) > Because it currently makes my bootstraps slow as molasses. Yes, stage 2 and 3 > are fine. But I thought released compilers were meant to have checking > switched > off completely.

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From gschafer at zip dot com dot au 2005-01-02 02:30 --- Because it currently makes my bootstraps slow as molasses. Yes, stage 2 and 3 are fine. But I thought released compilers were meant to have checking switched off completely. If you release the compiler like

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 02:23 --- Why do you say it is a bug, because stage2 and stage3 are not compiled with checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19223

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From gschafer at zip dot com dot au 2005-01-02 02:21 --- Fairynuff. As long as someone remembers to switch it off before release, because if not, it will then clearly be a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19223

[Bug bootstrap/19223] --disable-checking doesn't fully disable checking

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 02:16 --- No this is not a bug, this was done on purpose to catch some bugs which we were not catching before. -- What|Removed |Added -

[Bug bootstrap/19223] New: --disable-checking doesn't fully disable checking

During a `make bootstrap', I still get: gcc -c -pipe -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING during stage1 even though I configured with --disable-checking. This is because gcc/Makefile.in unconditionally does this: STAGE1_CHECKING = -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING Sure, bec

[Bug target/15059] [compilation abandoned] gnat bug detected.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 01:56 --- Invalid no feedback in 3 months (T -6 days). -- What|Removed |Added Status|WAITI

[Bug c++/16783] Accepts invalid integral constant expression for array size

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 01:32 --- Fixed in 4.0.0. -- What|Removed |Added Status|NEW |RESOL

[Bug rtl-optimization/13191] [64bit] Redundant sign extends

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 01:24 --- Hmm, this looks like it is fixed: L4: subf r0,r11,r10 addi r11,r11,1 extsw r0,r0 xor r2,r3,r0 xor r9,r9,r2 or r2,r2,r9 xor r2,r2,r0 xor r9,r9,r

[Bug c++/19199] [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary

--- Additional Comments From gdr at integrable-solutions dot net 2005-01-02 00:43 --- Subject: Re: [3.3/3.4/4.0 Regression] Wrong warning about returning a reference to a temporary "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | (In reply to comment #2) | > Why would t

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 00:37 --- On most targets we return the struct by slot address: g1 (&D.1575) [return slot addr]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19222

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 00:34 --- Here is the reduced testcase for -O0 (I assume -O2 is a related problem): struct locale { locale(const locale& __other) throw(); const locale& operator=(const locale& __other) throw(); }; void f1(const

[Bug rtl-optimization/12092] ICE: Floating point exception

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-02 00:19 --- Fixed in 4.0.0. -- What|Removed |Added Status|NEW |RESOL

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-02 00:16 --- It looks like imbue wants a const locale& as its argument (ios_base.h). getloc() returns locale. Probably, _M_getloc() should be used but this doesn't fix the ICE. -- http://gcc.gnu.org/bugzilla/show_b

[Bug rtl-optimization/12092] ICE: Floating point exception

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-02 00:15 --- Subject: Bug 12092 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-02 00:15:01 Modified files: gcc: ChangeLog loop.c gcc/testsui

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

--- Additional Comments From jh at suse dot cz 2005-01-02 00:14 --- Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64 > > --- Additional Comments From jh at suse dot cz 2005-01-01 23:52 --- > Subject: Re: [4.0 Regression] unrecognisable insn in regcla

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-01-02 00:11 --- Subject: Re: [4.0 Regression] ICE: in fold_convert, at fold-co > I get a different error at -O0: > /home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/include/complex:522: > internal compiler >

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

--- Additional Comments From andre dot maute at gmx dot de 2005-01-01 23:58 --- if i remove the architecture option from the configure parameters > g++-4.0-20041226-na -v Using built-in specs. Configured with: ../gcc-4.0-20041226/configure --prefix=/opt/gcc-4.0-20041226-na--enable-

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 23:53 --- I get a different error at -O0: /home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/include/complex:522: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101 -- http://gcc.gnu.org/b

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

--- Additional Comments From jh at suse dot cz 2005-01-01 23:52 --- Subject: Re: [4.0 Regression] unrecognisable insn in regclass on x86/amd64 > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 > 22:33 --- > (In reply to comment #21) > > This is the or

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 23:44 --- Patch posted here: . Mine. -- What|Removed |Added --

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-01 23:38 --- Created an attachment (id=7860) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7860&action=view) Preproccessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19222

[Bug c++/19222] [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 23:29 --- Can you attach the preprocessed source? -- What|Removed |Added CC|

[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

--- Additional Comments From jh at suse dot cz 2005-01-01 23:27 --- Subject: Re: [4.0 Regression] #pragma weak handling changes in 4.0.0 > > --- Additional Comments From rth at gcc dot gnu dot org 2004-12-31 23:30 > --- > I think that this sort of thing *ought* to work. How,

[Bug c++/19222] New: [4.0 Regression] ICE: in fold_convert, at fold-const.c:1980

And now the next problem. /home/dave/gnu/gcc-4.0/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gnu/gcc-4.0/o bjdir/gcc/ -nostdinc++ -L/home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/s rc -L/home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/src/.libs -B/home/dav e/opt/gnu/vax-ultrix/bin/ -B/

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-01-01 23:15 --- Subject: Re: [4.0 Regression] ICE: rtl_verify_flow_info > - emit_insn_after (seq, get_insns ()); > + emit_insn_after (seq, entry_of_function ()); That looks better. Dave -- http://

[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 23:05 --- I will note for the record that disabling local-alloc will resolve this problem. A patch for that is in the audit trail of another bug, for unrelated reasons: http://gcc.gnu.org/PR13776. It also happens

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 23:02 --- Like so: Index: function.c === RCS file: /cvs/gcc/gcc/gcc/function.c,v retrieving revision 1.597 diff -u -p -r1.597 function.c --- function.c

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 22:58 --- The correct fix would be to use entry_of_function instead. -- What|Removed |Added

[Bug middle-end/19221] [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-01 22:52 --- Created an attachment (id=7859) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7859&action=view) Possible fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19221

[Bug middle-end/19221] New: [4.0 Regression] ICE: rtl_verify_flow_info, at cfgrtl.c:2240

/home/dave/gnu/gcc-4.0/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gnu/gcc-4.0/o bjdir/gcc/ -nostdinc++ -L/home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/s rc -L/home/dave/gnu/gcc-4.0/objdir/vax-ultrix/libstdc++-v3/src/.libs -B/home/dav e/opt/gnu/vax-ultrix/bin/ -B/home/dave/opt/gnu/vax-ultri

[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 22:50 --- You've just constrained the compiler too much to do anything. You're right that gcc should produce fewer loads and stores sometimes, but in this case I suggest you show that this actually hurts you still w

Re: Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

Kaveh R. Ghazi wrote: There's also a 3.4/4.0 failure listed here: http://gcc.gnu.org/ml/gcc/2005-01/msg00034.html Any thoughts on {char,wchar_t}/13189.cc ? Yes, I'm working on it: something is messed up wrt the includes necessary when _GLIBCXX_USE___ENC_TRAITS: in normal builds you don't notice

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-01 22:40 --- GCC generates movdqa instruction which is not in sse set. -- What|Removed |Added

[Bug ada/19220] Return-by-reference type wrongly considered return-by-copy

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 22:39 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 22:33 --- (In reply to comment #21) > This is the original thread which leads to this regession: > > http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839 If you notice this works on all other targets other than x86/

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

--- Additional Comments From hjl at lucon dot org 2005-01-01 22:21 --- This is the original thread which leads to this regession: http://gcc.gnu.org/ml/gcc/2004-11/threads.html#00839 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18910

[Bug target/18910] [4.0 Regression] unrecognisable insn in regclass on x86/amd64

--- Additional Comments From hjl at lucon dot org 2005-01-01 22:16 --- I believe that the regression is caused by http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01166.html -- What|Removed |Added --

[Bug ada/19220] New: Return-by-reference type wrongly considered return-by-copy (regression)

gcc from current CVS, and also at the pre-ssa tag, both generate wrong code for the following example (a version of the Rosen trick). The basic problem seems to be that A_Type is returned by copy even though it is a return-by-reference type (it has a component, R, which is a return-by-reference

[Bug libfortran/18982] open(status="new") does not generate an error if the file exists

--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-01 22:07 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00024.html -- What|Removed |Added --

[Bug fortran/19168] Mismatched KINDs in SELECT CASE constucts is not handled correctly

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2005-01-01 21:57 --- There is a patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00023.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19168

Re: Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

> I'm trying to help for the libstdc++-v3 failure: Great, thanks! > > can you confirm that, in order to reproduce, I should just add > -fpic/-fPIC to the CXXFLAGS? Yup. There's also a 3.4/4.0 failure listed here: http://gcc.gnu.org/ml/gcc/2005-01/msg00034.html Any thoughts on {char,wchar_

[Bug ada/19219] ICE on legal (?) code: deriving from tagged type with unknown discriminants

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 21:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug ada/19219] New: ICE on legal (?) code: deriving from tagged type with unknown discriminants

> gcc -c q.ads +===GNAT BUG DETECTED==+ | 4.0.0 20041231 (experimental) (i686-pc-linux-gnu) Assert_Failure sem_ch3.adb:10509| | Error detected at q.ads:5:4 | | Please submit a bug report; see http:

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 21:15 --- Does this testcase works: void abort (void); int main1 (void) { int s[4], t[4], i; s[0] = s[1] = s[2] = s[3] = 1; for (i = 0; i < 4; i++) t[i] = s[i]; if (!t [0]) abort (); return 0; }

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-01 21:06 --- // reduced testcase, use "-O1 -ftree-vectorize" void abort (void); int main () { int s[4], t[4], i; s[0] = s[1] = s[2] = s[3] = 1; for (i = 0; i < 4; i++) t[i] = s[i]; if (!t

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

-- What|Removed |Added Attachment #7797 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

-- What|Removed |Added Attachment #7796 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107

[Bug tree-optimization/19107] regclass.c miscompiled by -ftree-vectorize

-- What|Removed |Added Attachment #7795 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19107

Re: Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

Hi Kaveh, Finally, here are the excess -fpic/-fPIC testsuite failures from mainline on i686-pc-linux-gnu as noted here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00027.html I'd like some assistance categorizing them please. I'm trying to help for the libstdc++-v3 failure: can you confirm

[Bug java/16839] Final vars in switch generate compile error in anonymous class.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 20:17 --- (In reply to comment #2) > Subject: RE: Final vars in switch generate compile error in anonymous cl > > This email makes absolutely no sense. What information is this message > trying to tell me? Does a

[Bug java/16839] Final vars in switch generate compile error in anonymous class.

--- Additional Comments From beandz at hotmail dot com 2005-01-01 20:11 --- Subject: RE: Final vars in switch generate compile error in anonymous cl This email makes absolutely no sense. What information is this message trying to tell me? Does anyone even know the difference between

Re: Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

On Jan 1, 2005, at 2:54 PM, Kaveh R. Ghazi wrote: FAIL: gcc.dg/tree-ssa/ssa-dce-2.c scan-tree-dump-times if 0 (New testcase.) This is expected as the function might be overridden in a different TU (yes this is a weird case but it can happen). Thanks, Andrew Pinski

Extra 4.0 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

Finally, here are the excess -fpic/-fPIC testsuite failures from mainline on i686-pc-linux-gnu as noted here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00027.html I'd like some assistance categorizing them please. A. Fixable in the testcase. B. Expected failures, use dg-skip-if or equiv. C

[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

--- Additional Comments From michaelni at gmx dot at 2005-01-01 18:57 --- (In reply to comment #12) > Why do people write inline-asm like this? why not? its valid code and a compiler should compile valid code ... > It is crazy to do so. Split up the inline-asm correctly. fix gcc fir

[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 17:22 --- Why do people write inline-asm like this? It is crazy to do so. Split up the inline-asm correctly. Anyone who writes like inline-asm should get what they get. For mmx inline-asm, you should be using the int

[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3

--- Additional Comments From stian at nixia dot no 2005-01-01 17:15 --- Reference to other bug-reports: http://bugs.gentoo.org/show_bug.cgi?id=71360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203

Extra 3.4 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

Here are the excess -fpic/-fPIC testsuite failures from 3.4.x on i686-pc-linux-gnu as noted here: http://gcc.gnu.org/ml/gcc-testresults/2005-01/msg00028.html I'd like some assistance categorizing them please. A. Fixable in the testcase. B. Expected failures, use dg-skip-if or equiv. C. Real bugs

Extra 3.3 -fpic/-fPIC testsuite failures on i686-unknown-linux-gnu

I've been running testsuites on i686-pc-linux-gnu with -fpic/-fPIC passes and have been getting some extra failures. Some of them involve inline asm, which I'm not familiar with. I'd like to solicit some feedback on which ones are: A. Fixable in the testcase. B. Expected failures, use dg-skip-if

[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 16:28 --- Yup, -march=i686 does the trick for me: $ ./cc1plus t.C -O -m32 -march=i686 A::A() A::A() A::A() B::B(const A&) B::B(const A&) B::B(const A&) void __static_initialization_and_destruction_0(in

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-01-01 16:28 --- Subject: Re: [4.0 Regression] Tree loop optimiza > Patch here: . Fixes the testsuite failure on hppa2.0w-hp-hpux11.11. No regressions seen

[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 16:26 --- . -- What|Removed |Added Status|ASSIGNED|RESOLVED R

[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-01 16:15 --- Subject: Bug 17544 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-01 16:15:24 Modified files: gcc: ChangeLog c-decl.c emit-rtl.c tree-cf

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 15:44 --- You can see the problem with this testcase (but we don't ICE because we only call verify_stmts in IV- OPTS :( ): void flexto(int *current,int instance_count) { int *end, temp, j; if (0http://gcc.gnu.org

[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 15:31 --- I think the problem is that we don't see the the address taken at all because we don't walk over the PHI nodes in compute_points_to_and_addr_escape so when we have dead code in PHIs we miss them. Note thi

[Bug c/19218] internal error with __attribute__ ((alias(xx))

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-01 13:19 --- It's a problem in the code itself: aliased functions must be defined in the file where they are aliased. The GNU assembler is more tolerant, but not other assemblers like Sun's. -- What|

[Bug c/19218] New: internal error with __attribute__ ((alias(xx))

I was trying to compile PHP 5.1 on Solaris 9 and I get this error: gcc -IZend/ -I/home/leic/ncpl/php-src/Zend/ -DPHP_ATOM_INC - I/home/leic/ncpl/php-src/include -I/home/leic/ncpl/php-src/main - I/home/leic/ncpl/php-src -I/home/leic/ncpl/php-src/Zend - D_POSIX_PTHREAD_SEMANTICS -I/home/leic/ncpl/p

[Bug libfortran/19213] CVS source broken on Solaris

--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-01 12:28 --- No problem as of 2005-01-01, 04:00 MET, with nothing changed in the scripts. Probably a temporary problem on my side. Sorry! PS: marked bug as resolved - WORKSFORME, I hope it was the right thing to do

[Bug libfortran/19213] CVS source broken on Solaris

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-01 12:23 --- No problem as of today on SPARC/Solaris 2.5.1, 2.6, 7, 8 and 9. Very likely a problem on your side. -- What|Removed |Added ---

[Bug c++/19184] Octave compilation is failing during running "make"

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-01 12:17 --- Andrew certainly meant "try 3.4.3" since the first thing we would ask you if you reported a bug against 3.4.1 would be to try 3.4.3. :-) -- What|Removed |Added ---

[Bug debug/17924] [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails

--- Additional Comments From jason at redhat dot com 2005-01-01 12:16 --- Subject: Re: [4.0 Regression] gcc.dg/debug/dwarf2/dwarf-die7.c fails On 31 Dec 2004 22:46:37 -, "dberlin at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote: > When we inline a C++ constructor that isn't goi

[Bug ada/19183] GNAT -fPIC Bug

-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/

[Bug libfortran/15235] libgfortran doesn't build on Solaris

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-01 12:14 --- Libgfortran builds on SPARC/Solaris 2.5.1, 2.6, 7, 8 and 9 as of today. I have no info for Solaris 10 yet. -- What|Removed |Added

[Bug libstdc++/18970] 3.4 default memory allocator much slower than 3.3 allocator when large amounts of data are turned over

--- Additional Comments From pcarlini at suse dot de 2005-01-01 11:09 --- > Yes, although you might want to revert to the 3.3 default allocator, as > the 3.4 default allocator is considerably slower for large programs. The default 3.4 ""allocator"", actually just forwards to new/delete

[Bug c++/17154] [4.0 Regression] Using declaration of function name ignored inside partial specialization of template class

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-01 10:08 --- Got it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lerdsuwa at

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

--- Additional Comments From aj at gcc dot gnu dot org 2005-01-01 09:49 --- I see the following new failures on Linux/x86-64 since Ira's patch went in: gcc.dg/tree-ssa/ifc-20040816-1.c (test for excess errors) gcc.dg/vect/pr18400.c (test for excess errors) gcc.dg/vect/pr1840