[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274

[paolo dot bonzini at lu dot unisi dot ch]

--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch  
2004-11-18 08:03 ---
Subject: Re:  ICE in do_jump, at dojump.c:274

> And that would mean it was caused by:
> * dojump.c (do_jump)  TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, COMPOUND_EXPR>:
> Abort on gimplified cases.

While I can work on a fix, those COND_EXPR were *not* valid GIMPLE at 
the time the patch was written.

Paolo


-- 


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

[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-11-18 
09:00 ---
OK, I'll take care of this since I caused it.

-- 
   What|Removed |Added

 AssignedTo|mark at codesourcery dot com|giovannibajo at libero dot
   ||it


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

[Bug fortran/18518] d1mach(4) (BLAS) broken, g77 regression

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-11-18 
09:02 ---
(In reply to comment #2)
> On AMD x32 the correct result is obtained with g77. g95 and pgfortran work as
> expected, only gfortran stops:
> 
> > gfortran d1mach.f && ./a.out
>   2.225073858507201E-308
> At line 215 of file d1mach.f
> STOP 778

Same result here, with the same processor.  There is different
(but not correct) behavior with -ffloat-store:

$ gfortran -ffloat-store d1mach.f && ./a.out
  2.225073858507201E-308
  4.882199637915989E-270
  5.092789898316654E-312
  4.925696698649795E-270
   2.79357004253718


-- 


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

[Bug c++/18538] New: internal compiler error / tree_low_cst / tree.c:3313

[thomas-dloop at kuehne dot cn]

the compiler panics on following code:

struct NameId{
char name[];
};

static NameId names[]={
0
};

-- 
   Summary: internal compiler error / tree_low_cst / tree.c:3313
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thomas-dloop at kuehne dot cn
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=18538

[Bug fortran/18539] New: Tru64 - runtime error with -ve memory for assumed shape arrays

[paul dot richard dot thomas at cea dot fr]

Note that this seems to be unique to the Tru64 build with gcc-3.3.2 (TWW)
It occurs with or without -fbounds-check

OSF1 V5.1 2650 alpha  (BUT NOT CYGWIN_NT-5.0 1.5.7(0.109/3/2) 2004-01-30 19:32 
i686)

GNU Fortran 95 (GCC 4.0.0 20041114 (experimental))
built with gcc-3.3.2 (TWW)

Index range, y(start:end) produce runtime error for start>end ,when used
for an assumed shape array.  

program negmem
   integer, parameter   ::N = 3
   integer  ::i
   real(kind = 8), dimension(N) ::y = (/ (real(i) , i = 1 , N) /)
   real(kind = 8)   ::scale = 2.0

! This part is OK

   do i = 1 , N
  print * , ' y(' , i+1 , ':' , N , ')'
  y( i + 1 : N ) = y( i + 1 : N ) / scale
  print * , y( i + 1 : N )
   end do
   
! This part causes the runtime error

   call scaler( y , scale , N)
   print *, 'output from scalar'
   print * , y
   stop
contains
   subroutine scaler( y , scale , N )
   real(kind =8), dimension(:)  ::y
   real(kind =8)::scale
   integer  ::N , i
   do i = 1 , N
  y( i + 1 : N ) = y( i + 1 : N ) / scale
   end do
   return
   end subroutine scaler
end program negmem

Produces:

  y(   2 :   3 )
1.001.50
  y(   3 :   3 )
   0.750
  y(   4 :   3 )
Fortran runtime error: Attempt to allocate a non-positive amount of memory.

-- 
   Summary: Tru64 - runtime error with -ve memory for assumed shape
arrays
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
CC: gcc-bugs at gcc dot gnu dot org,paulthomas2 at wanadoo
dot fr


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

[Bug fortran/18540] New: Jumping into blocks gives error rather than warning

[paul dot richard dot thomas at cea dot fr]

program lau_error
!
! most compilers seem to permit this excremental bit of coding
! some give warnings that this is bad stuff
! gfortran barfs on it
!
! In file lau_error.f90:12
!
! 10continue
!  1
! In file lau_error.f90:9
!
!if ( i > 1 ) goto 10
!   2
!Error: Label at (1) is not in the same block as the GOTO statement at (2)
!Paul Thomas 18/11/04
!
  integer  ::i , N = 2
  do i = 1 , N
print * , 'i =  ', i
if ( i > 1 ) goto 10!!jump into the if block *sigh*
if ( i > 0 ) then
   print * , 'first statement in if block'
 10continue
   print * , 'continue within if block'
end if
print * , 'out of if block'
  end do
  stop
end program lau_error

-- 
   Summary: Jumping into blocks gives error rather than warning
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paul dot richard dot thomas at cea dot fr
CC: gcc-bugs at gcc dot gnu dot org,paulthomas2 at wanadoo
dot fr


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

[Bug libfortran/15234] libgfortran doesn't compile on Tru64 UNIX

[paul dot richard dot thomas at cea dot fr]

--- Additional Comments From paul dot richard dot thomas at cea dot fr  
2004-11-18 11:32 ---
gcc-4.0 including gfortran build fine on Tru64 OSF1 V5.1 2650 alpha as long as 
gcc and GNU make are used in the build.

I built GNU Fortran 95 (GCC 4.0.0 20041114 (experimental)) with gcc-3.3.2 
(TWW). It gives no trouble at all, as long as LD_LIBRARY_PATH points to the gcc 
libraries and to gmp/mpfr.

-- 


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

[Bug rtl-optimization/17107] Opportunity to improve code generated for complex logical expression

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-18 
12:10 ---
Subject: Bug 17107

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-11-18 12:09:45

Modified files:
gcc: ChangeLog fold-const.c 
gcc/config/rs6000: rs6000.h 

Log message:
PR target/17107
* fold-const.c (RANGE_TEST_NON_SHORT_CIRCUIT): Rename to ...
(LOGICAL_OP_NON_SHORT_CIRCUIT): ... here.
(fold_range_test): Adjust.
(fold_truthop): Use it.
* config/rs6000/rs6000.h (RANGE_TEST_NON_SHORT_CIRCUIT): Rename to ...
(LOGICAL_OP_NON_SHORT_CIRCUIT): ... here.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6393&r2=2.6394
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.474&r2=1.475
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.h.diff?cvsroot=gcc&r1=1.346&r2=1.347



-- 


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

[Bug rtl-optimization/17107] Opportunity to improve code generated for complex logical expression

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2004-11-18 
12:14 ---
2004-11-18  Nathan Sidwell  <[EMAIL PROTECTED]>

PR target/17107
* fold-const.c (RANGE_TEST_NON_SHORT_CIRCUIT): Rename to ...
(LOGICAL_OP_NON_SHORT_CIRCUIT): ... here.
(fold_range_test): Adjust.
(fold_truthop): Use it.
* config/rs6000/rs6000.h (RANGE_TEST_NON_SHORT_CIRCUIT): Rename to ...
(LOGICAL_OP_NON_SHORT_CIRCUIT): ... here.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/18327] [3.3/3.4/4.0 Regression] ICE while compiling valid c code with g++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:14 ---
*** Bug 18538 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||thomas-dloop at kuehne dot
   ||cn


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

[Bug c++/18538] internal compiler error / tree_low_cst / tree.c:3313

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:14 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/17107] Opportunity to improve code generated for complex logical expression

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug c++/18541] New: "using" fails to make name visible without qualification

[igodard at pacbell dot net]

#include 
template >
class buffer : public std::basic_streambuf {
virtual
int_typeoverflow(int_type c = tr::eof());

virtual
typename int_type   overflow1(typename int_type c = tr::eof());

using std::basic_streambuf::int_type;

virtual
int_typeoverflow2(int_type c = tr::eof());

virtual
typename int_type   overflow3(typename int_type c = tr::eof());

virtual
std::basic_streambuf::int_type  overflow4(
std::basic_streambuf::int_type c = tr::eof());

virtual
typename std::basic_streambuf::int_type overflow5(
typename std::basic_streambuf::int_type c = tr::eof());
};
int main() {
buffer<> b;
}

gets you:

~/ootbc/common/test/src$ g++ foo.cc
foo.cc:5: error: `int_type' does not name a type
foo.cc:5: error: (perhaps `typename std::basic_streambuf<_CharT,
_Traits>::int_type' was intended)
foo.cc:8: error: expected nested-name-specifier before "int_type"
foo.cc:8: error: `int_type' does not name a type
foo.cc:8: error: (perhaps `typename std::basic_streambuf<_CharT,
_Traits>::int_type' was intended)
foo.cc:13: error: `int_type' does not name a type
foo.cc:13: error: (perhaps `typename std::basic_streambuf<_CharT,
_Traits>::int_type' was intended)
foo.cc:16: error: expected nested-name-specifier before "int_type"
foo.cc:16: error: `int_type' does not name a type
foo.cc:16: error: (perhaps `typename std::basic_streambuf<_CharT,
_Traits>::int_type' was intended)
foo.cc:19: error: ISO C++ forbids declaration of `int_type' with no type
foo.cc:19: error: cannot declare member `std::basic_streambuf<_CharT,
_Traits>::int_type' within `buffer'
foo.cc:19: error: expected `;' before "overflow4"


As suggested in the error for "overflow" (good message BTW), the form used in 
"overflow5" works. But a "using" for the inherited name "int_type" does not 
make 
the name visible either directly (overflow2) or when tagged with "typename" 
(overflow 3). But the "using" doesn't complain either. If I can "using" it I 
should be able to "use" it :-)

Ivan

-- 
   Summary: "using" fails to make name visible without qualification
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libfortran/15234] libgfortran doesn't compile on Tru64 4.0f UNIX

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:18 ---
5.1 is fixed but 4.0 is still broken.

-- 
   What|Removed |Added

  GCC build triplet|alpha-dec-osf5.1b   |
   GCC host triplet|alpha-dec-osf5.1b   |
 GCC target triplet|alpha-dec-osf5.1b   |alpha-dec-osf4.0f
Summary|libgfortran doesn't compile |libgfortran doesn't compile
   |on Tru64 UNIX   |on Tru64 4.0f UNIX


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

[Bug target/18542] New: ICE: output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

The code snippet in the attachment (stripped down real-world code) causes an ICE
when compiling with -01 or greater. The ICE does not occur with -O0.

# m68k-rtems4.7-gcc -O1 -c -o startup_rel-cpuboot.o cpuboot.c
cpuboot.c: In function `boot_phase_1':
cpuboot.c:11: internal compiler error: output_operand: invalid expression as 
operand
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

# m68k-rtems4.7-gcc --version
m68k-rtems4.7-gcc (GCC) 3.4.4 20041114 (prerelease)

-- 
   Summary: ICE: output_operand: invalid expression as operand
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: m68k-*-elf m68k-rtems*


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

[Bug target/18542] ICE: output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-18 
12:25 ---
Created an attachment (id=7564)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7564&action=view)
Code example to reproduce the ICE


-- 


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

[Bug c++/18541] "using" fails to make name visible without qualification

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:25 ---
Yes this is a bug in GCC, see PR 14258.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/14258] typename in a using declaration not supported

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:25 ---
*** Bug 18541 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||igodard at pacbell dot net


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:28 ---
At least the striped down source compiles just fine on the mainline.

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||4.0.0
Summary|ICE: output_operand: invalid|[3.4 only] ICE:
   |expression as operand   |output_operand: invalid
   ||expression as operand
   Target Milestone|--- |3.4.4


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

[Bug fortran/18540] Jumping into blocks gives error rather than warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:31 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 12:31:33
   date||


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

[Bug fortran/18539] Tru64 - runtime error with -ve memory for assumed shape arrays

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:33 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|Tru64 - runtime error with -|Tru64 - runtime error with -
   |ve memory for assumed shape |ve memory for assumed shape
   |arrays  |arrays


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

[Bug fortran/15335] runtime error "Attempt to allocate a negative amount of memory"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:33 ---
*** Bug 18539 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||paul dot richard dot thomas
   ||at cea dot fr


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

[Bug driver/7957] change request: more flexible %D specs directive so no need to set LD_LIBRARY_PATH

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:37 ---
I really doubt that we want this option as we have always recommend in setting 
LD_LIBRARY_PATH.

-- 
   What|Removed |Added

   Last reconfirmed|2004-08-19 05:32:11 |2004-11-18 12:37:36
   date||


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-18 
12:40 ---
Chris, Joel, could you try with your GCC versions?


-- 
   What|Removed |Added

 CC||cjohns at cybertec dot com
   ||dot au


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

[Bug fortran/18537] no warning about tabs with std=f95 option

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:44 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 12:44:09
   date||


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

[Bug tree-optimization/17635] [4.0 regression] ICE in verify_ssa: type mismatch

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-18 
12:46 ---
Fixed.
The testcase was committed, too.


-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/18528] [4.0? Regression] ICE with -fweb

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:48 ---
Confirmed, well on the mainline we have an ICE which is a regression:

t1.c: In function 'main':
t1.c:45: internal compiler error: in bitmap_ior, at bitmap.c:704
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |rtl-optimization
 Ever Confirmed||1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 12:48:20
   date||
Summary|miscompilation of inline|[4.0? Regression] ICE with -
   |assembler  with -fweb   |fweb
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/18532] libgcc.mk isn't parallel build safe for multilib

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:51 ---
Patch here: .

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||build, patch
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 12:51:16
   date||


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

[Bug tree-optimization/18478] [4.0 Regression] ICE with -funroll-loops

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-18 
12:51 ---
Fixed by Jeff's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00823.html


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/18533] EXTRA_MULTILIB_PARTS are used to build libgcc_s.so for multilib

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:51 ---
Confirmed, patch here: 
.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 12:51:54
   date||


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to work|4.0.0   |4.0.0 3.2.3


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

[Bug middle-end/17895] [4.0 Regression] tree CFG cleanup is slow

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:59 ---


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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
12:59 ---
*** Bug 17895 has been marked as a duplicate of this bug. ***

-- 
Bug 15524 depends on bug 17895, which changed state.

Bug 17895 Summary: [4.0 Regression] tree CFG cleanup is slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17895

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
13:00 ---
I will do some timings today but I think this is fixed now.

-- 


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[corsepiu at gcc dot gnu dot org]

--- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-18 
13:14 ---
The same ICE occurs for avr-rtems* and h8300-rtems* toolchains having been built
from the same sources.


-- 
   What|Removed |Added

 GCC target triplet|m68k-*-elf m68k-rtems*  |m68k-*-elf m68k-rtems* avr-
   ||rtems* h8300-rtems*


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

[Bug c++/18543] New: Error message for invalid friend declaration could be improved

[reichelt at gcc dot gnu dot org]

In the code snippet below the error messages for the template case
and the non-template case differ (the template case being worse):


struct A
{
friend int A();
};

template struct B
{
friend int B();
};

B<0> b;


non-template part:

  bug.cc:3: error: return type specification for constructor invalid
  bug.cc:3: warning: member functions are implicitly friends of their class

template part:

  bug.cc:8: error: return type specification for constructor invalid
  bug.cc: In instantiation of 'B<0>':
  bug.cc:11:   instantiated from here
  bug.cc:8: error: 'void B()' redeclared as different kind of symbol

that's not a constructor

  bug.cc:6: error: previous declaration of 'template > struct B'


This is present since at least gcc 2.95.3.

-- 
   Summary: Error message for invalid friend declaration could be
improved
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/15335] runtime error "Attempt to allocate a negative amount of memory"

[paul dot richard dot thomas at cea dot fr]

--- Additional Comments From paul dot richard dot thomas at cea dot fr  
2004-11-18 13:22 ---
This example gives a segmentation fault with Cygwin and gfortran 20041114

>   integer:: p(4)

Initialising p(4) = (/1,2,3,4/) gets rid of the fault and the programme runs to 
completion.  I do not think that this is entirely the same as #18539, which 
seems to be specific to Tru64 (and Linux?)  

Note that with p initialised, DRIVER still segment faults on Tru64 because i is 
unitialised (this should also fail under Cygwin.). If, I set I to 1, for 
example, then, finally I get the request for negative memory.

-- 


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

[Bug tree-optimization/18529] When the lower bound of a loop is non-constant we cannot find the number of iterations

[rakdver at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug c++/18543] Error message for invalid friend declaration could be improved

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
14:06 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 14:06:32
   date||


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2004-11-18 14:13 
---
Subject: Re:  [3.4 only] ICE: output_operand: invalid expression
 as operand

corsepiu at gcc dot gnu dot org wrote:
> --- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-18 
> 13:14 ---
> The same ICE occurs for avr-rtems* and h8300-rtems* toolchains having been 
> built
> from the same sources.
> 
> 

I have 3.2.3 and 3.3.5 RTEMS tools installed and tried this for
the m68k.  It looks OK there.  So it must be a 3.4.x specific
issue.

What other targets/versions do you want to try?

+ /opt/rtems-4.6/bin/m68k-rtems-gcc --version
m68k-rtems-gcc (GCC) 3.2.3 (OAR Corporation 
gcc-3.2.3-20040420/newlib-1.11.0-20030605-4)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ /opt/rtems-4.6/bin/m68k-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/m68k-rtems4.7-gcc --version
m68k-rtems4.7-gcc (GCC) 3.3.5
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

+ /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -O1 -c cpuboot.c




-- 


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

[Bug target/18542] [3.4 only] ICE: output_operand: invalid expression as operand

[joel at oarcorp dot com]

--- Additional Comments From joel at oarcorp dot com  2004-11-18 14:26 
---
Subject: Re:  [3.4 only] ICE: output_operand: invalid expression
 as operand

corsepiu at gcc dot gnu dot org wrote:
> --- Additional Comments From corsepiu at gcc dot gnu dot org  2004-11-18 
> 13:14 ---
> The same ICE occurs for avr-rtems* and h8300-rtems* toolchains having been 
> built
> from the same sources.
> 
> 


A bit more follow up.  Again the 4.6 tools are gcc 3.2.3 based
and the 4.7 are gcc 3.3.5.

+ /opt/rtems-4.6/bin/arm-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/h8300-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/i386-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/i960-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/m68k-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/mips-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/powerpc-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/sh-rtemself-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/sh-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.6/bin/sparc-rtems-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/arm-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/i386-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/mips64-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/mips-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/powerpc-rtems4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/sh-rtemself4.7-gcc -O1 -c cpuboot.c
+ /opt/rtems-4.7/bin/sparc-rtems4.7-gcc -O1 -c cpuboot.c

I tried it again at -O4 and it all compiled fine.

I think it is pretty safe to assume at this point that the
problem is specific to 3.4.

--joel


-- 


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
14:31 ---
I think this fixed except I have not checked with checking turned off.
With checking still on I get the following passes as hot:
 dominator optimization:  31.03 (42%) usr   0.02 ( 1%) sys  31.26 (40%) wall
 tree SSA verifier :   5.64 ( 8%) usr   0.00 ( 0%) sys   5.68 ( 7%) wall
 rename registers  :   7.37 (10%) usr   0.02 ( 1%) sys   7.46 (10%) wall

But cfg cleanup went down a huge amount:
 tree CFG cleanup  :   1.23 ( 2%) usr   0.00 ( 0%) sys   1.25 ( 2%) wall

Before (20041113) on a slightly faster machine and different OS:
 tree CFG cleanup  :  33.36 (43%) usr   0.01 ( 1%) sys  33.41 (42%) wall
 tree split crit edges :  16.83 (22%) usr   0.01 ( 1%) sys  16.87 (21%) wall
 dominator optimization:   7.94 (10%) usr   0.03 ( 2%) sys   7.97 (10%) wall
 tree SSA verifier :   2.57 ( 3%) usr   0.01 ( 1%) sys   2.53 ( 3%) wall
 rename registers  :   5.57 ( 7%) usr   0.03 ( 2%) sys   5.61 ( 7%) wall

Hmm, either DOM was just slowed down (because of checking) or something is 
really different between 
these two OS's.

But as you can see that tree CFG cleanup and tree split crit edges have sped up 
a lot.
I will try to get a new compiler built without checking turned on later today 
to get final numbers.

-- 


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

[Bug tree-optimization/18536] ICE: in emit_move_insn, at expr.c:2590 with -ftree-vectorize -msse2

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2004-11-18 14:33 
---
(In reply to comment #1)
> Confirmed,  the problem I think is the same as the PPC64 problem in PR 18403 
but I did not check the 
> patch which will fix that one for sure.

That patch does not fix this problem - this is a type mismatch in a different 
place than the one in PR18403. I have a fix for this problem - I'll send a 
patch shortly.

-- 


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

[Bug tree-optimization/18544] New: [4.0 regression] ICE with -ftree-vectorize

[reichelt at gcc dot gnu dot org]

The following code snippet causes an ICE on mainline when compiled with
"-ftree-vectorize -O -march=pentium2":

=
struct A
{
int x[2];

A()
{
int* p=x;
for (int i=0; i<2; ++i, ++p)
*p = 0;
}
};

A foo()
{
return A();
}
=

bug.cc: In function 'A foo()':
bug.cc:13: internal compiler error: in vect_create_data_ref_ptr, at
tree-vectorizer.c:1841
Please submit a full bug report, [etc.]

According to Phil's regression hunter this was introduced in October:
: Search converges between 2004-10-12-014001-trunk (#591) and
2004-10-15-014001-trunk (#592).

-- 
   Summary: [4.0 regression] ICE with -ftree-vectorize
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/18544] [4.0 regression] ICE with -ftree-vectorize

[reichelt at gcc dot gnu dot org]

-- 
   What|Removed |Added

  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=18544

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-11-18 15:56 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Thu, 2004-11-18 at 13:00 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
> 13:00 ---
> I will do some timings today but I think this is fixed now.
Please don't mark it as fixed.  THere's still some significant
lameness.  I suspect there's another 10-20% improvement waiting
to be realized without doing anything terribly difficult.

jeff




-- 


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

[Bug c++/18545] New: [3.4/4.0 regression] ICE when returning undefined type

[reichelt at gcc dot gnu dot org]

The following invalid code snippet crashes the C++ frontend:

===
struct A;

A foo()
{
A a;
return a;
}
===

bug.cc: In function 'A foo()':
bug.cc:7: error: return type 'struct A' is incomplete
bug.cc:9: error: aggregate 'A a' has incomplete type and cannot be defined
bug.cc:10: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in check_return_expr, at cp/typeck.c:6296
Please submit a full bug report, [etc.]

The bug is present since gcc 3.4.0.
Looks like it was introduced with the new parser:
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).

-- 
   Summary: [3.4/4.0 regression] ICE when returning undefined type
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18545] [3.4/4.0 regression] ICE when returning undefined type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
16:06 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 16:06:02
   date||
   Target Milestone|--- |3.4.4


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

[Bug tree-optimization/18544] [4.0 regression] ICE with -ftree-vectorize

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-11-18 
16:09 ---
Might be related to PR18536.


-- 


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

[Bug tree-optimization/18546] New: tree vectorizer does not understand RETURN_DECL

[pinskia at gcc dot gnu dot org]

Compile the following with the C and C++ front-end and you will get different 
assembly, the C front-
end does not do NVR at all while the C++ front-end will change the a decl to be 
the return_decl before 
so we the vectorizer cannot do the vectorization because it does not hanndle 
RETURN_DECLs at all.

struct A
{
int x[4];
};

struct A foo()
{
  struct A a;
  for (int i=0; i<4; ++i)
a.x[i] = 0;
  return a;
}

-- 
   Summary: tree vectorizer does not understand RETURN_DECL
   Product: gcc
   Version: 4.0.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=18546

[Bug tree-optimization/18544] [4.0 regression] ICE with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
16:14 ---
Confirmed, here is a reduced testcase (which shows maybe the problem):
struct A
{
int x[4];
};
struct A foo()
{
  struct A a;
  int* p=a.x;
  for (int i=0; i<4; ++i, ++p)
*p = 0;
  return a;
}

Note it works no when compiled with the C front-end but not with the C++ 
front-end.
It is more related to PR 18546 than it is to PR18536.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|i686-pc-linux-gnu   |i686-pc-linux-gnu, powerpc-
   ||darwin
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 16:14:17
   date||


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

[Bug c++/3332] friend function declaration in a class in a namespace causes error

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-11-18 
17:04 ---
Patch submitted (both are required):

  (Friend lookup part 2/n) 
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01372.html
  (Friend lookup part 3/n) 
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01495.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug bootstrap/18547] New: Cygwin

[illumanus at yahoo dot com]

In latest change in cygwin 1.5.12-1, all volumes default binmode. In Win32 
configurations using cygwin: genconditions.exe creates insn-*.c files that 
contain 0xD, which causes "make bootstrap" to fail. Isolated to gensupport.c 
init_md_reader. Fix is as follows:
Line 920 currently reads:
 input_file = fopen (filename, "r");
Line 920 should read:
 input_file = fopen (filename, "rt")
This fixes reading condition files in text mode vice default (binary mode). In 
binary mode for win32, 0xD will be read in. In text mode for win32, 0xD is 
suppressed. (Win32 systems store 0xD before 0xA ('\n') for text files)
Note that this bug will not affect non-win32 systems as for most other systems 
text mode = binary mode.

-- 
   Summary: Cygwin
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: illumanus at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: default (i386)
  GCC host triplet: default (i386)
GCC target triplet: default (i386)


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

[Bug bootstrap/18547] Cygwin

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
17:39 ---
Text mode is the default at least according to C89 so the bug is in cygwin and 
not GCC.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|Cygwin  |Cygwin


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

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
18:23 ---
Here are the current timings for the mainline and 3.3:
mainline:
[zhivago:~/src/localgccPRs] pinskia% time ~/local3/bin/gcc -S pr15524.c -O1
27.680u 1.240s 0:32.98 87.6%0+0k 0+6io 0pf+0w

3.3:
[zhivago:~/src/localgccPRs] pinskia% time gcc -S pr15524.c -O1
14.260u 0.560s 0:16.30 90.9%0+0k 0+4io 0pf+0w

At -O0:
mainline:
[zhivago:~/src/localgccPRs] pinskia% time ~/local3/bin/gcc -S pr15524.c
2.790u 0.350s 0:03.52 89.2% 0+0k 0+3io 0pf+0w

3.3:
[zhivago:~/src/localgccPRs] pinskia% time gcc -S pr15524.c
1.930u 0.280s 0:02.28 96.9% 0+0k 1+3io 0pf+0w

Note that is this on powerpc-darwin and with Apple's 3.3 (build 1650 or so).


So we are still twice as slow as 3.3 but faster than before.
Using -ftime-report I get:
 dominator optimization:  11.69 (42%) usr   0.13 ( 4%) sys  12.28 (38%) wall
 rename registers  :   3.32 (12%) usr   0.12 ( 4%) sys   3.62 (11%) wall

So only DOM needs to be sped up.

For DOM the problem comes from thread_across_edge when we go and update the 
profile of the BB.

For renane registers, most of a profile of compiling this source comes from 
regrename.c the loop which 
is around line 1761. 

-- 
   What|Removed |Added

   Severity|critical|normal


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

[Bug target/17735] [4.0 Regression] make stops with "initializer for integer value is too complicated" while building an avr-cross compiler

[bernie at develer dot com]

--- Additional Comments From bernie at develer dot com  2004-11-18 18:41 
---
Works for me, thanks!
Patch still waiting for review in gcc-patches.


-- 


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

[Bug fortran/18518] equivalenced variables are not saved

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-11-18 
18:53 ---
It appears that equivalenced variables are not
saved.

Here's a simplified test case:

$ cat pr18518-test.f90
program main
  call foo
  call bar
  call foo
end program main

subroutine foo
  integer i,g,h
  data i/0/
  equivalence (g,h)
  save g
  if (i == 0) then
 i = 1
 h = 12345
  end if
  print *,h
end subroutine foo

subroutine bar
  integer a(10)
  a = 34
end subroutine bar
$ gfortran pr18518-test.f90 && ./a.out
   12345
  34

-- 
   What|Removed |Added

Summary|d1mach(4)  (BLAS) broken,   |equivalenced variables are
   |g77 regression  |not saved


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

[Bug middle-end/18548] New: Miscompiles code generated by Gambit-C Scheme->C compiler

[lucier at math dot purdue dot edu]

 

-- 
   Summary: Miscompiles code generated by Gambit-C Scheme->C
compiler
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
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=18548

[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
18:56 ---
I noticed today that my patch for PR 18507 also helps this testcase.

-- 
   What|Removed |Added

  BugsThisDependsOn||18507


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

[Bug c/18549] New: -save-temps option ends with corrupt object file

[pschober at gmx dot ch]

if gcc is called with the -save-temps option the resulting object file is 
corrupt.
a call to the linker results in the following error message :
c:\programme\winavr\bin\..\lib\gcc-lib\avr\3.3.1\..\..\..\..\avr\lib\avr5\crtm16.o(.init9+0x0):undefined
reference to 'main'
without using the -save-temps option this error message doesn't appear.
if the file foo.s exists, the error doesn't appear as well (regardless of the
contents of foo.s);foo.s remains unchanged in this case

used calls :
avr-gcc -c -mmcu=atmega16 -save-temps foo.c
avr-gcc -mmcu=atmega16 -o foo.elf foo.o

this problem occurs on different versions (3.3.1, 3.4.1 tested) and on different
OS' (Windows 2000, Windows XP tested)

foo.c (works with other files as well) :
#include 

int main(void)
{
 while (1);
}

-- 
   Summary: -save-temps option ends with corrupt object file
   Product: gcc
   Version: 3.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pschober at gmx dot ch
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr


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

[Bug driver/18549] -save-temps option ends with corrupt object file

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |driver


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

[Bug middle-end/18548] Miscompiles code generated by Gambit-C Scheme->C compiler

[lucier at math dot purdue dot edu]

--- Additional Comments From lucier at math dot purdue dot edu  2004-11-18 
19:04 ---
Sorry for hitting return in the summary field ...

This is a catch-all bug report for miscompilations of machine-generated code
that is generated by the Gambit-C Scheme->C compiler.  Giovanni Bajo suggested
that I at least document the problem with proper preprocessed files, etc.

All 34 megabytes of the files are at

http://www.math.purdue.edu/~lucier/GNATS/GNATS-16/gambit-test.tgz

They were generated and the bug was verified with the following commands:

[EMAIL PROTECTED] gambc40b11]$ env CC='gcc -g -save-temps' ./configure
--enable-single-host
[EMAIL PROTECTED] gambc40b11]$ gcc -v
Reading specs from 
/home/lucier/local/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../configure --prefix=/home/lucier/local/ --enable-languages=c
--enable-checking=no
Thread model: posix
gcc version 4.0.0 20041118 (experimental)
[EMAIL PROTECTED] gambc40b11]$ make

[EMAIL PROTECTED] gambc40b11]$ cd bench
[EMAIL PROTECTED] bench]$ ./bench -c no gambit fib

Testing fib under Gambit-C
Compiling...
./bench: line 518: 25754 Segmentation fault  LD_LIBRARY_PATH=../../../lib
GAMBCDIR=../../../lib ../../../gsc/gsc -:=../../.. $1.scm
gcc: fib.c: No such file or directory
gcc: fib_.c: No such file or directory
Command exited with non-zero status 1
0.00user 0.00system 0:00.01elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (153major+23minor)pagefaults 0swaps
ls: fib: No such file or directory
Running...
time: cannot run ./fib: No such file or directory
Command exited with non-zero status 127
0.00user 0.00system 0:00.00elapsed ?%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (24major+8minor)pagefaults 0swaps
[EMAIL PROTECTED] bench]$ cd sys/gambit
[EMAIL PROTECTED] gambit]$ ls
fib.scm
[EMAIL PROTECTED] gambit]$ env GAMBCDIR=../../../lib ../../../gsc/gsc
-:=../../.. fib.scm
Segmentation fault
[EMAIL PROTECTED] gambit]$ env GAMBCDIR=../../../lib gdb ../../../gsc/gsc
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) run  -:=../../.. fib.scm
Starting program: /home/lucier/programs/gambc40b11/gsc/gsc -:=../../.. fib.scm

Program received signal SIGSEGV, Segmentation fault.
0x0815741b in ___H__20___front (___ps=0x8495ce0) at _front.c:7075
7075   ___SET_R2(___FIXMAX(___R3,___R2))


-- 


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

[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274

[dpatel at apple dot com]

--- Additional Comments From dpatel at apple dot com  2004-11-18 19:09 
---
Subject: Re:  ICE in do_jump, at dojump.c:274


On Nov 18, 2004, at 12:03 AM, paolo dot bonzini at lu dot unisi dot ch 
wrote:

> While I can work on a fix, those COND_EXPR were *not* valid GIMPLE at
> the time the patch was written.

I agree with you. While cleanup this stuff, you even cc'ed us and left 
some stuff around. May be we can update rewrite_outof_ssa()? See 
example I included above.

-
Devang



-- 


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

[Bug c++/7866] [parser] compile error when bit field has same name as namespace

[gcc at rhythm dot com]

--- Additional Comments From gcc at rhythm dot com  2004-11-18 19:21 ---
I just tried this under 3.3.3, and it is still a problem. Can someone clarify
which parser has the correction?

-- 


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

[Bug java/18550] New: Remainder on floating point doesn't return the expected result

[olivier_thomann at ca dot ibm dot com]

Using gcj,

gcj (GCC) 4.0.0 20040924 (experimental)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I built the following program into an executable. The expected result is false,
but when I run the executable I get true. I think the JLS (second edition) are
pretty clear that the right answer is false, since: f % Float.POSITIVE_INFINITY
should reply f. See:
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#24956

public class X {

public static void main(String args[]) {
System.out.println(3.14f % Float.POSITIVE_INFINITY != 
Float.NaN);
}
}

Here is the ant script use to run it:






 






















   



it is called inside another ant script that sets what file should be compiled.

Here is the output I get when doing the compilation:
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/specs
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib/libgcj.spec
rename spec lib to liborig
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20040924 (experimental)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/jc1.exe
C:\eclipse\workspaces\bingcj\tmp\X.java -fhash-synchronization
-fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions
-fno-omit-frame-pointer -fkeep-inline-functions -quiet -dumpbase X.java
-march=pentium4 -mfpmath=sse -auxbase-strip C:\eclipse\workspaces\bingcj\tmp\X.o
-O0 -version -fclasspath=../../bingcj/tmp/ -fassume-compiled -o
C:\DOCUME~1\othomann\LOCALS~1\Temp/ccOU.s
GNU Java version 4.0.0 20040924 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20040924 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
../../bingcj/tmp/
c:\java_tools\thisiscool-gcc\gcc-4.0\bin\../lib/gcc/../../share/java/libgcj-4.0.0.jar/
(system) (zip)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/bin/as.exe
-o C:\eclipse\workspaces\bingcj\tmp\X.o
C:\DOCUME~1\othomann\LOCALS~1\Temp/ccOU.s
 [echo] linking .o -> Toto310
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/specs
Reading specs from
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/lib/libgcj.spec
rename spec lib to liborig
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20040924 (experimental)
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/jvgenmain.exe
Xmain C:\DOCUME~1\othomann\LOCALS~1\Temp/cccr.i
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../libexec/gcc/i686-pc-mingw32/4.0.0/cc1.exe
C:\DOCUME~1\othomann\LOCALS~1\Temp/cccr.i -quiet -dumpbase Xmain.c
-march=pentium4 -mfpmath=sse -g1 -version -fdollars-in-identifiers -o
C:\DOCUME~1\othomann\LOCALS~1\Temp/cceI.s
GNU C version 4.0.0 20040924 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.0.0 20040924 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../../../../i686-pc-mingw32/bin/as.exe
-o C:\DOCUME~1\othomann\LOCALS~1\Temp/ccgZ.o
C:\DOCUME~1\othomann\LOCALS~1\Temp/cceI.s
c:/java_tools/thisiscool-gcc/gcc-4.0/bin/../lib/gcc/i686-pc-mingw32/4.0.0/../.

[Bug c++/7866] [parser] compile error when bit field has same name as namespace

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-11-18 19:24 
---
3.4.0 or newer.

-- 


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

[Bug java/18550] Remainder on floating point doesn't return the expected result

[olivier_thomann at ca dot ibm dot com]

--- Additional Comments From olivier_thomann at ca dot ibm dot com  
2004-11-18 19:26 ---
Sorry, my test case was wrong. Here is the right one:

public class X {

public static void main(String args[]) {
System.out.println(3.14f % Float.POSITIVE_INFINITY);
}
}

I expect the output to be: 3.14, but instead I get NaN.


-- 


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

[Bug target/18551] New: wrong asm output for -ffunction-sections with g++

[bernie at develer dot com]

The backend outputs invalid assembly containing
full function signatures when compiling C++
sources with -ffunction-sections:

  ldi r30,pm_lo8(.L_bool updateEEParam(uint16_t, uint8_t*)_body)

I'm not sure this is AVR specific, but it doesn't
certainly happen on i386-linux.

-- 
   Summary: wrong asm output for -ffunction-sections with g++
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: denisc at overta dot ru
ReportedBy: bernie at develer dot com
CC: gcc-bugs at gcc dot gnu dot org,marekm at amelek dot gda
dot pl
GCC target triplet: avr


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

[Bug target/18552] New: Annoying warning with -ffunction-sections -g

[bernie at develer dot com]

When building with both -ffunction-sections and
-g, the compiler outputs an invalid warning for
each compiled file:

  drv/timer.c:1: warning: -ffunction-sections may affect debugging on some 
targets

The code printing this is here:

--- gcc/toplev.c ---
#ifndef OBJECT_FORMAT_ELF
  if (flag_function_sections && write_symbols != NO_DEBUG)
warning ("-ffunction-sections may affect debugging on some targets");
#endif
--- gcc/toplev.c ---

A possible fix could be adding elfos.h to the tm_file
list for the avr target in config.gcc, which may also
lead to simplifications in some parts of config/avr.h.

-- 
   Summary: Annoying warning with -ffunction-sections -g
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bernie at develer dot com
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: avr


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

[Bug target/18553] New: Annoying warning with -ffunction-sections -g

[bernie at develer dot com]

When building with both -ffunction-sections and
-g, the compiler outputs an invalid warning for
each compiled file:

  drv/timer.c:1: warning: -ffunction-sections may affect debugging on some 
targets

The code printing this is here:

--- gcc/toplev.c ---
#ifndef OBJECT_FORMAT_ELF
  if (flag_function_sections && write_symbols != NO_DEBUG)
warning ("-ffunction-sections may affect debugging on some targets");
#endif
--- gcc/toplev.c ---

A possible fix could be adding elfos.h to the tm_file
list for the avr target in config.gcc, which may also
lead to simplifications in some parts of config/avr.h.

-- 
   Summary: Annoying warning with -ffunction-sections -g
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: denisc at overta dot ru
ReportedBy: bernie at develer dot com
CC: gcc-bugs at gcc dot gnu dot org,marekm at amelek dot gda
dot pl
  GCC host triplet: avr


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

[Bug target/18553] Annoying warning with -ffunction-sections -g

[bernie at develer dot com]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 19:42:06
   date||


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

[Bug target/18552] Annoying warning with -ffunction-sections -g

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:28 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/7866] [parser] compile error when bit field has same name as namespace

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |3.4.0


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

[Bug target/18553] Annoying warning with -ffunction-sections -g

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:28 ---
*** Bug 18552 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/18554] New: template function calling template member function does not compile

[matt_p_carter at yahoo dot com]

I have reduced the code needed to reproduce this compile error down to a single,
simple file:

Contents of b.cpp:
---BEGIN_CODE---
struct MyStruct
{
 template 
 void
 noop() {}
};

template 
void
myFunc()
{
 MyStruct ms;
 ms.noop();
}
---END_CODE---

% g++ -c b.cpp
b.cpp: In function `void myFunc()':
b.cpp:13: error: parse error before `>' token
% uname -a
CYGWIN_NT-5.1 rukus 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown 
Cygwin
% g++ -v
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls
--without-included-gettext --enable-libgcj --with-system-zlib
--enable-interpreter --enable-threads=posix --enable-java-gc=boehm
--enable-sjlj-exceptions --disable-version-specific-runtime-libs
--disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)

This bug report was submitted via http://gcc.gnu.org/bugzilla/enter_bug.cgi .
That page does not have file-upload capabilities, so I couldn't attach the
preprocessed file as requested by the "Reporting Bugs" instructions (a.k.a. bug
writing guidelines).

The "Reporting Bugs" instructions do not document what I should put in the "Host
triplet:", "Target triplet:", and "Build triplet:" fields of the bug report, so
I have left them blank.

I attempted to reproduce this bug in gcc-3.4.4, but I could not get gcc-3.4.4 to
install by following the installation instructions.

I have verified that the above code compiles without error under MIPSpro and
MSVC++ 7.1 .

-- 
   Summary: template function calling template member function does
not compile
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt_p_carter at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/18551] wrong asm output for -mcall-prologues with g++

[bernie at develer dot com]

--- Additional Comments From bernie at develer dot com  2004-11-18 20:30 
---
Oops, this PR should have been about "-mcall-prologues",
not "-ffunction-sections".


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 20:30:50
   date||
Summary|wrong asm output for -  |wrong asm output for -mcall-
   |ffunction-sections with g++ |prologues with g++


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

[Bug c++/18554] template function calling template member function does not compile

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:33 ---
The second most reported bug, PR 795.
This is already fixed in 3.4.0.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/795] parse error in member template method

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:33 ---
*** Bug 18554 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||matt_p_carter at yahoo dot
   ||com


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

[Bug java/18550] Remainder on floating point doesn't return the expected result

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:36 ---
It works on the mainline on powerpc-darwin.  This might be a mygwin bug as the 
front-end just makes 
the call to fmod.

-- 
   What|Removed |Added

 GCC target triplet||i686-pc-mingw32


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

[Bug target/18551] wrong asm output for -mcall-prologues with g++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:40 ---
You should not use:
  const char *cfun_name = current_function_name ();


-- 
   What|Removed |Added

   Keywords||wrong-code


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

[Bug target/18553] Annoying warning with -ffunction-sections -g

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:41 ---
Confirmed.

-- 
   What|Removed |Added

   Last reconfirmed|2004-11-18 19:42:06 |2004-11-18 20:41:43
   date||


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

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
20:46 ---
Note on the mainline on PPC-darwin we are about twice as fast 1.5 seconds 
compared to 3.3 (3.2 
seconds).

-- 


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

[Bug tree-optimization/18536] ICE: in emit_move_insn, at expr.c:2590 with -ftree-vectorize -msse2

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2004-11-18 21:12 
---
patch: 
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01512.html


-- 


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

[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
21:12 ---
Hmm, with the mainline on PPC-darwin for ir.ii at -O0 we are faster than both 
3.3 and 3.1.
3.1:
51.260u 2.110s 0:56.27 94.8%0+0k 0+7io 0pf+0w
3.3:
46.000u 3.600s 0:50.91 97.4%0+0k 0+7io 0pf+0w
mainline:
39.730u 5.270s 0:48.27 93.2%0+0k 0+8io 0pf+0w

Even at -O1 we are faster than 3.3:
mainline:
70.860u 5.010s 1:18.76 96.3%0+0k 0+11io 0pf+0w
3.3:
72.650u 13.250s 1:29.99 95.4%   0+0k 0+7io 0pf+0w
For -O2 we are only 1 second slower than 3.3:
mainline:
99.720u 5.510s 1:54.78 91.6%0+0k 0+13io 0pf+0w
3.3:
98.610u 38.800s 2:25.59 94.3%   0+0k 0+15io 0pf+0w

Could you check again on your platform?

-- 


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

[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2004-11-18 21:15 
---
Could this be applied to gcc-3_4-branch as well?
See http://bugzilla.redhat.com/bugzilla/attachment.cgi?id=106985
for a 3.4 testcase that used to work with GCC 3.3.4, but fails with 3.4 branch
as of a month ago or from today when compiled with
-O -fomit-frame-pointer -m32 -march=i386.


-- 


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

[Bug preprocessor/18555] New: Need a command line switch to control gcc's include and libary finding mechanism

[spolk at apple dot com]

Apple needs a command-line switch to the compiler which will change the lookup 
of include files and 
link libaries. The semantics would be something like:

-isystem-headers-and-libaries 

When this command line option is given to the compiler, all of the compiler's 
builtin searching for 
includes and libaries would start with  instead of with '/'. If a 
file is included or linked with 
and is not in the hierarchy given by  the compiler will return a 
"file not found" error.

All other command line options related to include and link searching, 
particular paths given by -I and 
the like, would be unchanged.

This command line search is useful for Apple's compiler, where we would like to 
build for other 
versions of Darwin while running on a stable host. It could also be used in an 
environment such as a 
distcc farm, where the system headers for a target system are in a known 
location, but the binaries on 
the build system will work just fine to build the program.

-- 
   Summary: Need a command line switch to control gcc's include and
libary finding mechanism
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spolk at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7
  GCC host triplet: powerpc-apple-darwin7
GCC target triplet: powerpc-apple-darwin7


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

[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
21:17 ---
So kinda like --with-sysroot by at done at run time instead at configure time.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|preprocessor|other
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 21:17:55
   date||


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

[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism

[austern at apple dot com]

--- Additional Comments From austern at apple dot com  2004-11-18 21:39 
---
We have a lot of options that are vaguely similiar to this.  It's also 
reminiscent of -iprefix.  But I actually 
think the closest analogy is to -B.  Its effect on header and library paths is 
the same as -B, but it 
doesn't change the search for compiler executables.

And while Syd is right that Apple would find this feature useful, I don't think 
there's anything about it 
that's specific to Apple or Darwin.  I expect it to be generally useful for 
people who are trying to deal 
with multiple similar-but-not-identical versions of an operating system.

-- 


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

[Bug tree-optimization/18529] When the lower bound of a loop is non-constant we cannot find the number of iterations

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-11-18 
21:54 ---
Patch:

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01516.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug tree-optimization/18544] [4.0 regression] ICE with -ftree-vectorize

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2004-11-18 21:56 
---
> Note it works no when compiled with the C front-end but not with the C++ 
front-end.
> It is more related to PR 18546 than it is to PR18536.

This patch fixes the ICE:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01517.html 

but by figuring out that it can't vectorize it:
"
Access function of ptr: {&.x[0], +, 4B}_1
step: 4B,  init: &.x[0]
...
  
loop at pr18544.cc:9: not vectorized: no memtag for ref.
"

So when this patch is installed this PR could be switched to "missed 
optimization".

-- 


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

[Bug c++/18556] New: C++ debug is broken

[hjl at lucon dot org]

I got so many "make check" failures in libstdc++ with gcc 4.0 from CVS
at Thu Nov 18 00:45:48 UTC 2004. They all have something like

# /export/build/gnu/gcc/build-ia64-linux/gcc/g++ -shared-libgcc
-B/export/build/gnu/gcc/build-ia64-linux/gcc/ -nostdinc++
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/gcc-4.0/ia64-unknown-linux-gnu/bin/
-B/usr/gcc-4.0/ia64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.0/ia64-unknown-linux-gnu/include -isystem
/usr/gcc-4.0/ia64-unknown-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT
-ffunction-sections -fdata-sections -fmessage-length=0
-DLOCALEDIR="/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/po/share/locale"
-nostdinc++
-I/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/include/ia64-unknown-linux-gnu
-I/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu/libstdc++-v3/include
-I/net/gnu/export/gnu/src/gcc/gcc/libstdc++-v3/libsupc++
-I/net/gnu/export/gnu/src/gcc/gcc/libstdc++-v3/include/backward
-I/net/gnu/export/gnu/src/gcc/gcc/libstdc++-v3/testsuite
/net/gnu/export/gnu/src/gcc/gcc/libstdc++-v3/testsuite/20_util/memory/auto_ptr/6.cc
   -include bits/stdc++.h 
-L/export/build/gnu/gcc/build-ia64-linux/ia64-unknown-linux-gnu//libstdc++-v3/testsuite
-lv3test -lm   -o ./6.exe 
/tmp/ccKs0Kx1.o(.debug_info+0x72ac): undefined reference to `typeinfo for B'
collect2: ld returned 1 exit status

Gcc 4.0 2004 is OK.

-- 
   Summary: C++ debug is broken
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug c++/18556] [4.0 Regression] C++ debug is broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
22:36 ---
http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00581.html is also broken.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-11-18 22:36:11
   date||
Summary|C++ debug is broken |[4.0 Regression] C++ debug
   ||is broken
   Target Milestone|--- |4.0.0


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

[Bug c++/18556] [4.0 Regression] C++ debug is broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-18 
22:41 ---
The only change between the 11 and the 13 which makes sense at even having an 
effect:
2004-11-12  Mark Mitchell  <[EMAIL PROTECTED]>

PR c++/18416
* passes.c (rest_of_decl_compilation): Do not look at DECL_RTL
when deciding whether to pass a variable to
cgraph_varpool_finalize_decl or assemble_variable.
* toplev.c (check_global_declarations): Do not clear DECL_RTL.

-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug c++/18556] [4.0 Regression] C++ debug is broken

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-11-18 
22:44 ---
I will need a preprocessed test case and command-line.


-- 


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

[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-11-18 
23:20 ---
Reopening on Jakub's request.


-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug tree-optimization/18557] New: Inefficient code generated by -ftree-vectorize on Alpha

[falk at debian dot org]

For this code:

int f(unsigned int *p) {
for (int i = 0; i < 64; ++i)
p[i] = 0;
}

I'd expect to get something like the output for this code:

int f2(unsigned int *p) {
int c = 64*4;
if ((unsigned long) p % 8) *p++ = 0, c -= 4;
unsigned long *l = p;
do *l++ = 0; while ((c -= 8) >= 8);
p = l;
if (c) *p++ = 0;
}

which is

f2:
and $16,7,$1
lda $4,256($31)
beq $1,$L11
stl $31,0($16)
lda $4,252($31)
lda $16,4($16)
$L11:
mov $31,$3
.align 4
$L12:
lda $3,8($3)
stq $31,0($16)
lda $16,8($16)
subl $4,$3,$2
cmple $2,7,$1
beq $1,$L12
beq $2,$L17
stl $31,0($16)
$L17:
ret

but I get:

f:
and $16,4,$1
lda $5,64($31)
lda $6,64($31)
mov $31,$7
cmpult $31,$1,$1
cmplt $1,64,$2
cmovne $2,$1,$5
ble $5,$L4
mov $31,$3
mov $31,$4
.align 4
$L12:
lda $3,1($3)
s4addq $4,$16,$1
addl $31,$3,$4
stl $31,0($1)
addl $31,$4,$2
cmple $5,$2,$1
beq $1,$L12
lda $1,64($31)
mov $2,$7
subl $1,$4,$6
$L4:
cmpeq $5,64,$1
bne $1,$L6
lda $1,64($31)
subq $1,$5,$22
sra $22,1,$4
addq $4,$4,$8
ble $8,$L8
s4addq $5,$16,$2
mov $31,$3
.align 4
$L10:
lda $3,1($3)
stq $31,0($2)
lda $2,8($2)
addl $31,$3,$1
cmple $4,$1,$1
beq $1,$L10
subl $6,$8,$6
addl $7,$8,$7
$L8:
cmpeq $22,$8,$1
bne $1,$L6
mov $31,$2
.align 4
$L14:
addl $2,$7,$1
subl $6,1,$6
lda $2,1($2)
s4addq $1,$16,$1
stl $31,0($1)
bne $6,$L14
$L6:
ret

which is pretty weird and inefficent code...

-- 
   Summary: Inefficient code generated by -ftree-vectorize on Alpha
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: alphaev68-unknown-linux-gnu
  GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu


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

[Bug tree-optimization/18557] Inefficient code generated by -ftree-vectorize on Alpha

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-19 
00:04 ---
Confirmed.
One issue is that we don't fold stuff:
  D.1061 = 8 - 1;
  D.1065 = 2 - 1;

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-11-19 00:04:13
   date||


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

[Bug c++/18556] [4.0 Regression] C++ debug is broken

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-11-19 00:34 ---
Please check out g++.old-deja/g++.mike/eh53.C. I got

[EMAIL PROTECTED] testsuite]$ /usr/gcc-4.0/bin/g++  
/net/gnu/export/gnu/src/gcc/gcc/gcc/testsuite/g++.old-deja/g++.mike/eh53.C -g -c
[EMAIL PROTECTED] testsuite]$ readelf -s eh53.o | grep zeroset 21: 

   16 OBJECT  WEAK   DEFAULT   10 _ZTI7zeroset
23:  9 OBJECT  WEAK   DEFAULT   12 _ZTS7zeroset
24: 32 FUNCWEAK   DEFAULT   13 _ZN7zerosetD1Ev
[EMAIL PROTECTED] testsuite]$ ../g++ -B../ 
/net/gnu/export/gnu/src/gcc/gcc/gcc/testsuite/g++.old-deja/g++.mike/eh53.C -g -c
[EMAIL PROTECTED] testsuite]$ readelf -s eh53.o | grep zeroset 17: 

   32 FUNCWEAK   DEFAULT   10 _ZN7zerosetD1Ev
19:  0 NOTYPE  GLOBAL DEFAULT  UND _ZTI7zeroset
[EMAIL PROTECTED] testsuite]$ ../g++ -B../ 
/net/gnu/export/gnu/src/gcc/gcc/gcc/testsuite/g++.old-deja/g++.mike/eh53.C -g
/tmp/cc0mrglD.o(.debug_info+0x197): undefined reference to `typeinfo for 
zeroset'
collect2: ld returned 1 exit status


-- 


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

[Bug other/18555] Need a command line switch to control gcc's include and libary finding mechanism

[dpatel at apple dot com]

--- Additional Comments From dpatel at apple dot com  2004-11-19 01:21 
---
It seems -isysroot may do the task here. I see its implementation in c-opts.c, 
but unfortunetly 1) it is 
not documented in cppopts.texi and 2) driver has one bug that causes it to eat 
isysroot argument. 
I will investigate.

-- 


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

[Bug c++/18556] [4.0 Regression] C++ debug is broken

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-11-19 01:42 ---
I have verified that

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00970.html

is the cause.

-- 


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