[Bug libfortran/23138] real-values print and add incorrectly (version 4.1.0 20050702, i686-pc-mingw32)

[jvdelisle at gcc dot gnu dot org]

--- Additional Comments From jvdelisle at gcc dot gnu dot org  2005-07-30 
06:31 ---
I have confirmed this bug on cygwin.  We can't get current builds on cygwin,
perhaps patch to pr21275 is needed?

-- 


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

[Bug target/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var

[jvdelisle at gcc dot gnu dot org]

--- Additional Comments From jvdelisle at gcc dot gnu dot org  2005-07-30 
06:29 ---
Can or will this patch be put into mainline?  Seems to be falling in a crack. 
It is needed to help with moving forward on pr23138.  I will apply the patch
given here.  My first attempts failed, maybe I have to do it manually.

-- 


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

[Bug libfortran/22570] Null Characters instead of blanks in text output.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-30 
06:18 ---
Subject: Bug 22570

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-07-30 06:18:35

Modified files:
libgfortran: ChangeLog 
libgfortran/io : transfer.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: x_slash_1.f 

Log message:
2005-07-30 Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/22570 and related issues.
* transfer.c (formatted_transfer): Make sure that there
really is data present before X- or T- editing. Move all
treatment of tabbing during writes to start of next data
producing format. Suppress incorrect zeroing of bytes_left
in slash formating. Insert int cast for assignment of a
difference of two gfc_offsets.

PR fortran/22570 an related issues.
* gfortran.dg/x_slash_1.f: New test.

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.69&r2=1.163.2.70
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.10&r2=1.32.2.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.309&r2=1.5084.2.310
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/x_slash_1.f.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug libfortran/22570] Null Characters instead of blanks in text output.

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-30 
05:33 ---
Subject: Bug 22570

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-30 05:33:40

Modified files:
libgfortran: ChangeLog 
libgfortran/io : transfer.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: x_slash_1.f 

Log message:
2005-07-30 Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/22570 and related issues.
* transfer.c (formatted_transfer): Make sure that there
really is data present before X- or T- editing. Move all
treatment of tabbing during writes to start of next data
producing format. Suppress incorrect zeroing of bytes_left
in slash formating. Insert int cast for assignment of a
difference of two gfc_offsets.

PR fortran/22570 an related issues.
* gfortran.dg/x_slash_1.f: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.271&r2=1.272
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.49&r2=1.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5856&r2=1.5857
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/x_slash_1.f.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/23143] [4.1 Regression] parameter forward declarations broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-30 
03:10 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/529] -Wshadow warns on function prototypes vs. global vars

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-30 
03:09 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug c/23145] struct {int i;} is not compatiable with struct {int i,j}

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-30 
03:05 ---
Hmm, Apple's 3.3-fast does not have this bug.
sv.i:4: warning: conflicting types for `a'
op.i:4: warning: previous declaration of `a'

-- 


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

[Bug c/23145] New: struct {int i;} is not compatiable with struct {int i,j}

[pinskia at gcc dot gnu dot org]

The C front-end says that struct {int i;} is compatiable with struct {int i,j} 
which is wrong.
The following testcase should be rejected but it is not:
 file1.c 
struct op {
  int i;
};
void a (struct op* o);
 end -
 file2.c -
struct listop {
  int i, j;
};
void a(struct listop *o) {}
 end 

This is not a regression, 3.4.0 accepts it also.  This causes us to remove some 
casts while compiling 
perlbmk and causes a type mismatch.  This is a very reduced testcase from the 
orginal one.

I am going to mark this as blocking PR 22368 as this causes to ICE with that 
patch.

-- 
   Summary: struct {int i;} is not compatiable with struct {int i,j}
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c
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
OtherBugsDependingO 22368
 nThis:


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

[Bug other/22368] [meta-bugs] mis-match types in GCC

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||23145


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

[Bug target/22582] -rdynamic is undocumented

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-07-30 
02:16 ---
Fixed on mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.1.0
 Resolution||FIXED


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

[Bug target/5362] Undocumented target options

[wilson at gcc dot gnu dot org]

-- 
Bug 5362 depends on bug 22582, which changed state.

Bug 22582 Summary: -rdynamic is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22582

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug target/22582] -rdynamic is undocumented

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-30 
02:12 ---
Subject: Bug 22582

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-30 02:12:26

Modified files:
gcc: ChangeLog 
gcc/doc: invoke.texi 

Log message:
Patch from Wolfgang Bangerth.
PR target/22582
* doc/invoke.texi: Document -rdynamic.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9612&r2=2.9613
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.660&r2=1.661



-- 


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

[Bug c/23143] [4.1 Regression] parameter forward declarations broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-30 
01:35 ---
Subject: Bug 23143

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-30 01:34:58

Modified files:
gcc: ChangeLog c-decl.c c-parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: parm-forwdecl-1.c parm-forwdecl-2.c 
  parm-forwdecl-3.c parm-forwdecl-4.c 

Log message:
PR c/23143
* c-parser.c (c_parser_parms_list_declarator): Call
mark_forward_parm_decls.
* c-decl.c (merge_decls): Only check DECL_IN_SYSTEM_HEADER for
decls with visibility structure.

testsuite:
* gcc.dg/parm-forwdecl-1.c, gcc.dg/parm-forwdecl-2.c,
gcc.dg/parm-forwdecl-3.c, gcc.dg/parm-forwdecl-4.c: New tests.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9611&r2=2.9612
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.678&r2=1.679
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-parser.c.diff?cvsroot=gcc&r1=2.20&r2=2.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5855&r2=1.5856
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-forwdecl-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-forwdecl-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-forwdecl-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/parm-forwdecl-4.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug libgcj/22580] [4.1 Regression] 'make -j' doesn't affect source->bytecode compilation

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-07-30 
01:02 ---
The problem is the compile-classes rule in the libjava/classpath/lib/Makefile.am
file.  This rule contains a line $(JAVAC) that has a recursive make hidden
inside it.  make -j requires that all lines that perform a recursive make
contain the string $(MAKE), the string ${MAKE}, or start with +.  This is before
variable substitution, etc.

Three possible solutions off the top of my head:
1) Add a comment that mentions $(MAKE), e.g. change the line
$(JAVAC)
to
$(JAVAC) # $(MAKE)
2) Add a + to indicate this line does a recursive make.  This is apparently
POSIX (though my manual isn't here to double check).  E.g. change the line
$(JAVAC)
to
+$(JAVAC)
3) Delete the JAVAC variable, and put the line in question directly into the
compile-classes rule.

I verified that the first two suggestions work.  I didn't try the third, it
seems less practical.

Since JAVAC is being conditionally set, and only the GCJ version has the hidden
recursive make, we probably need a conditional fix here.

I'll leave it to the java and/or classpath folks to decide how they want to fix
this.  You may want to check the make manual for info on the MAKE variable, -j,
jobserver, and +.

My libjava build is still going, so it is possible that there are other similar
problems I haven't noticed yet.

-- 


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

[Bug c/529] -Wshadow warns on function prototypes vs. global vars

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
23:58 ---
Subject: Bug 529

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-29 23:58:37

Modified files:
gcc: ChangeLog c-decl.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: Wshadow-3.c 

Log message:
PR c/529
* c-decl.c (warn_if_shadowing): Don't check for PARM_DECL in
nested function declarators.
(pushdecl): Don't call warn_if_shadowing for PARM_DECL.
(grokparms): Call warn_if_shadowing for parameters used within the
parameter list.
(store_parm_decls_newstyle): Call warn_if_shadowing for parameters
not used within the parameter list.
(store_parm_decls_oldstyle): Call warn_if_shadowing for parameters.

testsuite:
* gcc.dg/Wshadow-3.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9608&r2=2.9609
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcc&r1=1.677&r2=1.678
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5854&r2=1.5855
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/Wshadow-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c/23143] [4.1 Regression] parameter forward declarations broken

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-07-29 
23:34 ---
Subject: Re:  [4.1 Regression] parameter forward declarations
 broken

On Fri, 29 Jul 2005, pinskia at gcc dot gnu dot org wrote:

> Confirmed.  I did not even know of this extension.  I don't even see it 
> as being a documented one either, unless I missed something obvious.

It's documented in the section of extend.texi on VLAs.



-- 


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

[Bug c/23144] [4.0/4.1 Regression] invalid parameter forward declarations not diagnosed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
23:34 ---
Confirmed, this has been failing since at least 20040909.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 23:34:03
   date||
   Target Milestone|--- |4.0.2


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

[Bug c/23144] New: [4.0/4.1 Regression] invalid parameter forward declarations not diagnosed

[jsm28 at gcc dot gnu dot org]

GCC 4.0 fails to diagnose cases of parameter forward declarations followed by no
normal parameter declarations, such as

int g1(int a;);
int g2(int a; __attribute__((unused)));
int g3(int;);
int g4(int, long;);

The same applies to 4.1 once I've fixed bug 23143.  3.4 diagnoses these cases.

-- 
   Summary: [4.0/4.1 Regression] invalid parameter forward
declarations not diagnosed
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/23143] [4.1 Regression] parameter forward declarations broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
23:30 ---
Confirmed.  I did not even know of this extension.  I don't even see it as 
being a documented one 
either, unless I missed something obvious.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 23:30:30
   date||
   Target Milestone|--- |4.1.0


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

[Bug c/23143] New: [4.1 Regression] parameter forward declarations broken

[jsm28 at gcc dot gnu dot org]

The new C parser lost a call to mark_forward_parm_decls, thereby completely
breaking the GNU extension of forward parameter declarations.  I'm testing a
patch.  Testcases:

int f1(int a; int a);

should be accepted (rather than complaining about a duplicate parameter name),

int h1(int a; int b);

should be rejected.

Observations:

1. This is the first new C parser bug affecting valid code found since the
parser went in in February.

2. It suggests that no-one is using this extension.

3. I'm surprised that mark_forward_parm_decls didn't get removed as an unused
function after the call was lost.

4. The patch I'm testing restores things to the same functionality as in 4.0. 
There are various cases of invalid code involving this extension which 3.4
diagnoses and 4.0 doesn't; I'll file a separate bug for those.

-- 
   Summary: [4.1 Regression] parameter forward declarations broken
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: jsm28 at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/21720] GCC incorrectly rounds hex floats

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
23:24 ---
Fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/16989] [meta-bug] C99 conformance bugs

[pinskia at gcc dot gnu dot org]

-- 
Bug 16989 depends on bug 21720, which changed state.

Bug 21720 Summary: GCC incorrectly rounds hex floats
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21720

   What|Old Value   |New Value

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[ian at airs dot com]

--- Additional Comments From ian at airs dot com  2005-07-29 22:38 ---
I haven't checked g++ 3.3.x, but I have no reason to doubt you.  I think you
grasp the situation fine: at least for a while, g++ did not follow the ABI.  Now
it does.  It's a problem.  Any time you don't follow the ABI, it's a problem. 
It causes binary incompatibility, and forces people to recompile their code. 
People who don't have the source code are out of luck.

I'm not sure what question you are asking, if indeed you are asking a question
at all.  I'm not sure what else there is to say about the situation.


-- 


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

[Bug ada/23142] [4.1 regression] ACATS FAIL cxaa017 character processing wrong code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug ada/23142] [4.1 regression] ACATS FAIL cxaa017 character processing wrong code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|ACATS FAIL cxaa017 character|[4.1 regression] ACATS FAIL
   |processing wrong code   |cxaa017 character processing
   ||wrong code
   Target Milestone|--- |4.1.0


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

[Bug ada/23141] [4.1 Regression] ACATS FAIL c45651a fixed point wrong code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
22:20 ---
I think this is a VRP bug, but I could be wrong.  It might also be a fold-const 
bug.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
Summary|ACATS FAIL c45651a fixed|[4.1 Regression] ACATS FAIL
   |point wrong code|c45651a fixed point wrong
   ||code
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/23046] [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191

[falk at debian dot org]

--- Additional Comments From falk at debian dot org  2005-07-29 22:20 
---
waiting for testcase...

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug ada/23142] New: ACATS FAIL cxaa017 character processing wrong code

[laurent at guerby dot net]

Started failing between

LAST_UPDATED: Tue Jul 26 21:49:55 UTC 2005
LAST_UPDATED: Fri Jul 29 20:05:56 UTC 2005

on x86 and amd64-linux.

,.,. CXAA017 ACATS 2.5 05-07-30 00:03:57
 CXAA017 Check that Ada.Text_IO subprograms Look_Ahead and
Get_Immediate are available and produce correct results.
   * CXAA017 Not all of the characters on the first line were processed.
   * CXAA017 Not all of the characters on the second line were
processed.
 CXAA017 FAILED .

-- 
   Summary: ACATS FAIL cxaa017 character processing wrong code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-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=23142

[Bug ada/23141] New: ACATS FAIL c45651a fixed point wrong code

[laurent at guerby dot net]

Started failing between
LAST_UPDATED: Tue Jul 26 21:49:55 UTC 2005
LAST_UPDATED: Fri Jul 29 20:05:56 UTC 2005

on x86 and amd64-linux.

,.,. C45651A ACATS 2.5 05-07-29 23:43:34
 C45651A CHECK THAT, FOR FIXED POINT TYPES, THE ABS OPERATOR
PRODUCES CORRECT RESULTS - BASIC TYPES.
   * C45651A ABS (1.0 / 64) /= (1.0 / 64).
 C45651A FAILED .

-- 
   Summary: ACATS FAIL c45651a fixed point wrong code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-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=23141

[Bug target/23080] [4.0 regression] m68k ICE

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-07-29 22:00 ---
I consider this fixed. 

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug target/23078] [4.0 regression] m68k ICE

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-07-29 21:59 ---
I consider this fixed. 

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/23139] -pedantic -ffast-math breaks working code

[thor at math dot tu-berlin dot de]

--- Additional Comments From thor at math dot tu-berlin dot de  2005-07-29 
21:18 ---
Subject: Re:  -pedantic -ffast-math breaks working code

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
> 21:06 ---
> Can you attach the preprocessing source as the glibc I have installed 
> defineds HUGE_VAL as 
> __builtin_huge_val().
> 

Sorry to respond by mail, but the output is a bit too long to fit 
comfortably into the bug database; I submitted a shortened version there 
with only the preprocessed main program there. Please find the full 
program attached. LibC-dev is "libc6-dev  2.3.2.ds1-22".

Thanks,
Thomas

# 1 "huge.cpp"
# 1 ""
# 1 ""
# 1 "huge.cpp"
# 1 "/usr/include/math.h" 1 3 4
# 27 "/usr/include/math.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 295 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 296 "/usr/include/features.h" 2 3 4
# 318 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 319 "/usr/include/features.h" 2 3 4
# 28 "/usr/include/math.h" 2 3 4

extern "C" {



# 1 "/usr/include/bits/huge_val.h" 1 3 4
# 34 "/usr/include/math.h" 2 3 4



# 1 "/usr/include/bits/nan.h" 1 3 4
# 38 "/usr/include/math.h" 2 3 4


# 1 "/usr/include/bits/mathdef.h" 1 3 4
# 29 "/usr/include/bits/mathdef.h" 3 4
typedef long double float_t;

typedef long double double_t;
# 41 "/usr/include/math.h" 2 3 4
# 65 "/usr/include/math.h" 3 4
# 1 "/usr/include/bits/mathcalls.h" 1 3 4
# 53 "/usr/include/bits/mathcalls.h" 3 4


extern double acos (double __x) throw (); extern double __acos (double __x) 
throw ();

extern double asin (double __x) throw (); extern double __asin (double __x) 
throw ();

extern double atan (double __x) throw (); extern double __atan (double __x) 
throw ();

extern double atan2 (double __y, double __x) throw (); extern double __atan2 
(double __y, double __x) throw ();


extern double cos (double __x) throw (); extern double __cos (double __x) throw 
();

extern double sin (double __x) throw (); extern double __sin (double __x) throw 
();

extern double tan (double __x) throw (); extern double __tan (double __x) throw 
();




extern double cosh (double __x) throw (); extern double __cosh (double __x) 
throw ();

extern double sinh (double __x) throw (); extern double __sinh (double __x) 
throw ();

extern double tanh (double __x) throw (); extern double __tanh (double __x) 
throw ();




extern void sincos (double __x, double *__sinx, double *__cosx) throw (); 
extern void __sincos (double __x, double *__sinx, double *__cosx) throw ();






extern double acosh (double __x) throw (); extern double __acosh (double __x) 
throw ();

extern double asinh (double __x) throw (); extern double __asinh (double __x) 
throw ();

extern double atanh (double __x) throw (); extern double __atanh (double __x) 
throw ();







extern double exp (double __x) throw (); extern double __exp (double __x) throw 
();


extern double frexp (double __x, int *__exponent) throw (); extern double 
__frexp (double __x, int *__exponent) throw ();


extern double ldexp (double __x, int __exponent) throw (); extern double 
__ldexp (double __x, int __exponent) throw ();


extern double log (double __x) throw (); extern double __log (double __x) throw 
();


extern double log10 (double __x) throw (); extern double __log10 (double __x) 
throw ();


extern double modf (double __x, double *__iptr) throw (); extern double __modf 
(double __x, double *__iptr) throw ();




extern double exp10 (double __x) throw (); extern double __exp10 (double __x) 
throw ();

extern double pow10 (double __x) throw (); extern double __pow10 (double __x) 
throw ();





extern double expm1 (double __x) throw (); extern double __expm1 (double __x) 
throw ();


extern double log1p (double __x) throw (); extern double __log1p (double __x) 
throw ();


extern double logb (double __x) throw (); extern double __logb (double __x) 
throw ();






extern double exp2 (double __x) throw (); extern double __exp2 (double __x) 
throw ();


extern double log2 (double __x) throw (); extern double __log2 (double __x) 
throw ();








extern double pow (double __x, double __y) throw (); extern double __pow 
(double __x, double __y) throw ();


extern double sqrt (double __x) throw (); extern double __sqrt (double __x) 
throw ();





extern double hypot (double __x, double __y) throw (); extern double __hypot 
(double __x, double __y) throw ();






extern double cbrt (double __x) throw (); extern double __cbrt (double __x) 
throw ();








extern double ceil (double __x) throw () __attribute__ ((__const__)); extern 
double __ceil (double __x) throw () __attribute__ ((__const__));


extern double fabs (double __x) throw () __attribute__ ((__const__)); extern 
double __fabs (double __x) throw () __attribute__ ((__const__));


extern double floor (double __x) throw () __attribute__ ((__const__)); extern 
double __floor (double __x) throw () 

[Bug c++/23139] -pedantic -ffast-math breaks working code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
21:18 ---
Hmm, if passed in 4.0.0 20050225 but fails on the mainline.  It also works with 
the C front-end.

-- 


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

[Bug c++/23139] -pedantic -ffast-math breaks working code

[thor at math dot tu-berlin dot de]

--- Additional Comments From thor at math dot tu-berlin dot de  2005-07-29 
21:14 ---
As per request, here is the preprocessed source code:

int main(int argc,char **argv)
{
  double v = (__extension__ 0x1.0p2047);

  printf("%f\n",v);

  return 0;
}


-- 


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

[Bug c++/11624] -Wnon-virtual-dtor doesn't always work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
21:14 ---
*** Bug 23140 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||thor at math dot tu-berlin
   ||dot de


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

[Bug c++/23140] void warning on virtual classes with no destructor

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
21:14 ---
Actually this was a requested thing for 4.0, see PR 11624.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/21720] GCC incorrectly rounds hex floats

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
21:14 ---
Subject: Bug 21720

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-29 21:14:22

Modified files:
gcc: ChangeLog real.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gcc.dg: hex-round-1.c 
Added files:
gcc/testsuite/gcc.dg: hex-round-2.c 

Log message:
PR c/21720
* real.c (real_from_string): Also set last bit if there is a
nonzero hex digit beyond GCC's internal precision after ".".

testsuite:
* gcc.dg/hex-round-1.c: Test more cases.
* gcc.dg/hex-round-2.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9606&r2=2.9607
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/real.c.diff?cvsroot=gcc&r1=1.156&r2=1.157
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5852&r2=1.5853
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/hex-round-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/hex-round-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug c++/23139] -pedantic -ffast-math breaks working code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
21:06 ---
Can you attach the preprocessing source as the glibc I have installed defineds 
HUGE_VAL as 
__builtin_huge_val().

-- 
   What|Removed |Added

   Keywords||rejects-valid


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

[Bug c++/23140] New: void warning on virtual classes with no destructor

[thor at math dot tu-berlin dot de]

If compiled with -Wall, g++-4.0.1 will warn on classes with virtual functions
but *no* destructor at all. Note that even though this warning is well justified
on classes implementing a destructor - because virtual classes might get deleted
thru a base class pointer - this warning is not useful for classes with a
trivial (compiler-generated) destructor. Note that g++-3.4 and earler releases
of g++ did not warn on this case either.

How to reproduce: Enter the following code and save as "destructor.cpp":
/*snip*/
class A {
  int x;
public:
  A(int a)
: x(a)
  { }
  //
  virtual int get(void) const
  {
return x;
  }
};

class B : public A {
  int y;
public:
  B(int a)
: A(a), y(a+1)
  { }
  //
  virtual int get(void) const
  {
return y;
  }
};

int main(int argc,char **argv)
{
  return 0;
}
/*snip*/

Then compile as:
$ g++-4.0 -Wall destructor.cpp

Compiler output is:

destructor.cpp:1: warning: 'class A' has virtual functions but non-virtual
destructor
destructor.cpp:14: warning: 'class B' has virtual functions but non-virtual
destructor

Note that this warning is unjustified because deleting a class thru a base
class pointer works fine if both derived and base class only provide a
trivial (compiler-generated) destructor.

-- 
   Summary: void warning on virtual classes with no destructor
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thor at math dot tu-berlin dot de
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=23140

[Bug c++/23139] New: -pedantic -ffast-math breaks working code

[thor at math dot tu-berlin dot de]

Using the command line switches -pedantic -ffast-math triggers an error and
aborts compilation of code using HUGE_VAL.

To reproduce, save the following code as huge.cpp:

#include 
#include 

int main(int argc,char **argv)
{
  double v = HUGE_VAL;

  printf("%f\n",v);

  return 0;
}

Compile with:

g++-4.0 -ffast-math -pedantic huge.cpp

Result is:
huge.cpp:6:14: warning: use of C99 hexadecimal floating constant
huge.cpp:6: error: floating constant exceeds range of 'double'

Compilation aborts here. Note that there is a similar bug in the database,
namely #11931 that exists at least since g++-3.3.2 and has not been touched
yet. Unfortunately, starting with g++-4.0.1, this bug causes an unjustified
error (not just a warning) and thus avoids compilation of existing
production code. Bug #11931 has been marked as priority "low"; however,
since this bug remained in the bug data base for so long now, and since it
is now even raised to an error instead of just a warning, I would like to
suggest to raise the priority to "normal".

And please, please: Could please someone care about this one?

So long, and thanks a lot,
Thomas

-- 
   Summary: -pedantic -ffast-math breaks working code
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thor at math dot tu-berlin dot de
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=23139

[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-07-29 20:06 ---
Hi, 
 
a couple of weeks after identifying this issue, I have continued working with 
4.0.0. I never observed a similar failure in our production code. The issue 
seems to be strongly linked to the constraint requiring simultaneously two 
operands with the "+&" modifier. The back-end, itself never generates such a 
constraint pattern right now. 
 
It seems to me that the real problem has to do with register constraint 
matching. I personally do not have sufficient knowledge so that I would 
consider to start thinking about daring to eventually touch reload.c and 
comrades. On the other hand, I still feel uneasy about this bug.  
 
For this reason I am thinking about a workaround solely within the back-end. 
While refraining from requiring that code that contains the mentioned difficult 
constraits compiles, I presently think that one might already be better of with 
a situation where it triggers an ICE instead of generating wrong code. 
 
IMO, a possible workaround might be to simply disable within the machine 
description the move patterns that meet the two following two conditions  
1.) the move uses a memory reference stored in Y 
2.) the move target is the Y register itself 
 
My hope is that in absence of this move pattern, reload will no longer attempt 
to use the frame pointer register Y as spill register. 
 
This workaround certainly would be far from ideal, but better than nothing. I'd 
appreciate comments on this issue. 
 
Yours, 
 
Björn 

-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
19:29 ---
Subject: Bug 23131

CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-arm-branch
Changes by: [EMAIL PROTECTED]   2005-07-29 19:29:16

Modified files:
.  : ChangeLog.csl-arm 
gcc: configure.ac configure 

Log message:
Backport:
2005-07-29  Mark Mitchell  <[EMAIL PROTECTED]>
PR bootstrap/23131
* configure.ac (SYSTEM_HEADER_DIR): Avoid setting to empty
string.
* configure: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.csl-arm.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.1.2.26&r2=1.1.2.27
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.ac.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=2.19.2.13&r2=2.19.2.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.diff?cvsroot=gcc&only_with_tag=csl-arm-branch&r1=1.767.2.14&r2=1.767.2.15



-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
19:28 ---
Subject: Bug 23131

CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-3_4_3-linux-branch
Changes by: [EMAIL PROTECTED]   2005-07-29 19:28:31

Modified files:
.  : ChangeLog.csl 

Log message:
Backport:
2005-07-29  Mark Mitchell  <[EMAIL PROTECTED]>
PR bootstrap/23131
* configure.ac (SYSTEM_HEADER_DIR): Avoid setting to empty
string.
* configure: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.csl.diff?cvsroot=gcc&only_with_tag=csl-3_4_3-linux-branch&r1=1.1.6.11&r2=1.1.6.12



-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
19:27 ---
Subject: Bug 23131

CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-3_4_3-linux-branch
Changes by: [EMAIL PROTECTED]   2005-07-29 19:27:12

Modified files:
gcc: configure.ac configure 

Log message:
Backport:
2005-07-29  Mark Mitchell  <[EMAIL PROTECTED]>
PR bootstrap/23131
* configure.ac (SYSTEM_HEADER_DIR): Avoid setting to empty
string.
* configure: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.ac.diff?cvsroot=gcc&only_with_tag=csl-3_4_3-linux-branch&r1=2.19.2.9.2.4&r2=2.19.2.9.2.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.diff?cvsroot=gcc&only_with_tag=csl-3_4_3-linux-branch&r1=1.767.2.10.2.4&r2=1.767.2.10.2.5



-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-29 
19:24 ---
Fixed in GCC 4.1.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
19:20 ---
Subject: Bug 23131

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-29 19:20:49

Modified files:
gcc: ChangeLog configure.ac configure 

Log message:
PR bootstrap/23131
* configure.ac (SYSTEM_HEADER_DIR): Avoid setting to empty
string.
* configure: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9604&r2=2.9605
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.ac.diff?cvsroot=gcc&r1=2.124&r2=2.125
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/configure.diff?cvsroot=gcc&r1=1.919&r2=1.920



-- 


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

[Bug libfortran/23138] real-values print and add incorrectly (version 4.1.0 20050702, i686-pc-mingw32)

[post at tillmann-wegst dot de]

--- Additional Comments From post at tillmann-wegst dot de  2005-07-29 
19:01 ---
(In reply to comment #1)
> I cannot reproduce this with 20050729 on i686-pc-linux-gnu.

Yes, Steve Kargl has told me the same. The bug appears to be particular with 
the MinGW-version. 

-- 


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

[Bug libfortran/23138] real-values print and add incorrectly (version 4.1.0 20050702, i686-pc-mingw32)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
18:54 ---
I cannot reproduce this with 20050729 on i686-pc-linux-gnu.

-- 
   What|Removed |Added

  Component|fortran |libfortran
 GCC target triplet||i686-pc-mingw32


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

[Bug fortran/23138] New: real-values print and add incorrectly (version 4.1.0 20050702, i686-pc-mingw32)

[post at tillmann-wegst dot de]

Hi all, 

I'd like to report what looks like a bug in 
gfortran for Windows, version: 
"GNU F95 version 4.1.0 20050702 (experimental) (i686-pc-mingw32)"

It concerns values of type real, which both print and add 
incorrectly. 

To give an example, take this little program: 


program realtrouble
   real :: x
   integer :: i

   x=1.0
   i=5

   write(*,*) "x==",x! Prints 0.0 instead of 1.0 !!! 
   write(*,*) "x==",1.0  ! Prints 0.0 too !!! 
   write(*,*) "i==",i! Prints 5, as expected
end program realtrouble
--

Apart from incorrect results of write()ing: when summing 
several values of type real, adding 0.0 to 0.0 yielded 2.0, 
adding another 0.0 to 2.0 yielded 0.0 again! 

I've compiled and linked the program at the command-line 
under Windows XP with no particular flags, simply like this: 
gfortran gftest.f95

Here's what a verbose execution produced: 
Driving: gfortran gftest.f95 -v -lgfortranbegin -lgfortran
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc/configure --prefix=/mingw --enable-languages=c,f95
Thread model: win32
gcc version 4.1.0 20050702 (experimental)
 c:/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/f951.exe gftest.f95 -
quiet -dumpbase gftest.f9
5 -mtune=pentiumpro -auxbase gftest -version -o C:\DOKUME~1\Tillmann\LOKALE~1
\Temp/ccWqbaaa.s
GNU F95 version 4.1.0 20050702 (experimental) (i686-pc-mingw32)
compiled by GNU C version 3.4.4 (mingw special).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -o C:\DOKUME~1\Tillmann\LOKALE~1\Temp/ccIHcaaa.o C:\DOKUME~1
\Tillmann\LOKALE~1\Temp/ccWqbaaa.s
 c:/gfortran/bin/../libexec/gcc/i686-pc-mingw32/4.1.0/collect2.exe -Bdynamic 
C:/fortran/g95/lib/crt2
.o -Lc:/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.1.0 -
Lc:/gfortran/bin/../lib/gcc -LC:/fortran/g95/
lib -Lc:/gfortran/bin/../lib/gcc/i686-pc-mingw32/4.1.0/../../.. C:\DOKUME~1
\Tillmann\LOKALE~1\Temp/c
cIHcaaa.o -lgfortranbegin -lgfortran -lmingw32 -lgcc -lmoldname -lmingwex -
lmsvcrt -luser32 -lkernel
32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt
--

I've exchanged mails with Steven Kargl, who suggested to 
produce a .original-file using flag "-fdump-tree-original". 

This generated the following: 
MAIN__ ()
{
  real4 x;
  int4 i;

  x = 1.0e+0;
  i = 5;
  _gfortran_filename = "gftest.f95";
  _gfortran_line = 8;
  _gfortran_ioparm.unit = 6;
  _gfortran_ioparm.list_format = 1;
  _gfortran_st_write ();
  _gfortran_transfer_character ("x==", 3);
  _gfortran_transfer_real (&x, 4);
  _gfortran_st_write_done ();
  _gfortran_filename = "gftest.f95";
  _gfortran_line = 9;
  _gfortran_ioparm.unit = 6;
  _gfortran_ioparm.list_format = 1;
  _gfortran_st_write ();
  _gfortran_transfer_character ("x==", 3);
  {
real4 C.473 = 1.0e+0;

_gfortran_transfer_real (&C.473, 4);
  }
  _gfortran_st_write_done ();
  _gfortran_filename = "gftest.f95";
  _gfortran_line = 10;
  _gfortran_ioparm.unit = 6;
  _gfortran_ioparm.list_format = 1;
  _gfortran_st_write ();
  _gfortran_transfer_character ("i==", 3);
  _gfortran_transfer_integer (&i, 4);
  _gfortran_st_write_done ();
}
 

Steve's preliminary conclusion is (quote):
"(...).original shows that the gfortran frontend is
doing the right thing.  This is a gfortran library problem
or an interface with OS library problem." 

Kind regards 
   Tillmann Wegst

-- 
   Summary: real-values print and add incorrectly (version 4.1.0
20050702, i686-pc-mingw32)
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: post at tillmann-wegst dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/16989] [meta-bug] C99 conformance bugs

[jsm28 at gcc dot gnu dot org]

-- 
Bug 16989 depends on bug 21720, which changed state.

Bug 21720 Summary: GCC incorrectly rounds hex floats
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21720

   What|Old Value   |New Value

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |

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

[Bug middle-end/21720] GCC incorrectly rounds hex floats

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-07-29 18:31 
---
It turns out my patch actually fixed a similar problem with the code handling
digits before the ".", and my testcase didn't have enough zeroes to show the
problem on 64-bit hosts.  Testing a patch to fix the problem properly (by making
the same change to the code for digits after the "." and expanding the 
testcase).


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name

[uttamp at us dot ibm dot com]

--- Additional Comments From uttamp at us dot ibm dot com  2005-07-29 18:16 
---
I belive, till g++ 3.3.4, the mangled string used have that '_' as hown by
following example,

template struct S {
S(int i=0);
};
template &s> void f13();
extern S s13;
int main(void)
{
f13();
return 0;
}

With nm, I get 
 U __gxx_personality_v0
 T main
 U _Z3f13IXL_Z3s13EEEvv

Which I believe is the default and correct behavior. But with g++ > 3.4 (which
doesn't support abi-version=3) by default produces mangled string as
 U __gxx_personality_v0
 T main
 U _Z3f13ILZ3s13EEvv

And with g++ > 3.5.x user has to specify -fabi-version=3  as specified by Mark,
to get the correct string.
So there is a binary compatibility problem between object code created by older
g++ version < 3.3.4 and later version till g++ version 3.5.

Do you see my dilemma? Or am I still missing something very basic here? 
Sorry for any/all repetition over this subject. I would really appreciate the
reply for better understanding and clarification of this issue.


-- 


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

[Bug c++/23137] Difficulty accessing base template members from derived template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
18:14 ---
Read the release notes for 3.4.  This is invalid code.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/23137] New: Difficulty accessing base template members from derived template

[frank dot radish at marconi dot com]

The piece of code attached compiled without errors under gcc 3.3.3 (Red Hat 
Linux), but failed with 3.4.2 (Windows XP) and 3.4.3 (Solaris 2.8).

The information that I am sending in this report all pertains to 3.4.3 on 
Solaris.  But I also installed a version of Dev-C++ which installs on Windows 
XP and it has g++ 3.4.2 and the same failure exists there.

<289 /us/fradish/C++ > /us/bfsbld/Compilers/gcc/3.4.3/sparc-sun-
solaris2.7/bin/g++ -v
Reading specs from /us/bfsbld/Compilers/gcc/3.4.3/sparc-sun-
solaris2.7/lib/gcc/sparc-sun-solaris2.7/3.4.3/specs
Configured with: /us/bfsbld/Compilers/gcc/3.4.3/src/gcc/configure --
prefix=/us/bfsbld/Compilers/gcc/3.4.3/sparc-sun-solaris2.7 --disable-shared --
disable-multilib
Thread model: posix
gcc version 3.4.3

<290 /us/fradish/C++ > uname -a
SunOS bfs-qah51 5.8 Generic_117350-01 sun4u sparc SUNW,Ultra-5_10 

 build script ===
#!/bin/csh

set MAINDIR="/us/bfsbld/Compilers/gcc/3.4.3/sparc-sun-solaris2.7"
set GCC="${MAINDIR}/bin/g++"
set LIB="${MAINDIR}/lib"
set INCLUDE="${MAINDIR}/include"

set file=TListExample3WithScope.cpp

${GCC} -c $file -I ${INCLUDE} -save-temps
===

In the attached file TListExample3WithScope.cpp, in line 84 
(SLList::append()), you will see an unscoped
call to the inherited method bottom() and in line 85 is a commented-out 
call that is scoped by the base class name.  And in line 86 is an 
unscoped reference to "cursor".  If I use the unscoped versions of 
these, I get these errors:

<294 /us/fradish/C++ >  csh build
TListExample3WithScope.cpp: In member function `bool SLList::append(const 
T&)':
TListExample3WithScope.cpp:84: error: there are no arguments to `bottom' that 
depend on a template parameter, so a declaration of `bottom' must be available
TListExample3WithScope.cpp:84: error: (if you use `-fpermissive', G++ will 
accept your code, but allowing the use of an undeclared name is deprecated)
TListExample3WithScope.cpp:86: error: `cursor' undeclared (first use this 
function)
TListExample3WithScope.cpp:86: error: (Each undeclared identifier is reported 
only once for each function it appears in.)

If I use -fpermissive, the first error will just become a warning, but the 
second remains.  If I comile the same thing on
gcc 3.3.3, I do not encounter these errors.  If I use all of the scoped 
versions of all of these calls, the code compiles
and runs fine even on 3.4.x.

I can try to install a newer version of gcc (I guess you're up around 4.01 
now), but wanted to report this.
If this is not an error, but something that I am doing wrong that was 
tolerated in 3.3.3, can you let me
know?

P.S.  Here is the info for the 3.3.3 build where this isn't a problem:

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-
checking --disable-libunwind-exceptions --with-system-zlib --enable-
__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

=
//TListExample3WithScope.cpp
#include 
#include 

using namespace std;

template  struct SLEntry { 
SLEntry *next; 
T data;
SLEntry( const T &dat, SLEntry *nxt=NULL ) {
  data = dat;
  next = nxt;
}
~SLEntry(){}
};   

template  class SLListCursor { 
  private: 
  protected: 
SLEntry *head; 
SLEntry *cursor; 
SLListCursor(SLEntry *h=NULL, SLEntry *c=NULL){ 
   head = h; cursor = c; }
  public: 
SLListCursor( const SLListCursor & );
~SLListCursor(){} 
void top() { cursor = head; }
void bottom();
void next();
bool atEnd();
bool getData( T & );
};

template 
SLListCursor::SLListCursor( const SLListCursor &sl) { 
 head = sl.head;
 cursor = sl.cursor; 
}

template 
void SLListCursor::bottom() {
SLEntry *previous = NULL; 

if ( cursor == NULL ) { top(); } 

while ( cursor != NULL) { 
  previous = cursor; 
  next(); 
} 
cursor = previous; 
}

template 
void SLListCursor::next() {
if ( cursor != NULL) { 
  cursor = cursor->next; 
}
}

template 
bool SLListCursor::getData(T &dat) {
if ( cursor != NULL) { 
  dat = cursor->data; 
  return true;
}
return false;
} 

template 
bool SLListCursor::atEnd() {
if ( cursor == NULL) { 
  return true;
}
return false;
} 
 
template  class SLList: public SLListCursor { 
  private: 
  protected: 
  public: 
SLList(): SLListCursor() {}
~SLList(){}
// Compiler doesn't appear to see inherited methods/data
bool append( const T &value ) {
  bottom();
  //SLListCursor::bottom();
  SLEntry *tail = cursor; 
  //SLEntry *tail = SLListCursor::cursor; 
  SLEntry *newEnt = new SLEntry( value, NULL ); 
 
  SLListCursor::cursor = newEnt; 
  if

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 17:55:29
   date||


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-07-29 
17:33 ---
Yes, that's fixed the problem, thanks.

Builds now complete ok (testing still in progress).

-- 


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

[Bug tree-optimization/22550] [4.1 Regression] ICE in vrp_evaluate_conditional

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2005-07-29 
16:38 ---

Fix: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01971.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/22550] [4.1 Regression] ICE in vrp_evaluate_conditional

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
16:32 ---
Subject: Bug 22550

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-29 16:32:01

Modified files:
gcc: ChangeLog tree-cfgcleanup.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/tree-ssa: pr22550.C 

Log message:
PR 22550
* tree-cfgcleanup.c (cleanup_tree_cfg_1): Extract from ...
(cleanup_tree_cfg): ... here.
Call cleanup_tree_cfg_1 until there are no more cleanups to
do.

testsuite/ChangeLog

PR 22550
* g++.dg/tree-ssa/pr22550.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9601&r2=2.9602
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfgcleanup.c.diff?cvsroot=gcc&r1=2.3&r2=2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5851&r2=1.5852
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/tree-ssa/pr22550.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug rtl-optimization/23117] [4.1 Regression] ICE on valid code while building libgcc

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
16:31 ---
*** Bug 23136 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||kazu at gcc dot gnu dot org


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

[Bug target/23136] arm-none-eabi doesn't build anymore

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
16:31 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/23136] arm-none-eabi doesn't build anymore

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
16:24 ---
I think this is a dup of bug 23117.
Which was fixed by:
2005-07-29  Richard Earnshaw  <[EMAIL PROTECTED]>
Steven Bosscher  <[EMAIL PROTECTED]>

PR rtl-optimization/23117
* sched-rgn.c (add_branch_dependences): Handle COND_EXEC correctly
when head == tail.  Tidy comment.

-- 


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

[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k

[corsepiu at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail|4.0.0   |4.0.0 4.0.1


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

[Bug target/23136] New: arm-none-eabi doesn't build anymore

[kazu at gcc dot gnu dot org]

The arm-none-eabi build prematurely terminates with a segfault
while compiling crtstuff.c.  Here is a reduced testcase.

extern void abort (void) __attribute__((noreturn));

void
foo (int a)
{
  if (a)
abort ();
}

According to our (CodeSourcery's) automated tester,
this must have been caused before 2005-07-28 07:00UTC.

I have not analyzed where the segfault comes from.

-- 
   Summary: arm-none-eabi doesn't build anymore
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: critical
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/23135] find_reloads_toplev -> find_reloads_subreg_address uses wrong reload type

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||07/msg01968.html
   Keywords||patch


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-29 
16:01 ---
Created an attachment (id=9386)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9386&action=view)
Proposed patch

Richard --

I've tested this patch and believe it correct.  I'm running tests in more
configurations now.  I would appreciate if if you could confirm that it fixes
your problem.

Thanks,

-- Mark

-- 


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

[Bug middle-end/23135] find_reloads_toplev -> find_reloads_subreg_address uses wrong reload type

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-07-29 
15:29 ---
Created an attachment (id=9385)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9385&action=view)
context & patch

These are the patches that exposed the latent bug for sh-elf, together with the

reload bug fix.

-- 


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

[Bug middle-end/23135] New: find_reloads_toplev -> find_reloads_subreg_address uses wrong reload type

[amylaar at gcc dot gnu dot org]

I've added a movti expander to sh.md, and found a regression for -m4 -ml
on simd-1.c with optimization options -O1, -O2, -O3 and -Os .
I've foun that a output reload address was being overwritten by
a secondary output reload.
The secondary output reload had RELOAD_FOR_OUTPUT_ADDRESS, and the
address reload had RELOAD_FOR_OUTADDR_ADDRESS, both for the same
operand.  In the absence of a seond RELOAD_FOR_OUTPUT_ADDRESS
reload, these types are not supposed to conflict.  The output
address reload should have used RELOAD_FOR_OUTPUT_ADDRESS.

-- 
   Summary: find_reloads_toplev -> find_reloads_subreg_address uses
wrong reload type
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/21723] [4.0 Regression] ICE while building libgfortran

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
15:08 ---
Subject: Bug 21723

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-07-29 15:08:45

Modified files:
gcc: ChangeLog 
gcc/config/pa  : pa.md pa32-regs.h pa64-regs.h 

Log message:
PR target/21723
* pa.md: Remove fcpy alternative from movhi and movqi patterns.
* pa32-regs.h (HARD_REGNO_NREGS): Return two floating point registers
for complex modes when generating code for PA 1.0.
(VALID_FP_MODE_P): New macro.
(HARD_REGNO_MODE_OK): Use VALID_FP_MODE_P.  Use non-overlapping register
sets for all general and floating point modes.  Align wide floating
point modes to even register boundaries to comply with architectural
requirements.
(CLASS_MAX_NREGS): Update to align with change to HARD_REGNO_NREGS.
* pa64-regs.h (HARD_REGNO_NREGS): Update comment and formatting.
(VALID_FP_MODE_P): New macro.
(HARD_REGNO_MODE_OK): Use VALID_FP_MODE_P.  Use non-overlapping register
sets for all general and floating point modes.  Align wide floating
point modes to even register boundaries to comply with architectural
requirements.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.342&r2=2.7592.2.343
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.158.6.1&r2=1.158.6.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa32-regs.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.14&r2=1.14.36.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/pa64-regs.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.18&r2=1.18.28.1



-- 


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

[Bug tree-optimization/23127] [4.1 Regression] VRP propagates negation of antirange incorrectly

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-07-29 
14:59 ---
 I already commited testcases for this one and 23126.

-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-29 
14:54 ---
I understand what's causing this; patch coming soon.

-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[rearnsha at gcc dot gnu dot org]

--- Additional Comments From rearnsha at gcc dot gnu dot org  2005-07-29 
14:53 ---
Subject: Re:  [4.1 Regression] Fixincludes on
cross-build is scanning /usr/include

On Fri, 2005-07-29 at 15:45, mmitchel at gcc dot gnu dot org wrote:
> What is SYSTEM_HEADER_DIR in your generated gcc/Makefile?  Is it
> $(CROSS_SYSTEM_HEADER_DIR), $(NATIVE_SYSTEM_HEADER_DIR), or something worse?

# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /usr/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include

# autoconf sets SYSTEM_HEADER_DIR to one of the above.
SYSTEM_HEADER_DIR = 

Ie. it's empty.


-- 


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-29 
14:45 ---
Since you're not using --with-sysroot or --with-build-sysroot, I'm slightly
surprised.

What is SYSTEM_HEADER_DIR in your generated gcc/Makefile?  Is it
$(CROSS_SYSTEM_HEADER_DIR), $(NATIVE_SYSTEM_HEADER_DIR), or something worse?

I think I see a bug with *native* compilers that use --with-sysroot, but you're
in a cross configuration.  Of course, I'll try it myself and see momentarily.

Thanks!

-- 


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

[Bug tree-optimization/23133] recip does not factor division by function parameter

[rguenth at gcc dot gnu dot org]

--- Additional Comments From rguenth at gcc dot gnu dot org  2005-07-29 
14:28 ---
I have a patch for this.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-07-29 13:45:43 |2005-07-29 14:28:55
   date||


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

[Bug tree-optimization/23134] Address escapes even though the called function does not cause it to escape

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-07-29 13:57 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 13:57:51
   date||


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

[Bug libstdc++/22284] [4.1 Regression] ia64 exception handling broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
13:50 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/23133] recip does not factor division by function parameter

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
13:45 ---
Confirmed, another testcase (which might be needed as the redundant load of a 
and b are not done):
double a, b;
int x;
double foo(double d)
{
  double a1 = a, b1 = b;
  if (x)
 a1/=d;
  return (a1/d) * (b1/d);
}

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 13:45:43
   date||


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

[Bug rtl-optimization/19767] [3.4 only] CSE hang on very simple code with -O2 -ftracer

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-07-29 
13:43 ---
Testing a patch

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-02 19:06:47 |2005-07-29 13:43:15
   date||


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

[Bug tree-optimization/23134] Address escapes even though the called function does not cause it to escape

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||alias


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

[Bug tree-optimization/23134] New: Address escapes even though the called function does not cause it to escape

[pinskia at gcc dot gnu dot org]

Take this "stupid" example (even though this most likely shows up in GCC but I 
don't know for sure):
int g1(int);
static void h(int *a) { *a = 1; }

int g(void)
{
  int t = 0;
  h(&t);
  int t1 = t;
  g1(t1);
  return t1 == t;
}

That return should have been turned into "return 1" as t does not escape via h 
as h only touches it.
Compile with -O3 -fno-inline to see the problem.

-- 
   Summary: Address escapes even though the called function does not
cause it to escape
   Product: gcc
   Version: 4.1.0
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=23134

[Bug libstdc++/22284] [4.1 Regression] ia64 exception handling broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-07-29 
13:36 ---
Subject: Bug 22284

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-07-29 13:35:59

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/libsupc++: eh_personality.cc 

Log message:
2005-07-29  H.J. Lu  <[EMAIL PROTECTED]>

PR libstdc++/22284
* libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Revert
the change to info.ttype_base.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.3066&r2=1.3067
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/libsupc++/eh_personality.cc.diff?cvsroot=gcc&r1=1.17&r2=1.18



-- 


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

[Bug tree-optimization/23133] New: recip does not factor division by function parameter

[rguenth at gcc dot gnu dot org]

The following testcase, compiled with -O2 -ffast-math should have
1/d factored out, but doesn't, because d is a function parameter
and recip walks SSA_NAME defs, and d does not have one.

double a, b;
int x;
double foo(double d)
{
  if (x)
 a/=d;
  return a/d + b/d;
}

-- 
   Summary: recip does not factor division by function parameter
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2005-07-29 12:40 
---
Should a separate PR be opened requesting __GCC_PTHREADS__, so this PR can focus
on whether _REENTRANT should be defined unconditionally and discussion of an
alternative macro can take place separately?

I have the beginnings of a patch to define __GCC_PTHREADS__ whenever -pthread is
given if that would help. It's incomplete, as not all gcc/config/* files use
-pthread in the CPP_SPEC and I have only added -D__GCC_PTHREADS__ where CPP_SPEC
already does something for -pthread/-pthreads.  If I'm not wasting my time I'll
finish it off.

-- 


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

[Bug rtl-optimization/17808] Scheduler overly conservative in sched-deps

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug rtl-optimization/17808] Scheduler overly conservative in sched-deps

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-07-29 
12:39 ---
It seems we've dealt with all the fall-out now. 
 

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
12:38 ---
This is a -fweb latent bug.  If you do -O3 -fweb -funroll-loops on the 4.0 
branch it also fails.

I have a patch which seems to work around the bug but also causes cost model of 
address models to be 
different from the mainline and I don't know if it is a correct patch or not.

-- 
   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
Summary|[4.1 regression]|[4.1 regression]
   |elemental.f90 testsuite |elemental.f90 testsuite
   |failure |failure (-fweb)


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

[Bug c++/23132] Array delete'd through base class causes access violation in prog

[jorik dot dewit at gmail dot com]

--- Additional Comments From jorik dot dewit at gmail dot com  2005-07-29 
12:29 ---
(In reply to comment #1)
> *** This bug has been marked as a duplicate of 22609 ***

Sorry about reporting a duplicate. I had looked/searched. Maybe the default 
settings for the query form should include issues with status RESOLVED (but 
with resolution <> FIXED; i.e. especially INVALID  (and WONTFIX/DUPLICATE).
Maybe this would avoid some duplicate bug reports?

-- 


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

[Bug tree-optimization/21559] [4.1 Regression] missed jump threading

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |minor


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

[Bug c++/22003] [4.1 Regression] -freorder-blocks-and-partition and thunks

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
12:20 ---
My reduced testcase no longer ICEs.

-- 


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

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[david dot nospam dot hopwood at blueyonder dot co dot uk]

--- Additional Comments From david dot nospam dot hopwood at blueyonder dot 
co dot uk  2005-07-29 11:58 ---
 suggests defining
__GNUC_THREADMODEL__ to a string specifying the thread model.

-- 


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

[Bug c++/22609] delete [] called on base virtual destructor class [Segmentation failed]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:49 ---
*** Bug 15050 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bracken at ansoft dot com


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

[Bug c++/15050] Compiled templated code crashes on delete []

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:49 ---
Mark as a dup of bug 22609.

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

-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/15050] Compiled templated code crashes on delete []

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:48 ---
Reopening to ...

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c++/22609] delete [] called on base virtual destructor class [Segmentation failed]

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:47 ---
*** Bug 23132 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jorik dot dewit at gmail dot
   ||com


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

[Bug c++/23132] Array delete'd through base class causes access violation in prog

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:47 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug driver/20705] -pthread should enable all options required to use pthreads on all platforms

[david dot nospam dot hopwood at blueyonder dot co dot uk]

--- Additional Comments From david dot nospam dot hopwood at blueyonder dot 
co dot uk  2005-07-29 11:46 ---
-pthread is apparently deprecated on FreeBSD (see 
 and
).

As part of fixing this bug, it should be undeprecated, since the rationale for
deprecating it goes away if it works properly on all platforms (which on FreeBSD
would mean linking against either libkse or libpthread depending on the FreeBSD
version, I think).


-- 


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

[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:42 ---
-fspeculative-prefetching has now been removed from the mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.1.0


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

[Bug rtl-optimization/17491] -fspeculative-prefetching fails on powerpc-*

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:39 ---
-fspeculative-prefetching has now been removed from the mainline.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/23131] [4.1 Regression] Fixincludes on cross-build is scanning /usr/include

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|Fixincludes on cross-build  |[4.1 Regression] Fixincludes
   |is scanning /usr/include|on cross-build is scanning
   ||/usr/include
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/23128] [4.1 Regression] VRP fails for unsigned values

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:31 ---
Confirmed.

-- 
   What|Removed |Added

 CC||phython at gcc dot gnu dot
   ||org, dnovillo at gcc dot gnu
   ||dot org
   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-07-29 11:31:44
   date||
Summary|VRP fails for unsigned  |[4.1 Regression] VRP fails
   |values  |for unsigned values
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/23127] [4.1 Regression] VRP propagates negation of antirange incorrectly

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-29 
11:29 ---
Fixed in 20050729 already by:
2005-07-27  James A. Morrison  <[EMAIL PROTECTED]>

PR tree-optimization/22493
* tree-vrp.c (extract_range_from_unary_expr): Deal with -fwrapv and
VR_ANTI_RANGEs properly for NEGATE_EXPRs and ABS_EXPRs.

James, You want to apply this testcase as an example of something which VRP 
miscompiled?

-- 
   What|Removed |Added

 CC||phython at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |RESOLVED
   Keywords||wrong-code
 Resolution||FIXED
Summary|VRP propagates negation of  |[4.1 Regression] VRP
   |antirange incorrectly   |propagates negation of
   ||antirange incorrectly
   Target Milestone|--- |4.1.0


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