[Bug fortran/20986] New: erreur dans gfc_conv_string_tmp
it is fortran 77 code, if it is irrelevant please tell me. if you are interested i have other bugs. /home/antoine/bin/gfortran -v Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.0-20050402/configure --prefix=/home/antoine --with-gmp=/home/antoine/ --without-libiberty Modèle de thread: posix version gcc 4.0.0 20050402 (prerelease) the command /home/antoine/bin/gfortran -B/home/antoine -c -O2 -ffixed-form -fdefault-integer-8 -fdefault-real-8zzfimp.f the output : zzfimp.f: In function 'zzfimp': zzfimp.f:434: erreur interne du compilateur: dans gfc_conv_string_tmp, à fortran/trans-expr.c:736 Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. the source : SUBROUTINE ZZFIMP(MTABX,MTAB1) IMPLICIT INTEGER(I-N) IMPLICIT REAL*8 (A-H,O-Z) COMMON/COPTIO/IPLLB COMMON/COPTIO/IERPER, IERMAX, IERR REAL*4 REAERR COMMON/COPTIO/INTERR(10),REAERR(10) CHARACTER*40 MOTERR CHARACTER*72 TITREE CHARACTER*4 LOCERR COMMON/COPTIC/MOTERR,TITREE,LOCERR COMMON /COPTIO/IOTER, IOLEC, IOIMP, IOCAR, IOACQ COMMON /COPTIO/IOPER, IOSGB, IOGRA, IOSAU, IORES COMMON/COPTIO/IECHO, IIMPI,IOSPI COMMON/COPTIO/IDIM, MCOORD COMMON/COPTIO/IFOMOD COMMON/COPTIO/NIFOUR COMMON/COPTIO/IFOUR COMMON/COPTIO/NSDPGE REAL*4 DIOCAD,DIOCAE COMMON/COPTIO/DIOCAD, DIOCAE LOGICAL ZHORIZ , ZINIPS COMMON/COPTIO/ZHORIZ , ZINIPS COMMON/COPTIO/IONIVE COMMON/COPTIO/NGMAXY COMMON/COPTIO/IZROSF COMMON/COPTIO/ISOTYP COMMON/COPTIO/IEPTR CHARACTER*72 DATVER COMMON/COPTIC/DATVER COMMON/COPTIO/IOSCR,LTEXLU COMMON/COPTIC/TEXLU CHARACTER*500 TEXLU COMMON/COPTIO/NORINC,NORVAL,NORIND,NORVAD COMMON/COPTIO/NUCROU COMMON/COPTIC/LANGUE CHARACTER*4 LANGUE COMMON/COPTIO/IPSAUV COMMON/COPTIC/NOMFIC,NOMRES CHARACTER*72 NOMFIC,NOMRES COMMON/COPTIO/IPREFI,IFICLE,DIMATT,DIMFIC REAL*4 DIMATT,DIMFIC COMMON/COPTIO/IREFOR,ISAFOR REAL*4 DENSIT,DENSIU COMMON /CGEOME/DENSIT, DENSIU COMMON /CGEOME/NOMBR CHARACTER*4 NOMS COMMON /CGEOMC/NOMS(100) COMMON /CGEOME/ILCOUR COMMON/CGEOME/NBNNE(100),KDEGRE(100),KSURF(100) COMMON/CGEOME/NBSOM(100),NSPOS(100) COMMON/CGEOME/LPL(100),LPT(100) COMMON/CGEOME/IBSOM(300) COMMON/CGEOME/KSEGM(1500) COMMON/CGEOME/KDFAC(3,20),KFAC(1000),LFAC(1000) COMMON/CGEOME/LDEL(2,100),LTEL(2,100) COMMON/CGEOME/KSIF(11) COMMON /CGEOME/NBCOUL CHARACTER*4 NCOUL COMMON /CGEOMC/NCOUL(0:100) COMMON /CGEOME/IDCOUL COMMON/CGEOME/ITABM(0:10,0:10) COMMON/CGEOME/IOMBRE COMMON/CGEOME/IOEIL C SEGMENT,MCHELM C POINTEUR MCHEL1.MCHELM,MCHEL2.MCHELM,MCHEL3.MCHELM C POINTEUR MCHEL4.MCHELM,MCHEL5.MCHELM,MCHEL6.MCHELM C SEGMENT,MCHAML C POINTEUR MCHAM1.MCHAML,MCHAM2.MCHAML,MCHAM3.MCHAML C POINTEUR MCHAM4.MCHAML,MCHAM5.MCHAML,MCHAM6.MCHAML C SEGMENT,MELVAL C POINTEUR MELVA1.MELVAL,MELVA2.MELVAL,MELVA3.MELVAL C POINTEUR MELVA4.MELVAL,MELVA5.MELVAL,MELVA6.MELVAL C SEGMENT MCOORD C SEGMENT/MLENTI/(LECT(JG)),MLENT1.MLENTI,MLENT2.MLENTI, C1 MLENT3.MLENTI C SEGMENT MELEME C POINTEUR IPT1.MELEME,IPT2.MELEME,IPT3.MELEME,IPT4.MELEME C POINTEUR IPT5.MELEME,IPT6.MELEME,IPT7.MELEME,IPT8.MELEME C POINTEUR IPT9.MELEME C POINTEUR MELEM1.MELEME,SPGID.MELEME,SPGZ.MELEME C POINTEUR MELEMP.MELEME C SEGMENT MCHPOI C POINTEUR MCHPO1.MCHPOI,MCHPO2.MCHPOI,MCHPO3.MCHPOI,MCHPO4.MCHPOI C SEGMENT MSOUPO C POINTEUR MSOUP1.MSOUPO,MSOUP2.MSOUPO,MSOUP3.MSOUPO, C# MSOUP4.MSOUPO,MSOUP5.MSOUPO C SEGMENT MPOVAL C POINTEUR MPOVA1.MPOVAL,MPOVA2.MPOVAL,MPOVA3.MPOVAL, C# MPOVA4.MPOVAL,MPOVA5.MPOVAL,MPOVA6.MPOVAL C POINTEUR IZG1.MCHPOI, IZGG1.MPOVAL C POINTEUR IZTU1.MPOVAL C POINTEUR MZFLU.MPOVAL C POINTEUR IZVOL.MPOVAL C SEGMENT IZFFM C SEGMENT IZHR C POINTEUR IZF1.IZFFM C SEGMENT MLMOTS C POINTEUR MLMOT1.MLMOTS,MLMOT2.MLMOTS,MLMOT3.MLMOTS C POINTEUR MLMOT4.MLMOTS,MLMOT5.MLMOTS,MLMOT6.MLMOTS C POINTEUR LINCO.MLMOTS COMMON/OOOCOM/OOA(1),OOT,OOV(8),MOT_01,IPC_02,NOC_03,LIS_04,ICH_05 *,IEL_06,LEC_07,NUM_08,VEL_09,VPO_10,VPO_11,ITY_12,KZH_13,KTP_14,XY *Z_15,XCO_16,FN_17,GR_18,PG_19,HR_20,PGS_21,RPG_22,NUM_23,FN_24 INTEGEROOA,OOT,OOV,OOO,OO1,OO2,OO3,OO4,MCHELM,OO5 INTEGEROO6,OO7,OO8,OO9,OO10,MCHEL1,MCHEL2,MCHEL3,MCHEL4,MCHEL5 INTEGERMCHEL6,MCHAML,MCHAM1,MCHAM2,MCHAM3,MCHAM4,MCHAM5,MCHAM6,MEL *VAL,MELVA1 INTEGERMELVA2,MELVA3,MELVA4,MELVA5,MELVA6,MCOORD,MLENTI,MLENT1,MLE *NT2,MLENT3 INTEGERMELEME,IPT1,IPT2,IPT3,IPT4,IPT5,IPT6,IPT7,IPT8,IPT9 INTEGERMELEM1,SPGID,SPGZ,MELEMP,MCHPOI,MCHPO1,MCHPO2,M
[Bug c++/20987] New: friend declaration links to two functions
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-I
-D
X.CPP -oX.O
// file X.CPP
struct S
{
static int f4 ();
class C
{
public:
C ();
~C ();
private:
friend int f4 ();
static int i;
};
};
int f4 () { return S::C::i; }
int S::f4 () { return C::i; }// Comeau: member "S::C::i" is inaccessible
The code above compiles fine with GNU. Obviously the compiler binds the friend
declaration in class C to tow functions: to S::f4() and to ::f4() since both
functions can access the private member S::C::i.
It is not clear if the friend declaration should link to S::f4(). There is a
defect report (DR 138) which covers this case.
Kind regards
W. Roehrl
--
Summary: friend declaration links to two functions
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at de dot gi-de dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20987
[Bug libfortran/19016] [4.0 only] maxloc ignores mask
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13 08:27 --- Fixed in 4.1, waiting for 4.0 to reopen to apply there. -- What|Removed |Added Summary|maxloc ignores mask |[4.0 only] maxloc ignores ||mask Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19016
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From charlet at adacore dot com 2005-04-13 08:32 --- Subject: Re: makeinfo cannot process gnat_ugn_unw.texi > Arnaud, may be a candidate for review? Sure. I'd suggest posting the patch to gcc-patches@ Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug rtl-optimization/13724] Bad code generated for unsigned int -> long long multiplication
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13 09:23 --- Paolo Bozini mentioned this bug as an example of the 64bits arith on 32bits host "issue". -- What|Removed |Added OtherBugsDependingO||19721 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13724
[Bug libfortran/20108] [4.0 only] incorrect run time error on formatted read
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13 09:34 --- Fixed in 4.1, waiting for 4.0.1 to reopen. -- What|Removed |Added Summary|incorrect run time error on |[4.0 only] incorrect run |formatted read |time error on formatted read Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20108
[Bug c++/20980] internal compiler error on static member assignment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 09:39 --- But the code is still invalid and is really a dup of bug 20133. You most want: template int Test::myInt; template S& Test::myS = S::instance(); Not what you gave. The orginal ICE is fixed so still closing as fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20980
[Bug debug/20985] building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 09:46 --- 956.4byte $LFB4-. Are you sure that this is not an assembler problem? -- What|Removed |Added Severity|critical|normal Component|bootstrap |debug Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20985
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-04-13 09:46
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Tue, Apr 12, 2005 at 05:54:58PM -, mmitchel at gcc dot gnu dot org wrote:
>
> --- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-12
> 17:54 ---
> I like the simpler approach. If someone would test that for 4.0, I'd be
> ecstatic.
Here is what I have bootstrapped/regtested on
{i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux.
2005-04-13 Alexandre Oliva <[EMAIL PROTECTED]>
Roger Sayle <[EMAIL PROTECTED]>
PR target/20126
* loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
set the original address pseudo to the correct value before the
original insn, if possible, and leave the insn alone, otherwise
create a new pseudo, set it and replace it in the insn.
* recog.c (validate_change_maybe_volatile): New.
* recog.h (validate_change_maybe_volatile): Declare.
* gcc.dg/pr20126.c: New.
--- gcc/loop.c.jj 2005-04-03 10:33:24.0 +0200
+++ gcc/loop.c 2005-04-12 23:22:06.0 +0200
@@ -5478,9 +5478,20 @@ loop_givs_rescan (struct loop *loop, str
mark_reg_pointer (v->new_reg, 0);
if (v->giv_type == DEST_ADDR)
- /* Store reduced reg as the address in the memref where we found
- this giv. */
- validate_change (v->insn, v->location, v->new_reg, 0);
+ {
+ /* Store reduced reg as the address in the memref where we found
+this giv. */
+ if (!validate_change (v->insn, v->location, v->new_reg, 0))
+ {
+ if (loop_dump_stream)
+ fprintf (loop_dump_stream,
+"unable to reduce iv to register in insn %d\n",
+INSN_UID (v->insn));
+ bl->all_reduced = 0;
+ v->ignore = 1;
+ continue;
+ }
+ }
else if (v->replaceable)
{
reg_map[REGNO (v->dest_reg)] = v->new_reg;
--- gcc/testsuite/gcc.dg/pr20126.c 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/pr20126.c 10 Mar 2005 11:24:16 -
@@ -0,0 +1,50 @@
+/* dg-do run */
+/* dg-options "-O2" */
+
+/* PR target/20126 was not really target-specific, but rather a loop's
+ failure to take into account the possibility that a DEST_ADDR giv
+ replacement might fail, such as when you attempt to replace a REG
+ with a PLUS in one of the register_operands of cmpstrqi_rex_1. */
+
+extern void abort (void);
+
+typedef struct { int a; char b[3]; } S;
+S c = { 2, "aa" }, d = { 2, "aa" };
+
+void *
+bar (const void *x, int y, int z)
+{
+ return (void *) 0;
+}
+
+int
+foo (S *x, S *y)
+{
+ const char *e, *f, *g;
+ int h;
+
+ h = y->a;
+ f = y->b;
+ e = x->b;
+
+ if (h == 1)
+return bar (e, *f, x->a) != 0;
+
+ g = e + x->a - h;
+ while (e <= g)
+{
+ const char *t = e + 1;
+ if (__builtin_memcmp (e, f, h) == 0)
+ return 1;
+ e = t;
+}
+ return 0;
+}
+
+int
+main (void)
+{
+ if (foo (&c, &d) != 1)
+abort ();
+ return 0;
+}
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/20987] friend declaration links to two functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 09:58 --- Fixed in 3.4.0 and above: t.cc: In static member function `static int S::f4()': t.cc:13: error: `int S::C::i' is private t.cc:19: error: within this context -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20987
[Bug target/19150] [3.3/3.4/4.0/4.1 Regression] suboptimal fp division with -ffast-math
--- Additional Comments From uros at kss-loka dot si 2005-04-13 09:58 --- (In reply to comment #7) > Uros, what's the state of this bug? I don't understand if the patch linked in > comment #6 was committed, or which is its final version still pending > review/approval. Another approach was suggested by Roger Sayle in http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02017.html. We would force CONST_DOUBLE to memory only if (newly created) combined instruction with CONST_DOUBLE operand doesn't match. However, this approach requires some more hacking, and I havn't look into it (yet...?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19150
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13 10:01 --- The program test_spread from the original bug report is bogus. dim=1000 doesn't make sense (which invalidates my comment #5 and makes this particular case a diagnostics issue). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug fortran/20986] erreur dans gfc_conv_string_tmp
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 10:03 --- Even though this is a dup of bug 20971 which was just reported yesterday, please report more bugs. There are a large number of bugs in gfortran which are not known yet. *** This bug has been marked as a duplicate of 20971 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20986
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 10:03 --- *** Bug 20986 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||antoine dot letellier at ||free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 10:03 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-13 10:03:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20971
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From bernds_cb1 at t-online dot de 2005-04-13 10:08 --- Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry Jakub Jelinek wrote: > PR target/20126 > * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, > set the original address pseudo to the correct value before the > original insn, if possible, and leave the insn alone, otherwise > create a new pseudo, set it and replace it in the insn. > * recog.c (validate_change_maybe_volatile): New. > * recog.h (validate_change_maybe_volatile): Declare. > This doesn't appear to match the patch you posted. Bernd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug other/20988] New: D Language frontend Segmentation fault
gdc -v --save-temps -c VincoloIIF.d -- BEGIN OF OUTPUT -- Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec- prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib -- mandir=/usr/share/man --infodir=/usr/share/info --enable- languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --without-included- gettext --enable-libgcj --with-system-zlib --enable-interpreter --enable- threads=posix --enable-java-gc=boehm --enable-sjlj-exceptions --disable- version-specific-runtime-libs --disable-win32-registry Thread model: posix gcc version 3.3.3 (cygwin special) /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/cc1d.exe VincoloIIF.d -quiet -dumpbase VincoloIIF.d -auxbase VincoloIIF -version -o VincoloIIF.s GNU D version 3.3.3 (cygwin special) (i686-pc-cygwin) compiled by GNU C version 3.3.3 (cygwin special). GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=28350 VincoloIIF.d:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- END OF OUTPUT -- No *.i* files generated. -- Summary: D Language frontend Segmentation fault Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: critical Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marco dot falda at unipd dot it CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20988
[Bug other/20988] D Language frontend Segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 10:51 --- Since the D front-end is not part of GCC, we cannot reproduce you bug. I would report this bug to the people you got the D front-end from. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20988
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-04-13 11:38 --- Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry On Wed, Apr 13, 2005 at 12:05:35PM +0200, Bernd Schmidt wrote: > Jakub Jelinek wrote: > > PR target/20126 > > * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, > > set the original address pseudo to the correct value before the > > original insn, if possible, and leave the insn alone, otherwise > > create a new pseudo, set it and replace it in the insn. > > * recog.c (validate_change_maybe_volatile): New. > > * recog.h (validate_change_maybe_volatile): Declare. > > > This doesn't appear to match the patch you posted. Oops. Is: 2005-04-13 Alexandre Oliva <[EMAIL PROTECTED]> Roger Sayle <[EMAIL PROTECTED]> PR target/20126 * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, signal that all GIVs couldn't be reduced. * gcc.dg/pr20126.c: New. better? Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug c++/13744] ICE when using implicit copy constructor for struct defined in template function
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13 12:01 --- Subject: Bug 13744 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-13 12:01:03 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/inherit: local3.C Log message: PR c++/13744 * g++.dg/inherit/local3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5336&r2=1.5337 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/local3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13744
[Bug c++/13744] ICE when using implicit copy constructor for struct defined in template function
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-13 12:07 --- Fixed on mainline (which will become 4.1.0). -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13744
[Bug c++/18378] [3.4 Regression] ICE when returning a copy of a packed member
-- Bug 18378 depends on bug 13744, which changed state. Bug 13744 Summary: ICE when using implicit copy constructor for struct defined in template function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13744 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18378
[Bug libstdc++/20979] __gnu_cxx::bitmap_allocator export pruning
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 12:11 --- (In reply to comment #1) > Created an attachment (id=8615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8615&action=view) > free_list:: static removal > Hi, What has been done seems ok, but there is just one thing that niggles me. There is now the _M_get_mutex() function, which itself is not thread safe. So, if 2 or more threads try to get memory simultaneously, then the _M_get_mutex() function will be called 2 times, and the mutex will be initialized 2 times If that is possible that is. Basically, there seems to be arace here. HOwever, with the previous scenario, the static was initialized before anything happned [I think]. -Dhruv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
[Bug preprocessor/20989] New: The -M option gives object file names without directory
The -M preprocessor option (and -MM and similar options) strips the directory
part from the listed object file names. The documentaion for -M says:
"Unless specified explicitly (with `-MT' or `-MQ'), the object file
name consists of the basename of the source file with any suffix
replaced with object file suffix."
I interpret the word "basename" in the manual text to include directories as the
basename function in GNU make does, however the actual output is without
directories:
=== Content of test/test.c ===
#include "test.h"
#include
int main ()
{
puts (GREETING);
}
=== Content of test/test.h ===
#ifndef TEST_H
#define TEST_H
#define GREETING "Hello world"
#endif
===
$ gcc -MM test/test.c
test.o: test/test.c test/test.h
$
I had expected the output to be: "test/test.o: test/test.c test/test.h".
--
Summary: The -M option gives object file names without directory
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at safepro dot dk
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20989
Re: [Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote: > That mental model doesn't work right now with the way DOM & the > jump threader because they are too tightly intertwined. > The link that you have still not shown me is why doesn't this mental model work for the jump threader. That's why I said that I need to run the threader myself and see why it needs all these additional crutches. If the code has been cleaned up of redundancies, copies propagated, names have known values and ranges are set, then I don't see why we would need all the extra baggage. > The iteration step we see today would turn into a worklist. > ie, after we thread jumps, we walk through the IL for PHIs > which represent a copy that can be propagated. > Ah, here's something specific I don't follow. Why would you have these PHIs anymore? If all the arguments were ultimately equivalent, then the various propagators are bound to have removed them. If not, that sounds like a bug in them. > What's nice about this is the bulk of DOM as we know it today > disappears along with the expensive iteration in the case when > jumps are threaded. We just need the right APIs for copy > propagation and value handles. > Again, why? The propagators are supposed to have done this already. They are all supposed to work in conditional regions. > We could still potentially use ASSERT_EXPRs to encode > information about edge equivalences, though we probably would > still want the ASSERT_EXPR to appear as statement rather than > the RHS of a MODIFY_EXPR. > Odd, the nice thing about assertions being on the RHS is that you pin their result to a specific SSA name that you then get to use at every place naturally dominated by the assertion. If you could give me a concrete test case that I could sink my teeth in, that'd be great. Thanks. Diego.
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From dnovillo at redhat dot com 2005-04-13 13:03 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote: > That mental model doesn't work right now with the way DOM & the > jump threader because they are too tightly intertwined. > The link that you have still not shown me is why doesn't this mental model work for the jump threader. That's why I said that I need to run the threader myself and see why it needs all these additional crutches. If the code has been cleaned up of redundancies, copies propagated, names have known values and ranges are set, then I don't see why we would need all the extra baggage. > The iteration step we see today would turn into a worklist. > ie, after we thread jumps, we walk through the IL for PHIs > which represent a copy that can be propagated. > Ah, here's something specific I don't follow. Why would you have these PHIs anymore? If all the arguments were ultimately equivalent, then the various propagators are bound to have removed them. If not, that sounds like a bug in them. > What's nice about this is the bulk of DOM as we know it today > disappears along with the expensive iteration in the case when > jumps are threaded. We just need the right APIs for copy > propagation and value handles. > Again, why? The propagators are supposed to have done this already. They are all supposed to work in conditional regions. > We could still potentially use ASSERT_EXPRs to encode > information about edge equivalences, though we probably would > still want the ASSERT_EXPR to appear as statement rather than > the RHS of a MODIFY_EXPR. > Odd, the nice thing about assertions being on the RHS is that you pin their result to a specific SSA name that you then get to use at every place naturally dominated by the assertion. If you could give me a concrete test case that I could sink my teeth in, that'd be great. Thanks. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug libfortran/20970] gfortran - bus error -fdefault-integer-8
--- Additional Comments From dir at lanl dot gov 2005-04-13 13:08 --- Here is the crash walk back Thread 0 Crashed: 0 libgfortran.0.dylib 0x0023e99c _gfortran_compare_string + 0x68 (string_intrinsics.c:136) 1 adini 0x1d2c MAIN__ + 0x40 (adini.f:6) 2 adini 0x1d74 main + 0x18 3 adini 0x191c _start + 0x188 (crt.c:267) 4 dyld0x8fe1a558 _dyld_start + 0x64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20970
[Bug fortran/20990] New: Segmentation fault
/home/antoine/bin/gfortran -v Utilisation des specs internes. Target: x86_64-unknown-linux-gnu Configuré avec: ../gcc-4.0-20050402/configure --prefix=/home/antoine --with-gmp=/home/antoine/ --without-libiberty Modèle de thread: posix version gcc 4.0.0 20050402 (prerelease) command line : /home/antoine/bin/gfortran -B/home/antoine -c -O2 -ffixed-form -fdefault-integer-8 -fdefault-real-8jonct.f output : jonct.f: In function 'jonct': jonct.f:294: erreur interne du compilateur: Segmentation fault Veuillez soumettre un rapport complet d'anomalies, avec le source pré-traité si nécessaire. source : SUBROUTINE JONCT IMPLICIT INTEGER(I-N) COMMON/COPTIO/IPLLB COMMON/COPTIO/IERPER, IERMAX, IERR REAL*4 REAERR COMMON/COPTIO/INTERR(10),REAERR(10) CHARACTER*40 MOTERR CHARACTER*72 TITREE CHARACTER*4 LOCERR COMMON/COPTIC/MOTERR,TITREE,LOCERR COMMON /COPTIO/IOTER, IOLEC, IOIMP, IOCAR, IOACQ COMMON /COPTIO/IOPER, IOSGB, IOGRA, IOSAU, IORES COMMON/COPTIO/IECHO, IIMPI,IOSPI COMMON/COPTIO/IDIM, MCOORD COMMON/COPTIO/IFOMOD COMMON/COPTIO/NIFOUR COMMON/COPTIO/IFOUR COMMON/COPTIO/NSDPGE REAL*4 DIOCAD,DIOCAE COMMON/COPTIO/DIOCAD, DIOCAE LOGICAL ZHORIZ , ZINIPS COMMON/COPTIO/ZHORIZ , ZINIPS COMMON/COPTIO/IONIVE COMMON/COPTIO/NGMAXY COMMON/COPTIO/IZROSF COMMON/COPTIO/ISOTYP COMMON/COPTIO/IEPTR CHARACTER*72 DATVER COMMON/COPTIC/DATVER COMMON/COPTIO/IOSCR,LTEXLU COMMON/COPTIC/TEXLU CHARACTER*500 TEXLU COMMON/COPTIO/NORINC,NORVAL,NORIND,NORVAD COMMON/COPTIO/NUCROU COMMON/COPTIC/LANGUE CHARACTER*4 LANGUE COMMON/COPTIO/IPSAUV COMMON/COPTIC/NOMFIC,NOMRES CHARACTER*72 NOMFIC,NOMRES COMMON/COPTIO/IPREFI,IFICLE,DIMATT,DIMFIC REAL*4 DIMATT,DIMFIC COMMON/COPTIO/IREFOR,ISAFOR CHARACTER*4 NOMTP COMMON /CHAMP/ NOMTP(300) COMMON/LCHAMP/ LNOMTP CHARACTER*8 NOMIN COMMON /CHAMP/ NOMIN(5) COMMON/LCHAMP/ LNOMIN CHARACTER*8 NOMFR COMMON /CHAMP/ NOMFR(40) COMMON/LCHAMP/ LNOMFR CHARACTER*8 NOMCH COMMON /CHAMP/ NOMCH(50) COMMON/LCHAMP/ LNOMCH CHARACTER*8 NOMAT COMMON /CHAMP/ NOMAT(50) COMMON/LCHAMP/ LNOMAT CHARACTER*4 NOMDD COMMON /CHAMP/ NOMDD(40) COMMON/LCHAMP/ LNOMDD CHARACTER*4 NOMDU COMMON /CHAMP/ NOMDU(40) COMMON/LCHAMP/ LNOMDU CHARACTER*4 NOMVI COMMON /CHAMP/ NOMVI(40) COMMON/LCHAMP/ LNOMVI CHARACTER*4 NOMAC COMMON /CHAMP/ NOMAC(40) COMMON/LCHAMP/ LNOMAC CHARACTER*4 NOMST COMMON /CHAMP/ NOMST(60) COMMON/LCHAMP/ LNOMST CHARACTER*4 NOMDF COMMON /CHAMP/ NOMDF(60) COMMON/LCHAMP/ LNOMDF CHARACTER*4 NOMYO COMMON /CHAMP/ NOMYO(100) COMMON/LCHAMP/ LNOMYO CHARACTER*4 NOMCR COMMON /CHAMP/ NOMCR(100) COMMON/LCHAMP/ LNOMCR CHARACTER*4 NOMHO COMMON /CHAMP/ NOMHO(100) COMMON/LCHAMP/ LNOMHO CHARACTER*4 NOMVRI COMMON /CHAMP/ NOMVRI(100) COMMON/LCHAMP/ LNOVRI CHARACTER*4 NNAVI COMMON /CHAMP/ NNAVI(20) COMMON/LCHAMP/ LNNAVI COMMON /LCHAMP/ILNAVI C SEGMENT/MELSTR/(ISOSTU(N),IMELEM(N)),MELST1.MELSTR,MELST2.MELSTR C SEGMENT/MCLSTR/(ISOSTR(N),IRIGCL(N)),MCLST1.MCLSTR,MCLST2.MCLSTR C SEGMENT/MSTRUC/(LISTRU(N)),MSTRU1.MSTRUC,MSTRU2.MSTRUC C SEGMENT/MSOSTU/(ITYSOU,ISRAID,ISMASS,ISCHAM(NS)),MSOST1.MSOSTU,MSOS C&T2.MSOSTU C SEGMENT MELEME C POINTEUR IPT1.MELEME,IPT2.MELEME,IPT3.MELEME,IPT4.MELEME C POINTEUR IPT5.MELEME,IPT6.MELEME,IPT7.MELEME,IPT8.MELEME C POINTEUR IPT9.MELEME C SEGMENT MCOORD C SEGMENT MRIGID C POINTEUR RI1.MRIGID,RI2.MRIGID,RI3.MRIGID C POINTEUR RI4.MRIGID,RI5.MRIGID,RI6.MRIGID C SEGMENT XMATRI C POINTEUR XMATR1.XMATRI,XMATR2.XMATRI,XMATR3.XMATRI C POINTEUR XMATR4.XMATRI,XMATR5.XMATRI,XMATR6.XMATRI C SEGMENT IMATRI C POINTEUR IMATR1.IMATRI,IMATR2.IMATRI,IMATR3.IMATRI C POINTEUR IMATR4.IMATRI,IMATR5.IMATRI,IMATR6.IMATRI C SEGMENT DESCR C POINTEUR DES1.DESCR,DES2.DESCR,DES3.DESCR,DES4.DESCR C SEGMENT IMGEOD C SEGMENT MCHPOI C POINTEUR MCHPO1.MCHPOI,MCHPO2.MCHPOI,MCHPO3.MCHPOI,MCHPO4.MCHPOI C SEGMENT MSOUPO C POINTEUR MSOUP1.MSOUPO,MSOUP2.MSOUPO,MSOUP3.MSOUPO, C# MSOUP4.MSOUPO,MSOUP5.MSOUPO C SEGMENT MPOVAL C POINTEUR MPOVA1.MPOVAL,MPOVA2.MPOVAL,MPOVA3.MPOVAL, C# MPOVA4.MPOVAL,MPOVA5.MPOVAL,MPOVA6.MPOVAL C SEGMENT MATTAC C POINTEUR MATTA1.MATTAC,MATTA2.MATTAC C SEGMENT MSOUMA C POINTEUR MSOUM1.MSOUMA,MSOUM2.MSOUMA C SEGMENT MJONCT C POINTEUR MJONC1.MJONCT,MJONC2.MJONCT C SEGMENT MGEOCH C
[Bug middle-end/20991] New: ICE in cgraph_mark_reachable_node
Current gcc-4_0-branch (i.e. with PR20635 fix in) ICEs on the attached testcase
at -O3 -m32. It is a recent regression (the assert was added 2005-03-18)
and prevents building Octave.
virtual std::string octave_value::class_name() const (this)
{
...
}
seen in *.generic dump seems to be unused until *.dom1 time (till then
Fissparse uses
arg_106 = &D.101031;
D.141412_107 = arg_106->_vptr.octave_value;
D.141413_108 = D.141412_107 + 468B;
D.141414_109 = *D.141413_108;
OBJ_TYPE_REF(D.141414_109;arg_106->117) (&D.141411, arg_106) [return slot
addr];
and only in the first dominator pass this gets changed into:
arg_175 = &arg;
D.131589_176 = arg._vptr.octave_value;
D.131590_177 = D.131589_176 + 468B;
D.131591_178 = *D.131590_177;
class_name (&D.131588, &arg) [return slot addr];
but cgraph does not know about this call until Fissparse's assembly is emitted.
But at that point cgraph_global_info_ready is already true, therefore the ICE.
--
Summary: ICE in cgraph_mark_reachable_node
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,hubicka at gcc dot gnu
dot org
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug middle-end/20991] ICE in cgraph_mark_reachable_node
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-13 13:28 --- Created an attachment (id=8617) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8617&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug preprocessor/20989] The -M option gives object file names without directory
--- Additional Comments From neil at gcc dot gnu dot org 2005-04-13 13:29 --- Not a bug - you misunderstand basename. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20989
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ICE in |[4.0/4.1 Regression] ICE in |cgraph_mark_reachable_node |cgraph_mark_reachable_node Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/20992] New: error as no matching function with g++
g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --enable-language=c,c++ --prefix=/home/dinar/work/gcc-builds/gcc-4.0-i686-pc-linux-gnu/ Thread model: posix gcc version 4.0.0 20050412 (prerelease) while compiling source code: g++ sample.c -c sample.c: In function int main(): sample.c:13: error: no matching function for call to A::A(A) sample.c:4: note: candidates are: A::A(A&) sample.c:13: error: initializing temporary from result of A::A(T) [with T = int] -- Summary: error as no matching function with g++ Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dtemirbulatov at ru dot mvista dot com CC: dtemirbulatov at ru dot mvista dot com,gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20992
[Bug c++/20992] error as no matching function with g++
--- Additional Comments From dtemirbulatov at ru dot mvista dot com 2005-04-13 13:36 --- Created an attachment (id=8618) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8618&action=view) source to compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20992
[Bug preprocessor/20989] The -M option gives object file names without directory
--- Additional Comments From bje at safepro dot dk 2005-04-13 13:43 --- Then I suggest that the manual is clarified to make it clear what is meant. The word "basename" is easy to misunderstand, especially because the "basename" function in GNU make do keep the directory part of its arguments. I reopen the bug - as I think it is at least a bug in the documentation. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20989
[Bug c++/20992] error as no matching function with g++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 13:44 --- A(A&) is a copy constructor but does not allow binding to a temporary variable which is required here even if it is not called. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20992
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-13 14:26
---
Somewhat simplified testcase:
#include
#include
struct A { int i; };
struct B { int i; };
struct C { int i; };
struct D { int i; };
struct E
{
E (void);
E (bool b);
E (const A & m);
virtual ~ E (void);
virtual A m1 (bool x = false) const { return rep->m1 (x); }
virtual B m2 (bool x = false) const { return rep->m2 (x); }
virtual C m3 (bool x = false) const { return rep->m3 (x); }
virtual D m4 (bool x = false) const { return rep->m4 (x); }
virtual std::string m5 (void) const { return rep->m5 (); }
virtual std::string m6 (void) const { return rep->m6 (); }
union { E *rep; int count; };
};
struct F
{
F (void) : data () {}
F (const E & tc) : data (1, tc) {}
F (const F & obj):data (obj.data) {}
~F (void) {}
E operator () (int n) const { return n2 (n); }
int n1 (void) const { return data.size (); }
std::vector < E > data;
E n2 (int n) const { return data[n]; }
};
static bool foo (const E & arg) { return (arg.m6 () == "foo"); }
F bar (const F & args) { return E (foo (args (0))); }
F fn1 (const F & args)
{
E retval;
if (args (0).m6 () == "foo")
retval = args (0).m1 ();
return retval;
}
static F f2 (const B & v) { F retval; return retval; }
static F f2 (const C & v) { F retval; return retval; }
static F f2 (const D & v) { F retval; return retval; }
F
f3 (const F & x)
{
F retval;
int n = x.n1 ();
if (n != 1)
return retval;
E arg = x (0);
if (arg.m6 () == "foo")
{
if (arg.m5 () == "bar")
retval = f2 (x (0).m2 ());
else if (arg.m5 () == "baz")
retval = f2 (x (0).m3 ());
else
retval = f2 (x (0).m4 ());
}
return retval;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug preprocessor/20989] The -M option gives object file names without directory
--- Additional Comments From bje at safepro dot dk 2005-04-13 14:38 --- Actually the manual explicit says that any path in the input file name is kept by default in the description of the "-MT TARGET" option. So either the preprocessor or the manual does have a bug when the preprocessor discards the path: `-MT TARGET' Change the target of the rule emitted by dependency generation. By default CPP takes the name of the main input file, including any path, deletes any file suffix such as `.c', and appends the platform's usual object suffix. The result is the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20989
[Bug tree-optimization/20702] [tcb] ASSERT_EXPRs are not inserted when a certain "if" statement is present.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 14:56 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01456.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
[Bug tree-optimization/20913] copy-prop does not fold conditionals
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 14:56 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01457.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug middle-end/20991] [4.0/4.1 Regression] ICE in cgraph_mark_reachable_node
-- What|Removed |Added CC||dmitri at unm dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
[Bug c++/20993] New: GCC/GCJ not creating proper symbols for inline native CNI code
The following code will not link because j.getName has multiple definitions.
Both j.o and natj.o contain a T definition when natj.o should contain a W def.
Ultimatly this causes the mingw 4.0.0 cross compiler to not build a functioning
native compiler becuase libgcj.a contains multiple defintion.
[EMAIL PROTECTED] steve]$ cat j.java
class j
{
String _name;
j() {
_name="BOB";
}
String getName() {
return _name;
};
}
#pragma implementation "j.h"
#include "j.h"
#include
#include
int main(int argc,char** argv)
{
j *bob=new j();
bob->getName();
return 0;
}
gcjh j creates j.h
$ cat j.h
// DO NOT EDIT THIS FILE - it is machine generated -*- c++ -*-
#ifndef __j__
#define __j__
#pragma interface
#include
extern "Java"
{
class j;
}
class j : public ::java::lang::Object
{
public: // actually package-private
j ();
virtual ::java::lang::String *getName () { return _name; }
::java::lang::String * __attribute__((aligned(__alignof__(
::java::lang::Object _name;
public:
static ::java::lang::Class class$;
};
#endif /* __j__ */
$ nm j.o
b .bss
d .ctors
d .data
r .rdata
N .stab
N .stabstr
t .text
0094 d __catch_classes_j
0088 d __CD_j
0090 d __CT_j
d __FL_j
0030 t __GLOBAL__I_0__ZN1jC1Ev
U __Jv_RegisterClass
0020 d __MT_j
r __Utf1
000a r __Utf2
0016 r __Utf3
001e r __Utf4
002a r __Utf5
0044 r __Utf6
004c r __Utf7
00c0 D __ZN1j6class$E
0024 T __ZN1j7getNameEv
T __ZN1jC1Ev
U __ZN4java4lang6Object5cloneEv
U __ZN4java4lang6Object6class$E
U __ZN4java4lang6Object6equalsEPS1_
U __ZN4java4lang6Object8finalizeEv
U __ZN4java4lang6Object8hashCodeEv
U __ZN4java4lang6Object8toStringEv
U __ZN4java4lang6ObjectC1Ev
U __ZN4java4lang6String6class$E
0060 D __ZTVN1jE
U __ZTVN4java4lang5ClassE
$ nm natj.o
b .bss
d .data
r .rdata$_ZTI15_JvObjectPrefix
r .rdata$_ZTI1j
r .rdata$_ZTIN4java4lang6ObjectE
r .rdata$_ZTS15_JvObjectPrefix
r .rdata$_ZTS1j
r .rdata$_ZTSN4java4lang6ObjectE
t .text
t .text$_ZN1j7getNameEv
U ___main
U __alloca
U __Jv_AllocObject
U __ZN1j6class$E
T __ZN1j7getNameEv
U __ZN1jC1Ev
R __ZTI15_JvObjectPrefix
R __ZTI1j
R __ZTIN4java4lang6ObjectE
R __ZTS15_JvObjectPrefix
R __ZTS1j
R __ZTSN4java4lang6ObjectE
U __ZTVN10__cxxabiv117__class_type_infoE
U __ZTVN10__cxxabiv120__si_class_type_infoE
T _main
--
Summary: GCC/GCJ not creating proper symbols for inline native
CNI code
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steve at netfuel dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-mingw32msvc
GCC host triplet: i386-mingw32msvc
GCC target triplet: i386-mingw32msvc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug tree-optimization/20994] New: [4.1 regression] ICE with -ftree-vectorize
The following code snippet casues an ICE on mainline when compiled with
"-O -ftree-vectorize". The 4.0 branch is not affected.
===
int foo(double* p)
{
int i=0;
for (double* q; q!=p; ++q)
if (*q)
++i;
return i;
}
===
This is similar to PR20929. But it is not a duplicate since the bug in
PR 20929 is fixed on mainline.
--
Summary: [4.1 regression] ICE with -ftree-vectorize
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug middle-end/20995] New: [3.4 regression] ICE in const_binop, at fold-const.c:1391
This little piece of code here
-
template
void test ()
{
double d;
double mu = 1;
for (unsigned int i=0; i ();
-
ICEs with gcc3.4.4pre (and apparently all older versions of the 3.4.x branch I
have):
deal.II/tests> /ices/bangerth/tmp/build-gcc-3.4/gcc-install/bin/c++ -c x.cc
x.cc: In function `void test()':
x.cc:11: internal compiler error: tree check: expected real_cst, have
integer_cst in const_binop, at fold-const.c:1391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
On the machine I'm on right now, I don't have a 4.x compiler, so it may even be
a regression on 4.0 branch and/or mainline. It doesn't ICE gcc3.3.x, though.
W.
--
Summary: [3.4 regression] ICE in const_binop, at fold-
const.c:1391
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bangerth at dealii dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20995
[Bug tree-optimization/20913] copy-prop does not fold conditionals
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13 15:29 --- Subject: Bug 20913 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-13 15:28:55 Modified files: gcc: ChangeLog tree-ssa-copy.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20913.c Log message: gcc/ PR tree-optimization/20913 * tree-ssa-copy.c (copy_prop_visit_cond_stmt): Fold COND_EXPR. testsuite/ PR tree-optimization/20913 * gcc.dg/tree-ssa/pr20913.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8274&r2=2.8275 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-copy.c.diff?cvsroot=gcc&r1=2.25&r2=2.26 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5337&r2=1.5338 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20913.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391
--- Additional Comments From bangerth at dealii dot org 2005-04-13 15:29 --- Note that it isn't related to PR 19899, even though the failure seems similar. I should also note that the ICE happened with a compiler that had checking enabled. If checking is disabled, we simply get this: deal.II/tests> $HOME/bin/gcc-3.4/bin/c++ -c x.cc x.cc: In function `void test()': x.cc:11: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. W. -- What|Removed |Added Known to fail||3.4.2 3.4.4 Known to work||3.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20995
[Bug tree-optimization/20913] copy-prop does not fold conditionals
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13 15:33 --- Subject: Bug 20913 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-13 15:33:18 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/tree-ssa: pr20702.c Log message: gcc/ PR tree-optimization/20913 * tree-ssa-copy.c (copy_prop_visit_cond_stmt): Fold COND_EXPR. testsuite/ PR tree-optimization/20913 * gcc.dg/tree-ssa/pr20913.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8275&r2=2.8276 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.5&r2=2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5338&r2=1.5339 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr20702.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug ada/20822] makeinfo cannot process gnat_ugn_unw.texi
--- Additional Comments From ericw at evcohs dot com 2005-04-13 15:43 --- FYI, I've tested the patch on my system here and it works for me. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
[Bug target/20924] [4.0/4.1 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13 15:57 --- Subject: Bug 20924 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-13 15:57:38 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.md Log message: PR target/20924 * config/ia64/ia64.md (divsf3_internal_lat): Generate frcpa with fpsr 0 instead of fpsr 1. (divsf3_internal_thr): Ditto. (divdf3_internal_lat): Ditto. (divdf3_internal_thr): Ditto. (divxf3_internal_lat): Ditto. (divxf3_internal_thr): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8276&r2=2.8277 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&r1=1.148&r2=1.149 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
[Bug tree-optimization/20994] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-13
16:09 ---
The ICE was introduced with a merge from the tree-cleanup-branch:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00501.html
BTW, here's a C testcase:
===
int foo(double* p, double* q)
{
int i=0;
for (; q!=p; ++q)
if (*q)
++i;
return i;
}
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug libstdc++/20979] __gnu_cxx::bitmap_allocator export pruning
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-04-13 16:32
---
I posit that this usage of static local variables, as written, is thread safe
with gcc-4.0.x compilers. (Since resolution of c++/13684).
! _Mutex*
! _M_get_mutex()
! {
! static _Mutex _S_mutex;
! return &_S_mutex;
! }
This object is only constructed (and initialized) once. After initial
construction, a pointer to the initial object is returned. Don't let the
simplicity of this solution fool you!
This change actually improves portability for initialization, especially on
non-SVR4 platforms, where order of initalization of static objects may differ
from expectations.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
[Bug tree-optimization/20929] [4.0 Regression] internal compiler error: verify_stmts failed.
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-13
16:48 ---
Confirmed.
Here's a reduced testcase (compile with -O2):
===
typedef int INT;
int i;
int foo(INT j) { return (i>0 ? (i<3?j:0) : i) - i; }
===
(The stupid typedef is indeed crucial.)
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2005-04-13 16:48:45
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20929
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-13 16:54 --- This was fixed by a patch by Mark Mitchell on 2005-04-01. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug c++/13684] local static object variable constructed once but ctors and dtors called multiple times on same memory when called in multiple threads
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 16:56 --- (In reply to comment #19) > I want to emphasize here again one principle of C and C++: Trust the > programmers, and allow them to do low-level tunings for performance. Or what > is > the purpose of C++ (when compared with "high-level" languages like Python)? > This "fix" rid the programmers of their right to choose the way they want. > > Unless the future C++ standard demands protection in such cases, I do not > think > the compiler-provided mechanism a good idea. I would agree with you. Btw, what is the approach adopted in case the app. is a single threaded one? Are the locks still taken in this case? Also, if it is an mt-app. but the programmer is sure that that particula function will NOT be reentrant, why should he pay the penalty of a lock or/and a check every time the function is called? Stroustrup continuously emphasised that C++ was designed to be as fast if not faster than C in most respects, and I guess that's why C++ is gaining popularity. If it were to use the java approach then it would be just another bloat-language -Dhruv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13684
[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot
--- Additional Comments From mueller at kde dot org 2005-04-13 16:57 --- can we think about retargeting fixing the optimisation for 4.0.1 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug c++/20996] New: friend class declaration in namespace wrong in template class with specialisation
The code below won't compile. It behaves as though the line
class val { friend class rec; } is erroneously declaring a 'struct rec' in
the global namespace. (Uncomment the other use of rec to see this.) The error
message from 4.0 is:
y.cpp: In function 'int main(int, char**)':
y.cpp:29: error: 'rec' was not declared in this scope
y.cpp:29: error: expected `;' before 'r'
This shows up on 3.4.3, 3.4.4 and 4.0.
David
namespace ns
{
template
class val
{
T get(const unsigned char *data) const;
public:
friend class rec; // see 7.3.1.2
val() { }
};
template<>
inline float val::get(const unsigned char *data) const
{ return *reinterpret_cast(data); }
class rec
{
public:
const unsigned char *data;
};
}
using namespace ns;
int
main(int argc, char **argv)
{
rec r;
//::rec s;
return 0;
}
--
Summary: friend class declaration in namespace wrong in template
class with specialisation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drtr at dial dot pipex dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20996
[Bug libstdc++/20979] __gnu_cxx::bitmap_allocator export pruning
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 17:02
---
Subject: Re: __gnu_cxx::bitmap_allocator export pruning
--- bkoz at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
> --- Additional Comments From bkoz at gcc dot gnu
> dot org 2005-04-13 16:32 ---
> I posit that this usage of static local variables,
> as written, is thread safe
> with gcc-4.0.x compilers. (Since resolution of
> c++/13684).
>
> ! _Mutex*
> ! _M_get_mutex()
> ! {
> ! static _Mutex _S_mutex;
> ! return &_S_mutex;
> ! }
>
> This object is only constructed (and initialized)
> once. After initial
> construction, a pointer to the initial object is
> returned. Don't let the
> simplicity of this solution fool you!
>
> This change actually improves portability for
> initialization, especially on
> non-SVR4 platforms, where order of initalization of
> static objects may differ
> from expectations.
hmmm. then the code should be correct
However, wrt efficiency, there will be a penalty
beause you need to acquire a mutex to acquire a mutex!
Ironical isn't it
wrt initialization order, yes, this is definitely an
improvement.
Just as a thought, I was wondering if it could be made
global at the namespace level. then, all this wouldn't
matter, and initialization orders would also be
guaranteed
OT: WRT the static initialization problem.
Also, to make the check on whether guard has been
set/reset, a lock must be prepended before it right?
So, that would stall the bus for some time
Probably not what one would wish for ideally, but I'm
generally against the language protecting against
these kind of things.
>
> -benjamin
>
>
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching
> someone who is.
>
-Dhruv Matani
http://www.geocities.com/dhruvbird/
__
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20979
[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases
--- Additional Comments From law at redhat dot com 2005-04-13 17:11 --- Subject: Re: [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases On Wed, 2005-04-13 at 13:04 +, dnovillo at redhat dot com wrote: > --- Additional Comments From dnovillo at redhat dot com 2005-04-13 13:03 > --- > Subject: Re: [4.0 Regression] jump threading on trees is slow with switch > statements with large # of cases > > On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote: > > > That mental model doesn't work right now with the way DOM & the > > jump threader because they are too tightly intertwined. > > > The link that you have still not shown me is why doesn't this > mental model work for the jump threader. That's why I said that > I need to run the threader myself and see why it needs all these > additional crutches. That the model we wont to go to -- but it's certainly not where we are today. Why? Because the jump threader exposes more optimization opportunities for DOM (including constant and copy propagations) and DOM exposes more opportunities for the threader. They are inherently tied together with their current structure. > > If the code has been cleaned up of redundancies, copies > propagated, names have known values and ranges are set, then I > don't see why we would need all the extra baggage. Because threading exposes new opportunities to perform constant and copy propagation and redundancy elimination. > > > The iteration step we see today would turn into a worklist. > > ie, after we thread jumps, we walk through the IL for PHIs > > which represent a copy that can be propagated. > > > Ah, here's something specific I don't follow. Why would you have > these PHIs anymore? If all the arguments were ultimately > equivalent, then the various propagators are bound to have > removed them. If not, that sounds like a bug in them. They are exposed as a result of jump threading. For example we might have something like: BB 3: x3 = PHI (x2 (0), x1 (1), x1 (2)); [ ... ] if (cond) goto X, else goto Y If jump threading manages to determine where the conditional will go when BB3 is reached via BB0, then we'll be able to remove the PHI argument associated with the edge from BB0 to BB3. That in turn exposes a copy propagation opportunity (x3 = x1). Or when we thread a jump we might expose a new redundancy because the dominator graph changed. Whenever we expose a redundancy we also expose a copy propagation opportunity. > > > What's nice about this is the bulk of DOM as we know it today > > disappears along with the expensive iteration in the case when > > jumps are threaded. We just need the right APIs for copy > > propagation and value handles. > > > Again, why? The propagators are supposed to have done this > already. They are all supposed to work in conditional regions. You really don't seem to understand what the threader does and how its actions can expose new optimization opportunities. I might suggest you look very closely at what happens for a test like 20030714-2.c which is derived from real code. As we thread jumps, we expose new redundancy elimination opportunities, which in turn expose new copy propagation opportunities. > > We could still potentially use ASSERT_EXPRs to encode > > information about edge equivalences, though we probably would > > still want the ASSERT_EXPR to appear as statement rather than > > the RHS of a MODIFY_EXPR. > > > Odd, the nice thing about assertions being on the RHS is that you > pin their result to a specific SSA name that you then get to use > at every place naturally dominated by the assertion. > > If you could give me a concrete test case that I could sink my > teeth in, that'd be great. Go back the PR I've referenced twice. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
[Bug c++/20996] friend class declaration in namespace wrong in template class with specialisation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 17:38 --- Fixed on the mainline (for 4.1.0), there might be a dup of this bug somewhere with the rest of the friend bugs in GCC. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20996
[Bug target/20924] [4.0 regression] inline float divide does not set correct fpu status flags
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 17:39 --- Fixed at least on the mainline. -- What|Removed |Added Summary|[4.0/4.1 regression] inline |[4.0 regression] inline |float divide does not set |float divide does not set |correct fpu status flags|correct fpu status flags http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20924
[Bug tree-optimization/20994] [4.1 regression] ICE with -ftree-vectorize
-- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20994
[Bug libgcj/20993] GCC/GCJ not creating proper symbols for inline native CNI code
-- What|Removed |Added Component|c++ |libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug libgcj/20997] New: gij -verbose fails with a VM error
When running gij with the -verbose option, it immediately fails with the following error: $ gij -verbose C1 libgcj: couldn't create virtual machine Same for '-verbose:class', '--verbose', or any other verbose option. Reproduced on 4.0.0 and HEAD. -- Summary: gij -verbose fails with a VM error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ziga dot mahkovec at klika dot si CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20997
[Bug libgcj/20997] gij -verbose fails with a VM error
--- Additional Comments From ziga dot mahkovec at klika dot si 2005-04-13 17:49 --- Created an attachment (id=8619) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8619&action=view) Fix for the parsing code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20997
[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 17:50 --- It does not ICE with "3.4.0 20040116" but does with "3.4.0 (release)". -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail|3.4.2 3.4.4 |3.4.2 3.4.4 3.4.0 Known to work|3.3.2 |3.3.2 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-04-13 17:50:06 date|| Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20995
[Bug debug/20985] building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions
--- Additional Comments From drow at false dot org 2005-04-13 17:50 --- Subject: Re: New: building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions On Wed, Apr 13, 2005 at 05:22:07AM -, herbert at 13thfloor dot at wrote: > ./configure --enable-languages=c --disable-nls --disable-threads > --disable-shared --disable-checking --prefix=/usr --target=mips-linux > make TARGET_LIBGCC2_CFLAGS='-Dinhibit_libc -D__gthr_posix_h' > > results in ... > /gcc-3.3.5/gcc/xgcc -B/gcc-3.3.5/gcc/ -B/usr/mips-linux/bin/ > -B/usr/mips-linux/lib/ -isystem /usr/mips-linux/include -O2 -DIN_GCC > -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes > -Wmissing-prototypes -isystem ./include -fPIC -g -DIN_LIBGCC2 > -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I. -I./. -I./config > -I./../include -DL_divdi3 -c ./libgcc2.c -fexceptions -fnon-call-exceptions > -o > libgcc/./_divdi3.o > /root/tmp/ccI71cbx.s: Assembler messages: > /root/tmp/ccI71cbx.s:956: Error: operation combines symbols in different > segments > > 955.4byte $LASFDE1-$Lframe1 > 956.4byte $LFB4-. > 957.4byte $LFE4-$LFB4 > > (removing the '-.' in that line *G* makes it work with gas 2.15.94.0.2.2) The feature was removed from the assembler, because it is not ABI compliant. This is fixed in GCC 3.4 and later. You can just delete the definition in config/mips/linux.h that causes this. ASM_PREFERRED_EH_DATA_FORMAT or something similar, I don't remember the spelling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20985
[Bug debug/20985] building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions
--- Additional Comments From drow at false dot org 2005-04-13 17:51 --- Subject: Re: building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions On Wed, Apr 13, 2005 at 09:46:26AM -, pinskia at gcc dot gnu dot org wrote: > Component|bootstrap |debug BTW, this has little to do with debugging; it's unwind information, which is runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20985
[Bug libgcj/20997] gij -verbose fails with a VM error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 17:52 --- Fixed already by: 2005-04-07 Thomas Fitzsimmons <[EMAIL PROTECTED]> * prims.cc (parse_verbose_args): Fix verbose argument parsing. http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00717.html http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00716.html -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20997
[Bug middle-end/20985] building mips/64 cross compiler on x86 produces incorrect assembler code for _divdi3 with -fnon-call-exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 17:53 --- Closing as fixed then. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|debug |middle-end Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20985
[Bug middle-end/20965] [4.1 Regression] GCC can no longer build itself on ppc-darwin
-- What|Removed |Added Severity|normal |critical Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20965
[Bug java/17092] gcj should use unlock_getc instead of getc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:00 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17092
[Bug debug/20998] New: GCC does not emit debug info for variables in anonymous unions
Here is the simple C++ program :
int main()
{
union {
int z;
unsigned int w;
}; w = 0;
}
--
Summary: GCC does not emit debug info for variables in anonymous
unions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug tree-optimization/18178] Missed opportunity for removing bounds checking
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:06 --- Now the problem is that we don't remove the extra load of a->length because of aliasing. -- What|Removed |Added Status|SUSPENDED |NEW Keywords||alias Last reconfirmed|2005-02-08 19:15:05 |2005-04-13 18:06:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178
[Bug tree-optimization/19659] GCC does not remove an "if" statement that never triggers.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:10 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19659
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- Bug 19721 depends on bug 19659, which changed state. Bug 19659 Summary: GCC does not remove an "if" statement that never triggers. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19659 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/20913] copy-prop does not fold conditionals
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 18:14 --- Just checked in a patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug tree-optimization/20702] [tcb] ASSERT_EXPRs are not inserted when a certain "if" statement is present.
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 18:14 --- Just checked in a patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
[Bug tree-optimization/19789] tree optimizers do not know that constant global variables do not change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:15 --- Fixed on the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
-- Bug 19721 depends on bug 19789, which changed state. Bug 19789 Summary: tree optimizers do not know that constant global variables do not change http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19789 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
[Bug tree-optimization/20913] copy-prop does not fold conditionals
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
[Bug tree-optimization/20702] [tcb] ASSERT_EXPRs are not inserted when a certain "if" statement is present.
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
[Bug debug/20998] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:18 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-13 18:18:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug debug/20998] [3.4/4.0/4.1 Regression] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:21 --- This is a regression from 3.3.3. -- What|Removed |Added Keywords||wrong-debug Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Summary|GCC does not emit debug info|[3.4/4.0/4.1 Regression] GCC |for variables in anonymous |does not emit debug info for |unions |variables in anonymous ||unions Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug debug/20998] GCC does not emit debug info for variables in anonymous unions
--- Additional Comments From dpatel at apple dot com 2005-04-13 18:19 --- Subject: Re: GCC does not emit debug info for variables in anonymous unions It is because of ALIAS_DECL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20998
[Bug tree-optimization/20514] hoisting of label out of jumptable would take place at cse, should happen at trees
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
18:30 ---
Two things, we just don't jump thread.
Another testcase:
int i;
int main()
{
for (;;)
{
switch (i)
{
case 5:
i = 4;
break;
default:
return 0;
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20514
[Bug tree-optimization/20999] New: store should not be done if we don't change its value
int i;
void f()
{
int t = i;
if(t == 4)
t = 3;
i = t;
}
void f1()
{
if (i == 4)
i = 3;
}
--
Summary: store should not be done if we don't change its value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20999
[Bug tree-optimization/21000] New: store should not be done if we don't change its value
Like PR 20999 but this time the function should be empty which it is on the RTL
level:
int i;
void f()
{
int t = i;
i = t;
}
--
Summary: store should not be done if we don't change its value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
[Bug tree-optimization/21000] store should not be done if we don't change its value
-- What|Removed |Added Severity|normal |enhancement Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
[Bug tree-optimization/20999] store should not be done if we don't change its value
-- What|Removed |Added Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20999
[Bug fortran/20990] Segmentation fault
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-13 18:34 --- With -fdefault-integer-8: $ gfc -c -fdefault-integer-8 pr20990.f pr20990.f: In function jonct: pr20990.f:280: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:152 Without that: $ gfc -c pr20990.f pr20990.f: In function jonct: pr20990.f:294: internal compiler error: Segmentation fault I'm using dichotomic debugging to find what goes wrong right now. But I have a doubt: did someone actually *write* that code? -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-13 18:34:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20990
[Bug tree-optimization/21000] store should not be done if we don't change its value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
18:36 ---
Three more cases:
void f1(int *i)
{
*i = *i;
}
int j;
void f2()
{
j = j;
}
int *k;
void f3()
{
*k = *k;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
[Bug middle-end/20995] [3.4 regression] ICE in const_binop, at fold-const.c:1391
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 18:59 --- : Search converges between 2004-01-25-trunk (#440) and 2004-01-26-trunk (#441). : Search converges between 2004-05-20-trunk (#457) and 2004-05-23-trunk (#458). Looking at the construct, I almost want to say this was "fixed" by: 2004-05-20 Roger Sayle <[EMAIL PROTECTED]> PR middle-end/3074 * fold-const.c (strip_compound_expr): Delete function. (count_cond): Delete function. (fold_binary_op_with_conditional_arg): Only perform transformations "a + (b?c:d) -> b ? a+c : a+d" and "(b?c:d) + a -> b ? c+a : d+a" when a is constant. This greatly simplifies this routine. -- What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20995
[Bug libgcj/20993] GCC/GCJ not creating proper symbols for inline native CNI code
--- Additional Comments From steve at netfuel dot com 2005-04-13 19:03 --- This as also been duplicated using the mingw binary release of gcc-3.4.2-20040916-1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
[Bug tree-optimization/21001] New: VRP is weak when the tested variable in a COND_EXPR is used in the COND_EXPR.
Consider:
int
foo (int a)
{
int b = a != 0;
if (b)
if (a != 0)
return 1;
return 0;
}
With "-O2 -ftree-no-dominator-opts", VRP generates:
foo (a)
{
int b;
int D.1153;
:
b_3 = a_2 != 0;
if (b_3 != 0) goto ; else goto ;
:;
if (a_2 != 0) goto ; else goto ;
:;
D.1153_6 = 1;
goto ();
:;
D.1153_5 = 0;
# D.1153_1 = PHI ;
:;
return D.1153_1;
}
Note that the second "if" statement is always true,
but VRP does not notice that.
Forward-propagating "a_2 != 0" into the first "if" statement will do
the desired optimization.
--
Summary: VRP is weak when the tested variable in a COND_EXPR is
used in the COND_EXPR.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: kazu at cs dot umass dot edu
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21001
[Bug tree-optimization/21000] store should not be done if we don't change its value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13 19:16 --- We just don't generate any RTL for "i = i". The optimization for f in comment #0 happens in combine for 3.4.0, so maybe fold could do it, I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
[Bug tree-optimization/21000] store should not be done if we don't change its value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
19:18 ---
One more thing, we miss a sibcal optimization due to this:
int i;
int g(void) __attribute__((pure));
int f()
{
int t = i;
int t1 = g();
i = t;
return t1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21000
[Bug rtl-optimization/21002] New: RTL prologue and basic-block reordering pessimizes delay-slot filling
This with LAST_UPDATED "Wed Apr 13 18:35:48 UTC 2005", just after committing CRIS prologue as RTL. Compare the assembly of the attached file (a pruned version corresponding to the fp-bit libgcc object _pack_df.o) compiled at -O2 with to a few minutes before that LAST_UPDATED. Also observable with -mno-prologue-epilogue as follows: --- packd.s 2005-04-13 21:13:39.448893527 +0200 +++ packd.s.proepi 2005-04-13 21:13:19.986146213 +0200 @@ -4,6 +4,8 @@ .global ___pack_d .type ___pack_d, @function ___pack_d: + subq 32,$sp + movem $r5,[$sp] move.d [$r10+12],$r2 move.d [$r10+16],$r3 move.d [$r10+4],$r5 @@ -15,21 +17,19 @@ ___pack_d: beq .L5 cmpq 2,$r9 - beq .L37 - clear.d $r0 - + beq .L7 + nop test.d $r2 ax test.d $r3 - beq .L38 - clear.d $r1 - + beq .L7 + nop move.d [$r10+8],$r4 The first two delay-slots aren't filled any more, when having an RTL prologue (and epilogue). The unexpected/unwanted difference goes away with -fno-reorder-blocks. Issue noted here awaiting further investigation. -- Summary: RTL prologue and basic-block reordering pessimizes delay-slot filling Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21002
[Bug fortran/20990] Segmentation fault
--- Additional Comments From antoine dot letellier at free dot fr 2005-04-13 19:21 --- we have a our own dialect which is preprocessed in fortran. usually we compile with g77 . antoine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20990
[Bug rtl-optimization/21002] RTL prologue and basic-block reordering pessimizes delay-slot filling
--- Additional Comments From hp at gcc dot gnu dot org 2005-04-13 19:21 --- Created an attachment (id=8620) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8620&action=view) testcase mentioned in description -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21002
[Bug ada/21003] New: Error detected at gnatmake.ads:27:1
When trying to bootstrap/build gcc off of the 4.0 branch, LAST_UPDATED: Wed Apr 13 05:09:35 UTC 2005, I get a build error when tryint to build gnat ../../xgcc -B../../ -c -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -gnatpg -gnata -I- -I../rts -I. - I/usr/local/src/branch/gcc/gcc/ada /usr/local/src/branch/gcc/gcc/ada/gnatmake.a db -o gnatmake.o +===GNAT BUG DETECTED==+ | 4.0.0 20050413 (prerelease) (sparc-unknown-linux-gnu) GCC error: | | in save_gnu_tree, at ada/utils.c:158 | | Error detected at gnatmake.ads:27:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /usr/local/src/branch/gcc/gcc/ada/gnatmake.adb /usr/local/src/branch/gcc/gcc/ada/gnatmake.ads /usr/local/src/branch/gcc/gcc/ada/gnatvsn.ads /usr/local/src/branch/gcc/gcc/ada/make.ads /usr/local/src/branch/gcc/gcc/ada/table.ads /usr/local/src/branch/gcc/gcc/ada/types.ads compilation abandoned make[4]: *** [gnatmake.o] Error 1 make[4]: Leaving directory `/usr/local/src/branch/objdir32/gcc/ada/tools' make[3]: *** [gnattools1] Error 2 make[3]: Leaving directory `/usr/local/src/branch/objdir32/gcc/ada' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/usr/local/src/branch/objdir32/sparc-linux/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/usr/local/src/branch/objdir32' make: *** [bootstrap] Error 2 -- Summary: Error detected at gnatmake.ads:27:1 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com CC: ebotcazou at libertysurf dot fr,gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-unknown-linux-gnu GCC host triplet: sparc-unknown-linux-gnu GCC target triplet: sparc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21003
