[Bug fortran/31608] wrong types in character array/scalar binop

[fxcoudert at gcc dot gnu dot org]

--- Comment #20 from fxcoudert at gcc dot gnu dot org  2007-10-03 08:08 
---
Further reduced testcase:

  integer i(1)
  print *, transfer(achar(i), "x")
  end

The type mismatch disappears if you change the transfer statement into
transfer(["x"]), "x", so this is a problem in the return type of achar in
trans-intrinsic.c, I think.

Also, there are an interesting number of ICEs for testcases differing only
slightly with the one reported here, including:

  integer i(1)
  print *, transfer(char(i), "x")
  end

and

  character(len=1) :: string
  print *, transfer(((transfer(string,"x",1))), "x")
  end


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-07-03 10:40:16 |2007-10-03 08:08:50
   date||


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

[Bug target/33635] New: Bootstrap broken on mips-sgi-irix6.5

[fxcoudert at gcc dot gnu dot org]

Mainline currently doesn't bootstrap on mips-sgi-irix6.5 due to an ICE while
compiling mips-sgi-irix6.5/64/libgcc/_powitf2.o at stage 1. This happens,
afaict, with any use of the TF mode with either -mabi=64 or -mabi=n32:

$ cat foo.i
void __powitf2 (float x __attribute__ ((mode (TF {}
$ /usr/people/francois/devel/ibin/./gcc/cc1 -fpreprocessed foo.i -quiet
zsh: segmentation fault  /usr/people/francois/devel/ibin/./gcc/cc1
-fpreprocessed foo.i -quiet

The backtrace for the segfault is:

Program received signal SIGSEGV, Segmentation fault.
0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
2481{
(gdb) where
#0  0x104d7d50 in reg_classes_intersect_p (c1=32, c2=MD0_REG)
at ../../trunk/gcc/regclass.c:2481
#1  0x102323cc in mips_cannot_change_mode_class (from=TFmode, to=DImode,
class=FP_REGS) at ../../trunk/gcc/config/mips/mips.c:9346
#2  0x10823a38 in simplify_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5014
#3  0x10824968 in simplify_gen_subreg (outermode=DImode, op=0x40b4c80,
innermode=TFmode, byte=0) at ../../trunk/gcc/simplify-rtx.c:5211
#4  0x1027a700 in operand_subword (op=0x40b4c80, offset=0,
validate_address=1, mode=TFmode) at ../../trunk/gcc/emit-rtl.c:1425
#5  0x1027a76c in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1438
#6  0x10337484 in emit_move_multi_word (mode=TFmode, x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3275
#7  0x10337980 in emit_move_insn_1 (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3347
#8  0x10337dc0 in emit_move_insn (x=0x4c84200, y=0x40b4c80)
at ../../trunk/gcc/expr.c:3407
#9  0x102b4894 in copy_to_reg (x=0x40b4c80) at ../../trunk/gcc/explow.c:617
#10 0x1027a7cc in operand_subword_force (op=0x40b4c80, offset=0, mode=TFmode)
at ../../trunk/gcc/emit-rtl.c:1448


I'm keeping the build tree so that I can investigate more if needed, please
tell me what to do.


-- 
   Summary: Bootstrap broken on mips-sgi-irix6.5
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug fortran/26682] gfortran fails with -fwhole-program optimization

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-10-03 09:46 
---
Subject: Bug 26682

Author: fxcoudert
Date: Wed Oct  3 09:46:46 2007
New Revision: 128977

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128977
Log:
PR fortran/26682

* options.c (gfc_post_options): Issue an error when
-fwhole-program is used.

* doc/invoke.texi (-fwhole-program): Document that Fortran
doesn't support this option.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c


-- 


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

[Bug debug/31899] [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2007-10-03 10:02 
---
Subject: Bug 31899

Author: rguenth
Date: Wed Oct  3 10:01:43 2007
New Revision: 128978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128978
Log:
2007-10-03  Doug Kwan  <[EMAIL PROTECTED]>
Richard Guenther  <[EMAIL PROTECTED]>

PR debug/31899
* dwarf2out.c (reference_to_unused): Disable sanity checking,
be conservative instead.

* g++.dg/debug/using3.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/debug/using3.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/31899] [4.2 Regression] -g and using declaration causing ICE in reference_to_unused

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2007-10-03 10:04 
---
Fixed on the trunk, queued for 4.2.3.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.2.2
  Known to work||4.3.0
Summary|[4.2/4.3 regression] -g and |[4.2 Regression] -g and
   |using declaration causing   |using declaration causing
   |ICE in reference_to_unused  |ICE in reference_to_unused
   Target Milestone|4.2.2   |4.2.3


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

[Bug c++/15764] no cleanup if temporary's dtor terminates with an exception

[jason at gcc dot gnu dot org]

--- Comment #10 from jason at gcc dot gnu dot org  2007-10-03 10:43 ---
Subject: Bug 15764

Author: jason
Date: Wed Oct  3 10:43:42 2007
New Revision: 128979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128979
Log:
PR c++/15764
* cp/decl.c (wrap_cleanups_r): New fn.
(wrap_temporary_cleanups): New fn.
(initialize_local_var): Call it.
* tree-eh.c (same_handler_p): New fn.
(optimize_double_finally): New fn.
(refactor_eh_r): New fn.
(refactor_eh): New fn.
(pass_refactor_eh): New pass.
* tree-pass.h: Declare it.
* passes.c (init_optimization_passes): Add it.

Added:
trunk/gcc/testsuite/g++.dg/eh/init-temp1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/passes.c
trunk/gcc/tree-eh.c
trunk/gcc/tree-pass.h


-- 


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

[Bug fortran/33198] Derived type in common: Default initializer not rejected

[tobi at gcc dot gnu dot org]

--- Comment #3 from tobi at gcc dot gnu dot org  2007-10-03 11:37 ---
Subject: Bug 33198

Author: tobi
Date: Wed Oct  3 11:37:44 2007
New Revision: 128980

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128980
Log:
PR fortran/33198
fortran/
* resolve.c (has_default_initializer): Move to top.  Make bool.
(resolve_common_blocks): Simplify logic.  Add case for derived
type initialization.
(resolve_fl_variable_derived): Split out from ...
(resolve_fl_variable): ... from here, while adapting to new h_d_i
interface.
testsuite/
* gfortran.dg/common_errors_1.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/common_errors_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33636] New: Rejects valid use of vector subscript in derived type parameter

[fxcoudert at gcc dot gnu dot org]

This was seen on ppc-darwin and x86_64-linux with -m32:

$ cat x.f90
  implicit none
  type vec3
integer, dimension(1) :: coords
  end type vec3
  type(vec3), parameter :: v1 = vec3((/ 0 /))
  integer :: i

  i = 1
  print *, v1%coords ((/i/))
  end
$ gfortran -m32 x.f90
x.f90:9.23:

  print *, v1%coords ((/i/))
 1
Error: index in dimension 1 is out of bounds at (1)


-- 
   Summary: Rejects valid use of vector subscript in derived type
parameter
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
OtherBugsDependingO 32834
 nThis:


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

[Bug fortran/33636] Rejects valid use of vector subscript in derived type parameter

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-03 12:27:28
   date||


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

[Bug regression/33637] New: "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"

[haubi at gentoo dot org]

Sorry for the details - might not be required as I already tracked down the
problem to the source line...

When NM_FOR_TARGET requires arguments (fex "-B -X32_64" for aix), checking for
nm in gcc/configure{,.ac} is broken:

Assume 
*) source is /source/gcc-4.2.0
*) builddir is /build
*) configured --prefix=/prefix (and others, but irrelevant)

checking what assembler to use... /usr/ccs/bin/as
checking what linker to use... /usr/ccs/bin/ld
/source/gcc-4.2.0/gcc/configure: line 13513: test: too many arguments
checking for powerpc-ibm-aix5.3.0.0-nm... /usr/bin/nm
checking what nm to use... /usr/bin/nm
checking for objdump... no

This only becomes a real problem, when there is some symlink or wrapper
available as "/prefix/${target}/bin/nm", or somehow else NM_FOR_TARGET already
contains full path.

checking what assembler to use... /prefix/powerpc-ibm-aix5.3.0.0/bin/as
checking what linker to use... /prefix/powerpc-ibm-aix5.3.0.0/bin/ld
/source/gcc-4.2.0/gcc/configure: line 13513: test: too many arguments
checking for /prefix/powerpc-ibm-aix5.3.0.0/bin/nm... no
checking what nm to use...
checking for objdump... no

So it ends up with no nm at all.

The follow-up problems are:

1) generated builddir/gcc/nm is (missing /path/to/nm)
#!/bin/sh
exec  "$@"

2) while configuring powerpc-ibm-aix5.3.0.0/libstdc++-v3:

checking dynamic linker characteristics... aix5.3.0.0 ld.so
checking command to parse /build/./gcc/nm -B -X32_64 output... /build/./gcc/nm:
line 2: exec: -B: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
/build/./gcc/nm: line 2: exec: -B: invalid option
exec: usage: exec [-cl] [-a name] file [redirection ...]
failed
checking if libtool supports shared libraries... yes

3) The generated libstdc++.a does not export any symbols, because nm fails to
create a list of symbols due to 2).

4) When using g++, the simplest resulting linker error is

ld: 0711-317 ERROR: Undefined symbol: __gxx_personality_v0

'-bnoquiet' linker-output contains this line:

LIBRARY: Shared object libstdc++.a[libstdc++.so.6]: 0 symbols imported.

Looks like the same problem was here:
http://gcc.gnu.org/ml/gcc-help/2007-09/msg00100.html

The code around line 13513 in gcc-4.2.0/gcc/configure is:

13507 if test -f $gcc_cv_binutils_srcdir/configure.in \
13508  && test -f ../binutils/Makefile \
13509  && test x$build = x$host; then
13510 gcc_cv_nm=../binutils/nm-new$build_exeext
13511 elif test -x nm$build_exeext; then
13512 gcc_cv_nm=./nm$build_exeext
13513 elif test -x $NM_FOR_TARGET; then
   ^^^ broken ^^^
13514 gcc_cv_nm="$NM_FOR_TARGET"
13515 else
13516 # Extract the first word of "$NM_FOR_TARGET", so it can be a
program name with args.
13517 set dummy $NM_FOR_TARGET; ac_word=$2
13518 echo "$as_me:$LINENO: checking for $ac_word" >&5

This problem came up with gentoo-alt/prefix - still using native toolchain. but
wrapped with binutils-config - thus /prefix/${target}/bin/nm is available
(actually gentoo-alt/prefix configures with --prefix=/prefix/usr and builds
within some longer builddir - have it shortened here for readability).

Have already searched in gcc-svn:
This problem was introduced in revision 110266 of trunk/gcc/configure.ac, being
both in gcc-4.2-branch and trunk, but not gcc-4.1-branch.

What I'm unable to say is how to fix this correctly.


-- 
   Summary: "checking for nm: test: too many arguments" causes
"Undefined symbol: __gxx_personality_v0"
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: haubi at gentoo dot org
 GCC build triplet: powerpc-ibm-aix5.3.0.0
  GCC host triplet: powerpc-ibm-aix5.3.0.0
GCC target triplet: powerpc-ibm-aix5.3.0.0


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

[Bug middle-end/33638] New: optimization bug: wrong code with -fforce-addr

[manfred99 at gmx dot ch]

I have a rather nasty optimization issue with gfortran (as of yesterday). 
As I think it could be an optimization issue and not an gfortran frontend
issue, so I assigned it to the middle-end.

I narrowed my problem to one single fortran function. If I compile this
function with
"gfortran -O2 -march=pentium4" the output is OK, using
"gfortran -O2 -march=pentium4 -fforce-addr" produces wrong output.

When reducing optimization level to "-O1", the issue vanishes for all tried
flag combinations.
If I comment out a particular non-functional line in this code, the issue goes
away:

if (always_true) then
  
else
   this_line_commented_out_makes_it_working_again
   
endif

I will add assembler output of original, non-working code as well as
of working code when commenting the non-functional line, both compiled with
"gfortran -O2 -march=pentium4 -fforce-addr -S comunpack.f"
Function code is added as well.


Further data points:
- output of -fdump-tree-optimized is the same for both the working and the 
broken case (of the original function, not the line commenting test).
- there are differences in assembler output though.
- the code calls C functions.
- I could reproduce this issue on an different, non-pentium4 machine 
using the same flags.
- the flag -march=pentium4 is necessary to trigger the issue.


-- 
   Summary: optimization bug: wrong code with -fforce-addr
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch


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

[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr

[manfred99 at gmx dot ch]

--- Comment #1 from manfred99 at gmx dot ch  2007-10-03 12:46 ---
Created an attachment (id=14288)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14288&action=view)
Source code of affected function


-- 


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

[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr

[manfred99 at gmx dot ch]

--- Comment #2 from manfred99 at gmx dot ch  2007-10-03 12:47 ---
Created an attachment (id=14289)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14289&action=view)
Assembler code of original code


-- 


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

[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr

[manfred99 at gmx dot ch]

--- Comment #3 from manfred99 at gmx dot ch  2007-10-03 12:49 ---
Created an attachment (id=14290)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14290&action=view)
Assembler code when commenting line 315, works


-- 


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

[Bug java/33639] New: gcj generates assembler errors

[aph at gcc dot gnu dot org]

This is from https://bugzilla.redhat.com/show_bug.cgi?id=297961

The problem is that .class files can now (as of Java 1.5) contain classes whose
name contains a hyphen.  The mangling used to generate internal labels in gcj
passes these hyphens through to the assembler rather than mangling them.


-- 
   Summary: gcj generates assembler errors
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: java
AssignedTo: aph at gcc dot gnu dot org
ReportedBy: aph at gcc dot gnu dot org


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

[Bug java/33639] gcj generates assembler errors

[aph at gcc dot gnu dot org]

--- Comment #1 from aph at gcc dot gnu dot org  2007-10-03 13:00 ---
Subject: Bug 33639

Author: aph
Date: Wed Oct  3 12:59:57 2007
New Revision: 128981

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128981
Log:
2007-10-03  Andrew Haley  <[EMAIL PROTECTED]>

PR java/33639
* class.c (mangled_classname): Detect and replace illegal
characters in assembly language symbols.
(gen_indirect_dispatch_tables): Call mangled_classname() on
the type.


Modified:
trunk/gcc/java/ChangeLog
trunk/gcc/java/class.c


-- 


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

[Bug java/33639] gcj generates assembler errors

[aph at gcc dot gnu dot org]

--- Comment #2 from aph at gcc dot gnu dot org  2007-10-03 13:02 ---
Fixed.


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug fortran/33636] Rejects valid use of vector subscript in derived type parameter

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-10-03 13:03 ---
On PPC Darwin, I get:

[karma] f90/bug% gfc pr33636.f90
[karma] f90/bug% a.out
   0
[karma] f90/bug% gfc -m64 pr33636.f90
[karma] f90/bug% a.out
   0
[karma] f90/bug% gfc
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90:34.28:

  v2 = vec3 (v1%coords ((/i+1, i, i-1/))) ! also broken
   1
Error: index in dimension 1 is out of bounds at (1)
[karma] f90/bug% gfc -m64
/opt/gcc/_gcc-clean/gcc/testsuite/gfortran.dg/derived_comp_array_ref_5.f90
[karma] f90/bug% a.out 
[karma] f90/bug% 

i.e., the test case of this PR compiles for both 32 and 64 bit modes for gcc
version 4.3.0 20071002, while derived_comp_array_ref_5.f90 compiles only in 64
bit mode (wrong cast somewhere?-)


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[tobi at gcc dot gnu dot org]

-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tobi at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-02 15:59:33 |2007-10-03 14:40:17
   date||


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

[Bug c++/33616] [4.1/4.2/4.3 regression] "lvalue required as unary '&' operand" with template pmf

[bangerth at dealii dot org]

--- Comment #1 from bangerth at dealii dot org  2007-10-03 14:48 ---
Confirmed, a regression introduced by the new parser in 3.4.0.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||rejects-valid
  Known to fail||3.4.0 4.0.4 4.1.0 4.2.0
   ||4.3.0
  Known to work||3.3.6
   Last reconfirmed|-00-00 00:00:00 |2007-10-03 14:48:18
   date||
Summary|"lvalue required as unary   |[4.1/4.2/4.3 regression]
   |'&' operand" with template  |"lvalue required as unary
   |pmf |'&' operand" with template
   ||pmf


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

[Bug fortran/33198] Derived type in common: Default initializer not rejected

[tobi at gcc dot gnu dot org]

--- Comment #4 from tobi at gcc dot gnu dot org  2007-10-03 15:01 ---
Fixed on trunk.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c++/33616] [4.1/4.2/4.3 regression] "lvalue required as unary '&' operand" with template pmf

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.2.2


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

[Bug regression/33637] "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-03 15:38 ---
One should note the gnu binutils does not support the newer features in aix so
it is really not supported with gcc on aix.


-- 


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

[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2007-10-03 15:43 ---
Please provide enough sources to create an _executable_ that shows the failure.
We are dealing with runtime failure here.

A _short_ testcase (<30 lines) is nice to have, so all non-related parts should
be removed. Wandering through a maze of jumps certainly doesn't help to find
the problem.

An abort() should be called for wrong result, but at least wrong result and
expected result should be described to help trace the issue down.

BTW: Assembler dumps are not _that_ informative, especially without
-fverbose-asm ;)


-- 


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

[Bug tree-optimization/33576] segfault in extract_muldiv for cpu2006 benchmark

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2007-10-03 15:45 ---
Subject: Bug 33576

Author: spop
Date: Wed Oct  3 15:45:10 2007
New Revision: 128986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128986
Log:
2007-10-03  Sebastian Pop  <[EMAIL PROTECTED]>

PR tree-optimization/33576
* testsuite/gcc.dg/tree-ssa/pr33576.c: New.
* tree-loop-linear.c (linear_transform_loops): Call remove_iv.
* lambda.h (lambda_loopnest_to_gcc_loopnest): New parameter.
(remove_iv): Declared.
* lambda-code.c (remove_iv): Not static.
(lambda_loopnest_to_gcc_loopnest): New parameter remove_ivs.
Don't remove ivs there, save ivs in the buffer.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr33576.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lambda-code.c
trunk/gcc/lambda.h
trunk/gcc/tree-loop-linear.c


-- 


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

[Bug tree-optimization/33576] segfault in extract_muldiv for cpu2006 benchmark

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2007-10-03 15:47 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[tobi at gcc dot gnu dot org]

--- Comment #1 from tobi at gcc dot gnu dot org  2007-10-03 16:12 ---
Created an attachment (id=14291)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view)
Putative patch

This patch fixes the testcase.

FX, I take it that you have a ready-built compiler with type-checking enabled. 
In that case I would ask you to try this patch.  Otherwise I'll take care of
this myself.


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[tobi at gcc dot gnu dot org]

--- Comment #2 from tobi at gcc dot gnu dot org  2007-10-03 16:22 ---
Created an attachment (id=14292)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292&action=view)
Putative patch redux

Coming to think of it, the charlen thing can probably also be moved to the
first switch and done unconditionally.  This hasn't yet gotten the testsuite
treatment from me, though.


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:26 
---
(In reply to comment #1)
> Created an attachment (id=14291)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view) [edit]
> Putative patch

I thought about that, because it seems right, but the the question is: what was
the intent of the original situation, which only copied typespec only for
unknown types?

> FX, I take it that you have a ready-built compiler with type-checking 
> enabled. 
> In that case I would ask you to try this patch.  Otherwise I'll take care of
> this myself.

I'll test it.


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Comment #4 from Tobias dot Schlueter at physik dot uni-muenchen dot de  
2007-10-03 16:36 ---
Subject: Re:  Parentheses get wrong kind during matching

fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:26 
> ---
> (In reply to comment #1)
>> Created an attachment (id=14291)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14291&action=view) [edit]
>> Putative patch
> 
> I thought about that, because it seems right, but the the question is: what 
> was
> the intent of the original situation, which only copied typespec only for
> unknown types?

I'm thinking that was a case of playing it overly safe as the comment 
indicates.

OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 
for which I have no explanation at the moment, I'll have to doublecheck 
if it disappears without my patch.

 > I'll test it.

Thanks!

- Tobi


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:40 
---
(In reply to comment #4)
> OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 
> for which I have no explanation at the moment, I'll have to doublecheck 
> if it disappears without my patch.

Hum... Why do I keep sending regular regressions heads-up, can you remind me?
;-)

http://gcc.gnu.org/ml/fortran/2007-10/msg00040.html


-- 


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

[Bug objc++/27248] FAIL: obj-c++.dg/encode-3.mm (test for excess errors)

[razin at avaya dot com]

--- Comment #2 from razin at avaya dot com  2007-10-03 16:44 ---
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of 27232 ***
> 

Hello! 
I am currently experiencing the same problem when using 4.2.1. There is not
particular description if this bug is going to be addressed as well as any
clear explanation about further action or workaround (which I know but do not
see the reason for). Please provide the information about the official but
that's actually open for that issue as well as further action that hopefully
will take place to resolve it.

Thank you!
Sergey


-- 

razin at avaya dot com changed:

   What|Removed |Added

 CC||razin at avaya dot com


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Comment #6 from Tobias dot Schlueter at physik dot uni-muenchen dot de  
2007-10-03 16:46 ---
Subject: Re:  Parentheses get wrong kind during matching

fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:40 
> ---
> (In reply to comment #4)
>> OTOH I'm seeing a testsuite failure with derived_comp_array_ref_5.f90 
>> for which I have no explanation at the moment, I'll have to doublecheck 
>> if it disappears without my patch.
> 
> Hum... Why do I keep sending regular regressions heads-up, can you remind me?
> ;-)

Ouch, a warning regression seemd so unlikely to happen in the tree that 
I thought it would be my fault, even though I very well remembered that 
you had sent an e-mail pointing out failures of default_format_1.f90 
(which I'm seeing as well).

Note to self: always memorize e-mail's from FX in their entirety :)


-- 


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:52 
---
(In reply to comment #6)
> failures of default_format_1.f90 (which I'm seeing as well)

You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's
what you've got these days)? That's not supposed to happen, I thought it'd be
only on powerpc-darwin (which I have xfail'ed)! Could you compile it and run it
under gdb, and see where it aborts? (I expect it to be the line about tiny, in
which case it'd be the same failure as powerpc.)


-- 


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

[Bug c++/33640] New: [4.2.2 regression] testsuite failure in g++.dg/other/unused1.C

[ghazi at gcc dot gnu dot org]

I'm seeing a regression in gcc-4.2.2 prerelease:

FAIL: g++.dg/other/unused1.C scan-assembler
(string|ascii?)z?\\t"class2("|000)

The failure happens on multiple (all?) configurations starting around Sept
13th:

CLEAN results:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00609.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00619.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00684.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00634.html

ERROR results:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00664.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00677.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00734.html
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00683.html

and the error still occurs as of last night's checkout:
http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00096.html


-- 
   Summary: [4.2.2 regression] testsuite failure in
g++.dg/other/unused1.C
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org


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

[Bug middle-end/33641] New: perlbmk gets type mismatch in pointer plus expression

[janis at gcc dot gnu dot org]

Benchmark perlbmk from SPEC CPU2000 fails at runtime on powerpc64-linux with
several sets of optimization flags.  When built with a compiler configured with
--enable-checks=all, file toke.c fails to build.  The following minimized
testcase:

typedef enum { one, two } exp;
extern exp pe;
extern char pt[256];
void psd (void (*f) (void *), void *p);
static void rle (void *e) { }
void
foo (void)
{
  psd ((void (*)(void *)) (rle), (void *) (pt + pe));
}

fails the same way, even with -O0, and also with an i686-linux cross compiler,
with:

bug6.c: In function ‘foo’:
bug6.c:14: error: type mismatch in pointer plus expression
void *

char *



D.1249 = &pt + pe.0

Besides the obvious bug, it's annoying that the compiler doesn't report an ICE.


-- 
   Summary: perlbmk gets type mismatch in pointer plus expression
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[Tobias dot Schlueter at physik dot uni-muenchen dot de]

--- Comment #8 from Tobias dot Schlueter at physik dot uni-muenchen dot de  
2007-10-03 17:06 ---
Subject: Re:  Parentheses get wrong kind during matching

fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-10-03 16:52 
> ---
> (In reply to comment #6)
>> failures of default_format_1.f90 (which I'm seeing as well)
> 
> You're seeing failures of default_format_1.f90 on i686-darwin (IIRC, that's
> what you've got these days)? That's not supposed to happen, I thought it'd be
> only on powerpc-darwin (which I have xfail'ed)! Could you compile it and run 
> it
> under gdb, and see where it aborts? (I expect it to be the line about tiny, in
> which case it'd be the same failure as powerpc.)

I checked all tests individually, and both the tests related to 
tiny(0.0_8) fail.


-- 


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

[Bug rtl-optimization/33642] New: unrecognizable insn for -frtl-abstract-sequences

[janis at gcc dot gnu dot org]

Almost any source file compiled for any of a large number of targets
(powerpc*-*, arm-eabi, hppa-linux, mipsel-linux, s390*-linux, sh*-*, sparc*-*)
with -O2 -frtl-abstract-sequences results in the following:

bug1.c: In function ‘foo’:
bug1.c:8: error: unrecognizable insn:
(insn 28bug1.c:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The testcase used here:

int foo (void)
{
  return 0;
}


-- 
   Summary: unrecognizable insn for -frtl-abstract-sequences
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[fxcoudert at gcc dot gnu dot org]

--- Comment #9 from fxcoudert at gcc dot gnu dot org  2007-10-03 17:09 
---
(In reply to comment #8)
> I checked all tests individually, and both the tests related to 
> tiny(0.0_8) fail.

That means Apple's printf() failures to read and write denormals are not
powerpc-specific. I've xfail'ed the test on all *-apple-darwin*. Thanks for
testing!


-- 


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

[Bug fortran/33643] New: "Line truncated" warning in gfortran if trailing blanks extend beyond 132 columns

[michael dot a dot richmond at nasa dot gov]

When I compile the program listed below with the command "gfortran -c
sysmat.f90" I get the message "Warning: Line truncated at (1)"

PROGRAM sysmat
! The following line has enough trailing blanks to make it 133 characters long
i = 0   
END PROGRAM sysmat


-- 
   Summary: "Line truncated" warning in gfortran if trailing blanks
extend beyond 132 columns
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug fortran/33643] "Line truncated" warning in gfortran if trailing blanks extend beyond 132 columns

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-03 17:39 ---
I think this warning is correct even if the characters are spaces.


-- 


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

[Bug middle-end/33644] New: ICE in local_cprop_pass with -ftrapv for crafty

[janis at gcc dot gnu dot org]

Benchmark crafty from SPEC CPU2000 gets an ICE for 32-bit powerpc (linux, aix,
darwin, eabi) when compiled with -O2 -ftrapv, as shown by this minimized test:

extern char *bar (const char *);
int *m, *b;

void
foo (void)
{
  int *mv;
  int p;
  char a[17];

  p = bar (a) - a;
  for (mv = m; mv < b; mv++)
if (p && ((*mv  & 7) != p))
  *mv=0;
}

which gives the following output when compiled with -O2 -ftrapv:

bug.c: In function ‘foo’:
bug.c:15: internal compiler error: in local_cprop_pass, at gcse.c:3240
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE in local_cprop_pass with -ftrapv for crafty
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug middle-end/33644] ICE in local_cprop_pass with -ftrapv for crafty

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2007-10-03 18:08 ---
A regression hunt identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=125624

r125624 | dberlin | 2007-06-11 18:02:15 + (Mon, 11 Jun 2007)

This is the merge of the dataflow branch into mainline.


-- 


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

[Bug tree-optimization/33645] New: undefined static variable in vortex for -fno-unit-at-a-time

[janis at gcc dot gnu dot org]

Benchmark vortex from SPEC CPU2000 compiled with "-O2 -fno-unit-at-atime" for
powerpc64-linux fails to build due to a missing symbol.  For each of 24 cross
cc1's that I tried, symbol "That" from the following minimized testcase is not
defined in the .s file:

extern void bar (int *);
void
foo (void)
{
  static int That;
  static int *This = &That;

  bar (This);
}

The failure starts with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=126947

r126947 | hubicka | 2007-07-26 03:43:40 + (Thu, 26 Jul 2007)


-- 
   Summary: undefined static variable in vortex for -fno-unit-at-a-
time
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug c++/15764] no cleanup if temporary's dtor terminates with an exception

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2007-10-03 18:26 ---
Fixed for 4.3.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.3.0   |
  Known to work||4.3.0
 Resolution||FIXED


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

[Bug target/33635] Bootstrap broken on mips-sgi-irix6.5

[rsandifo at gcc dot gnu dot org]

--- Comment #1 from rsandifo at gcc dot gnu dot org  2007-10-03 18:39 
---
Sorry, this is my fault.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-03 18:39:04
   date||


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

[Bug fortran/33646] New: [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC CPU 2006

[hjl at lucon dot org]

Gcc 4.3 revision 128980 generates:

str.fppized.f90:337.29:

  module procedure create
1
Error: Ambiguous interfaces 'create' and 'create' in generic interface
'create_' at (1) 
str.fppized.f90:337.29:

Revision 128885 is OK.


-- 
   Summary: [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC
CPU 2006
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org


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

[Bug target/33635] Bootstrap broken on mips-sgi-irix6.5

[rsandifo at gcc dot gnu dot org]

--- Comment #2 from rsandifo at gcc dot gnu dot org  2007-10-03 18:39 
---
Subject: Bug 33635

Author: rsandifo
Date: Wed Oct  3 18:39:30 2007
New Revision: 128991

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128991
Log:
gcc/
PR target/33635
* config/mips/mips-protos.h (mips_split_64bit_move): Rename to...
(mips_split_doubleword_move): ...this.
* config/mips/mips.c (mips_subword): Extend to handle 64-bit words;
use natural endianness for multi-format FPR values.
(mips_split_64bit_move): Rename to...
(mips_split_doubleword_move): ...this and extend to 64-bit words.
Use move_doubleword_fpr* patterns for moves involving FPRs.
(mips_save_reg): Update the call to mips_split_64bit_move.
(mips_secondary_reload_class): Return NO_REGS for any reload of a
nonzero constant into an FPR if the constant can be forced to memory.
* config/mips/mips.md: Update the splitter calls to
mips_split_64bit_move.
(UNSPEC_LOAD_DF_LOW): Rename to...
(UNSPEC_LOAD_LOW): ...this.
(UNSPEC_LOAD_DF_HIGH): Rename to...
(UNSPEC_LOAD_HIGH): ...this.
(UNSPEC_STORE_DF_HIGH): Rename to...
(UNSPEC_STORE_WORD): ...this.
(SPLITF): New mode iterator.
(HALFMODE): New mode attribute.
(movtf): New expander.
(*movtf_internal): New define_insn_and_split.
(move_doubleword_fpr): New expander.
(load_df_low, load_df_high, store_df_high, mthc1, mfhc1): Replace
with...
(load_low, load_high, store_word, mthc1)
(mfhc1): ...these more general patterns.

gcc/testsuite/
PR target/33635
* gcc.target/mips/mips.exp (setup_mips_tests): Set mips_isa_rev
and mips_forced_be.
(dg-mips-options): Handle -EL and -mel.  Make -mfp64 imply
-mhard-float and a suitable ISA.  Improve handling of -mipsXrY
options.
* gcc.target/mips/fpr-moves-1.c: New test.
* gcc.target/mips/fpr-moves-2.c: Likewise.
* gcc.target/mips/fpr-moves-3.c: Likewise.
* gcc.target/mips/fpr-moves-4.c: Likewise.
* gcc.target/mips/fpr-moves-5.c: Likewise.
* gcc.target/mips/fpr-moves-6.c: Likewise.
* gcc.target/mips/mips32r2-mxhc1.c: Remove -march=mips32r2

Added:
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-1.c
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-2.c
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-3.c
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-4.c
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-5.c
trunk/gcc/testsuite/gcc.target/mips/fpr-moves-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips-protos.h
trunk/gcc/config/mips/mips.c
trunk/gcc/config/mips/mips.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/mips/mips.exp
trunk/gcc/testsuite/gcc.target/mips/mips32r2-mxhc1.c


-- 


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

[Bug target/33635] Bootstrap broken on mips-sgi-irix6.5

[rsandifo at gcc dot gnu dot org]

--- Comment #3 from rsandifo at gcc dot gnu dot org  2007-10-03 18:42 
---
Thanks for the report.  As per my gcc-patches@ message,
I think the committed patch is at least a step on the
road to recovery.  Please let me know if it fixes things,
or if it still isn't enough.


-- 

rsandifo at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING


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

[Bug fortran/33539] Too much noise for zero-length character strings

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-10-03 18:51 ---
This may work:

$ svn diff
Index: resolve.c
===
--- resolve.c   (revision 128885)
+++ resolve.c   (working copy)
@@ -6563,7 +6563,7 @@ resolve_charlen (gfc_charlen *cl)

   /* "If the character length parameter value evaluates to a negative
  value, the length of character entities declared is zero."  */
-  if (cl->length && !gfc_extract_int (cl->length, &i) && i <= 0)
+  if (cl->length && !gfc_extract_int (cl->length, &i) && i < 0)
 {
   gfc_warning_now ("CHARACTER variable has zero length at %L",
   &cl->length->where);

(I do want a warning for a length that's less than zero, but
exactly zero seems to be OK).


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement


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

[Bug target/32893] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize

[dorit at gcc dot gnu dot org]

--- Comment #16 from dorit at gcc dot gnu dot org  2007-10-03 18:52 ---
Ryan, thanks a lot for the info. FYI, I started a discussion about this here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00202.html


-- 


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

[Bug fortran/33647] New: _gfortran_copy_string missing in libgfortran.a

[longb at cray dot com]

In the library .../lib64/libgfortran.a, the 4.1.2 version has a routine

  _gfortran_copy_string

in the strong_intrinsics.o component.  For the same 4.2.1 library there is no
corresponding entry point.

It appears that codes compiled with 4.1.2 generate internal calls to this entry
point.  Attempting to link a library built with 4.1.2 and a code compiled and
linked with the 4.2.1 compiler results in an "undefined reference" message from
the loader for _gfortran_copy_string.

Is it by design that codes compiled with 4.1.2 cannot be linked with 4.2.1? Is
it a viable workaround to manually extract the string_intrinsic.o component
from the old libgfortran.a file and insert it into the new libgfortran.a
library, replacing the current version?


-- 
   Summary: _gfortran_copy_string missing in libgfortran.a
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
 GCC build triplet: x86_64-suse-linux
  GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux


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

[Bug middle-end/33641] perlbmk gets type mismatch in pointer plus expression

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-03 18:32 ---
I'll have a look.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-03 18:32:27
   date||


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

[Bug fortran/33647] _gfortran_copy_string missing in libgfortran.a

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-03 19:22 ---
And this is by design.  gfortran 4.1 is ABI incompatiable with gfortran 4.2. 
This is one of the reasons why in 4.2 (or is it only on the trunk), we added
symbol versioning support.  This is not the only place where 4.1 is different
from 4.2.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libfortran/33469] Default formats for real input are not precise enough

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2007-10-03 19:30 ---
gcc/testsuite/gfortran.dg/default_format_1.f90 passes the test if I replace

if (y /= x) res = res + 1

by

z=0.0_k
if (abs(x-y)>nearest(z,1.0_k)) res = res + 1

in the two places of test_r8, i.e. the tests fail for TINY() because the result
differs from the original value by ~+/-5.0E-324: the smallest denormalized
number.  I have noticed that this happens for an odd number of iterations of
NEAREST(), but I did not figure out if the culprit was the WRITE() or the
READ(). I have also seen the same problem with xlf and g95.

I suggest that the test includes this change and does not xfail on Darwin.


-- 


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

[Bug libfortran/33469] Default formats for real input are not precise enough

[dominiq at lps dot ens dot fr]

--- Comment #11 from dominiq at lps dot ens dot fr  2007-10-03 19:34 ---
BTW I have forgotten to explain why I have to use an auxiliary variable 'z': if
I usenearest(0.0_8,1.0_8); I get

default_format_1_db.f90:70.29:

if (abs(x-y)>nearest(0.0_8,1.0_8)) print *, x, y, x-y
1
Error: Result of NEAREST underflows its kind at (1)
default_format_1_db.f90:84.29:

if (abs(x-y)>nearest(0.0_8,1.0_8)) print *, x, y, x-y
1
Error: Result of NEAREST underflows its kind at (1)
default_format_1_db.f90:93.25:

  use test_default_format
1
Fatal Error: Can't open module file 'test_default_format.mod' for reading at
(1): No such file or directory

Producing a hard error for an underflow is indeed an incredibely clever idea!-(

Reminds me of a compiler which crunched NaNs and Infs with delight, but aborted
on underflow, very handy for waves simulations!


-- 


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

[Bug fortran/33647] _gfortran_copy_string missing in libgfortran.a

[longb at cray dot com]

--- Comment #2 from longb at cray dot com  2007-10-03 19:44 ---
Subject: Re:  _gfortran_copy_string missing in libgfortran.a

I suspected this might be the case, but did not find it documented.  
Thanks for the quick reply.

Cheers,
Bill


pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-03 19:22 
> ---
> And this is by design.  gfortran 4.1 is ABI incompatiable with gfortran 4.2. 
> This is one of the reasons why in 4.2 (or is it only on the trunk), we added
> symbol versioning support.  This is not the only place where 4.1 is different
> from 4.2.
>
>
>   


-- 


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

[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr

[manfred99 at gmx dot ch]

--- Comment #5 from manfred99 at gmx dot ch  2007-10-03 20:10 ---
Subject: Re:  optimization bug: wrong code with
 -fforce-addr


> --- Comment #4 from ubizjak at gmail dot com  2007-10-03 15:43 ---
> Please provide enough sources to create an _executable_ that shows the
> failure.
> We are dealing with runtime failure here.
>

If I could come up with a short testcase just like that, 
I would have done so already.

> A _short_ testcase (<30 lines) is nice to have, so all non-related parts
> should
> be removed. Wandering through a maze of jumps certainly doesn't help to
> find
> the problem.
> 
> An abort() should be called for wrong result, but at least wrong result
> and
> expected result should be described to help trace the issue down.
> 

I will see what I can do, but do not expect any miracles.
This is from a large software package with ~10^2 functions
and at the end there is a binary output file of several MB which is
either as it should or not :-(

And as I told in the bug report, inserting or deleting code suddenly
let the issue vanish. I already tried to reduce this code with the 
result that removing dead code fixed the miscompilation.

> BTW: Assembler dumps are not _that_ informative, especially without
> -fverbose-asm ;)
> 

As it was not clear to me what information to provide, I asked first
on the gcc mailing list, to no avail, so I provided just some random
information.


BTW 1:
# gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fx/gfortran_nightbuild/trunk/configure
--prefix=/home/fx/gfortran_nightbuild/irun-20071001
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20071001 (experimental) [trunk revision 128899] (GCC)


BTW 2:
Code was checked with valgrind and efence, seems to be ok.


-- 


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

[Bug c++/33640] [4.2.2 regression] testsuite failure in g++.dg/other/unused1.C

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2007-10-03 20:42 ---
This looks like PR33429.  Perhaps we should backport the XFAIL that was
installed on mainline.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||33429
  Known to fail||4.2.2
  Known to work||4.1.3 4.3.0


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

[Bug tree-optimization/33648] New: ICE in verify_flow_info for -fmodulo-sched -freorder-blocks-and-partition

[janis at gcc dot gnu dot org]

Most benchmarks in SPEC CPU2000 fail to compile with an ICE when compiled with
"-O2 -fmodulo-sched -freorder-blocks-and-partition" for powerpc* and s390*
targets.  Compiling the following minimized testcase:

unsigned res;
void
foo (unsigned code, int len)
{
  int i;
  for (i = 0; i < len; i++)
  res |= code & 1;
}

gives the output:

bug.c: In function ‘foo’:
bug.c:8: error: fallthru edge crosses section boundary (bb 9)
bug.c:8: error: fallthru edge crosses section boundary (bb 7)
bug.c:8: error: fallthru edge crosses section boundary (bb 13)
bug.c:8: error: fallthru edge crosses section boundary (bb 12)
bug.c:8: error: fallthru edge crosses section boundary (bb 3)
bug.c:8: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The failure starts with this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=127293

r127293 | revitale | 2007-08-08 12:21:37 + (Wed, 08 Aug 2007)


-- 
   Summary: ICE in verify_flow_info for -fmodulo-sched -freorder-
blocks-and-partition
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug fortran/33646] [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC CPU 2006

[hjl at lucon dot org]

--- Comment #1 from hjl at lucon dot org  2007-10-03 20:33 ---
[EMAIL PROTECTED] build_base_o2.]$ cat bar.f90 
module BAR_MODULE
   implicit none
   private
   publiccreate_
   interface create_
  module procedure create
   end interface
contains
   subroutine create(self)
character(*) :: self
  pointer :: self
  allocate(self)
   end subroutine
end
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gfortran -c bar.f90
[EMAIL PROTECTED] build_base_o2.]$ cat foo.f90 
module FOO_MODULE
   use BAR_MODULE
   implicit none
   private
   publiccreate_
   interface create_
  module procedure create
   end interface

   publiccreate_copy_
   interface create_copy_
  module procedure create_copy
   end interface
contains

   subroutine create(self)
character(*) :: self
  pointer :: self
  nullify(self)
  allocate(self)

  self = " "
   end subroutine

   subroutine create_copy(self,s)
character(*) :: self
  pointer :: self
  character(*) :: s
  call create_(self)
   end subroutine
end
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.3/bin/gfortran -c foo.f90
foo.f90:7.29:

  module procedure create
1
Error: Ambiguous interfaces 'create' and 'create' in generic interface
'create_' at (1)
foo.f90:7.29:

  module procedure create
1
Warning: Ambiguous interfaces 'create' and 'create' in generic interface
'create_' at (1)
[EMAIL PROTECTED] build_base_o2.]$ 


-- 


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

[Bug fortran/33646] [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC CPU 2006

[hjl at lucon dot org]

--- Comment #2 from hjl at lucon dot org  2007-10-03 20:55 ---
It should be:

[EMAIL PROTECTED] pr33646]$ cat bar.f90 
module BAR_MODULE
   implicit none
   private
   publiccreate_
   interface create_
  module procedure create
   end interface
   type system_type
   integer(kind=kind(1)) :: max_memory_used
   end type

contains

   subroutine create(self)
type(system_type) :: self
  pointer :: self
  allocate(self)
   end subroutine

end
[EMAIL PROTECTED] pr33646]$ cat bar.f90 
module BAR_MODULE
   implicit none
   private
   publiccreate_
   interface create_
  module procedure create
   end interface
   type system_type
   integer(kind=kind(1)) :: max_memory_used
   end type

contains

   subroutine create(self)
type(system_type) :: self
  pointer :: self
  allocate(self)
   end subroutine

end
[EMAIL PROTECTED] pr33646]$ make
gfortran -c bar.f90
gfortran -c foo.f90
foo.f90:7.29:

  module procedure create
1
Error: Ambiguous interfaces 'create' and 'create' in generic interface
'create_'
 at (1)
foo.f90:7.29:

  module procedure create
1
Warning: Ambiguous interfaces 'create' and 'create' in generic interface
'create
_' at (1)
make[1]: *** [foo.o] Error 1


-- 


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

[Bug fortran/33646] [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC CPU 2006

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2007-10-03 21:21 ---
hj,

It's me - I'll revert the patch that did this, right away.

Cheers

Paul


-- 


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

[Bug ada/33634] bootstrap with ada failed

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2007-10-03 
21:23 ---
Subject: Re:  bootstrap with ada failed

> --- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-10-03 06:08 
> ---
> Try to revert the big SRA patch.

128907 is ok.  128908 is broken.

Dave


-- 


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

[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-03 21:02 ---
-frtl-abstract-sequences
It is a size optimization method. This option is to find identical
sequences of code, which can be turned into pseudo-procedures and then replace
all occurrences with calls to the newly created subroutine. It is kind of an
opposite of -finline-functions. This optimization runs at RTL level.

I propose to kill all traces of it unless someone steps up and maintains this
piece of code and we enable it for -Os.


-- 


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

[Bug fortran/26682] gfortran fails with -fwhole-program optimization

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-10-03 21:27 
---
Subject: Bug 26682

Author: fxcoudert
Date: Wed Oct  3 21:27:39 2007
New Revision: 128993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128993
Log:
PR fortran/26682
* trans-decl.c (build_function_decl): Set "externally_visible"
attribute on the MAIN program decl.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c


-- 


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

[Bug fortran/26682] gfortran fails with -fwhole-program optimization

[fxcoudert at gcc dot gnu dot org]

--- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-10-03 21:30 
---
I've fixed 1 and 2 (and added an error message when -fwhole-program is used
with Fortran), and there is a separate PR to track 3, so I'll close this one.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug ada/33634] bootstrap with ada failed

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2007-10-03 21:31 
---
> 128907 is ok.  128908 is broken.

OK, thanks for confirming.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-03 21:31:51
   date||


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

[Bug fortran/33646] [4.3 Regression] Gcc 4.3 failed to compile tonto in SPEC CPU 2006

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2007-10-03 21:32 ---
> It's me

I have warned you;-)


-- 


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

[Bug fortran/33646] [4.3 Regression] Gcc 4.3 revision 128954 failed tonto in SPEC CPU 2006

[hjl at lucon dot org]

--- Comment #5 from hjl at lucon dot org  2007-10-03 21:38 ---
Revision 128954:

http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00058.html

is the cause.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
Summary|[4.3 Regression] Gcc 4.3|[4.3 Regression] Gcc 4.3
   |failed to compile tonto in  |revision 128954 failed tonto
   |SPEC CPU 2006   |in SPEC CPU 2006


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

[Bug fortran/33626] Parentheses get wrong kind during matching

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2007-10-03 22:05 
---
(In reply to comment #2)
> Created an attachment (id=14292)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14292&action=view) [edit]
> Putative patch redux

That patch regtests fines on x86_64-linux with type-checking enabled. It's OK
to commit.


-- 


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[hjl at lucon dot org]

--- Comment #9 from hjl at lucon dot org  2007-10-03 22:17 ---
(In reply to comment #8)
> Subject: Re:  attribute((aligned)) doesn't work for variables on the stack for
> greater than required alignement
> 
> On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
> <[EMAIL PROTECTED]> wrote:
> >
> >
> > --- Comment #7 from hjl at lucon dot org  2007-10-03 22:04 ---
> > What is the performance impact of
> >
> > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html
> 
> The performance impact is non if the variables don't need aligned.
> Otherwise you get a small penality at the very begining for the
> alignment of the variable itself.  Really this is only to be used with
> big alignments like 128byte alignment (for using with a DMA system
> like in the Cell).
> 

What is the performance if the stack alignment adjustment is required in
all functions with floating point variables on stack?


-- 


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-10-03 22:07 ---
Subject: Re:  attribute((aligned)) doesn't work for variables on the stack for
greater than required alignement

On 3 Oct 2007 22:04:28 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #7 from hjl at lucon dot org  2007-10-03 22:04 ---
> What is the performance impact of
>
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html

The performance impact is non if the variables don't need aligned.
Otherwise you get a small penality at the very begining for the
alignment of the variable itself.  Really this is only to be used with
big alignments like 128byte alignment (for using with a DMA system
like in the Cell).

-- Pinski


-- 


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[hjl at lucon dot org]

--- Comment #7 from hjl at lucon dot org  2007-10-03 22:04 ---
What is the performance impact of

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html

Intel compiler has a very efficient way to align the stack:

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

It saves stack pointer in frame pointer. Can we implement it for suitable
cases/backends and properly handle

1. tail call optimization.
2. stack unwind.
3. nested functions.


-- 


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

[Bug c++/8007] typeof(...) as template arg doesn't work

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2007-10-03 21:54 ---
The error the trunk gives is correct; this is not one of the allowed uses of a
member function name in [expr.prim]p10.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[david_albert at axiometric dot com]

--- Comment #5 from david_albert at axiometric dot com  2007-10-03 22:06 
---
This issue has affected *many* developers on a variety of platforms including
ARM and PPC.  There is no elegant way to resolve this without searching through
every line of code.  There is a warning -Wcast-align that helps to find where
some of these alignment issues may exist, but there is no nice way to fix them
(i.e. the warning will persist even after the variable in question is aligned).

Please consider re-submitting this as an enhancement request.


-- 


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

[Bug c/33629] bad code with -O2 if pointer dereference followed by null test

[rask at gcc dot gnu dot org]

--- Comment #3 from rask at gcc dot gnu dot org  2007-10-03 22:13 ---
You could open a request for a warning when a null pointer check is optimized
away after dereferencing the pointer.


-- 


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[hjl at lucon dot org]

--- Comment #10 from hjl at lucon dot org  2007-10-03 22:27 ---
For backend with frame pointer and working -fomit-frame-pointer -g, can
we

1. Make -fomit-frame-pointer per function, instead of per file.
2. Enable -fomit-frame-pointer for functions which need stack alignment.
3. Mark frame-pointer as reserved and use frame pointer to save stack
pointer.

and make sure that

1. tail call optimization.
2. stack unwind.
3. nested functions.
4. inline functions

work properly?


-- 


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

[Bug tree-optimization/33649] New: cc1 segfaults when multiple tree opts disabled

[janis at gcc dot gnu dot org]

Every test in SPEC CPU2000 causes cc1 to segfault when built with:

  -O2
  -fno-tree-ch
  -fno-tree-copy-prop
  -fno-tree-dominator-opts
  -fno-tree-store-copy-prop
  -fno-tree-vrp

Yes, a normal person wouldn't do that, but in theory we'd like the optimization
passes to not rely on each other.  Minimizing a test case proved to be
frustrating because even a change in whitespace could cause a compile to
suddenly succeed.  The following tests in gcc/testsuite/gcc.dg fail in the same
way with these options for powerpc-linux.  I tried one of them with 24 cross
cc1s and most failed in the same way.

  2906-1.c
  20020122-2.c
  20020426-2.c
  20040916-1.c
  20050111-2.c
  20050702-1.c
  20070507-1.c

The failure is in tree-ssa-pre.c:2002 with i=20, postorder[i]=283741360.


-- 
   Summary: cc1 segfaults when multiple tree opts disabled
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[pinskia at gcc dot gnu dot org]

--- Comment #11 from pinskia at gcc dot gnu dot org  2007-10-03 22:40 
---
(In reply to comment #7)
> It saves stack pointer in frame pointer. Can we implement it for suitable
> cases/backends and properly handle

This only helps x86 really.  If you look at my patch, it already implements
(correctly) handling large cases like 128byte alignment (which people use with
the Cell).  What you are proposing will cause more stack to be used than
actually required and more complex for the normal case.  If you look at my
patch, you will see it handles 1-4 issues nicely without any problems (because
the stack itself is not realigned).  Oh on PPC, the stack pointer has to be
correct so you cannot use frame pointer to be the old stack pointer.


-- 


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

[Bug tree-optimization/33650] New: ICE in verify_curr_properties for -O2 -fno-tree-salias

[janis at gcc dot gnu dot org]

Just about any input to gcc for any target results in the following ICE for
"-O2 -fno-tree-salias":

bug7.c: In function ‘foo’:
bug7.c:1: internal compiler error: in verify_curr_properties, at passes.c:1043
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here's the testcase used here:

  void foo (void) { return; }

This was discussed starting at http://gcc.gnu.org/ml/gcc/2007-09/msg00503.html,
with the conclusion that the flag is probably worthwhile and there should be a
dummy pass after salias.


-- 
   Summary: ICE in verify_curr_properties for -O2 -fno-tree-salias
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org


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

[Bug tree-optimization/33650] ICE in verify_curr_properties for -O2 -fno-tree-salias

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-03 23:12 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-03 23:12 ---
*** Bug 33650 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu dot org


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

[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement

[hjl at lucon dot org]

--- Comment #12 from hjl at lucon dot org  2007-10-04 00:01 ---
(In reply to comment #11)

> This only helps x86 really.  If you look at my patch, it already implements
> (correctly) handling large cases like 128byte alignment (which people use with
> the Cell).  What you are proposing will cause more stack to be used than
> actually required and more complex for the normal case.  If you look at my
> patch, you will see it handles 1-4 issues nicely without any problems (because
> the stack itself is not realigned).  Oh on PPC, the stack pointer has to be
> correct so you cannot use frame pointer to be the old stack pointer.

Does your patch handle register spill which needs a larger alignment? What
is the impact of your approach on performance when stack alignment is needed
for local variable as well as register spill?


-- 


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

[Bug c++/11078] [ABI] decltype(T()) doesn't work

[jason at gcc dot gnu dot org]

--- Comment #28 from jason at gcc dot gnu dot org  2007-10-03 23:54 ---
Changing the testcase to use decltype instead of typeof produces this error
with current sources:

wa.C:2: sorry, unimplemented: zero-operand casts cannot be mangled due to a
defect in the C++ ABI

Now that we have decltype, I think we don't need to worry about mangling
typeof.  I'm just going to add a sorry to suggest that people use decltype
instead.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doug dot gregor at gmail dot
   ||com
   Keywords|ice-on-valid-code   |rejects-valid
Summary|[ABI] ICE in write_type with|[ABI] decltype(T()) doesn't
   |typeof and templates|work


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

[Bug c/33651] New: Request warning on null pointer chk optimized after ptr deref

[david_albert at axiometric dot com]

With -O2 and above, the optimizer will remove null pointer checks after the
pointer has been de-referenced.  This makes assumptions about the run-time
environment: that de-referencing address 0 is illegal and will cause an MMU
fault.  This assumption is invalid in some environments such as those where
address 0 contains a table that may be legitimately accessed.  The removal of
subsequent null pointer checks results in potentially serious object code
generation errors for valid C input code.

Please add a warning on removal of null pointer checks following de-reference
of that pointer.

ref. c/33629


-- 
   Summary: Request warning on null pointer chk optimized after ptr
deref
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david_albert at axiometric dot com
 GCC build triplet: 4.2.0
  GCC host triplet: i686-pc-cygwin
GCC target triplet: arm-elf-gcc


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

[Bug c++/11756] ICE's when using typeof in template function parameter type declarations

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2007-10-04 01:01 ---
Subject: Bug 11756

Author: jason
Date: Thu Oct  4 01:01:00 2007
New Revision: 128999

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128999
Log:
PR c++/11756
* mangle.c (write_type) [TYPEOF_TYPE]: Just sorry.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c


-- 


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

[Bug c++/11756] ICE's when using typeof in template function parameter type declarations

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2007-10-04 01:01 ---
This works with decltype, so I'm just going to change the ICE using typeof to a
sorry.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


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

[Bug c++/13740] ICE when mangling template which uses typeof

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2007-10-04 01:05 ---
The testcase works fine if I change typeof to __decltype and add the necessary
template<> template<> to the third line.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/11756] ICE's when using typeof in template function parameter type declarations

[igodard at pacbell dot net]

--- Comment #6 from igodard at pacbell dot net  2007-10-04 01:15 ---
Can you spell kludge?


-- 


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

[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2007-10-04 01:29 ---
Both bug32182 and test_4 work for me with pre-4.3.0 on i686-pc-linux-gnu, so
I'm going to set known to work for 4.3.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.3.0


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

[Bug c++/32470] [4.2/4.3 regression] fvisibility=hidden without effect in some cases

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-09-11 22:37:55 |2007-10-04 01:30:50
   date||


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

[Bug c++/21560] #pragma pack(1) doesn't work on the inner classes inside the temlated class

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-01-26 12:21:34 |2007-10-04 01:37:13
   date||
Summary|#pragma(1) doesn't work on  |#pragma pack(1) doesn't work
   |the inner classes inside the|on the inner classes inside
   |temlated class  |the temlated class


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

[Bug c++/24312] C++ front-end doesn't correctly handle distinction between global initializers and ctors

[jason at gcc dot gnu dot org]

--- Comment #4 from jason at gcc dot gnu dot org  2007-10-04 01:45 ---
This is not a bug; Mark's comment in bug 21089 had to do with the fact that
[basic.start.init] says that static initialization happens before dynamic
initialization.  Using foo() in Y's initializer makes Y dynamically
initialized, so it is not required to be initialized before s.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug c++/20416] Incorrect lifetime for temporary with static const reference

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-20 18:40:42 |2007-10-04 01:45:58
   date||


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

[Bug c++/13740] ICE when mangling template which uses typeof

[gdr at cs dot tamu dot edu]

--- Comment #13 from gdr at cs dot tamu dot edu  2007-10-04 01:46 ---
Subject: Re:  ICE when mangling template which uses typeof

"jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

| The testcase works fine if I change typeof to __decltype and add the
necessary
| template<> template<> to the third line. 

That is fine with me.  

Should we deprecate typeof?

-- Gaby


-- 


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

[Bug c++/21560] #pragma pack(1) doesn't work on the inner classes inside the temlated class

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2007-10-04 01:50 ---


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


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/7046] #pragma pack(1) context evaluated at point of instantiation rather than declaration

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2007-10-04 01:50 ---
*** Bug 21560 has been marked as a duplicate of this bug. ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||yuri at tsoft dot com


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

[Bug c++/7046] #pragma pack(1) context evaluated at point of instantiation rather than declaration

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-11 23:00:55 |2007-10-04 01:50:24
   date||


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

[Bug fortran/33643] "Line truncated" warning in gfortran if trailing blanks extend beyond 132 columns

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-10-04 03:06 
---
This is not a bug.  See the manual:

-ffree-line-length-n
Set column after which characters are ignored in typical free-form lines in
the source file. The default value is 132. n may be `none', meaning that the
entire line is meaningful. -ffree-line-length-0 means the same thing as
-ffree-line-length-none. 

So you can set it to none or some number larger than 132.

Closing


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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