[Bug tree-optimization/22014] [4.1 Regression] ICE in do_structure_copy, at tree-ssa-structalias.c:2363

[marcus at jet dot franken dot de]

--- Additional Comments From marcus at jet dot franken dot de  2005-06-17 
07:01 ---
this code is btw generic 
 
connect (fd, (struct sockaddr*)&sockaddrinvar, sizeof(sockaddrinvar)); 
 
so it triggers in every socket client program using linux glibc. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22014

[Bug libstdc++/22102] New: Implement resolution of DR 233

[pcarlini at suse dot de]

This is to track DR 233: eventually we want the exact behavior mandated in the
resolution (e.g., probably, checks both before and after). See also:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1780.html

-- 
   Summary: Implement resolution of DR 233
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102

[Bug middle-end/22072] bizarre code for int*int/2

[pluto at agmk dot net]

--- Additional Comments From pluto at agmk dot net  2005-06-17 09:33 ---
(In reply to comment #9)
> (In reply to comment #8)
> > did i miss something in my math? 
> 
> Yes in C, % (remainder and not mod) is negative iff one of the operands is
negative.
> so it is -2*2 + -1 = -5. , integer divide in C is truncated.

[ cite ]

"The New ISO Standard for C (C9X)"

25).
The integer division and modulus operators are defined to perform
truncation *towards zero*. (In C89, it was implementation-defined whether
truncation was done towards zero or -infinity. This is (obviously)
important only if one or both operands are negative. Consider:

-22 / 7 = -3truncation towards zero
-22 % 7 = -1

-22 / 7 = -4truncation towards -infinity
-22 % 7 =  6

Both satisfy the required equation (a/b)*b + a%b == a.
The second has the advantage that the modulus is always positive
-- but they decided on the other (more Fortran-like, less Pascal-like) 
variant...)

[ /cite ]

so it's all clear now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22072

[Bug tree-optimization/21963] [4.1 Regression] ICE (Segmentation fault) with -m64

[fischer at td dot mw dot tum dot de]

--- Additional Comments From fischer at td dot mw dot tum dot de  
2005-06-17 09:44 ---
Applied above patch to my local checkout and tested. Works nicely :) 
 
Victor 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963

[Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[belyshev at depni dot sinp dot msu dot ru]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.1.0
  Known to work||4.0.0 4.0.1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 10:07:46
   date||
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug c/22065] -fdump-tree-original causes static function to emitted with the same name

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-06-17 10:24 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0 4.0.1 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 10:24:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22065

[Bug c++/18698] [3.4/4.0/4.1 regression] Error message using "using" for code not using "using" ;-)

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-06-17 11:26 
---
Not sure if this is the same bug or if it should be a new PR:

struct A {
NS::y b;
};

gives the same "using-declaration" diagnostic if compiled with -DNS= or
-DNS=std, but not otherwise.

This can be caused simply by failing to declare NS::y, e.g. by forgetting to
include a header.  The diagnostic is pretty unhelpful.


-- 
   What|Removed |Added

 CC||redi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18698

[Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2005-06-17 12:58 
---
> bug.c: In function 'foo':
> bug.c:4: internal compiler error: in get_bb_copy, at cfg.c:1078

a bunch of vectorizer testcases are failing with this error on 
i686-pc-linux-gnu and powerpc-darwin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug libgcj/22084] Divide_1 test case hangs

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2005-06-17 
13:13 ---
Confirmed, though I see a FAIL instead of a hang. It has only started 
appearing this week. It fails like:

  -1459606597
  -2147483648
  335645025
  FAIL: Divide_1 execution - source compiled test

instead of the expected:

  -2147483648
  -2147483648
  0
  0
  [...]

Note that the values are totally off.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 13:13:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084

[Bug libstdc++/22102] Implement resolution of DR 233

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 13:29:25
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22102

[Bug libgcj/22084] Divide_1 test case hangs

[dnovillo at redhat dot com]

--- Additional Comments From dnovillo at redhat dot com  2005-06-17 13:44 
---
Subject: Re:  Divide_1 test case hangs

On Fri, Jun 17, 2005 at 01:13:49PM -, rmathew at gcc dot gnu dot org wrote:

>   -2147483648
>   -2147483648
>   0
>   0
>   [...]
> 
> Note that the values are totally off.
> 
This looks somewhat familiar.  Could you try testing with
-fno-tree-vrp?


Diego.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084

[Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[hubicka at ucw dot cz]

--- Additional Comments From hubicka at ucw dot cz  2005-06-17 13:53 ---
Subject: Re:  [4.1 regression] ICE with -ftree-vectorize

> 
> --- Additional Comments From dorit at il dot ibm dot com  2005-06-17 
> 12:58 ---
> > bug.c: In function 'foo':
> > bug.c:4: internal compiler error: in get_bb_copy, at cfg.c:1078
> 
> a bunch of vectorizer testcases are failing with this error on 
> i686-pc-linux-gnu and powerpc-darwin

THe attached patch should fix it.  I wonder why it didn't show up in my
i686 regtest originally?  (are the vectorizer testcases disabled by
default or something?)


Index: tree-vect-transform.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vect-transform.c,v
retrieving revision 2.25
diff -c -3 -p -r2.25 tree-vect-transform.c
*** tree-vect-transform.c   10 Jun 2005 14:51:44 -  2.25
--- tree-vect-transform.c   17 Jun 2005 13:13:52 -
*** vect_transform_loop (loop_vec_info loop_
*** 2048,2053 
--- 2048,2054 
if (vect_print_dump_info (REPORT_DETAILS, UNKNOWN_LOC))
  fprintf (vect_dump, "=== vec_transform_loop ===");
  
+   initialize_original_copy_tables ();

/* Peel the loop if there are data refs with unknown alignment.
   Only one data ref with unknown store is allowed.  */
*** vect_transform_loop (loop_vec_info loop_
*** 2139,2144 
--- 2140,2147 
   until all the loops have been transformed?  */
update_ssa (TODO_update_ssa);
  
+   free_original_copy_tables ();
+ 
if (vect_print_dump_info (REPORT_VECTORIZED_LOOPS, LOOP_LOC (loop_vinfo)))
  fprintf (vect_dump, "LOOP VECTORIZED.");
  }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug target/22083] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-06-17 13:56 
---
The macro was defined for AIX 5.1 by Roger Sayle:

2003-07-04  Roger Sayle  <[EMAIL PROTECTED]>

* config/rs6000/aix51.h (TARGET_C99_FUNCTIONS): Define.
* config/rs6000/aix52.h (TARGET_C99_FUNCTIONS): Likewise.

-- 
   What|Removed |Added

 CC||roger at eyesopen dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 13:56:51
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug target/22083] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:02 ---
See  for the patch 
which caused it.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug tree-optimization/22103] New: [4.1 Regression] Statement makes a memory store .., complex

[pinskia at gcc dot gnu dot org]

Take the following function, we ICE at -O1 now:

_Complex float f(void);
void *a;

_Complex float g(void)
{
  _Complex float x = f();
  __imag__ x = 1.0;
  if (__imag__ x != 1.0)
{
  a = &x;
}
  return x;
}

The ICE we get is:
vi t.c.t.c: In function ?g?:
t.c:5: error: Statement makes a memory store, but has no V_MAY_DEFS nor 
V_MUST_DEFS
REALPART_EXPR  = x$real_11;
t.c:5: internal compiler error: verify_ssa failed.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

This is most likely the same as the ICE referenced in:
.

-- 
   Summary: [4.1 Regression] Statement makes a memory store ..,
complex
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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,rth at gcc dot gnu dot
org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22103

[Bug tree-optimization/22103] [4.1 Regression] Statement makes a memory store .., complex

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22103

[Bug c/22104] New: using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

I was minding my own business compiling some math code, the profile-generate
build worked and ran fine then I tried a profile-use build and it borked
bitching and all...

-- 
   Summary: using "-fprofile-use" on code that has HUGE amounts of
inline asm borks it
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tomstdenis at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: Linux prescott 2.6.11.11 #1 Tue May 31 09:06:43 EDT 2005
i686 In
  GCC host triplet: Linux prescott 2.6.11.11 #1 Tue May 31 09:06:43 EDT 2005
i686 In
GCC target triplet: Linux prescott 2.6.11.11 #1 Tue May 31 09:06:43 EDT 2005
i686 In


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 14:31 
---
Created an attachment (id=9104)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9104&action=view)
It's the preprocessed code that died.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|Linux prescott 2.6.11.11 #1 |
   |Tue May 31 09:06:43 EDT 2005|
   |i686 In |
   GCC host triplet|Linux prescott 2.6.11.11 #1 |
   |Tue May 31 09:06:43 EDT 2005|
   |i686 In |
 GCC target triplet|Linux prescott 2.6.11.11 #1 |i686-pc-linux-gnu
   |Tue May 31 09:06:43 EDT 2005|
   |i686 In |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug middle-end/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:36 ---
Can you show how you compiled both with -fprofile-generate and -fprofile-use?

-- 
   What|Removed |Added

  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug target/22089] [4,1 Regression] bootstrap ices / insn does not satisfy its constraints.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:39 ---
Fixed by RTH's patch in
.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-code
Summary|Divide_1 test case hangs|[4.1 Regression] Divide_1
   ||test case hangs
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-code
Summary|TARGET_C99_FUNCTIONS is |[3.4/4.0/4.1 Regression]
   |wrongly defined on AIX 5.1  |TARGET_C99_FUNCTIONS is
   ||wrongly defined on AIX 5.1
   Target Milestone|--- |3.4.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug fortran/22101] use of type(x), pointer:: next => null() causes compilation to fail with a spurious error message

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:47 ---
This is most likely the same bug as PR 16606 or PR 21370 but since I have not 
reduced it yet, I don't 
know which one for sure. 

-- 
   What|Removed |Added

  BugsThisDependsOn||16606, 21370


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22101

[Bug target/22089] [4,1 Regression] bootstrap ices / insn does not satisfy its constraints.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:49 ---
Woops the patch has not been checked in yet for some reason I thought it was.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

[Bug target/22089] [4,1 Regression] bootstrap ices / insn does not satisfy its constraints.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|REOPENED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 14:51 
---
(In reply to comment #2)
> Can you show how you compiled both with -fprofile-generate and -fprofile-use?

cc -march=prescott -fprofile-generate -Wall -W -Wshadow -I./ -O3 -funroll-loops
-fomit-frame-pointer   -c -o fp_set.o fp_set.c

Typical compile statement [just the .c and .o file names change].  I ran my
demo, then did 

rm -f *.[ao]

Then did the build again  switching "-generate" to "-use".

Tom

-- 
   What|Removed |Added

  Component|middle-end  |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug middle-end/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:52 ---
(In reply to comment #3)
One more question, what is the ICE?

-- 
   What|Removed |Added

  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug tree-optimization/22100] [4.1 regression] internal compiler error: in tree_verify_flow_info

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22100

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 14:54 
---
(In reply to comment #4)
> (In reply to comment #3)
> One more question, what is the ICE?

What is ICE and how do I figure that out?

Tom

-- 
   What|Removed |Added

  Component|middle-end  |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
14:55 ---
What is the error comming from GCC with -fprofile-use?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug ada/19382] ACATS cxb5002 simple To_Fortran test fails at runtime on s390-linux

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||alias


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19382

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2005-06-17 15:15 
---
pr19155.f produces the following error output:

At line 13 of file pr19155.f
Fortran runtime error: Range error during floating point read

AIX strtod ("", NULL) sets errno to EINVAL, as allowed by the standard ("may 
be set"); Linux and *BSD do not.  libgfortran does not expect errno to be set.


-- 
   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2005-06-12 09:21:43 |2005-06-17 15:15:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

[Bug c/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 15:32 
---
(In reply to comment #6)
> What is the error comming from GCC with -fprofile-use?

cc -march=prescott -fprofile-use -Wall -W -Wshadow -I./ -O3 -funroll-loops
-fomit-frame-pointer   -c -o fp_sqr_comba.o fp_sqr_comba.c
fp_sqr_comba.c: In function `fp_sqr_comba_small':
fp_sqr_comba.c:364: warning: 'sc0' might be used uninitialized in this function
fp_sqr_comba.c:364: warning: 'sc1' might be used uninitialized in this function
fp_sqr_comba.c:364: warning: 'sc2' might be used uninitialized in this function
fp_sqr_comba.c:1872: internal compiler error: in verify_local_live_at_start, at
flow.c:546
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/> for instructions.
Preprocessed source stored into /tmp/cc626adC.out file, please attach this to
your bugreport.
make: *** [fp_sqr_comba.o] Error 1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug rtl-optimization/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
15:36 ---
(In reply to comment #7)
> See http://bugs.gentoo.org/> for instructions.

Is there a reason why you reported this to here and not to gentoo or did gentoo 
tell you to file it here?
Also since this is only reproducible with -fprofile-use, can you attach the 
full program since we cannot 
reproduce without running it?

-- 
   What|Removed |Added

  Component|c   |rtl-optimization
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-06-17 
15:40 ---
Keeping the patch keyword and changing the patch URL, here is the fix for that
new bug: http://gcc.gnu.org/ml/fortran/2005-06/msg00240.html

-- 
   What|Removed |Added

URL|http://gcc.gnu.org/ml/fortra|http://gcc.gnu.org/ml/fortra
   |n/2005-06/msg00240.html |n/2005-06/msg00318.html


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

[Bug rtl-optimization/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 15:41 
---
Created an attachment (id=9105)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9105&action=view)
Profile data for the file that dies


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug rtl-optimization/22104] using "-fprofile-use" on code that has HUGE amounts of inline asm borks it

[tomstdenis at gmail dot com]

--- Additional Comments From tomstdenis at gmail dot com  2005-06-17 15:44 
---
(In reply to comment #8)
> (In reply to comment #7)
> > See http://bugs.gentoo.org/> for instructions.
> 
> Is there a reason why you reported this to here and not to gentoo or did
gentoo tell you to file it here?
> Also since this is only reproducible with -fprofile-use, can you attach the
full program since we cannot 
> reproduce without running it?

I've sent the profile data and I've uploaded the code to

http://libtomcrypt.org/tfm.tar.bz2

Build with:
CFLAGS="-march=prescott -fprofile-generate" make && gcc -march=prescott
-fprofile-generate -O3 -fomit-frame-pointer -funroll-loops ecc.c libtfm.a -o ecc

Then run "./ecc"

Then run "rf -f [.][ao]"

Rebuild with:

CFLAGS="-march=prescott -fprofile-use" make && gcc -march=prescott -fprofile-use
-O3 -fomit-frame-pointer -funroll-loops ecc.c libtfm.a -o ecc



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22104

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
16:20 ---
Subject: Bug 19155

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-17 16:20:30

Modified files:
libgfortran: ChangeLog 
libgfortran/io : read.c 

Log message:
PR libfortran/19155
* io/read.c (convert_real): strtod can set errno to EINVAL on an
empty string, but we shouldn't have an error in that case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.245&r2=1.246
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&r1=1.10&r2=1.11



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
16:24 ---
Subject: Bug 19155

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-17 16:23:42

Modified files:
libgfortran: ChangeLog 
libgfortran/io : read.c 

Log message:
PR libfortran/19155
* io/read.c (convert_real): strtod can set errno to EINVAL on an
empty string, but we shouldn't have an error in that case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.54&r2=1.163.2.55
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/read.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.8.10.2&r2=1.8.10.3



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

[Bug fortran/21875] [meta-bug] NIST test suite failures

[fxcoudert at gcc dot gnu dot org]

-- 
Bug 21875 depends on bug 19155, which changed state.

Bug 19155 Summary: [4.0 only] blanks not treated as zeros in 'E' format read 
(NIST FM110.FOR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

   What|Old Value   |New Value

 Status|WAITING |NEW
 Status|NEW |RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21875

[Bug libfortran/19155] [4.0 only] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-06-17 
16:24 ---
Closed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[fxcoudert at gcc dot gnu dot org]

-- 
Bug 19292 depends on bug 19155, which changed state.

Bug 19155 Summary: [4.0 only] blanks not treated as zeros in 'E' format read 
(NIST FM110.FOR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155

   What|Old Value   |New Value

 Status|WAITING |NEW
 Status|NEW |RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292

[Bug tree-optimization/22103] [4.1 Regression] Statement makes a memory store .., complex

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-06-17 17:05 
---
For reference ACATS FAIL with the same ICE are cxg1003 and cxg2007.

/home/guerby/work/gcc/build/build-20050617T085204/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050617T085204/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050617T085204/gcc/testsuite/ada/acats/support
cxg1003.adb
cxg1003.adb: In function 'CXG1003':
cxg1003.adb:63: error: Statement makes a memory store, but has no V_MAY_DEFS nor
V_MUST_DEFS
IMAGPART_EXPR  = SR.373_64;
+===GNAT BUG DETECTED==+
| 4.1.0 20050617 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| verify_ssa failed.   |
| Error detected at cxg1003.adb:478:5  |

/home/guerby/work/gcc/build/build-20050617T085204/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050617T085204/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050617T085204/gcc/testsuite/ada/acats/support
cxg2007.adb
cxg2007.adb: In function 'CXG2007':
cxg2007.adb:68: error: Statement makes a memory store, but has no V_MAY_DEFS nor
V_MUST_DEFS
IMAGPART_EXPR  = SR.460_62;
+===GNAT BUG DETECTED==+
| 4.1.0 20050617 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| verify_ssa failed.   |
| Error detected at cxg2007.adb:291:5  |


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22103

[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-06-17 
17:05 ---
I can only reproduce this with 'make check'.
When I compile the test case by hand with an installed compiler,
it works.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084

[Bug ada/22105] New: ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-im.c:219

[laurent at guerby dot net]

/home/guerby/work/gcc/build/build-20050617T085204/gcc/xgcc -c
-B/home/guerby/work/gcc/build/build-20050617T085204/gcc/ -gnatws -O2
-I/home/guerby/work/gcc/build/build-20050617T085204/gcc/testsuite/ada/acats/support
cxg2018.adb
+===GNAT BUG DETECTED==+
| 4.1.0 20050617 (experimental) (x86_64-unknown-linux-gnu) GCC error:  |
| in for_each_index, at tree-ssa-loop-im.c:219 |
| Error detected at cxg2018.adb:355:5  |

-- 
   Summary: ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-
im.c:219
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22105

[Bug target/22089] [4,1 Regression] bootstrap ices / insn does not satisfy its constraints.

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-06-17 17:17 
---
For the record, the following 12 ACATS tests get the same ICE on x86-linux.

c38202a 
c3a0004 
c910001 
c940005 
c940010 
c940013 
c95086c 
c95086e 
c95086f 
c951002 
c954024 
c954026

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2005-06-17 17:22 
---
Unfortunately, the AIX 5.1 machine that was loaned to OpenEye by IBM has had to
be returned since this patch was submitted/applied in 2003.  So my only guess is
that this may have been a patch level issue with bos.adt.libm as I'm fairly
confident that our 5.1 machine had sqrtf and friends when the patch was
developed.  We do still have a 5.2 machine, and that certainly has sqrtf.
Could this be related to the version(s) of IBM's Visual Age C/C++, that was
installed on the machine?

Unfortunately, without access to a 5.1 box I'm unable to properly test the
obvious trivial change to config/rs6000/aix51.h.  Clearly, if there are flavors
of AIX 5.1 out there without sqrtf, it unsafe to define TARGET_C99_FUNCTIONS in
aix51.h.  Fortunately, such a change won't negatively affect users of AIX 5.2 or
later.

Dave, I'm happy to post an untested patch to gcc-patches if that's appropriate.
Alternatively, Lev could you try removing the five lines I added to aix51.h and
confirm that that resolves the issues you're seeing.

Many thanks in advance.  Sorry for any inconvenience.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug tree-optimization/22105] [4.1 Regression] ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-im.c:219

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|ada |tree-optimization
Summary|ACATS ICE cxg2018   |[4.1 Regression] ACATS ICE
   |for_each_index, at tree-ssa-|cxg2018 for_each_index, at
   |loop-im.c:219   |tree-ssa-loop-im.c:219
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22105

[Bug libfortran/22106] New: Dynamically linking a C program with libgfortran produces a strange error

[svrci at tbi dot univie dot ac dot at]

Test case:
#include 
int main()
{
 printf("BLAH\n");
 return 0;
}
compiling the above prog. with "gcc blah.c -o blah" creates a working 
executable.
When compiling it with "gcc blah.c -o blah -lgfortran" (which should not change
anything (?)) the output can no longer be re-directed via pipe or wedge.
stracing the libgfortran linked executable shows
write(1, "\n", 5
)   = 5
close(2)= 0
close(1)= 0
close(0)= 0
munmap(0x2aaac000, 4096)= 0
exit_group(0)   = ?
Maybe the close()es are to blame, since the executable not linked against
libgfortran.so doesn't contain the close() statements. 
The behavior was observed with vanilla-gcc4.0.0 as well as with the version
shipping with fedora core 4, in 32 an 64 bit mode.
doing a "gcc blah.c ${wherever}/libgfortran.a -o blah" does work.
Strange...
best regards
Andreas

-- 
   Summary: Dynamically linking a C program with libgfortran
produces a strange error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svrci at tbi dot univie dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu (?)
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22106

[Bug libfortran/22106] Dynamically linking a C program with libgfortran produces a strange error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
18:12 ---
This basicially fixed in 4.0.1 but there might be other issues left.
This is also a dup of bug 20179.

*** This bug has been marked as a duplicate of 20179 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22106

[Bug libfortran/20179] cannot mix C and Fortran I/O

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
18:12 ---
*** Bug 22106 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||svrci at tbi dot univie dot
   ||ac dot at


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[lmakhlis at bmc dot com]

--- Additional Comments From lmakhlis at bmc dot com  2005-06-17 19:01 
---
It might be an issue with the patch level of libm -- I was testing on 5.1 ML04,
which was released in 2002 -- but I've found another machine at ML05 (released
in Oct 2003), and it still doesn't have sqrtf and friends in libm.  I don't have
access to anything newer than that right now.

I doubt it's related to Visual Age. VAC's implementation of the standard C++
library, /usr/lib/libC.a, does have sqrtf and friends -- but I'm not linking
with it when using GCC.

Before submitting the bug report, I tried removing the macro definition in
aix51.h, and it does solve the problem.  There is a related C++-specific problem
that still isn't solved, but maybe that merits a separate PR.  The problem is:

If you have C++ code that uses std::sqrt(float) and build a dynamically linked
executable on AIX 5.1, then bring it over to AIX 5.2, it won't run, because
sqrtf() is now in libm, but not in libstdc++.  This doesn't seem to be a problem
on other platforms (for example, a program compiled on Solaris 8, against
sqrtf() in libstdc++, runs fine on Solaris 10, with sqrtf() in libm), but on AIX
the dynamic loader looks for a symbol only in a specific library.  I am guessing
it's a difference between COFF and ELF?

As a side point, TARGET_C99_FUNCTION isn't defined on any Solaris platforms.  I
think it's okay to define it on Solaris 9 and up?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
19:05 ---
(In reply to comment #4)
> If you have C++ code that uses std::sqrt(float) and build a dynamically linked
> executable on AIX 5.1, then bring it over to AIX 5.2, it won't run, because
> sqrtf() is now in libm, but not in libstdc++.  This doesn't seem to be a 
> problem
> on other platforms (for example, a program compiled on Solaris 8, against
> sqrtf() in libstdc++, runs fine on Solaris 10, with sqrtf() in libm), but on 
> AIX
> the dynamic loader looks for a symbol only in a specific library.  I am 
> guessing
> it's a difference between COFF and ELF?

That is not a bug, you cannot do that as libstdc++ is not forward compatiable, 
this is also happens on 
Darwin (Mac OS X).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-17 
19:13 ---
> As a side point, TARGET_C99_FUNCTION isn't defined on any Solaris platforms.  
> I
> think it's okay to define it on Solaris 9 and up?

Only Solaris 10 has full C99 math support out of the box (and after a bit of
tweaking to make it usable for GCC).

-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug target/22083] [3.4/4.0/4.1 Regression] TARGET_C99_FUNCTIONS is wrongly defined on AIX 5.1

[lmakhlis at bmc dot com]

--- Additional Comments From lmakhlis at bmc dot com  2005-06-17 19:32 
---
Andrew: I am trying to run older (5.1) programs on a newer (5.2) system, not
vice versa -- why would that require forward (rather than backward) 
compatibility?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22083

[Bug ada/21959] [4.1 Regression] Ada depends on signed overflow

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-17 
19:56 ---
Well, it seems to me that the culprit is fold, no?

else if (!in_gimple_form
 && TREE_INT_CST_HIGH (arg1) == signed_max_hi
 && TREE_INT_CST_LOW (arg1) == signed_max_lo
 && TYPE_UNSIGNED (TREE_TYPE (arg1))
 /* signed_type does not work on pointer types.  */
 && INTEGRAL_TYPE_P (TREE_TYPE (arg1)))
  {
/* The following case also applies to X < signed_max+1
   and X >= signed_max+1 because previous transformations.  */
if (code == LE_EXPR || code == GT_EXPR)
  {
tree st0, st1;
st0 = lang_hooks.types.signed_type (TREE_TYPE (arg0));
st1 = lang_hooks.types.signed_type (TREE_TYPE (arg1));
return fold
  (build2 (code == LE_EXPR ? GE_EXPR: LT_EXPR,
   type, fold_convert (st0, arg0),
   fold_convert (st1, integer_zero_node)));
  }
  }

(gdb) p debug_tree(arg0)
 
unit size 
user align 8 symtab 0 alias set -1 precision 8 min  max  RM size 
pointer_to_this >
unsigned ignored QI file ../../asets.adb line 3 size  unit size 
align 8 context  initial
>
$13 = void
(gdb) p debug_tree(arg1)
  constant
invariant 127>
$14 = void
(gdb) p code
$15 = LE_EXPR


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959

[Bug ada/21959] [4.1 Regression] Ada depends on signed overflow

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
20:02 ---
(In reply to comment #8)
> Well, it seems to me that the culprit is fold, no?

No because Ada front-end is creating:
signed_char <= 127 which is always true, removing this from fold would not 
change the problem as it 
will still be optimized away.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959

[Bug c++/22107] New: Type checking seems to break with string operator=

[weage98 at yahoo dot com]

The following code compiles with an error:

#include 

int main() {

  std::string s = 1234;

}

while this code compiles and runs, but produces garbage results:

#include 

int main() {

  std::string s;
  s = 1234;

}

-- 
   Summary: Type checking seems to break with string operator=
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weage98 at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: gnu/linux i686


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22107

[Bug c++/22107] Type checking seems to break with string operator=

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
20:17 ---
Invalid, and here is why:
  std::string s = 1234;

trys to call a constructor and not operator=.

s = 1234; calls operator= where the type is char so 1234 is converted to char 
and then calls the 
operator=.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22107

[Bug c/22052] [4.0/4.1 Regression] redefinition of inline function succeeds

[echristo at redhat dot com]

--- Additional Comments From echristo at redhat dot com  2005-06-17 20:21 
---
Here are the 4 testcases that I've been using to test, the first two you've
seen. (and no, the dg stuff isn't done yet, but that's merely to make the
testsuite happy.)

test1:
/* { dg-do compile } */
/* This test is expected to fail with an error for the redefinition of foo.
   This violates the constraint of 6.9#3 (no more than one external definition
   of an identifier with internal linkage in the same translation unit).  */
static inline int foo(void) { return 1; }
static inline int foo(void) { return 0; } /* { dg-error "" } */

test2:
/* { dg-do compile } */
/* This test should compile successfully.  */
extern inline int foo(void) { return 0; }
inline int foo (void) { return 1; }

test3:
/* { dg-do compile } */
/* This testcase should fail since we're redefining foo in the same
   translation unit.  */
extern inline int foo(void) { return 0; }
inline int foo (void) { return 1; }
int foo (void) { return 2; } /* { dg-error "error: redefinition of 'foo'" } */

test4:
/* { dg-do compile } */
/* This testcase should fail since we're redefining foo in the same
   translation unit.  */
int foo (void) { return 2; }
extern inline int foo (void) { return 1; }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22052

[Bug ada/21959] [4.1 Regression] Ada depends on signed overflow

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-17 
20:23 ---
> No because Ada front-end is creating:
> signed_char <= 127 which is always true, removing this from fold would not
> change the problem as it will still be optimized away.

Where do you see signed_char?  The type 0x556d9144 is unsigned.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959

[Bug target/22089] [4.1 Regression] bootstrap ices / insn does not satisfy its constraints.

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-06-17 20:32 
---
All ACATS fail are fixed by RTH patch.

http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01046.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

Bug on sizeof(void) == 1, must be undefined or negative, == -100000.

[jc-nospam]

Please, to run this script of 5 lines:

#!/bin/sh
cat > bug_void.c <

[Bug target/22089] [4.1 Regression] bootstrap ices / insn does not satisfy its constraints.

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-06-17 20:35 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22089

[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
20:37 ---
(In reply to comment #10)
> > No because Ada front-end is creating:
> > signed_char <= 127 which is always true, removing this from fold would not
> > change the problem as it will still be optimized away.
> 
> Where do you see signed_char?  The type 0x556d9144 is unsigned.

Woops, I must have read something wrong.
This is still a bug in the VRP.
C Testcase:
unsigned char c[0xFF];
void f(void)
{
  unsigned char i;
  c[128] = 128;
  i = 0;
  while (1)
  {
if (((signed char) i) < 0) break;
c[i] = ' ';
i++;
  }
}

-- 
   What|Removed |Added

 CC||dnovillo at gcc dot gnu dot
   ||org
  Component|ada |tree-optimization
Summary|[4.1 Regression] Ada depends|[4.1 Regression] vrp
   |on signed overflow  |miscompiles Ada front-end,
   ||drops loop exit test in
   ||well-defined wrap-around
   ||circumstances


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959

[Bug target/19889] g++.old-deja/g++.law/profile1.C execution test fails on ia64-hpux

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
20:46 ---
Subject: Bug 19889

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-17 20:45:51

Modified files:
gcc: ChangeLog 
gcc/config/ia64: hpux.h ia64.c ia64-protos.h ia64.md 

Log message:
PR target/19889
* config/ia64/hpux.h (FUNCTION_PROFILER): New (dummy).
(PROFILE_HOOK): New.
(PROFILE_BEFORE_PROLOGUE): Undef.
(NO_PROFILE_COUNTERS): New.
* config/ia64/ia64-protos.h (ia64_profile_hook): New.
* config/ia64/ia64.c (ia64_compute_frame_size): Add ifdef.
(gen_mcount_func_rtx): New.
(ia64_profile_hook): New.
* config/ia64/ia64.md (ip_value): New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9173&r2=2.9174
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/hpux.h.diff?cvsroot=gcc&r1=1.51&r2=1.52
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.376&r2=1.377
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64-protos.h.diff?cvsroot=gcc&r1=1.74&r2=1.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.md.diff?cvsroot=gcc&r1=1.153&r2=1.154



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19889

[Bug tree-optimization/22103] [4.1 Regression] Statement makes a memory store .., complex

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 20:47:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22103

[Bug c/22052] [4.0/4.1 Regression] redefinition of inline function succeeds

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-06-17 
20:48 ---
Subject: Re:  [4.0/4.1 Regression] redefinition of inline function
 succeeds

On Fri, 17 Jun 2005, echristo at redhat dot com wrote:

> Here are the 4 testcases that I've been using to test, the first two you've
> seen. (and no, the dg stuff isn't done yet, but that's merely to make the
> testsuite happy.)

These results seem OK.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22052

[Bug tree-optimization/21959] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
20:54 ---
Why does ivcanon/tree-ssa-loop-niter gets this correct (at 128) but VRP cannot.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959

Re: Bug on sizeof(void) == 1, must be undefined or negative, == -100000.

[Andrew Pinski]

On Jun 17, 2005, at 4:33 PM, [EMAIL PROTECTED] wrote:


Please, to run this script of 5 lines:

#!/bin/sh
cat > bug_void.c <

This is invalid code and a GNU extension to take the sizeof(void).  The 
reason

why GCC defines it as 1 is because you can do the following:
void *a;
a++;

If you want to error out on GNU extensions, use -pedantic-errors.

Thanks,
Andrew Pinski

[Bug tree-optimization/22105] [4.1 Regression] ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-im.c:219

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
21:16 ---
The following should fix it, I am testing it right now:
Index: tree-ssa-loop-im.c
===

RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-im.c,v
retrieving revision 2.45
diff -u -p -r2.45 tree-ssa-loop-im.c
--- tree-ssa-loop-im.c  7 Jun 2005 12:01:29 -   2.45
+++ tree-ssa-loop-im.c  17 Jun 2005 21:14:25 -
@@ -202,6 +202,7 @@ for_each_index (tree *addr_p, bool (*cbc
case STRING_CST:
case RESULT_DECL:
case VECTOR_CST:
+   case COMPLEX_CST:
  return true;
 
case TARGET_MEM_REF:


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 21:16:28
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22105

[Bug c++/22107] Type checking seems to break with string operator=

[weage98 at yahoo dot com]

--- Additional Comments From weage98 at yahoo dot com  2005-06-17 21:27 
---
Ok.  This also compiles without warnings:

#include 

int main() {

  std::string s;
  long l = 1234;
  s = l;

}

Aparently the compiler is doing automatic type conversion from long to char;
however, it does not warn about this with the following options enabled:  -Wall
-pedantic -W -Wconversion 

I don't see an operator=(long) definition for string in libstdc++.

Is there a warning option that I am missing here?  Has this warning been
included in newer releases?

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22107

Re: Bug on sizeof(void) == 1, must be undefined or negative, == -100000.

[jc-nospam]

On Jun 17, 2005, at 17:05:37, [EMAIL PROTECTED] wrote:

> This is invalid code and a GNU extension to take the sizeof(void).  The 
> reason
> why GCC defines it as 1 is because you can do the following:
> void *a;
> a++;
>
> If you want to error out on GNU extensions, use -pedantic-errors.
>
> Thanks,
> Andrew Pinski

To imagine the worst situation:

char *x = (char *)0xBAD0DAD0;
x++; // -> x = 0xBAD0DAD1 (adding +1)
int *y = x;  // -> y = 0xBAD0DAD1
y++; // -> y = 0xBAD0DAD5 (adding +4, sizeof(int)==4 )
void *z = y; // -> z = 0xBAD0DAD5
z++; // adding +0? adding +1? adding +4? abort this error?

Sincerely yours, J.C.

[Bug c++/22107] Type checking seems to break with string operator=

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
21:29 ---
(In reply to comment #2)
> Aparently the compiler is doing automatic type conversion from long to char;
> however, it does not warn about this with the following options enabled:  
> -Wall
> -pedantic -W -Wconversion 

Yes which is what the C++ standard requires.

> Is there a warning option that I am missing here?  Has this warning been
> included in newer releases?

The warning is filed under PR 18821, I had forgot to mention that.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22107

Re: Bug on sizeof(void) == 1, must be undefined or negative, == -100000.

[Andrew Pinski]

On Jun 17, 2005, at 5:27 PM, [EMAIL PROTECTED] wrote:


On Jun 17, 2005, at 17:05:37, [EMAIL PROTECTED] wrote:


void *z = y; // -> z = 0xBAD0DAD5
z++; // adding +0? adding +1? adding +4? abort this error?


Since this is a GNU extension, GCC defines as adding 1.  See the  
documentation

where this is documented.
http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Pointer-Arith.html#Pointer- 
Arith



 In GNU C, addition and subtraction operations are supported on  
pointers to void and on pointers to functions. This is done by treating  
the size of a void or of a function as 1.


 A consequence of this is that sizeof is also allowed on void and on  
function types, and returns 1.


The option -Wpointer-arith requests a warning if these extensions are  
used.


-- Pinski

[Bug tree-optimization/21817] [4.0 Regression] ICE in for_each_index, at tree-ssa-loop-im.c:200

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
21:34 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21817

[Bug tree-optimization/22105] [4.1 Regression] ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-im.c:219

[pinskia at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
21:34 ---
Subject: Bug 22105

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-17 21:33:52

Modified files:
gcc: ChangeLog tree-ssa-loop-im.c 

Log message:
2005-06-17  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/22105
* tree-ssa-loop-im.c (for_each_index): Handle COMPLEX_CST.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9174&r2=2.9175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-im.c.diff?cvsroot=gcc&r1=2.45&r2=2.46


--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
21:34 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22105

[Bug tree-optimization/22105] [4.1 Regression] ACATS ICE cxg2018 for_each_index, at tree-ssa-loop-im.c:219

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
21:34 ---
Subject: Bug 22105

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-17 21:33:52

Modified files:
gcc: ChangeLog tree-ssa-loop-im.c 

Log message:
2005-06-17  Andrew Pinski  <[EMAIL PROTECTED]>

PR tree-opt/22105
* tree-ssa-loop-im.c (for_each_index): Handle COMPLEX_CST.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9174&r2=2.9175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-im.c.diff?cvsroot=gcc&r1=2.45&r2=2.46



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22105

Re: Bug on sizeof(void) == 1, must be undefined or negative, == -100000.

[jc-nospam]

On Jun 17, 2005, at 17:31:34, [EMAIL PROTECTED] wrote:

> Since this is a GNU extension, GCC defines as adding 1.  See the  
> documentation
> where this is documented.
> http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Pointer-Arith.html#Pointer- 
> Arith
>
>
>   In GNU C, addition and subtraction operations are supported on  
> pointers to void and on pointers to functions. This is done by treating  
> the size of a void or of a function as 1.
>
>   A consequence of this is that sizeof is also allowed on void and on  
> function types, and returns 1.
>
> The option -Wpointer-arith requests a warning if these extensions are  
> used.
>
> -- Pinski

Conclusion: the GNU's law is:

 "void IS A byte"
(1 void == 1 byte)

-- J.C. --

[Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-06-17 22:11 
---
Fixed: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01535.html

Although I didn't see this pr before writing the patch, I like my patch
better because not all paths go through loop peeling.  Which means that
we'd do the init/free in cases that don't need it.

No, the vectorization tests are never disabled.  We *always* at least do
the compile tests.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug target/22085] [4.1 Regression] error with -fpreprocessed

[bonzini at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 22:12:27
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22085

[Bug c++/17413] [3.4 regression] local classes as template argument

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-17 
22:13 ---
Subject: Bug 17413

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-17 22:13:36

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog pt.c 
Added files:
gcc/testsuite/g++.dg/template: local5.C 

Log message:
2005-06-17  Geoffrey Keating  <[EMAIL PROTECTED]>

PR c++/17413
* pt.c (type_unification_real): Apply template type deduction even
to procedure parameters that are not dependent on a template
parameter.

Index: testsuite/ChangeLog
2005-06-17  Geoffrey Keating  <[EMAIL PROTECTED]>

PR c++/17413
* g++.dg/template/local5.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5649&r2=1.5650
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/local5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4794&r2=1.4795
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.1007&r2=1.1008



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17413

[Bug middle-end/22108] New: [4.1 Regression] intrinsic.c:2044: error: insn does not satisfy its constraints

[danglin at gcc dot gnu dot org]

stage1/xgcc -Bstage1/ -B/opt/gnu/gcc/gcc-4.1.0/hppa2.0w-hp-hpux11.11/bin/ -c   -
g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototyp
es -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror
-fno-common   -DHAVE_CONFIG_H-I. -Ifortran -I../../gcc/gcc -I../../gcc/gcc/f
ortran -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/i
nclude  ../../gcc/gcc/fortran/intrinsic.c -o fortran/intrinsic.o
../../gcc/gcc/fortran/intrinsic.c: In function 'add_functions':
../../gcc/gcc/fortran/intrinsic.c:2044: error: insn does not satisfy its constra
ints:
(insn 7670 3254 8366 0 ../../gcc/gcc/fortran/intrinsic.c:1410 (set (reg/f:SI 141
0)
(high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2] ))) 50 {*pa.md:2778} (nil)
(expr_list:REG_EQUIV (high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2] ))
(nil)))
../../gcc/gcc/fortran/intrinsic.c:2044: internal compiler error: in reload_cse_s
implify_operands, at postreload.c:391

Sign, it's been three weeks since the last successful bootstrap.

-- 
   Summary: [4.1 Regression] intrinsic.c:2044: error: insn does not
satisfy its constraints
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa2.0w-hp-hpux11.11
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22108

[Bug java/21045] Anonymous inner class constructor's exceptions can't be caught or thrown

[mckinlay at redhat dot com]

--- Additional Comments From mckinlay at redhat dot com  2005-06-17 22:59 
---
Confirmed

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-17 22:59:08
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045

[Bug middle-end/22108] [4.1 Regression] intrinsic.c:2044: error: insn does not satisfy its constraints

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2005-06-17 
23:19 ---
Hmm, seems like the insn wasn't deleted for some reason.  From
intrinsic.c.23.greg:

Reloads for insn # 3263
Reload 0: reload_in (SI) = (high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2]
))
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (reg/f:SI 1410)
reload_reg_rtx: (reg:SI 20 %r20)

...

(insn 7670 3254 8366 0 ../../gcc/gcc/fortran/intrinsic.c:1410 (set (reg/f:SI 141
0)
(high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2] ))) 50 {*pa.md:2778} (nil)
(expr_list:REG_EQUIV (high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2] ))
(nil)))

(insn 8366 7670 3263 0 ../../gcc/gcc/fortran/intrinsic.c:1410 (set (reg:SI 20 %r
20)
(high:SI (symbol_ref/v/f:SI ("*L$C0040") [flags 0x2] ))) 50 {*pa.md:2778} (nil)
(nil))



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22108

Re: [Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[Jan Hubicka]

> 
> --- Additional Comments From rth at gcc dot gnu dot org  2005-06-17 22:11 
> ---
> Fixed: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01535.html
> 
> Although I didn't see this pr before writing the patch, I like my patch
> better because not all paths go through loop peeling.  Which means that
> we'd do the init/free in cases that don't need it.

Ah, thanks for fixing that!  I just sent patch for that too, but too
late..
> 
> No, the vectorization tests are never disabled.  We *always* at least do
> the compile tests.

Weird, my scripts must have some kind of leak then.  I have to dig into
logs...

Honza
> 
> -- 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||FIXED
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug tree-optimization/22088] [4.1 regression] ICE with -ftree-vectorize

[hubicka at ucw dot cz]

--- Additional Comments From hubicka at ucw dot cz  2005-06-17 23:31 ---
Subject: Re:  [4.1 regression] ICE with -ftree-vectorize

> 
> --- Additional Comments From rth at gcc dot gnu dot org  2005-06-17 22:11 
> ---
> Fixed: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01535.html
> 
> Although I didn't see this pr before writing the patch, I like my patch
> better because not all paths go through loop peeling.  Which means that
> we'd do the init/free in cases that don't need it.

Ah, thanks for fixing that!  I just sent patch for that too, but too
late..
> 
> No, the vectorization tests are never disabled.  We *always* at least do
> the compile tests.

Weird, my scripts must have some kind of leak then.  I have to dig into
logs...

Honza
> 
> -- 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution||FIXED
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22088

[Bug middle-end/22108] [4.1 Regression] intrinsic.c:2044: error: insn does not satisfy its constraints

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
23:34 ---
This should have been fixed by:
2005-06-17  Richard Henderson  <[EMAIL PROTECTED]>

* local-alloc.c (update_equiv_regs): Update reg_equiv_init
properly when moving an initialization insn.


-- 
   What|Removed |Added

   Keywords||build, ice-on-valid-code
   Target Milestone|--- |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22108

[Bug middle-end/22108] [4.1 Regression] intrinsic.c:2044: error: insn does not satisfy its constraints

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-17 23:37 ---
Subject: Re:  [4.1 Regression] intrinsic.c:2044: error: insn does not satisfy 
its constraints

> This should have been fixed by:
> 2005-06-17  Richard Henderson  <[EMAIL PROTECTED]>
> 
> * local-alloc.c (update_equiv_regs): Update reg_equiv_init
> properly when moving an initialization insn.

Thanks, I'll update and try again.  I had just started a build with
Bernd's last reload patch reverted.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22108

[Bug target/22085] [4.1 Regression] error with -fpreprocessed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
23:48 ---
The reason why I marked this as a regression is because it causes -save-temps 
not to work.

-- 
   What|Removed |Added

  Known to fail||4.1.0
  Known to work||4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22085

[Bug tree-optimization/22100] [4.1 regression] internal compiler error: in tree_verify_flow_info

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.1.0
  Known to work||4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22100

[Bug libstdc++/22109] New: [4.0.1 Regression] /home/dave/opt/gnu/bin/ld: BFD 2.16.91 20050612 internal error

[danglin at gcc dot gnu dot org]

/bin/sh ../libtool --tag CXX --mode=link /home/dave/gcc-4.0/objdir/gcc/xgcc -sha
red-libgcc -B/home/dave/gcc-4.0/objdir/gcc/ -nostdinc++ -L/home/dave/gcc-4.0/obj
dir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-4.0/objdir/hppa-linux/libstdc++
-v3/src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.0.0/hppa-linux/bin/ -B/home/dave/op
t/gnu/gcc/gcc-4.0.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.0.0/hp
pa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.0.0/hppa-linux/sys-includ
e -Wl,-O1   -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual  -
fdiagnostics-show-location=once  -ffunction-sections -fdata-sections   -o libstd
c++.la -rpath /home/dave/opt/gnu/gcc/gcc-4.0.0/lib -version-info 6:5:0 -Wl,--ver
sion-script=libstdc++-symbol.ver -lm  bitmap_allocator.lo pool_allocator.lo mt_a
llocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_li
st.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_i
nit.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo locale_facets.lo
 localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.
lo fstream-inst.lo ext-inst.lo io-inst.lo istream-inst.lo istream.lo locale-inst
.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-i
nst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst
.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages
_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo
 c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm
/home/dave/gcc-4.0/objdir/gcc/xgcc -shared-libgcc -B/home/dave/gcc-4.0/objdir/gc
c/ -nostdinc++ -L/home/dave/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src -L/home/d
ave/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/gcc/gc
c-4.0.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.0.0/hppa-linux/lib/ -isys
tem /home/dave/opt/gnu/gcc/gcc-4.0.0/hppa-linux/include -isystem /home/dave/opt/
gnu/gcc/gcc-4.0.0/hppa-linux/sys-include -shared -nostdlib /usr/lib/crti.o /home
/dave/gcc-4.0/objdir/gcc/crtbeginS.o  .libs/bitmap_allocator.o .libs/pool_alloca
tor.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_i
o.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/glo
bals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.
o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_ini
t.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o
 .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .
libs/ext-inst.o .libs/io-inst.o .libs/istream-inst.o .libs/istream.o .libs/local
e-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/s
stream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs
/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .li
bs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/message
s_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.
o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/libm
ath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive  -L/home/
dave/gcc-4.0/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-4.0/objdir/hppa
-linux/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.l
ibs/libsupc++convenience.a -lm -L/home/dave/gcc-4.0/objdir/gcc -L/home/dave/opt/
gnu/gcc/gcc-4.0.0/lib/gcc/hppa-linux/../.. -lgcc_s -lgcc -lc -lgcc_s -lm -lgcc_s
 -lgcc -lc -lgcc_s   /home/dave/gcc-4.0/objdir/gcc/crtendS.o /usr/lib/crtn.o  -W
l,-O1 -Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6 -
o .libs/libstdc++.so.6.0.5
/home/dave/opt/gnu/bin/ld: BFD 2.16.91 20050612 internal error, aborting at ../.
./src/bfd/elf32-hppa.c line 3680 in elf32_hppa_relocate_section

/home/dave/opt/gnu/bin/ld: Please report this bug.

This appears to have been introduced by the recent change to symbol
versioning.

-- 
   Summary: [4.0.1 Regression] /home/dave/opt/gnu/bin/ld: BFD
2.16.91 20050612 internal error
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109

[Bug libstdc++/22109] [4.0 Regression] /home/dave/opt/gnu/bin/ld: BFD 2.16.91 20050612 internal error

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-17 
23:55 ---
To me this looks like a binutils bug.

-- 
   What|Removed |Added

 CC||bkoz at gcc dot gnu dot org,
   ||jakub at gcc dot gnu dot org
   Keywords||build
  Known to fail||4.0.1
  Known to work||4.0.0
Summary|[4.0.1 Regression]  |[4.0 Regression]
   |/home/dave/opt/gnu/bin/ld:  |/home/dave/opt/gnu/bin/ld:
   |BFD 2.16.91 20050612|BFD 2.16.91 20050612
   |internal error  |internal error
   Target Milestone|--- |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109

[Bug libstdc++/22109] [4.0 Regression] /home/dave/opt/gnu/bin/ld: BFD 2.16.91 20050612 internal error

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2005-06-18 00:08 ---
Subject: Re:  [4.0 Regression] /home/dave/opt/gnu/bin/ld: BFD 2.16.91 20050612 
internal error

> To me this looks like a binutils bug.

Quite possibly.   However, I wanted a heads up until the exact cause
of the problem is determined.  I've seen this on two different systems.
My build yesterday using the same tools was successful.

.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109

[Bug testsuite/20554] New testsuite fails: error: alias definitions not supported in this configuration

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-18 
01:21 ---
Does these fail now?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554

[Bug middle-end/20506] verify_stmts calls error() on internal errors(notes)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-18 
01:23 ---
Maybe we should be using note instead or something different.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-18 01:23:36
   date||
Summary|verify_stmts calls error()  |verify_stmts calls error()
   |on internal errors  |on internal errors(notes)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20506

[Bug middle-end/20506] verify_stmts calls error() on internal errors(notes)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-18 
01:23 ---
Like a non fatal internal_error.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20506

[Bug testsuite/20554] New testsuite fails: error: alias definitions not supported in this configuration

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2005-06-18 
01:34 ---
Fixed by patch:

2005-04-04  John David Anglin  <[EMAIL PROTECTED]>

* gcc.c-torture/compile/2009-1.c: Require weak and alias support.
* gcc.c-torture/compile/2009-2.c: Likewise.
* gcc.c-torture/compile/981001-2.c: Likewise.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554

[Bug testsuite/20554] New testsuite fails: error: alias definitions not supported in this configuration

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20554