[Bug bootstrap/8477] autoconf script chooses wrong value for gcc_gxx_include_path

[julians37 at gmail dot com]

--- Comment #10 from julians37 at gmail dot com  2009-06-05 04:48 ---
Configuring with --enable-version-specific-runtime-libs appears to be a
workaround, although I'm a bit unclear on what exactly this flag does.


-- 


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

[Bug tree-optimization/36318] SRA pessimizes struct copies without -Os

[astrange at ithinksw dot com]

--- Comment #4 from astrange at ithinksw dot com  2009-06-05 04:31 ---
This bug must have been weaker than I remembered it; when I used 4 char fields
instead of one char[4], 4.4 behaved properly too.

How about:
Alexander Strange http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36318

[Bug c++/2316] g++ fails to overload on language linkage

[marc dot glisse at normalesup dot org]

--- Comment #18 from marc dot glisse at normalesup dot org  2009-06-05 
04:22 ---
(In reply to comment #17)
I just checked, and the sunpro warning is overzealous. It is meant to catch
cases where the programmer writes a declaration with one linkage and later
provides a definition with some other linkage, which ends up as an overload and
not a definition of the first function (this is a valid use, but may not be
what the programmer intended). It is hard to warn about such wrong cases
without also catching perfectly normal uses...

http://forums.sun.com/thread.jspa?threadID=5390323


-- 


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

[Bug bootstrap/8477] autoconf script chooses wrong value for gcc_gxx_include_path

[julians37 at gmail dot com]

--- Comment #9 from julians37 at gmail dot com  2009-06-05 02:26 ---
This is still present in at least 4.0.4, 4.3.2 and 4.3.3.

Example gcc -v output for 4.0.4 follows.


$ cat helloworld.cpp
#include 

int main()
{
   return 0;
}
$ /redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/g++ -v helloworld.cpp 
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /redacted2/gcc-4.0.4-source-mYKeHk/gcc-4.0.4/configure
--prefix=/redacted/gcc/4.0.4-build1
--exec-prefix=/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/
--disable-dependency-tracking
Thread model: posix
gcc version 4.0.4

/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.4/cc1plus
-quiet -v -iprefix
/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/
-D_GNU_SOURCE helloworld.cpp -quiet -dumpbase helloworld.cpp -mtune=pentiumpro
-auxbase helloworld -version -o /tmp/cc36UwXw.s
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4/i686-pc-linux-gnu"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4/backward"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../i686-pc-linux-gnu/include"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686//lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686//lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4/i686-pc-linux-gnu"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686//lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../../../include/c++/4.0.4/backward"
ignoring duplicate directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686//lib/gcc/i686-pc-linux-gnu/4.0.4/include"
ignoring nonexistent directory
"/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686//lib/gcc/i686-pc-linux-gnu/4.0.4/../../../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/redacted/gcc/4.0.4-build1/arch/linux-fc3/i686/bin/../lib/gcc/i686-pc-linux-gnu/4.0.4/include
 /usr/local/include
 /redacted/gcc/4.0.4-build1/include
 /usr/include
End of search list.
GNU C++ version 4.0.4 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.4 20050721 (Red Hat 3.4.4-2).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
helloworld.cpp:1:20: error: iostream: No such file or directory
$


-- 

julians37 at gmail dot com changed:

   What|Removed |Added

 CC||julians37 at gmail dot com


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[pinskia at gcc dot gnu dot org]

--- Comment #10 from pinskia at gcc dot gnu dot org  2009-06-04 23:49 
---
(In reply to comment #8)
> Last revision that did bootstrap on hppa-linux is 147972, starting with 147996
> I get on compile farm gcc61:

This issue looks like my bug, PR 40347.


-- 


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[sje at cup dot hp dot com]

--- Comment #9 from sje at cup dot hp dot com  2009-06-04 23:47 ---
Laurent, your bootstrap problem on hppa-linux looks like a separate problem and
you should submit a new defect for that bug.  This problem is definitely due to
r148080 when we started comparing libgcc objects during the stage2/stage3
object comparision step.  We have been generating different code (a different
symbol name) for some time but we never compared the objects before so it never
mattered before.

The issue with hppa-hpux is the use of get_random_seed in
get_file_function_name.


-- 


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

[Bug bootstrap/40347] [4.5 Regression] i386-dariwn ICEs while building libgcc during stage2

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-06-04 22:14 ---
I got the same on hppa-linux:

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

See rev and commit info there.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug fortran/37203] Check ORDER= of RESHAPE

[burnus at gcc dot gnu dot org]

--- Comment #10 from burnus at gcc dot gnu dot org  2009-06-04 21:59 ---
Merged patch from the fortran-dev branch to the trunk (4.5).

Close bug as FIXED. Thanks for the patches, Thomas and Daniel!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/37203] Check ORDER= of RESHAPE

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2009-06-04 21:52 ---
Subject: Bug 37203

Author: burnus
Date: Thu Jun  4 21:52:32 2009
New Revision: 148190

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148190
Log:
gcc/fortran/
2009-06-04  Daniel Franke  

PR fortran/37203
* check.c (gfc_check_reshape): Additional checks for the
SHAPE and ORDER arguments.
* simplify.c (gfc_simplify_reshape): Converted argument checks
to asserts.

gcc/testsuite/
2009-06-04  Daniel Franke  

PR fortran/37203
* gfortran.dg/reshape_order_5.f90: New.
* gfortran.dg/reshape_shape_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/reshape_order_5.f90
trunk/gcc/testsuite/gfortran.dg/reshape_shape_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40348] Powerpc spe segfaults in vectorizing powf (a[i], 0.5f)

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2009-06-04 21:19 
---
Created an attachment (id=17952)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17952&action=view)
Reduced test case

Compile with -O3 -ffast-math -mspe on a compiler configured for
powerpc-spe-eabi.


-- 


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

[Bug tree-optimization/40348] New: Powerpc spe segfaults in vectorizing powf (a[i], 0.5f)

[meissner at gcc dot gnu dot org]

I was testing the power7 changes by building a powerpc-spe-eabi compiler to
make sure I hadn't broken anything, and I trying compiling a vector test that I
have that does almost all operations and sees whether the compiler vectorizes
it.  When I compile the tests of power (a[i], 0.5f), which is supposed to
optimize the code into sqrt with -O3 and -ffast-math, the compiler segfaults.

This case fails for the mainline as well as my branch.

-etna-> gdb cc1
GNU gdb 6.6
Copyright (C) 2006 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 "ppc-suse-linux"...
Using host libthread_db library "/lib/power6/libthread_db.so.1".
Breakpoint 1 at 0x1019e678: file /home/meissner/fsf-src/trunk/gcc/diagnostic.c,
line 730.
Breakpoint 2 at 0x1019e5d4: file /home/meissner/fsf-src/trunk/gcc/diagnostic.c,
line 670.
Breakpoint 3 at 0x108b1af0
Breakpoint 4 at 0x108b17f0
(gdb) r -O3 -mspe -quiet -ffast-math vect.i -o vect-O3.s
Starting program: /home/meissner/fsf-build-ppc32/trunk-spe/gcc/cc1 -O3 -mspe
-quiet -ffast-math vect.i -o vect-O3.s
Breakpoint 3 at 0xfea3298: file exit.c, line 34.
Breakpoint 4 at 0xfea1af8: file abort.c, line 50.

Program received signal SIGSEGV, Segmentation fault.
gimple_build_call (fn=0x0, nargs=1) at
/home/meissner/fsf-src/trunk/gcc/gimple.c:319
319   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL || is_gimple_call_addr
(fn));
(gdb) print fn
$1 = (tree) 0x0
(gdb) list 
314 {
315   va_list ap;
316   gimple call;
317   unsigned i;
318
319   gcc_assert (TREE_CODE (fn) == FUNCTION_DECL || is_gimple_call_addr
(fn));
320
321   call = gimple_build_call_1 (fn, nargs);
322
323   va_start (ap, nargs);
(gdb) list -
304
305   return call;
306 }
307
308
309 /* Build a GIMPLE_CALL statement to function FN.  NARGS is the number
of
310arguments.  The ... are the arguments.  */
311
312 gimple
313 gimple_build_call (tree fn, unsigned nargs, ...)
(gdb) list -
294
295 gimple
296 gimple_build_call_vec (tree fn, VEC(tree, heap) *args)
297 {
298   unsigned i;
299   unsigned nargs = VEC_length (tree, args);
300   gimple call = gimple_build_call_1 (fn, nargs);
301
302   for (i = 0; i < nargs; i++)
303 gimple_call_set_arg (call, i, VEC_index (tree, args, i));
(gdb) up
#1  0x1081d2ec in vect_recog_pow_pattern (last_stmt=,
type_in=0xffdeec70, type_out=) at
/home/meissner/fsf-src/trunk/gcc/tree-vect-patterns.c:521
521   gimple stmt = gimple_build_call (newfn, 1, base);
(gdb) print newfn
$2 = (tree) 0x0
(gdb) list 
516 {
517   tree newfn = mathfn_built_in (TREE_TYPE (base), BUILT_IN_SQRT);
518   *type_in = get_vectype_for_scalar_type (TREE_TYPE (base));
519   if (*type_in)
520 {
521   gimple stmt = gimple_build_call (newfn, 1, base);
522   if (vectorizable_function (stmt, *type_in, *type_in)
523   != NULL_TREE)
524 {
525   var = vect_recog_temp_ssa_var (TREE_TYPE (base), stmt);
(gdb) list -
506
507   var = vect_recog_temp_ssa_var (TREE_TYPE (base), NULL);
508   stmt = gimple_build_assign_with_ops (MULT_EXPR, var, base, base);
509   SSA_NAME_DEF_STMT (var) = stmt;
510   return stmt;
511 }
512
513   /* Catch square root.  */
514   if (TREE_CODE (exp) == REAL_CST
515   && REAL_VALUES_EQUAL (TREE_REAL_CST (exp), dconsthalf))
(gdb) list 506
501&& tree_low_cst (exp, 0) == 2)
502   || (TREE_CODE (exp) == REAL_CST
503   && REAL_VALUES_EQUAL (TREE_REAL_CST (exp), dconst2)))
504 {
505   *type_in = TREE_TYPE (base);
506
507   var = vect_recog_temp_ssa_var (TREE_TYPE (base), NULL);
508   stmt = gimple_build_assign_with_ops (MULT_EXPR, var, base, base);
509   SSA_NAME_DEF_STMT (var) = stmt;
510   return stmt;
(gdb) 
511 }
512
513   /* Catch square root.  */
514   if (TREE_CODE (exp) == REAL_CST
515   && REAL_VALUES_EQUAL (TREE_REAL_CST (exp), dconsthalf))
516 {
517   tree newfn = mathfn_built_in (TREE_TYPE (base), BUILT_IN_SQRT);
518   *type_in = get_vectype_for_scalar_type (TREE_TYPE (base));
519   if (*type_in)
520 {

As you can see, the mathfn_built_in is returning NULL, but the code assumes it
is non-null.  I will upload a reduced test case as an attachment.


-- 
   Summary: Powerpc spe segfaults in vectorizing powf (a[i], 0.5f)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot g

[Bug bootstrap/40347] [4.5 Regression] i386-dariwn ICEs while building libgcc during stage2

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/40347] New: [4.5 Regression] i386-dariwn ICEs while building libgcc during stage2

[pinskia at gcc dot gnu dot org]

In file included from
/Users/apinski/src/local/gcc/libgcc/../gcc/unwind-dw2-fde-darwin.c:34:0:/Users/apinski/src/local/gcc/libgcc/../gcc/unwind-pe.h:
In function 'size_of_encoded_value':
/Users/apinski/src/local/gcc/libgcc/../gcc/unwind-pe.h:89:1: internal compiler
error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1770
Please submit a full bug report,with preprocessed source if appropriate.

Why it does not fail during stage1 is interesting for me.


-- 
   Summary: [4.5 Regression] i386-dariwn ICEs while building libgcc
during stage2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org


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

[Bug libfortran/40344] O32 libgfortran.so fails to link on IRIX 6.5

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-06-04 20:48 ---
> ld: FATAL   2  : Internal: at ../../ld/multigot.c lgot_local_got_offset()
>  seg_ndx exceeds per_seg_lgot_table

Sounds like a linker bug. What was actually the solution for
http://gcc.gnu.org/ml/gcc-bugs/2001-07/msg00225.html
(your email, that time for g77)


-- 


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[laurent at guerby dot net]

--- Comment #8 from laurent at guerby dot net  2009-06-04 20:31 ---
Last revision that did bootstrap on hppa-linux is 147972, starting with 147996
I get on compile farm gcc61:

/home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/
-B/n/61/guerby/install-trunk/hppa2.0-unknown-linux-gnu/bin/
-B/n/61/guerby/install-trunk/hppa2.0-unknown-linux-gnu/lib/ -isystem
/n/61/guerby/instal\
l-trunk/hppa2.0-unknown-linux-gnu/include -isystem
/n/61/guerby/install-trunk/hppa2.0-unknown-linux-gnu/sys-include-g -O2 -O2 
-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-pr\
ototypes -Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -DELF=1
-DLINUX=1 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I.
-I. -I../.././gcc -I../../../trunk/libgcc -I../../\
../trunk/libgcc/. -I../../../trunk/libgcc/../gcc
-I../../../trunk/libgcc/../include  -DHAVE_CC_TLS -o _bswapdi2.o -MT
_bswapdi2.o -MD -MP -MF _bswapdi2.dep -DL_bswapdi2 -c
../../../trunk/libgcc/../gcc/libgc\
c2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../trunk/libgcc/../gcc/libgcc2.c: In function '__bswapdi2':
../../../trunk/libgcc/../gcc/libgcc2.c:513: internal compiler error: in
dwarf2out_begin_epilogue, at dwarf2out.c:2689
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_bswapdi2.o] Error 1
make[3]: Leaving directory
`/home/guerby/build/hppa2.0-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

I don't know if it's related.

Might have been caused/triggered by dwarf2out change since it introduced the
point of the ICE (dwarf2out_begin_epilogue):

2009-05-29  Richard Henderson  
...
(dwarf2out_begin_epilogue): New.
...


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net,
   ||rth at gcc dot gnu dot org


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

[Bug ada/40346] Many Ada tests fail on Tru64 UNIX V4.0F/V5.1B

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-06-04 20:21 ---
Unfortunately the compile farm alpha machine is down (gcc30) and I haven't been
able to reach the administrator yet.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug ada/40346] Many Ada tests fail on Tru64 UNIX V4.0F/V5.1B

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2009-06-04 19:56 ---
Created an attachment (id=17951)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17951&action=view)
acats.log from alpha-dec-osf4.0f make check


-- 


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

[Bug ada/40346] New: Many Ada tests fail on Tru64 UNIX V4.0F/V5.1B

[ro at gcc dot gnu dot org]

Between between 20090511 (rev 147380) and 20090522 (rev 147798), many ACATS
and gnat.dg tests started failing on Tru64 UNIX V4.0F and V5.1B. acats.log
shows
various types of errors, but of 612 exceptions raised, 364 are
CONSTRAINT_ERROR:

I've attached the full acats.log for the details.

What's the best way to proceed here?


-- 
   Summary: Many Ada tests fail on Tru64 UNIX V4.0F/V5.1B
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug libgcj/40345] New: All libjava executions tests time out on Tru64 UNIX V4.0F

[ro at gcc dot gnu dot org]

Between 20090511 (rev 147380) and 20090522 (rev 147798), all libjava execution
tests started to time out on Tru64 UNIX V4.0F, as can be seen by comparing

http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00301.html

and

http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg01898.html

On the other hand, Tru64 UNIX V5.1B is not affected.  I've yet to determine the
root cause.


-- 
   Summary: All libjava executions tests time out on Tru64 UNIX
V4.0F
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: alpha-dec-osf4.0f
  GCC host triplet: alpha-dec-osf4.0f
GCC target triplet: alpha-dec-osf4.0f


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

[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare

[dje dot gcc at gmail dot com]

--- Comment #3 from dje dot gcc at gmail dot com  2009-06-04 19:41 ---
Subject: Re:  AIX PPC64 libgcc bootstrap miscompare

Only the rs6000 changes: r148138.  I am trying to narrow it down to
the rs6000.c change or the asm changes.


-- 


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

[Bug libfortran/40344] New: O32 libgfortran.so fails to link on IRIX 6.5

[ro at gcc dot gnu dot org]

Between 20090402 (rev 145459) and 20090522 (rev 147798), the o32 libgfortran.so
failed to link, breaking IRIX 6 bootstrap:

/vol/gccsrc/obj/gcc-4.5.0-20090522/6.5-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.5.0-20090522/6.5-gcc/./gcc/
-B/vol/gcc/mips-sgi-irix6.5/bin/ -B/vol/gcc/mips-sgi-irix6.5/lib/ -isystem
/vol/gcc/mips-sgi-irix6.5/include -isystem
/vol/gcc/mips-sgi-irix6.5/sys-include  -mabi=32 -shared  .libs/backtrace.o
.libs/compile_options.o .libs/convert_char.o .libs/environ.o .libs/error.o
.libs/fpu.o .libs/main.o .libs/memory.o .libs/pause.o .libs/stop.o
.libs/string.o .libs/select.o .libs/all_l1.o .libs/all_l2.o .libs/all_l4.o
.libs/all_l8.o .libs/all_l16.o .libs/any_l1.o .libs/any_l2.o .libs/any_l4.o
.libs/any_l8.o .libs/any_l16.o .libs/count_1_l.o .libs/count_2_l.o
.libs/count_4_l.o .libs/count_8_l.o .libs/count_16_l.o .libs/maxloc0_4_i1.o
.libs/maxloc0_8_i1.o .libs/maxloc0_16_i1.o .libs/maxloc0_4_i2.o
.libs/maxloc0_8_i2.o .libs/maxloc0_16_i2.o .libs/maxloc0_4_i4.o
.libs/maxloc0_8_i4.o .libs/maxloc0_16_i4.o .libs/maxloc0_4_i8.o
.libs/maxloc0_8_i8.o .libs/maxloc0_16_i8.o .libs/maxloc0_4_i16.o
.libs/maxloc0_8_i16.o .libs/maxloc0_16_i16.o .libs/maxloc0_4_r4.o
.libs/maxloc0_8_r4.o .libs/maxloc0_16_r4.o .libs/maxloc0_4_r8.o
.libs/maxloc0_8_r8.o .libs/maxloc0_16_r8.o .libs/maxloc0_4_r10.o
.libs/maxloc0_8_r10.o .libs/maxloc0_16_r10.o .libs/maxloc0_4_r16.o
.libs/maxloc0_8_r16.o .libs/maxloc0_16_r16.o .libs/maxloc1_4_i1.o
.libs/maxloc1_8_i1.o .libs/maxloc1_16_i1.o .libs/maxloc1_4_i2.o
.libs/maxloc1_8_i2.o .libs/maxloc1_16_i2.o .libs/maxloc1_4_i4.o
.libs/maxloc1_8_i4.o .libs/maxloc1_16_i4.o .libs/maxloc1_4_i8.o
.libs/maxloc1_8_i8.o .libs/maxloc1_16_i8.o .libs/maxloc1_4_i16.o
.libs/maxloc1_8_i16.o .libs/maxloc1_16_i16.o .libs/maxloc1_4_r4.o
.libs/maxloc1_8_r4.o .libs/maxloc1_16_r4.o .libs/maxloc1_4_r8.o
.libs/maxloc1_8_r8.o .libs/maxloc1_16_r8.o .libs/maxloc1_4_r10.o
.libs/maxloc1_8_r10.o .libs/maxloc1_16_r10.o .libs/maxloc1_4_r16.o
.libs/maxloc1_8_r16.o .libs/maxloc1_16_r16.o .libs/maxval_i1.o
.libs/maxval_i2.o .libs/maxval_i4.o .libs/maxval_i8.o .libs/maxval_i16.o
.libs/maxval_r4.o .libs/maxval_r8.o .libs/maxval_r10.o .libs/maxval_r16.o
.libs/minloc0_4_i1.o .libs/minloc0_8_i1.o .libs/minloc0_16_i1.o
.libs/minloc0_4_i2.o .libs/minloc0_8_i2.o .libs/minloc0_16_i2.o
.libs/minloc0_4_i4.o .libs/minloc0_8_i4.o .libs/minloc0_16_i4.o
.libs/minloc0_4_i8.o .libs/minloc0_8_i8.o .libs/minloc0_16_i8.o
.libs/minloc0_4_i16.o .libs/minloc0_8_i16.o .libs/minloc0_16_i16.o
.libs/minloc0_4_r4.o .libs/minloc0_8_r4.o .libs/minloc0_16_r4.o
.libs/minloc0_4_r8.o .libs/minloc0_8_r8.o .libs/minloc0_16_r8.o
.libs/minloc0_4_r10.o .libs/minloc0_8_r10.o .libs/minloc0_16_r10.o
.libs/minloc0_4_r16.o .libs/minloc0_8_r16.o .libs/minloc0_16_r16.o
.libs/minloc1_4_i1.o .libs/minloc1_8_i1.o .libs/minloc1_16_i1.o
.libs/minloc1_4_i2.o .libs/minloc1_8_i2.o .libs/minloc1_16_i2.o
.libs/minloc1_4_i4.o .libs/minloc1_8_i4.o .libs/minloc1_16_i4.o
.libs/minloc1_4_i8.o .libs/minloc1_8_i8.o .libs/minloc1_16_i8.o
.libs/minloc1_4_i16.o .libs/minloc1_8_i16.o .libs/minloc1_16_i16.o
.libs/minloc1_4_r4.o .libs/minloc1_8_r4.o .libs/minloc1_16_r4.o
.libs/minloc1_4_r8.o .libs/minloc1_8_r8.o .libs/minloc1_16_r8.o
.libs/minloc1_4_r10.o .libs/minloc1_8_r10.o .libs/minloc1_16_r10.o
.libs/minloc1_4_r16.o .libs/minloc1_8_r16.o .libs/minloc1_16_r16.o
.libs/minval_i1.o .libs/minval_i2.o .libs/minval_i4.o .libs/minval_i8.o
.libs/minval_i16.o .libs/minval_r4.o .libs/minval_r8.o .libs/minval_r10.o
.libs/minval_r16.o .libs/product_i1.o .libs/product_i2.o .libs/product_i4.o
.libs/product_i8.o .libs/product_i16.o .libs/product_r4.o .libs/product_r8.o
.libs/product_r10.o .libs/product_r16.o .libs/product_c4.o .libs/product_c8.o
.libs/product_c10.o .libs/product_c16.o .libs/sum_i1.o .libs/sum_i2.o
.libs/sum_i4.o .libs/sum_i8.o .libs/sum_i16.o .libs/sum_r4.o .libs/sum_r8.o
.libs/sum_r10.o .libs/sum_r16.o .libs/sum_c4.o .libs/sum_c8.o .libs/sum_c10.o
.libs/sum_c16.o .libs/matmul_i1.o .libs/matmul_i2.o .libs/matmul_i4.o
.libs/matmul_i8.o .libs/matmul_i16.o .libs/matmul_r4.o .libs/matmul_r8.o
.libs/matmul_r10.o .libs/matmul_r16.o .libs/matmul_c4.o .libs/matmul_c8.o
.libs/matmul_c10.o .libs/matmul_c16.o .libs/matmul_l4.o .libs/matmul_l8.o
.libs/matmul_l16.o .libs/transpose_i4.o .libs/transpose_i8.o
.libs/transpose_i16.o .libs/transpose_r4.o .libs/transpose_r8.o
.libs/transpose_r10.o .libs/transpose_r16.o .libs/transpose_c4.o
.libs/transpose_c8.o .libs/transpose_c10.o .libs/transpose_c16.o
.libs/shape_i4.o .libs/shape_i8.o .libs/shape_i16.o .libs/eoshift1_4.o
.libs/eoshift1_8.o .libs/eoshift1_16.o .libs/eoshift3_4.o .libs/eoshift3_8.o
.libs/eoshift3_16.o .libs/cshift1_4.o .libs/cshift1_8.o .libs/cshift1_16.o
.libs/reshape_i4.o .libs/reshape_i8.o .libs/reshape_i16.o .libs/reshape_r4.o
.libs/reshape_r8.o .libs/reshape_r10.o .libs/reshape_r16.o .libs/reshape_c4.o
.libs/reshape_c8.o .libs/reshape_c10.o .libs/reshape_c16.o .libs/in_pack_i1.o
.libs/in_pack_i2.o .libs/in_pack_i4.o .libs/in_pack_i

[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-06-04 19:32 ---
r148138 or r148137?  What are the exact differences?  Any differences between
generated assembly between 2nd and 3rd stage for those object files?


-- 


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

[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare

[dje at gcc dot gnu dot org]

--- Comment #1 from dje at gcc dot gnu dot org  2009-06-04 19:27 ---
confirmed.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2009-06-04 19:27:46
   date||


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

[Bug bootstrap/40343] New: AIX PPC64 libgcc bootstrap miscompare

[dje at gcc dot gnu dot org]

GCC bootstrap on AIX 5.3 miscompares all ppc64/libgcc files.  This appears to
be caused by Jakub's rs6000 CFI patch.


-- 
   Summary: AIX PPC64 libgcc bootstrap miscompare
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu 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=40343

[Bug c++/40342] New: [4.4/4.5 Regression] ambiguous overload not diagnosed

[jsm28 at gcc dot gnu dot org]

The following invalid C++ code is not diagnosed with -pedantic
by 4.4 or 4.5.

template  int f(T1 *, const T2 *) { return 0; }
template  int f(const T1 *, T2 *) { return 0; }

int (*p)(const int *, const int *) = f;

4.3 correctly diagnoses it:

t.C:4: error: converting overloaded function 'f' to type 'int (*)(const int*,
const int*)' is ambiguous
t.C:1: error: candidates are: int f(T1*, const T2*) [with T1 = const int, T2 =
int]
t.C:2: error: int f(const T1*, T2*) [with T1 = int, T2 = const
int]


-- 
   Summary: [4.4/4.5 Regression] ambiguous overload not diagnosed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[dje at gcc dot gnu dot org]

--- Comment #7 from dje at gcc dot gnu dot org  2009-06-04 19:25 ---
Okay, I think these are separate bugs.  The HP-PA error may be due to
Alexandre's change.


-- 


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

[Bug c++/40341] New: [4.4/4.5 Regression] invalid use of member in static member function not diagnosed

[jsm28 at gcc dot gnu dot org]

The following invalid C++ code is not diagnosed with -pedantic
by 4.4 or 4.5.

class c {
public:
  static int f ();
  int i;
};

int
c::f ()
{
  return sizeof (i);
}

4.3 correctly diagnoses it:

t.C: In static member function 'static int c::f()':
t.C:4: error: invalid use of member 'c::i' in static member function
t.C:10: error: from this location


-- 
   Summary: [4.4/4.5 Regression] invalid use of member in static
member function not diagnosed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug fortran/39893] [4.4] gfortran ICE on invalid program

[kargl at gcc dot gnu dot org]

--- Comment #10 from kargl at gcc dot gnu dot org  2009-06-04 19:11 ---
Fixed on 4.4.x and trunk. Closing.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/24929] long long shift/mask operations should be better optimized

[aldot at gcc dot gnu dot org]

--- Comment #7 from aldot at gcc dot gnu dot org  2009-06-04 18:18 ---
(In reply to comment #5)

> movzbl  18(%esp), %eax
> 
> could be used in this particular case.

4.3.3 onward seem to do that. Fixed?

$ for i in 4.2 4.3 4.4 4.5.orig-HEAD;do printf "### %s\n" $(gcc-$i
-dumpversion) ; gcc-$i -march=i386 -O2 -S -o- pr24929.c -fomit-frame-pointer |
awk 'BEGIN{yep=0;}/^f:/{yep=1;}/^\./{yep=0;}{if (yep){print $0}}';done
### 4.2.4
f:
pushl   %edi
pushl   %esi
pushl   %ebx
movl16(%esp), %esi
movl20(%esp), %edi
movl24(%esp), %ecx
movl28(%esp), %ebx
movl%ebx, %ecx
xorl%ebx, %ebx
shrl$16, %ecx
movzbl  %cl,%eax
xorl%edx, %edx
shldl   $8, %esi, %edi
sall$8, %esi
orl %esi, %eax
orl %edi, %edx
popl%ebx
popl%esi
popl%edi
ret
.size   f, .-f
.p2align 2,,3
### 4.3.3
f:
movl4(%esp), %edx
movl8(%esp), %ecx
shldl   $8, %edx, %ecx
sall$8, %edx
movzbl  18(%esp), %eax
orl %edx, %eax
movl%ecx, %edx
ret
.size   f, .-f
.p2align 2,,3
### 4.4.0
f:
movl4(%esp), %edx
movl8(%esp), %ecx
shldl   $8, %edx, %ecx
sall$8, %edx
movzbl  18(%esp), %eax
orl %edx, %eax
movl%ecx, %edx
ret
.size   f, .-f
.p2align 2,,3
### 4.5.0
f:
movl4(%esp), %edx
movl8(%esp), %ecx
shldl   $8, %edx, %ecx
sall$8, %edx
movzbl  18(%esp), %eax
orl %edx, %eax
movl%ecx, %edx
ret
.size   f, .-f
.p2align 2,,3


-- 


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

[Bug middle-end/40340] [4.4/4.5 Regression] Fortification warning no longer emitted in inlines

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-06-04 17:55 ---
4.3 reported (with -O2 -Wall):
In function 'memset',
inlined from 'main' at w.c:6:
w.h:11: warning: call to __builtin___memset_chk will always overflow
destination buffer
In function 'memset',
inlined from 'main' at w.c:14:
w.h:11: warning: call to __builtin___memset_chk will always overflow
destination buffer
4.4 reports:
In file included from w.c:1:
w.h: In function 'main':
w.h:11: warning: call to __builtin___memset_chk will always overflow
destination buffer
and with -O2 -Wall -Wsystem-headers:
In file included from w.c:1:
w.h: In function 'main':
w.h:11: warning: call to __builtin___memset_chk will always overflow
destination buffer
w.h:11: warning: call to __builtin___memset_chk will always overflow
destination buffer


-- 


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

[Bug middle-end/40340] [4.4/4.5 Regression] Fortification warning no longer emitted in inlines

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-06-04 17:44 ---
r138031 broke it altogether (no warnings were emitted at all), PR39272
made at least one of the two warnings reappear.


-- 


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

[Bug middle-end/40340] [4.4/4.5 Regression] Fortification warning no longer emitted in inlines

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


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

[Bug middle-end/40340] New: [4.4/4.5 Regression] Fortification warning no longer emitted in inlines

[jakub at gcc dot gnu dot org]

w.h:
#pragma GCC system_header
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *__s, int __c, size_t __n)
  __attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1)));
extern __inline __attribute__ ((__always_inline__))
__attribute__ ((__artificial__))
void *
__attribute__ ((__nothrow__))
memset (void *__dest, int __ch, size_t __len)
{
  return __builtin___memset_chk (__dest, __ch, __len, __builtin_object_size
(__dest, 0));
}
w.c:
#include "w.h"

static inline void
test (char *p)
{
  memset (p, 0, 6);
}

int
main (void)
{
  char buf[4];
  test (buf);
  memset (buf, 0, 6);
  return 0;
}

gcc 4.3 used to emit 2 warnings, gcc 4.4 and trunk only one (but both 4.3 and
4.4+ emit two __memset_chk calls that will always __chk_fail at runtime).


-- 
   Summary: [4.4/4.5 Regression] Fortification warning no longer
emitted in inlines
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[dje at gcc dot gnu dot org]

--- Comment #6 from dje at gcc dot gnu dot org  2009-06-04 17:17 ---
Alexandre committed the change in revision 148080 and I successfully
bootstrapped AIX yesterday with revision 148105.


-- 


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[dje at gcc dot gnu dot org]

--- Comment #5 from dje at gcc dot gnu dot org  2009-06-04 17:11 ---
Jakub mentioned that Alexandre patch added comparison of libgcc, which may not
have been compared before.  But I successfully bootstrapped with Alexandre's
patch the previous day.


-- 


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

[Bug fortran/39893] [4.4] gfortran ICE on invalid program

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2009-06-04 17:02 ---
Subject: Bug 39893

Author: kargl
Date: Thu Jun  4 17:01:45 2009
New Revision: 148176

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148176
Log:
Merged r146816 from trunk into 4.4 branch.  Specifically,

2009-04-26  Steven G. Kargl  

PR fortran/39893
* gfortran.dg/assumed_charlen_dummy.f90: New Test.


2009-04-26  Steven G. Kargl  

PR fortran/39893
fortran/data.c (gfc_assign_data_value): If the lvalue is an
assumed character length entity in a data statement, then
return FAILURE to prevent segmentation fault.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/assumed_charlen_dummy.f90
  - copied unchanged from r146816,
trunk/gcc/testsuite/gfortran.dg/assumed_charlen_dummy.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/data.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[sje at cup dot hp dot com]

--- Comment #4 from sje at cup dot hp dot com  2009-06-04 16:42 ---
I am not sure I understand the what the pointer in comment #3 has to do with
this failure.  I think the issue is get_file_function_name in tree.c.  If
first_global_object_name is false and targetm.have_ctors_dtors is false then
we run into code that has the comment:

 /* Otherwise, the name must be unique across the entire link.
 We don't have anything that we know to be unique to this translation
 unit, so use what we do have and throw in some randomness.  */

I think this is what we are running into.


-- 


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

[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-06-04 16:30 ---
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01800.html

Reading that makes me understand why libgcc was not being checked before.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|bootstrap comparision fails |[4.5 Regression] bootstrap
   |on 32 bit PA when comparing |comparision fails on 32 bit
   |libgcc objects  |PA when comparing libgcc
   ||objects
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/40338] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[dje at gcc dot gnu dot org]

--- Comment #2 from dje at gcc dot gnu dot org  2009-06-04 16:18 ---
AIX started miscomparing in libgcc as well.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed|-00-00 00:00:00 |2009-06-04 16:18:21
   date||


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

[Bug bootstrap/40338] bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[sje at cup dot hp dot com]

--- Comment #1 from sje at cup dot hp dot com  2009-06-04 15:52 ---
Compiling the following program with -O2 -fPIC -g -fexceptions will reproduce
the problem.  I get a global variable created with a different name using
gcc/cc1 and prev-gcc/cc1.

void splat (void) { return; }
static void (*bar) (void) = *splat;
void foo (void) { bar (); }


-- 


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

[Bug c/40339] gcc: error trying to exec 'as': execvp: No such file or directory

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-06-04 15:47 
---
Properly install as. This is definitely not a GCC issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/34419] Weirdness with numeric_limits in special functions

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-06-04 15:46 
---
Any news on this?


-- 


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

[Bug c/40339] gcc: error trying to exec 'as': execvp: No such file or directory

[dsandler at paychex dot com]

--- Comment #2 from dsandler at paychex dot com  2009-06-04 15:28 ---
(In reply to comment #1)
> the gcc driver program is not finding as.

What is the appropriate course of action?


-- 


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

[Bug c/40339] gcc: error trying to exec 'as': execvp: No such file or directory

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-04 15:25 ---
the gcc driver program is not finding as.


-- 


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

[Bug c/40339] New: gcc: error trying to exec 'as': execvp: No such file or directory

[dsandler at paychex dot com]

When compiling a program with gcc, we are receiving the following error...

gcc: error trying to exec 'as': execvp: No such file or directory

We checked that 'as' exists, and it does.  Please advise.


-- 
   Summary: gcc: error trying to exec 'as': execvp: No such file or
directory
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dsandler at paychex dot com


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

[Bug libstdc++/40297] [C++0x] debug mode vs atomics

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-06-04 15:16 
---
Let's CC Benjamin...


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug bootstrap/40338] New: bootstrap comparision fails on 32 bit PA when comparing libgcc objects

[sje at cup dot hp dot com]

Starting with r148080 we compare libgcc objects in addition to gcc objects
during bootstrap.  The 32 bit PA bootstrap build is failing because the libgcc
objects are different.  It looks like it is the debug section that has
differences but I haven't got any further then that in my analysis.


-- 
   Summary: bootstrap comparision fails on 32 bit PA when comparing
libgcc objects
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
  GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11


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

[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2009-06-04 15:03 ---
Added testcase and closing the bug


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/40337] New: PPLLIBS flags do not include -lm

[fierevere at ya dot ru]

When libgmp, libgmpxx, mpfr, ppl and cloog are built as static (.a) libraries
-lm is needed for PPLLIBS , but it isnt added
therefore build fails unless -lm is added

i586-sylvia-linux-ar rc libbackend.a insn-attrtab.o insn-automata.o insn-emit.o
insn-extract.o insn-modes.o insn-opinit.o insn-output.o insn-peep.o
insn-preds.o insn-recog.o ggc-page.o alias.o alloc-pool.o auto-inc-dec.o
bb-reorder.o bitmap.o bt-load.o builtins.o caller-save.o calls.o cfg.o
cfganal.o cfgbuild.o cfgcleanup.o cfgexpand.o cfghooks.o cfglayout.o cfgloop.o
cfgloopanal.o cfgloopmanip.o cfgrtl.o combine.o combine-stack-adj.o convert.o
coverage.o cse.o cselib.o dbxout.o dbgcnt.o dce.o ddg.o debug.o df-byte-scan.o
df-core.o df-problems.o df-scan.o dfp.o diagnostic.o dojump.o dominance.o
domwalk.o double-int.o dse.o dwarf2asm.o dwarf2out.o ebitmap.o emit-rtl.o
et-forest.o except.o explow.o expmed.o expr.o final.o fixed-value.o
fold-const.o function.o fwprop.o gcse.o genrtl.o ggc-common.o gimple.o
gimple-iterator.o gimple-low.o gimple-pretty-print.o gimplify.o graph.o
graphds.o graphite.o gtype-desc.o haifa-sched.o hooks.o ifcvt.o init-regs.o
integrate.o intl.o ira.o ira-build.o ira-costs.o ira-conflicts.o ira-color.o
ira-emit.o ira-lives.o jump.o lambda-code.o lambda-mat.o lambda-trans.o
langhooks.o lcm.o lists.o loop-doloop.o loop-init.o loop-invariant.o loop-iv.o
loop-unroll.o loop-unswitch.o lower-subreg.o mcf.o mode-switching.o
modulo-sched.o omega.o omp-low.o optabs.o options.o opts-common.o opts.o
params.o passes.o pointer-set.o postreload-gcse.o postreload.o predict.o
pretty-print.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o
reginfo.o regmove.o regrename.o regstat.o reload.o reload1.o reorg.o resource.o
rtl-error.o rtl-factoring.o rtl.o rtlanal.o rtlhooks.o sbitmap.o sched-deps.o
sched-ebb.o sched-rgn.o sched-vis.o sdbout.o see.o sel-sched-ir.o
sel-sched-dump.o sel-sched.o simplify-rtx.o sparseset.o sreal.o stack-ptr-mod.o
statistics.o stmt.o stor-layout.o stringpool.o targhooks.o timevar.o toplev.o
tracer.o tree-affine.o tree-call-cdce.o tree-cfg.o tree-cfgcleanup.o
tree-chrec.o tree-complex.o tree-data-ref.o tree-dfa.o tree-dump.o tree-eh.o
tree-if-conv.o tree-into-ssa.o tree-iterator.o tree-loop-distribution.o
tree-loop-linear.o tree-nested.o tree-nrv.o tree-object-size.o tree-optimize.o
tree-outof-ssa.o tree-parloops.o tree-phinodes.o tree-predcom.o
tree-pretty-print.o tree-profile.o tree-scalar-evolution.o tree-sra.o
tree-switch-conversion.o tree-ssa-address.o tree-ssa-alias.o tree-ssa-ccp.o
tree-ssa-coalesce.o tree-ssa-copy.o tree-ssa-copyrename.o tree-ssa-dce.o
tree-ssa-dom.o tree-ssa-dse.o tree-ssa-forwprop.o tree-ssa-ifcombine.o
tree-ssa-live.o tree-ssa-loop-ch.o tree-ssa-loop-im.o tree-ssa-loop-ivcanon.o
tree-ssa-loop-ivopts.o tree-ssa-loop-manip.o tree-ssa-loop-niter.o
tree-ssa-loop-prefetch.o tree-ssa-loop-unswitch.o tree-ssa-loop.o
tree-ssa-math-opts.o tree-ssa-operands.o tree-ssa-phiopt.o tree-ssa-phiprop.o
tree-ssa-pre.o tree-ssa-propagate.o tree-ssa-reassoc.o tree-ssa-sccvn.o
tree-ssa-sink.o tree-ssa-structalias.o tree-ssa-ter.o tree-ssa-threadedge.o
tree-ssa-threadupdate.o tree-ssa-uncprop.o tree-ssa.o tree-ssanames.o
tree-stdarg.o tree-tailcall.o tree-vect-analyze.o tree-vect-generic.o
tree-vect-patterns.o tree-vect-transform.o tree-vectorizer.o tree-vrp.o tree.o
value-prof.o var-tracking.o varasm.o varray.o vec.o version.o vmsdbgout.o web.o
xcoffout.o i386.o  host-linux.o cgraph.o cgraphbuild.o cgraphunit.o
cppdefault.o incpath.o ipa-cp.o ipa-inline.o ipa-prop.o ipa-pure-const.o
ipa-reference.o ipa-struct-reorg.o ipa-type-escape.o ipa-utils.o ipa.o
matrix-reorg.o prefix.o tree-inline.o tree-nomudflap.o varpool.o
i586-sylvia-linux-ranlib  libbackend.a
/home/sylvia/tmp/gcc-4.4.1-20090604/build/./prev-gcc/xgcc
-B/home/sylvia/tmp/gcc-4.4.1-20090604/build/./prev-gcc/
-B/usr/local/gcc-4.4/i586-sylvia-linux/bin/  -pipe -fomit-frame-pointer -g0
-mmmx -msse2 -mfpmath=sse -march=pentium4 -ftree-vectorize -floop-interchange
-floop-block -floop-strip-mine -ftree-loop-distribution -O3
-fomit-frame-pointer -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1-dummy
c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o \
  main.o  libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a -L/var/tmp/lib -lcloog -L/var/tmp/lib -lppl_c
-lppl -lgmpxx /usr/local/gcc-4.4/lib/libstdc++.a -L/var/tmp/lib -L/var/tmp/lib
-lmpfr -lgmp
/var/tmp/lib/libppl.a(MIP_Problem.o): In

[Bug middle-end/40093] Optimization by functios reordering.

[hubicka at gcc dot gnu dot org]

--- Comment #6 from hubicka at gcc dot gnu dot org  2009-06-04 14:50 ---
There is simple algoritm reordering functions so calls more commonly leads to
following function in memory. (just order calls by frequency and concatenate
them into sequences and then order sequences to promote forward calls).

The problem here is that this conflicts with the optimizations propagatng
information top-down across callgraph (like stack alignment).

So I can write easilly pass that will give desired order, but I don't want
production of RTL bodies to happen this order and thus we need some assembler
support for this to order stuff properly (gas has subsections that would do
fine). I was just bit lazy to implement this so far.


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-04 14:50:20
   date||


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

[Bug c++/2316] g++ fails to overload on language linkage

[paolo dot carlini at oracle dot com]

--- Comment #17 from paolo dot carlini at oracle dot com  2009-06-04 14:49 
---
Interestingly, the only current compiler I tried which actually accepts this
(SunStudio) warns:

"2316.C", line 8: Warning: function int(int(*)()) overloads extern "C"
int(extern "C" int(*)()) because of different language linkages.


-- 


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

[Bug c++/40336] Language linkage should be part of the function type

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-04 14:36 ---


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


-- 

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

[Bug c++/2316] g++ fails to overload on language linkage

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2009-06-04 14:36 
---
*** Bug 40336 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||schaub-johannes at web dot
   ||de


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

[Bug c++/40336] New: Language linkage should be part of the function type

[schaub-johannes at web dot de]

Hello all, i discovered that the following code doesn't compile, why i expected
that it compiles fine

template struct F { typedef int type; };
template struct F { };

typedef void(*fp0)();
extern "C" typedef void (*fp1)();

int main() { F::type i; }

// diagnostic:
main.cpp: In function 'int main()':
main.cpp:7: error: 'type' is not a member of 'F'
main.cpp:7: error: expected ';' before 'i'

The problem seems to be that it thinks the function pointer types are the same
- but C++ is very clear on that they are different types.


-- 
   Summary: Language linkage should be part of the function type
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/31537] duplicate weakref emitted with IMA

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-06-04 13:41 
---
We are getting LTO (and maybe LIPO), no need for -combine being fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenther at suse dot de]

--- Comment #12 from rguenther at suse dot de  2009-06-04 13:39 ---
Subject: Re:  Fortran does not set TYPE_CANONICAL
 properly

On Thu, 4 Jun 2009, burnus at gcc dot gnu dot org wrote:

> --- Comment #11 from burnus at gcc dot gnu dot org  2009-06-04 12:51 
> ---
> (In reply to comment #10)
> > That hack is already gone ... ;)
> The truck hack yes, the question is whether one can also do something about 
> the
> following? Or is this a wider problem?
> 
>   /* ???  Array types are not properly unified in all cases as we have
>  spurious changes in the index types for example.  Removing this
>  causes all sorts of problems with the Fortran frontend.  */
>   if (TREE_CODE (type1) == ARRAY_TYPE
>   && TREE_CODE (type2) == ARRAY_TYPE)
> return -1;

It's a wider problem.  It's char[1:1] vs. char where the FE is
very inconsistent, also char[1:] vs. char[1:1], etc.

Probably not worth fixing.  Maybe after everything else is ...

Richard.


-- 


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

[Bug c/31537] duplicate weakref emitted with IMA

[aldot at gcc dot gnu dot org]

--- Comment #12 from aldot at gcc dot gnu dot org  2009-06-04 13:24 ---
Well, without it fixed it's impossible to build libgfortran (and other apps)
with combine, which would be a very nice thing to have.
The sample patch above exposed no regressions fwiw.


-- 


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

[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

[ebotcazou at gcc dot gnu dot org]

--- Comment #36 from ebotcazou at gcc dot gnu dot org  2009-06-04 13:24 
---
> This bug is marked as one of the "GCC 4.5 pending patches" PRs. Why?  I see no
> pending patch...?

They are at AdaCore for the time being.  Will need to submit them...


-- 


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

[Bug middle-end/20548] [4.3/4.4/4.5 regression] ACATS c52103x c52104x c52104y segfault

[steven at gcc dot gnu dot org]

--- Comment #35 from steven at gcc dot gnu dot org  2009-06-04 12:58 ---
This bug is marked as one of the "GCC 4.5 pending patches" PRs. Why?  I see no
pending patch...?


-- 


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

[Bug c/31537] duplicate weakref emitted with IMA

[steven at gcc dot gnu dot org]

--- Comment #11 from steven at gcc dot gnu dot org  2009-06-04 12:55 ---
Oh, the temptation to close this as WONTFIX  Objections?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug libfortran/32784] [win32] Using 'CONOUT$', 'CONIN$', or 'CONERR$' as assigned file generates Fortran runtime error: Bad file descriptor

[steven at gcc dot gnu dot org]

--- Comment #32 from steven at gcc dot gnu dot org  2009-06-04 12:54 ---
Jerry, was the patch submitted already?


-- 


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

[Bug target/38091] [Patch] H8SX: Bit instructions enhancement

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-06-04 12:53 ---
This is one of the "GCC 4.5 pending patches". Since we are in stage 1, now is a
good time to submit this patch.


-- 


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

[Bug rtl-optimization/38373] 32-bit Vortex degradation on PPC due to bad RTL aliasing

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-06-04 12:52 ---
This is one of the "GCC 4.5 pending patches". Now would be a good time to do
something with this patch -- like, submitting it.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[burnus at gcc dot gnu dot org]

--- Comment #11 from burnus at gcc dot gnu dot org  2009-06-04 12:51 ---
(In reply to comment #10)
> That hack is already gone ... ;)
The truck hack yes, the question is whether one can also do something about the
following? Or is this a wider problem?

  /* ???  Array types are not properly unified in all cases as we have
 spurious changes in the index types for example.  Removing this
 causes all sorts of problems with the Fortran frontend.  */
  if (TREE_CODE (type1) == ARRAY_TYPE
  && TREE_CODE (type2) == ARRAY_TYPE)
return -1;


-- 


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-06-04 12:41 
---
Subject: Bug 39371

Author: rguenth
Date: Thu Jun  4 12:41:31 2009
New Revision: 148167

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148167
Log:
2009-06-04  Richard Guenther  

PR c++/39371
* g++.dg/torture/pr40335.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr40335.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/19599] function pointer prevents tail-call optimization on arm

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-06-04 12:39 ---
Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00373.html


-- 


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-06-04 12:38 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|3.3.6   |3.3.6 4.3.3
  Known to work|2.95.4 4.4.0|2.95.4 4.3.4 4.4.0
 Resolution||FIXED


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-06-04 12:38 
---
Subject: Bug 39371

Author: rguenth
Date: Thu Jun  4 12:37:48 2009
New Revision: 148166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148166
Log:
2009-06-04  Richard Guenther  

PR c++/39371
* g++.dg/torture/pr40335.C: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr40335.C
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-06-04 12:35 ---
Subject: Bug 39371

Author: rguenth
Date: Thu Jun  4 12:35:25 2009
New Revision: 148165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148165
Log:
2009-06-04  Richard Guenther  

Backport from mainline
2009-03-09  Jakub Jelinek  

PR c++/39371
* semantics.c (finish_switch_cond): Don't call get_unwidened.
* decl.c (finish_case_label): Pass SWITCH_STMT_TYPE as 3rd argument
instead of TREE_TYPE (cond).

* g++.dg/opt/switch2.C: Add -w to dg-options.
* g++.dg/warn/Wswitch-1.C: Adjust expected warnings.
* g++.dg/warn/switch1.C: New test.
* g++.dg/other/switch3.C: New test.
* g++.dg/torture/pr40335.C: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/switch3.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr40335.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/switch1.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/decl.c
branches/gcc-4_3-branch/gcc/cp/semantics.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/switch2.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/warn/Wswitch-1.C


-- 


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenther at suse dot de]

--- Comment #10 from rguenther at suse dot de  2009-06-04 11:49 ---
Subject: Re:  Fortran does not set TYPE_CANONICAL
 properly

On Thu, 4 Jun 2009, burnus at gcc dot gnu dot org wrote:

> --- Comment #9 from burnus at gcc dot gnu dot org  2009-06-04 11:47 
> ---
> Cf. also thread at http://gcc.gnu.org/ml/fortran/2009-06/msg00057.html
> 
> (Maybe if -fwhole-file is the permanent default and this problem is fixed, the
> hack at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html can be removed
> ...)

That hack is already gone ... ;)

Richard.


-- 


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[burnus at gcc dot gnu dot org]

--- Comment #9 from burnus at gcc dot gnu dot org  2009-06-04 11:47 ---
Cf. also thread at http://gcc.gnu.org/ml/fortran/2009-06/msg00057.html

(Maybe if -fwhole-file is the permanent default and this problem is fixed, the
hack at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00937.html can be removed
...)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug libfortran/40334] [4.4/4.5 Regression] changed BACKSPACE behaviour at end of file.

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|[4.4, 4.5 Regression]   |[4.4/4.5 Regression] changed
   |changed BACKSPACE behaviour |BACKSPACE behaviour at end
   |at end of file. |of file.


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

[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug c++/36695] [4.3 Regression] Value-initialization of reference type is allowed.

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-06-04 11:35 
---
Not worth fixing on the 4.3 branch.  Fixed for 4.4.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.4   |4.4.0


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

[Bug c++/34269] [4.3 regression] Incomplete __decltype/__typeof expressions accepted

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-06-04 11:34 ---
Not worth fixing on the 4.3 branch.  Fixed for 4.4.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.3.4   |4.4.0


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-06-04 11:21 ---
I'm testing a backport.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu dot org|rguenth at gcc dot gnu dot
   ||org
   Keywords||wrong-code


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-06-04 11:16 ---
Oh, 4.4 and 4.5 already work.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|3.3.6 4.3.3 4.4.0 4.5.0 |3.3.6 4.3.3
 Resolution||DUPLICATE


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

[Bug c++/39371] [4.3 Regression] Incorrectly rejects switch((unsigned int)boolvar)

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-06-04 11:16 ---
*** Bug 40335 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||shenrfen at gmail dot com


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-06-04 10:55 ---
The whole-file patches now expose this problem.

! { dg-do run }
! Test the fix for PR34438, in which default initializers
! forced the derived type to be static; ie. initialized once
! during the lifetime of the programme.  Instead, they should
! be initialized each time they come into scope.
!
module demo
   type myint
 integer :: bar = 42
   end type myint
end module demo

! ...who came up with this one too.
subroutine func (retval2)
  use demo
  type(myint) :: foo2 = myint (77)
  type(myint) :: retval2
  retval2 = foo2
  foo2%bar = 999
end subroutine func

subroutine other
  use demo
  interface
subroutine func(rv2)
  use demo
  type(myint) :: rv2
   end subroutine func
  end interface
  type(myint) :: val2
  call func (val2)
  if ((val2%bar .ne. 77_4)) call abort ()

end subroutine other

! Run both tests.
  call other
 end
! { dg-final { cleanup-modules "demo M1" } }


with -O2 -fwhole-file we inline func into other and get

other ()
{
  static struct myint foo2D.1539 = {.barD.1534=77};
  static struct myint foo2D.1539 = {.barD.1534=77};
  struct myint & retval2D.1572;
  struct myint val2D.1544;
  integer(kind=4)D.8 D.1547;

:
  val2D.1544.barD.1542 = 42;
  retval2D.1572_6 = (struct myint &) &val2D.1544;
  *retval2D.1572_6 = foo2D.1539;
  foo2D.1539.barD.1534 = 999;
  D.1547_1 = val2D.1544.barD.1542;
  if (D.1547_1 != 77)

which looks good sofar.  But the store *retval2D.1572_6 = foo2D.1539 is
through a different struct myint than the load from val2D.1544.barD.1542
so we optimize the load to 42 -- the only visible aliasing store.

 
unit size 
align 32 symtab 0 alias set 2 canonical type 0x77fd1180
fields 
SI file t.f90 line 23 col 0 size 
unit size 
align 32 offset_align 128
offset 
bit offset  context
>
pointer_to_this  chain >
addressable used SI file t.f90 line 30 col 0 size  unit size 
align 32 context >

and

 
unit size 
align 32 symtab 0 alias set 4 canonical type 0x77fced80
fields 
SI file t.f90 line 15 col 0 size 
unit size 
align 32 offset_align 128
offset 
bit offset  context
>
reference_to_this  chain >

arg 0 
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x77fcef00>
visited var def_stmt retval2_6 =
(struct myint &) &val2;

version 6
ptr-info 0x77f9ac10>>

so the Frontend misses proper type unification.


-- 


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

[Bug ada/40288] undefined reference to `__gnat_begin_handler' for -mabi=32 on mips64el-linux

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-06-04 10:48 ---
This was indeed a trailing space in my local change, now fixed:

http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00280.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-06-04 10:45 
---
Note that 3_4-branch, 4_0-branch, 4_1-branch, 4_2-branch are all closed.


-- 


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[shenrfen at gmail dot com]

--- Comment #5 from shenrfen at gmail dot com  2009-06-04 10:24 ---
Thanks very much.
Waiting for your patch. the patch of gcc3.3.5 is also expected if you have
enough time to do it. it should be similar with gcc4.**
Thanks agian. 


-- 


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-06-04 10:05 ---
GCC 3.3 is very old and no longer maintained.

> g++-4.4 -o t t.C
t.C: In function ‘int main()’:
t.C:9: warning: case label value exceeds maximum value for type

which seems indeed bogus (but hints at what happens).

The C frontend correctly dispatches to the default case but still warns:

> gcc-4.4 -o t t.c -Wall
t.c: In function ‘main’:
t.c:9: warning: case label value exceeds maximum value for type
t.c:16: warning: control reaches end of non-void function


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|x86 |
   GCC host triplet|x86 |
 GCC target triplet|x86 |
   Keywords||diagnostic, wrong-code
  Known to fail||3.3.6 4.3.3 4.4.0 4.5.0
  Known to work||2.95.4
   Last reconfirmed|-00-00 00:00:00 |2009-06-04 10:05:43
   date||
Version|unknown |4.4.0


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[shenrfen at gmail dot com]

--- Comment #3 from shenrfen at gmail dot com  2009-06-04 09:47 ---
I have debug the C++ front-end of gcc3.3.5.
In function finish_switch_cond:

  if (cond != error_mark_node)
{
  cond = default_conversion (cond);
  cond = fold (build1 (CLEANUP_POINT_EXPR, TREE_TYPE (cond), cond));
}

SRF: the type of cond is "int"

  if (cond != error_mark_node)
{
  index = get_unwidened (cond, NULL_TREE);
  /* We can't strip a conversion from a signed type to an unsigned,
 because if we did, int_fits_type_p would do the wrong thing
 when checking case values for being in range,
 and it's too hard to do the right thing.  */
  if (TREE_UNSIGNED (TREE_TYPE (cond))
  == TREE_UNSIGNED (TREE_TYPE (index)))
cond = index;
}

SRF: bug the type of cond is back to "signed char" here.
 Maybe there is something error in function "get_unwidened" 


-- 


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

[Bug c/39843] -funsigned-bitfields discards "aligned" attribute

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-04 09:22 ---
(In reply to comment #0)
> % gcc-snapshot -funsigned-bitfields testsuite/gcc.dg/bitfld-3.c
> % ./a.out
> Abort

Confirmed with gcc-4.4-20090602 and gcc-4.3-20090531 on i686-pc-linux-gnu. I
haven't been able to reproduce the problem on x86_64.


-- 


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[shenrfen at gmail dot com]

--- Comment #2 from shenrfen at gmail dot com  2009-06-04 09:09 ---
The expected result should be -1, not 255.
But the result is 255 when I use g++ to compiling this code.


-- 

shenrfen at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/40335] The implement of Switch statment is against with C++ standard

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-06-04 09:04 ---
Integral promotion is performed on the switch argument, thus signed char -1
is sign-extended to int -1.  You probably want (unsigned char) i instead.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|The implement of Switch |The implement of Switch
   |statment is against with C++|statment is against with C++
   |standard|standard


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

[Bug c++/40335] New: The implement of Switch statment is against with C++ standard

[shenrfen at gmail dot com]

Source code: 1.cpp
#include 
static int i;

int
main (void)
{
  i = -1; 
  switch ((signed char) i) {
  case 255:
printf("255\n");
break;
  default:
printf("default\n");
break;
  }
}

Compiling command  : g++ 1.cpp && ./a.out
result : 255
The expected result: default  

According to C++ standard, an integral promotion of expression "(signed char)
i" should be performed firstly, the result of control expression should be
0x; then the label of case statment will be converted to int-type. So the
expected result should be default in my opinion. 

Thanks very much.

C++ standard:
The condition shall be of integral type, enumeration type, or of a class type
for which a single conversion function to integral or enumeration type exists
(12.3). If the condition is of class type, the condition is converted by
calling that conversion function, and the result of the conversion is used in
place of the original condition for the remainder of this section. 
Integral promotions are performed.
Any statement within the switch statement can be labeled with one or more case
labels as follows:
case constant-expression :
where the constant-expression shall be an integral constant-expression. The
integral constant-expression (5.19) is implicitly converted to the promoted
type of the switch condition.


-- 
   Summary: The implement of Switch statment is against with C++
standard
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shenrfen at gmail dot com
 GCC build triplet: x86
  GCC host triplet: x86
GCC target triplet: x86


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

[Bug target/10901] non-local goto's don't work on darwin

[gcc at microbizz dot nl]

--- Comment #21 from gcc at microbizz dot nl  2009-06-04 08:01 ---
No problem that it still fails. It will be fixed after the next big-bang, in
thirty billion years.


-- 


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

[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility

[jb at gcc dot gnu dot org]

--- Comment #17 from jb at gcc dot gnu dot org  2009-06-04 07:40 ---
(In reply to comment #16)
> Can this PR now be closed?

Yes, I think so. There are still some remnants of ASF in internal I/O, but I
don't think it hurts. 


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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