[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-01-11 23:00 --- Created an attachment (id=7930) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7930&action=view) current mt_allocator include -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265

[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-01-11 23:01 --- Created an attachment (id=7931) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7931&action=view) current mt_allocator source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19265

[Bug libstdc++/19265] problem with _S_destroy_thread_key when using dynamic libraries

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-01-11 23:02 --- here. I'll make it really easy for you to check. I'm pretty sure this is fixed in the current code, but your analysis would be appreciated before we close this report. To move this newer version to the 3.4.x

[Bug ada/19386] New: ACATS c330001 fails at runtime on sparc-solaris,x86_64-linux

But it passes on x86-linux, ppc-linux/darwin, s390-linux. ,.,. C330001 ACATS 2.5 05-01-10 04:59:01 C330001 Check that a variable object of an indefinite type is properly initialized/constrained by an initial value assignment that is a) an aggregate, b) a funct

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

--- Additional Comments From joel at gcc dot gnu dot org 2005-01-11 23:19 --- Created an attachment (id=7932) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7932&action=view) test case This is the preprocessed output of newlib's e_atan2.c. I cut out the cpp directives and bzip'ed

[Bug fortran/19387] New: Fortran compiler tries to print HOST_WIDE_INT with %d format

In trans-common.c there are two calls to gfc_warning that pass a HOST_WIDE_INT variable and a %d format. The calls in question are in translate_common, where we call gfc_warning with the variable 'offset' and again with the variable 'common_segment->offset'. This will not work when HOST_WIDE_INT

[Bug target/18562] SSE constant vector initialization produces dead constant values on stack

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-11 23:58 --- Your first test case is fixed by the patch for PR13366. We now get .align 16 .LC0: .long 1067869798 .long 1067869798 .long 1067869798 .long 1067869798 ...

[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap

--- Additional Comments From joel at gcc dot gnu dot org 2005-01-12 00:03 --- (In reply to comment #7) > sparc/sol2.h seems to be used just for sparc*-*-solaris* (correct) > and sparc*-*-{elf,rtems}* (incorrectly). sparc*-*-linux* and > sparc*-*-{free,net,open}bsd* don't use sol2.h at a

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

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-12 00:06 --- Subject: Bug 17949 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-12 00:05:56 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c Lo

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

--- Additional Comments From rakdver at gcc dot gnu dot org 2005-01-12 00:07 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

-- Bug 19379 depends on bug 19307, which changed state. Bug 19307 Summary: [4.0 Regression] ICE with -msse2 -mno-80387 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307 What|Old Value |New Value --

[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 00:19 --- And it works with today's compiler too. As for the use of the 80387 move instructions, even with -mno-80387, this isn't a regression. At least 3.2 did this as well. One could argue that -msoft-float should im

[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 00:28 --- Well, you have a problem. What do you want the ABI for soft-float to be? As RTEMS is probably the only user of -msoft-float, you get to choose. Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want

[Bug fortran/19362] ICE in fold_convert, at fold-const.c:1998

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW

[Bug tree-optimization/18755] invariant/constant not recomputed when ADDR_EXPR changed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 01:14 --- The patch is here: by the way to find the places. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18755

[Bug fortran/19387] Fortran compiler tries to print HOST_WIDE_INT with %d format

-- What|Removed |Added GCC target triplet||ia64-hp-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19387

[Bug rtl-optimization/16669] ICE with union { long double l; }

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 01:46 --- Fixed on the mainline. I think by the sub register work which RTH did. -- What|Removed |Added ---

[Bug fortran/19294] intrinsic_transpose.f90 runtime crash

--- Additional Comments From phython at gcc dot gnu dot org 2005-01-12 01:58 --- This patch fixes the testcase on sparc-linux --- intrinsic_transpose.f90.old 2005-01-11 20:48:30.498247968 -0500 +++ intrinsic_transpose.f90 2005-01-11 20:45:38.026467664 -0500 @@ -2,7 +2,7 @@ program

[Bug fortran/19269] transpose(reshape(...)) of character array segfaults.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 02:03 --- This looks closely related to PR 19271. PR 19276 is the meta bug for char array problems. -- What|Removed |Added ---

[Bug fortran/19294] intrinsic_transpose.f90 runtime crash

--- Additional Comments From phython at gcc dot gnu dot org 2005-01-12 02:15 --- Here is some more filler. The main difference between the optimized dumps at -O1 is original: atmp.40.dtype = 546; atmp.40.dim[0].stride = 1; atmp.40.dim[0].lbound = 0; atmp.40.dim[0].ubound = 1;

[Bug ada/19388] New: [4.0 Regression] MAX_OFILE_ALIGNMENT on PA HP-UX

gcc -D_XOPEN_UNIX -D_XOPEN_SOURCE_EXTENDED -D_INCLUDE__STDC_A1_SOURCE -D_INCLUDE _XOPEN_SOURCE_500 -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -mdisable-inde xing-fno-common -DHAVE_CONFIG_H-I. -Iada -I../../

[Bug rtl-optimization/9085] Unable to find register to spill when optimizing

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-12 02:31 --- // C testcase, use '-O1 -mregparm=1 -fschedule-insns -march=i386': struct A { int j; }; void foo (struct A *p, int j) { p->j = j % 3; } Introduced by this change: Tue Oct 27 23:32:34 1998

[Bug ada/19388] [4.0 Regression] MAX_OFILE_ALIGNMENT on PA HP-UX

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 02:32 --- Hmm, I think pa abose of the macro really is the cause, maybe we should change the macro to dependent on the decl and then force the explicat use in the pa back-end so we don't run into this again? What

[Bug target/19250] minss/maxss SSE insn not generated for -mfpmath=sse

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW

[Bug target/19252] sub optimal use of fpu comparisons in SSE code

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED

[Bug target/19009] Loading of FP constants into FP reg via SSE reg

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW

[Bug ada/19388] [4.0 Regression] MAX_OFILE_ALIGNMENT on PA HP-UX

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-01-12 02:53 --- Subject: Re: [4.0 Regression] MAX_OFILE_ALIGNMENT on PA HP-UX > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 > 02:32 --- > Hmm, I think pa abose of the macro real

[Bug target/19389] New: Odd gpr mem load unrecognizable insn

The attached testcase gives /src/tmp/20021008-1.c: In function 'foo': /src/tmp/20021008-1.c:62: error: unrecognizable insn: (insn 47 17 48 0 (set (reg:DI 9 9 [ D.1156 ]) (mem:DI (plus:DI (reg:DI 3 3 [ buf ]) (const_int 1 [0x1])) [0 S8 A128])) -1 (nil) (nil)) /src/tmp/200

[Bug target/19389] Odd gpr mem load unrecognizable insn

--- Additional Comments From amodra at bigpond dot net dot au 2005-01-12 03:03 --- Created an attachment (id=7933) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7933&action=view) powerpc64 testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19389

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

-- What|Removed |Added Known to work||3.4.3 Summary|Odd gpr mem load|[4.0 Regression] Odd gpr mem |unrecogn

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 03:44 --- Confirmed. -- What|Removed |Added CC||pinskia at

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

--- Additional Comments From amodra at bigpond dot net dot au 2005-01-12 04:08 --- Testing a fix -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodr

[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2

--- Additional Comments From giovannibajo at libero dot it 2005-01-12 04:22 --- (In reply to comment #14) > I have managed to reduce one of the test sets, for CLS Drivers to a case of 3 > failures out of 108 tests. Looking at the test report I am able to > narrow down to three test dri

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

--- Additional Comments From amodra at bigpond dot net dot au 2005-01-12 05:03 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00632.html -- What|Removed |Added K

[Bug target/19389] [4.0 Regression] Odd gpr mem load unrecognizable insn

-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19389

[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 05:12 --- Hmm, I think this is a bad gcc extension: extern short int aa[][]; Note with -pedantic we warning about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19333

[Bug c/19390] New: Accepts invalid code (well I don't know if it is invalid or not but I think it should be)

I don't see why we just reject the following code: extern short int aa[][]; In Comeau's compiler, in both C89 and C99 mode, they reject it. Though we have to be care full not to reject: union incomplete (*foo)[4]; which is only undefined in C89 but it is invalid in C99 -- Summary: A

[Bug c/19390] Accepts invalid code (well I don't know if it is invalid or not but I think it should be)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 05:30 --- Just one more data point, ICC 8.0 in strict ANSI C99 mode will reject mode will reject it also. But will accept it in the default semi gcc like mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=193

[Bug c/19390] Accepts invalid code (well I don't know if it is invalid or not but I think it should be)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 05:36 --- Note Comeau rejects the incomplete union also in C89 mode but not in its relax mode for either C89 or C99 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19390

[Bug tree-optimization/19341] [4.0 Regression] DCE eliminating non-dead code

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 05:41 --- Not invalid. The asm is a pointer escape point. -- What|Removed |Added Last reconfirmed|-

[Bug tree-optimization/19341] [4.0 Regression] DCE eliminating non-dead code

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-12 05:41 --- . -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Re

[Bug target/19315] variable is not emitted in the asm

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 05:43 --- -pedantic rejects the code. This looks like another undocumened extension and how it works too. Reading the comment in c-decl.c says this is how it should work but this is just plainly stupid: /*

[Bug driver/19353] Faulty handling of startfile_prefix_spec

--- Additional Comments From gschafer at zip dot com dot au 2005-01-12 05:46 --- (In reply to comment #1) > Hmm, this SPEC should be removed from the mainline, it is unused in GCC at > all. Ok, good. I suppose removing faulty code is better then leaving it there for folks to (ab)use.

[Bug driver/19353] Faulty handling of startfile_prefix_spec

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 05:49 --- (In reply to comment #3) > BTW, at first glance, the patch you posted cannot possibly be correct. An "if" > statement was removed but the following "else if" statement was left in place. > Then again, I coul

[Bug target/19274] temporary not eliminated in composite _mm_set_ps1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 06:07 --- This has been fixed now, I think by a patch which also fixed PR 13366. We get the same code for both functions in 32bit mode. But note in 64bit mode, we get better code for not_eliminated: not_eliminated: .L

[Bug tree-optimization/19341] [4.0 Regression] DCE eliminating non-dead code

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|2005-01-12 05:41:12 |2005-01-

[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 06:26 --- I will have to file a new bug for this as we produce so much worse code now on the mainline but that is because we expand the + to do it all four times instead of using the sse/mmx unit which is just plai

[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent

-- What|Removed |Added BugsThisDependsOn||19391 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552

[Bug middle-end/19391] New: [4.0 Regression] missed optimization with size of 8 vectors

We do not generate the vector instructions with the following code on x86_64 (and x86 -msse3): typedef short mmxw __attribute__ ((vector_size(8))); typedef int mmxdw __attribute__ ((vector_size(8))); mmxdw dw; mmxw w; void test(){ w+=w; dw= (mmxdw)w; } The code comes from PR 14552 bu

[Bug middle-end/19391] [4.0 Regression] missed optimization with size of 8 vectors

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 06:34 --- Note this worked with 20041124. -- What|Removed |Added Target Milestone|---

[Bug target/16362] i386/x86-64 backend missing logical vector operations

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 06:41 --- Fixed 3 days ago by: * config/i386/emmintrin.h (_mm_cvtsi128_si32): Move earlier. (_mm_cvtsi128_si64x): Likewise. (_mm_srl_epi64, _mm_srl_epi32, _mm_srl_epi16, _mm_sra_epi32, _mm_sra_

[Bug tree-optimization/18589] could optimize FP multiplies better

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12 06:50 --- This is actually not a target issue, it can be shown on ppc also and other targets including x86. doing (f1*f2)^2^2 will be the best every where as it is only three instructions and it would take the same

[Bug target/18562] SSE constant vector initialization produces dead constant values on stack

--- Additional Comments From uros at kss-loka dot si 2005-01-12 06:53 --- (In reply to comment #3) In the second testcase, compiler should figure out that the whole val1[] array is initialized with constants. In this case, .LCx constant vector can be built in compile time and a load of

[Bug rtl-optimization/18081] [3.4 only] Infinite memory allocation on -O3

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

[Bug rtl-optimization/18081] [3.4 only] Infinite memory allocation on -O3

-- What|Removed |Added Known to work|4.0.0 |4.0.0 3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081

<    1   2