[Bug bootstrap/44226] [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-05-21 06:49 ---
Revision 159644:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00697.html

may be the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||law at gcc dot gnu dot org


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

[Bug bootstrap/44226] New: [4.6 regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 159650 gave

/export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./gcc/
-B/usr/local/ia64-unknown-linux-gnu/bin/
-B/usr/local/ia64-unknown-linux-gnu/lib/ -isystem
/usr/local/ia64-unknown-linux-gnu/include -isystem
/usr/local/ia64-unknown-linux-gnu/sys-include-g -O2 -O2  -g -O2 -DIN_GCC  
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -fPIC -DUSE_GAS_SYMVER -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I../../../src-trunk/libgcc
-I../../../src-trunk/libgcc/. -I../../../src-trunk/libgcc/../gcc
-I../../../src-trunk/libgcc/../include  -DHAVE_CC_TLS  -o _negdi2.o -MT
_negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c
../../../src-trunk/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../src-trunk/libgcc/../gcc/libgcc2.c: In function '__negti2':
../../../src-trunk/libgcc/../gcc/libgcc2.c:76:1: internal compiler error: in
ira_tune_allocno_costs_and_cover_classes, at ira-costs.c:1797
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [_negdi2.o] Error 1
make[6]: *** Waiting for unfinished jobs

Revision 159635 is OK.


-- 
   Summary: [4.6 regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/44225] Workaround for error: ... cannot appear in a constant-expression

[tuschjan at yahoo dot de]

--- Comment #1 from tuschjan at yahoo dot de  2010-05-21 06:32 ---
Created an attachment (id=20717)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20717&action=view)
demo source code


-- 


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

[Bug c++/44225] New: Workaround for error: ... cannot appear in a constant-expression

[tuschjan at yahoo dot de]

I observed the following issue with g++-4.3.4:

I can work around the restriction of initializing a static const integral 
class member with a non-constant expression.
This violates the standard and should be rejected by "-pedantic".
Correct me, if I'm wrong.

I cut down my code to the following (concededly a bit contrived) demo 
scenario:

--- Example Code ---
template 
struct X {
  static const NT VALUE;
};
template 
const NT X::VALUE = static_cast(x);

struct FailingTruth {
  static const bool VALUE = X::VALUE < X::VALUE;
}; 

template 
struct Test {
  static const bool VALUE = X::VALUE < X::VALUE;
};

struct WorkingTruth {
  static const bool VALUE = Test<1,2>::VALUE;
};

template 
struct UseAsTemplateParamter {
  enum {
VALUE = B
  };
};

UseAsTemplateParamter object;

--- End Example Code ---

The compiler correctly complains with
error: âX::VALUEâ cannot appear in a constant-expression
in "FailingTruth".

However, when I encasulate the  very same condition using the Test template 
class, the "WorkingTruth" code is accepted by g++. I could even use 
WorkingTruth::VALUE as a non-type template parameter (see last line).


Am I missing something here, or does that really violate the standard.

Regards Jan.

PS: Don't get me wrong, I like this "feature", it is really useful, when doing 
some meta-programming involving floating-point constants :-)


-- 
   Summary: Workaround for error: ... cannot appear in a constant-
expression
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tuschjan at yahoo dot de
 GCC build triplet: GNU/Linux x86
  GCC host triplet: GNU/Linux x86
GCC target triplet: GNU/Linux x86


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[joakim dot tjernlund at transmode dot se]

--- Comment #11 from joakim dot tjernlund at transmode dot se  2010-05-21 
06:23 ---
(In reply to comment #10)
> > On my mpc8321 it is a big difference(don't have numbers handy). Why would
> > such a simply insn be a problem performance wise?
> > I know the kernel still uses the carry insn's for calculating the
> > Internet checksum.
> 
> mpc8321 is a relatively simplistic pipeline.  Processors like POWER4, 5, 6, 7
> may not have the same characteristics.  Even with carry bit register renaming,
> it is an extra input/output to a dedicated resource, an extra register port.
> 
> XLC currently avoids carry completely for POWER5 and POWER6:

Avoids? I was under the impression the gcc doesn't try to be smart
yet so no ppc CPU gets to use the "add with carry" insn yet.

> 
> .add32carry:
> add r5,r3,r4
> cmpl0,0,r5,r4
> addir3,r5,1
> bclrBO_IF,CR0_LT
> ori r3,r5,0x
> blr
> 
> One cannot assume that fewer UISA instructions equates with fewer
> microarchitecture operations and faster performance.

If this is the case for something as simple as add with carry, one really
needs a simple way to tell gcc what ppc class CPU one wants to use.
Otherwise only the fastest CPUs gets optimal code and the rest, that
really needs fast code, gets punished.


-- 


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

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-05-21 06:21 ---
The patch in comment #2 fixes the ICE, but is probably the cause of

FAIL: gfortran.dg/select_type_1.f03  -O  (internal compiler error)
FAIL: gfortran.dg/select_type_1.f03  -O   (test for errors, line 63)
FAIL: gfortran.dg/select_type_1.f03  -O   (test for errors, line 65)
FAIL: gfortran.dg/select_type_1.f03  -O  (test for excess errors)

The ICE is

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:54.77:

class default  ! { dg-error "cannot be followed by a second DEFAULT CASE" }
   1  
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:56.77:

class default  ! { dg-error "cannot be followed by a second DEFAULT CASE" }
   2  
Error: The DEFAULT CASE at (1) cannot be followed by a second DEFAULT CASE at
(2)
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

and the missing errors are

/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:63.11:

  type is (t2)  ! { dg-error "overlaps with CASE label" }
   1
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/select_type_1.f03:65.11:

  type is (t2)  ! { dg-error "overlaps with CASE label" }
   2
Error: CASE label at (1) overlaps with CASE label at (2)

Otherwise I did not noticed other side effects.


-- 


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

[Bug middle-end/44224] [4.6 Regression]: build broken for cris-elf in libgcc

[kkojima at gcc dot gnu dot org]

--- Comment #2 from kkojima at gcc dot gnu dot org  2010-05-21 04:03 ---
Similar build failure seen on sh4-unknown-linux-gnu.

/exp/ldroot/dodes/xsh-gcc-orig/./gcc/xgcc
-B/exp/ldroot/dodes/xsh-gcc-orig/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/
-B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem
/usr/local/sh4-unknown-linux-gnu/include -isystem
/usr/local/sh4-unknown-linux-gnu/sys-include-g -O2 -O2  -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -mieee -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
-fpic -mieee -DNO_FPSCR_VALUES -I. -I. -I../.././gcc
-I../../../ORIG/trunk/libgcc -I../../../ORIG/trunk/libgcc/.
-I../../../ORIG/trunk/libgcc/../gcc -I../../../ORIG/trunk/libgcc/../include 
-DHAVE_CC_TLS  -o _addvdi3.o -MT _addvdi3.o -MD -MP -MF _addvdi3.dep
-DL_addvdi3 -c ../../../ORIG/trunk/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../ORIG/trunk/libgcc/../gcc/libgcc2.c: In function '__addvdi3':
../../../ORIG/trunk/libgcc/../gcc/libgcc2.c:114:1: internal compiler error: in
ira_tune_allocno_costs_and_cover_classes, at ira-costs.c:1797

On SH, cc1 fails to compile 

  long long foo (long long x) { return x;}

with the same assert at -O0.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||kkojima at gcc dot gnu dot
   ||org


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

[Bug middle-end/44224] [4.6 Regression]: build broken for cris-elf in libgcc

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2010-05-21 03:34 ---
Created an attachment (id=20716)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20716&action=view)
Shortened libgcc2.i

Compile with "./cc1 -fpreprocessed l.i -march=v10 -O2 -o libgcc2.s", observe
ICE.


-- 


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

[Bug middle-end/44224] New: [4.6 Regression]: build broken for cris-elf in libgcc

[hp at gcc dot gnu dot org]

With revision 159638 a combined tree built for cris-elf.
>From revision 159644, build was broken as follows:

# If this is the top-level multilib, build all the other
# multilibs.
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris
-L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys
-L/tmp/hpautotest-gcc1/gcc/libgloss/cris
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/
-B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem
/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include-g -O2 -march=v10
-mbest-lib-options -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc -I/tmp/hpautotest-gcc1/gcc/libgcc/.
-I/tmp/hpautotest-gcc1/gcc/libgcc/../gcc
-I/tmp/hpautotest-gcc1/gcc/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c \

/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/tmp/hpautotest-gcc1/gcc/libgcc/../gcc/libgcc2.c:562:1: internal compiler
error: in ira_tune_allocno_costs_and_cover_classes, at ira-costs.c:1797
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [_muldi3.o] Error 1

Authors of suspect patches in the above revision range CC:ed.
Preprocessed code to be attached momentarily.


-- 
   Summary: [4.6 Regression]: build broken for cris-elf in libgcc
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, build
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug target/44199] ppc64 glibc miscompilation

[pthaugen at gcc dot gnu dot org]

--- Comment #13 from pthaugen at gcc dot gnu dot org  2010-05-21 02:32 
---
Bootstrap of trunk went fine. Regression test (contrib/test_summary) showed the
following difference between base/patched versions, but didn't have any
testcases show up in the diff, so not sure what to make of that. This is for
32-bit gcc testsuite.

< # of expected passes  59078
---
> # of expected passes  59075
98c98
< # of unsupported tests872
---
> # of unsupported tests875


-- 


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

[Bug rtl-optimization/44223] segmentation fault with -g -fsched-pressure

[astrange at ithinksw dot com]

--- Comment #1 from astrange at ithinksw dot com  2010-05-21 02:02 ---
Created an attachment (id=20715)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20715&action=view)
file


-- 


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

[Bug rtl-optimization/44223] New: segmentation fault with -g -fsched-pressure

[astrange at ithinksw dot com]

> gcc -O3 -g -fsched-pressure -fschedule-insns -S crash1m.i
crash1m.i: In function 'ff_adts_write_frame_header':
crash1m.i:35:2: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Backtrace:
(gdb) run
Starting program:
/usr/local/gcc46/libexec/gcc/x86_64-apple-darwin10.3.1/4.6.0/cc1 -fpreprocessed
crash1m.i -march=core2 -mcx16 -msahf -maes -mpclmul -mpopcnt -msse4.2 --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072
-mtune=core2 -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase crash1m.i
-mmacosx-version-min=10.6.3 -auxbase crash1m -g -O3 -version -fsched-pressure
-fschedule-insns -o crash1m.s
Reading symbols for shared libraries .++. done
GNU C (GCC) version 4.6.0 20100521 (experimental) (x86_64-apple-darwin10.3.1)
compiled by GNU C version 4.2.1 (Apple Inc. build 5659), GMP version
4.3.1, MPFR version 2.4.2-p3, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20100521 (experimental) (x86_64-apple-darwin10.3.1)
compiled by GNU C version 4.2.1 (Apple Inc. build 5659), GMP version
4.3.1, MPFR version 2.4.2-p3, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 5c588719ada4c17718f398d6d2dbd7a3

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x
0x0001004edc54 in dying_use_p (use=0x141720070) at
../../../src/gcc/gcc/haifa-sched.c:769
769 if (NONDEBUG_INSN_P (next->insn)
(gdb) bt
#0  0x0001004edc54 in dying_use_p (use=0x141720070) at
../../../src/gcc/gcc/haifa-sched.c:769
#1  0x0001004f055d in setup_insn_reg_pressure_info [inlined] () at
/Users/astrange/Projects/src/gcc/gcc/haifa-sched.c:1130
#2  0x0001004f055d in ready_sort (ready=0x100b0b5e0) at
../../../src/gcc/gcc/haifa-sched.c:1502
#3  0x0001004f5e4b in schedule_block (target_bb=0x7fff5fbfe4e8) at
../../../src/gcc/gcc/haifa-sched.c:3203
#4  0x00010060c8bd in schedule_insns () at
../../../src/gcc/gcc/sched-rgn.c:3001
#5  0x00010060cd4f in rest_of_handle_sched () at
../../../src/gcc/gcc/sched-rgn.c:3512
#6  0x00010059cb3f in execute_one_pass (pass=0x100b99d40) at
../../../src/gcc/gcc/passes.c:1589
#7  0x00010059ce1d in execute_pass_list (pass=0x100b99d40) at
../../../src/gcc/gcc/passes.c:1644
#8  0x00010059ce2f in execute_pass_list (pass=0x100b98ec0) at
../../../src/gcc/gcc/passes.c:1645
#9  0x0001006cd1d0 in invoke_plugin_callbacks [inlined] () at
/Users/astrange/Projects/src/gcc/gcc/plugin.h:413
#10 0x0001006cd1d0 in tree_rest_of_compilation (fndecl=0x14252f300) at
../../../src/gcc/gcc/tree-optimize.c:416
#11 0x000100898ef6 in cgraph_expand_function (node=0x14240cd20) at
../../../src/gcc/gcc/cgraphunit.c:1622
#12 0x00010089c07d in cgraph_expand_all_functions [inlined] () at
/Users/astrange/Projects/src/gcc/gcc/cgraphunit.c:1701
#13 0x00010089c07d in cgraph_optimize () at
../../../src/gcc/gcc/cgraphunit.c:1957
#14 0x00010089c676 in cgraph_finalize_compilation_unit () at
../../../src/gcc/gcc/cgraphunit.c:1161
#15 0x0001f0f2 in c_write_global_declarations () at
../../../src/gcc/gcc/c-decl.c:9578
#16 0x0001006623c5 in do_compile () at ../../../src/gcc/gcc/toplev.c:1059
#17 0x000100662b1d in toplev_main (argc=32, argv=0x7fff5fbfe828) at
../../../src/gcc/gcc/toplev.c:2433
#18 0x00010f64 in start ()


-- 
   Summary: segmentation fault with -g -fsched-pressure
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
  GCC host triplet: x86_64-apple-darwin10.3.1


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

[Bug testsuite/32064] ssp tests can't find libssp

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-05-21 01:53 ---
*** Bug 28242 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


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

[Bug testsuite/28242] running the testsuite with -fstack-protector fail (not finding libssp)

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2010-05-21 01:53 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/44222] [4.6 regression] Revision 159621 caused new x86 test failures

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2010-05-21 01:52 ---
Subject: Re:   New: [4.6 regression] Revision 159621 caused new x86 test
failures

This is the same problem as the other sse testcases.

Sent from my iPhone

On May 20, 2010, at 6:34 PM, "hjl dot tools at gmail dot com"
 wrote:

> On Linux/x86, revision 159621:
>
> http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html
>
> caused
>
> FAIL: gcc.target/i386/3dnow-1.c (internal compiler error)
> FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
> FAIL: gcc.target/i386/3dnow-2.c (internal compiler error)
> FAIL: gcc.target/i386/3dnow-2.c (test for excess errors)
> FAIL: gcc.target/i386/3dnowA-1.c (internal compiler error)
> FAIL: gcc.target/i386/3dnowA-1.c (test for excess errors)
> FAIL: gcc.target/i386/3dnowA-2.c (internal compiler error)
> FAIL: gcc.target/i386/3dnowA-2.c (test for excess errors)
> FAIL: gcc.target/i386/pr42549.c (internal compiler error)
> FAIL: gcc.target/i386/pr42549.c (test for excess errors)
>
>
> -- 
>   Summary: [4.6 regression] Revision 159621 caused new x86  
> test
>failures
>   Product: gcc
>   Version: 4.6.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: target
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: hjl dot tools at gmail dot com
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44222
>


-- 


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

Re: [Bug target/44222] New: [4.6 regression] Revision 159621 caused new x86 test failures

[Andrew Pinski]

This is the same problem as the other sse testcases.

Sent from my iPhone

On May 20, 2010, at 6:34 PM, "hjl dot tools at gmail dot com" > wrote:



On Linux/x86, revision 159621:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html

caused

FAIL: gcc.target/i386/3dnow-1.c (internal compiler error)
FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
FAIL: gcc.target/i386/3dnow-2.c (internal compiler error)
FAIL: gcc.target/i386/3dnow-2.c (test for excess errors)
FAIL: gcc.target/i386/3dnowA-1.c (internal compiler error)
FAIL: gcc.target/i386/3dnowA-1.c (test for excess errors)
FAIL: gcc.target/i386/3dnowA-2.c (internal compiler error)
FAIL: gcc.target/i386/3dnowA-2.c (test for excess errors)
FAIL: gcc.target/i386/pr42549.c (internal compiler error)
FAIL: gcc.target/i386/pr42549.c (test for excess errors)


--
  Summary: [4.6 regression] Revision 159621 caused new x86  
test

   failures
  Product: gcc
  Version: 4.6.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: target
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-05-21 01:41 ---
The fix introduced:

FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-assembler-times movnti 18
FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-tree-dump-times optimized "={nt}" 18

on Linux/ia32.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|FIXED   |


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

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

[jmalcolm at sigphi dot ca]

--- Comment #5 from jmalcolm at sigphi dot ca  2010-05-21 01:39 ---
With more RAM, the compile completed successfully

(In reply to comment #4)
> I doubled the amount of RAM below and am trying again.  I will update here if
> it works.
> 
> (In reply to comment #2)
> > (In reply to comment #1)
> > > >xgcc: Internal error: Killed (program cc1)
> > > 
> > > How much memory do you have?  Do you have virtual memory setup?
> > > 
> > 
> > MemTotal:   368864 kB
> > MemFree: 14316 kB
> > Buffers:  7844 kB
> > Cached: 179256 kB
> > SwapCached:   3376 kB
> > Active: 228756 kB
> > Inactive:90624 kB
> > HighTotal:   0 kB
> > HighFree:0 kB
> > LowTotal:   368864 kB
> > LowFree: 14316 kB
> > SwapTotal:  262136 kB
> > SwapFree:  432 kB
> > Dirty:5880 kB
> > Writeback:   0 kB
> > AnonPages:  130144 kB
> > Mapped:  20616 kB
> > Slab:17500 kB
> > PageTables:   3272 kB
> > NFS_Unstable:0 kB
> > Bounce:  0 kB
> > CommitLimit:446568 kB
> > Committed_AS:   777500 kB
> > VmallocTotal:   487416 kB
> > VmallocUsed:  2228 kB
> > VmallocChunk:   485188 kB
> > 
> 


-- 

jmalcolm at sigphi dot ca changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/44222] New: [4.6 regression] Revision 159621 caused new x86 test failures

[hjl dot tools at gmail dot com]

On Linux/x86, revision 159621:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html

caused

FAIL: gcc.target/i386/3dnow-1.c (internal compiler error)
FAIL: gcc.target/i386/3dnow-1.c (test for excess errors)
FAIL: gcc.target/i386/3dnow-2.c (internal compiler error)
FAIL: gcc.target/i386/3dnow-2.c (test for excess errors)
FAIL: gcc.target/i386/3dnowA-1.c (internal compiler error)
FAIL: gcc.target/i386/3dnowA-1.c (test for excess errors)
FAIL: gcc.target/i386/3dnowA-2.c (internal compiler error)
FAIL: gcc.target/i386/3dnowA-2.c (test for excess errors)
FAIL: gcc.target/i386/pr42549.c (internal compiler error)
FAIL: gcc.target/i386/pr42549.c (test for excess errors)


-- 
   Summary: [4.6 regression] Revision 159621 caused new x86 test
failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44206] [4.6 Regression] ICE: Inline clone with address taken

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-05-21 01:16 ---
It is caused by revision 159354:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html


-- 


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

[Bug c++/44221] modulo of two variables results in: Floating point exception (core dumped)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-21 00:33 ---
x % 0u is undefined which is what you are running into.  So an exception
happens.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/44221] New: modulo of two variables results in: Floating point exception (core dumped)

[Joshua dot Pedrick at gmail dot com]

The following code compiles, but fails to run as expected:

#include  

int main()
{
   for ( size_t ticks = 0; ticks < 100; ++ticks )
   {
  for ( size_t ii = 0; ii < 10; ++ii )
  {
 std::cout << ticks % ii << std::endl;

  }
   }
}


-- 
   Summary: modulo of two variables results in: Floating point
exception (core dumped)
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Joshua dot Pedrick at gmail dot com


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[dje at gcc dot gnu dot org]

--- Comment #10 from dje at gcc dot gnu dot org  2010-05-21 00:28 ---
> On my mpc8321 it is a big difference(don't have numbers handy). Why would
> such a simply insn be a problem performance wise?
> I know the kernel still uses the carry insn's for calculating the
> Internet checksum.

mpc8321 is a relatively simplistic pipeline.  Processors like POWER4, 5, 6, 7
may not have the same characteristics.  Even with carry bit register renaming,
it is an extra input/output to a dedicated resource, an extra register port.

XLC currently avoids carry completely for POWER5 and POWER6:

.add32carry:
add r5,r3,r4
cmpl0,0,r5,r4
addir3,r5,1
bclrBO_IF,CR0_LT
ori r3,r5,0x
blr

One cannot assume that fewer UISA instructions equates with fewer
microarchitecture operations and faster performance.


-- 


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

[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-05-20 22:38 
---
Fixed, both -std=c++98 and -std=c++0x.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2010-05-20 22:36 ---
Subject: Bug 41792

Author: paolo
Date: Thu May 20 22:35:49 2010
New Revision: 159643

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159643
Log:
2010-05-20  Paolo Carlini  

PR libstdc++/41792
* include/tr1_impl/array: Use std::__addressof.
* include/std/functional (reference_wrapper): Likewise.
* include/ext/throw_allocator.h: Likewise.
* include/ext/pool_allocator.h: Likewise.
* include/ext/bitmap_allocator.h: Likewise.
* include/ext/new_allocator.h: Likewise.
* include/ext/malloc_allocator.h: Likewise.
* include/ext/array_allocator.h: Likewise.
* include/ext/mt_allocator.h: Likewise.
* include/ext/extptr_allocator.h: Likewise.
* include/bits/stl_list.h: Likewise.
* include/bits/hashtable_policy.h: Likewise.
* include/bits/forward_list.h: Likewise.
* include/bits/stl_uninitialized.h: Likewise.
* include/bits/list.tcc: Likewise.
* include/bits/stl_construct.h: Likewise.
* include/bits/stl_tree.h: Likewise.
* testsuite/20_util/reference_wrapper/41792.cc: New.
* testsuite/23_containers/unordered_map/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/multimap/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/set/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/unordered_multimap/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/unordered_set/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/vector/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/deque/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/multiset/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/list/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/unordered_multiset/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/map/requirements/
explicit_instantiation/4.cc: Likewise.
* testsuite/23_containers/array/requirements/
explicit_instantiation/3.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/
dr438/assign_neg.cc: Adjust dg-error line numbers.
* testsuite/23_containers/forward_list/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/forward_list/requirements/dr438/
constructor_2_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
assign_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
insert_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
constructor_1_neg.cc: Likewise.
* testsuite/23_containers/list/requirements/dr438/
constructor_2_neg.cc: Likewise.

2010-05-20  Peter Dimov  
Paolo Carlini  

* include/bits/move.h (__addressof, addressof): Add.
* testsuite/util/testsuite_api.h (struct OverloadedAddress): Add.
* testsuite/20_util/addressof/requirements/
explicit_instantiation.cc: New.
* testsuite/20_util/addressof/1.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/addressof/
trunk/libstdc++-v3/testsuite/20_util/addressof/1.cc
trunk/libstdc++-v3/testsuite/20_util/addressof/requirements/
   
trunk/libstdc++-v3/testsuite/20_util/addressof/requirements/explicit_instantiation.cc
trunk/libstdc++-v3/testsuite/20_util/reference_wrapper/41792.cc
   
trunk/libstdc++-v3/testsuite/23_containers/array/requirements/explicit_instantiation/3.cc
   
trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/forward_list/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/list/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/map/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/multimap/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/multiset/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/set/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/requirements/explicit_instantiation/4.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-20 21:53 ---
> It would be nice if -Wunused-dummy-argument would be split from
> -Wunused-variable and also be moved from -Wall to -Wextra to make
> it consistent with C, where -Wunused-parameter plays this role.

Mostly done. We had unused-dummy warnings in -Wall for so long, that I left
them there.

The -W[no-]unused-dummy-argument option will be available with 4.6.0.
No backport as it is not a feature, not a bug.

Closing.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2010-05-20 21:49 ---
Subject: Bug 38407

Author: dfranke
Date: Thu May 20 21:49:07 2010
New Revision: 159641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159641
Log:
gcc/fortran/:
2010-05-20  Daniel Franke  

PR fortran/38407
* lang.opt (Wunused-dummy-argument): New option.
* gfortran.h (gfc_option_t): Add warn_unused_dummy_argument.
* options.c (gfc_init_options): Disable warn_unused_dummy_argument.
(set_Wall): Enable warn_unused_dummy_argument.
(gfc_handle_option): Set warn_unused_dummy_argument according to
command line.
* trans-decl.c (generate_local_decl): Separate warnings about
unused variables and unused dummy arguments.
* invoke.texi: Documented new option.

gcc/testsuite/:
2010-05-20  Daniel Franke  

PR fortran/38407
* warn_unused_dummy_argument_1.f90: New.
* warn_unused_dummy_argument_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_1.f90
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/options.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

[burnus at gcc dot gnu dot org]

--- Comment #14 from burnus at gcc dot gnu dot org  2010-05-20 21:13 ---
Created an attachment (id=20714)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20714&action=view)
Updated draft

Use Bugzilla as backup to make sure the patch does not get lost.

Mostly regtests now (353 FAILS with 73 tests), though there are still some
issues, e.g., the DWARF name should be without @  (for "(gdb) pt"). Some clean
up is needed, cf. also comment  #13. Test cases: See bottom of attachment 20567
and attachment 20599.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #20696|0   |1
is obsolete||


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

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

[jmalcolm at sigphi dot ca]

--- Comment #4 from jmalcolm at sigphi dot ca  2010-05-20 21:06 ---
I doubled the amount of RAM below and am trying again.  I will update here if
it works.

(In reply to comment #2)
> (In reply to comment #1)
> > >xgcc: Internal error: Killed (program cc1)
> > 
> > How much memory do you have?  Do you have virtual memory setup?
> > 
> 
> MemTotal:   368864 kB
> MemFree: 14316 kB
> Buffers:  7844 kB
> Cached: 179256 kB
> SwapCached:   3376 kB
> Active: 228756 kB
> Inactive:90624 kB
> HighTotal:   0 kB
> HighFree:0 kB
> LowTotal:   368864 kB
> LowFree: 14316 kB
> SwapTotal:  262136 kB
> SwapFree:  432 kB
> Dirty:5880 kB
> Writeback:   0 kB
> AnonPages:  130144 kB
> Mapped:  20616 kB
> Slab:17500 kB
> PageTables:   3272 kB
> NFS_Unstable:0 kB
> Bounce:  0 kB
> CommitLimit:446568 kB
> Committed_AS:   777500 kB
> VmallocTotal:   487416 kB
> VmallocUsed:  2228 kB
> VmallocChunk:   485188 kB
> 


-- 


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

[Bug target/43404] ARM: Internal compiler error when using '&foo' in naked function

[torsten at debian dot org]

--- Comment #7 from torsten at debian dot org  2010-05-20 20:47 ---
This also hit me. I wanted to build a simple data logger for an ARM board. Of
course I wanted to give gcc 4.4 a go (I used a compiler from the 3.x series
before...), combined with current FreeRTOS (from www.freertos.org).

The interrupt handlers do not compile just as for Nut/OS. I found a discussion
about the issue at the arm-gnu archives. Quoting the post at 
http://www.codesourcery.com/archives/arm-gnu/msg02517.html by Mark Mitchell:

-
This code makes invalid use of the "naked" attribute.

>From the manual:

"The only statements that can be safely included in naked functions are
asm statements that do not have operands. All other statements,
including declarations of local variables, if statements, and so forth,
should be avoided. Naked functions should be used to implement the body
of an assembly function, while allowing the compiler to construct the
requisite function declaration for the assembler."
-

I disagree with this interpretation. "should" be avoided is different from
"must". For me this is just an indication that nothing is guaranteed about the
generated code - which is fine, interrupt handlers will naturally have to
revised for compiler updates.

Disregarding this as "invalid code" basically sends the signal that gcc is
unusable for small embedded systems. Of course it is possible to create a
trampoline function in assembler for each interrupt handler, but for small
systems, the overhead is relevant. So I'd rather set up the required registers
manually using some asm instructions but write the body of the function in C.

Looking at FreeRTOS' Subversion repository, they already started to add an
extra indirection to all interrupt handlers. :-(


-- 

torsten at debian dot org changed:

   What|Removed |Added

 CC||torsten at debian dot org


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

[Bug fortran/44213] ICE when extending abstract type

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-05-20 20:36 ---
The ICE is fixed by this more or less obvious patch:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 159561)
+++ gcc/fortran/resolve.c   (working copy)
@@ -10556,10 +10556,10 @@ ensure_not_abstract (gfc_symbol* sub, gfc_symbol*
  This is not the most efficient way to do this, but it should be ok and is
  clearer than something sophisticated.  */

-  gcc_assert (ancestor && ancestor->attr.abstract && !sub->attr.abstract);
+  gcc_assert (ancestor && !sub->attr.abstract);

   /* Walk bindings of this ancestor.  */
-  if (ancestor->f2k_derived)
+  if (ancestor->attr.abstract && ancestor->f2k_derived)
 {
   gfc_try t;
   t = ensure_not_abstract_walker (sub,
ancestor->f2k_derived->tb_sym_root);


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-20 20:24:30 |2010-05-20 20:36:07
   date||


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

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

[jmalcolm at sigphi dot ca]

--- Comment #3 from jmalcolm at sigphi dot ca  2010-05-20 20:27 ---
Starting the compile again from unpacked the tar file through to build stops in
exactly the same spot.


-- 


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

[Bug fortran/44213] ICE when extending abstract type

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-05-20 20:24 ---
My first feeling was that this would be illegal, but I could not find anything
in the standard supporting this feeling. F03 only has the following
restrictions:

C427 (R429) If the type definition contains or inherits (4.5.6.1) a
deferred binding (4.5.4), ABSTRACT shall appear.

C428(R429) If ABSTRACT appears, the type shall be extensible.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 20:24:30
   date||
Summary|[OOP] ICE when extending|ICE when extending abstract
   |abstract type   |type
   Target Milestone|--- |4.6.0


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

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

[jmalcolm at sigphi dot ca]

--- Comment #2 from jmalcolm at sigphi dot ca  2010-05-20 20:21 ---
(In reply to comment #1)
> >xgcc: Internal error: Killed (program cc1)
> 
> How much memory do you have?  Do you have virtual memory setup?
> 

MemTotal:   368864 kB
MemFree: 14316 kB
Buffers:  7844 kB
Cached: 179256 kB
SwapCached:   3376 kB
Active: 228756 kB
Inactive:90624 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   368864 kB
LowFree: 14316 kB
SwapTotal:  262136 kB
SwapFree:  432 kB
Dirty:5880 kB
Writeback:   0 kB
AnonPages:  130144 kB
Mapped:  20616 kB
Slab:17500 kB
PageTables:   3272 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:446568 kB
Committed_AS:   777500 kB
VmallocTotal:   487416 kB
VmallocUsed:  2228 kB
VmallocChunk:   485188 kB


-- 


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

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-05-20 20:14 ---
To fix this, one basically has to defer the generation of the vtype symbol to
resolution stage, which is what the following patch does:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 159561)
+++ gcc/fortran/resolve.c   (working copy)
@@ -10589,6 +10589,22 @@ resolve_fl_derived (gfc_symbol *sym)
   int i;

   super_type = gfc_get_derived_super_type (sym);
+  
+  if (sym->attr.is_class && sym->ts.u.derived == NULL)
+{
+  /* Fix up incomplete CLASS symbols.  */
+  gfc_component *data;
+  gfc_component *vptr;
+  gfc_symbol *vtab;
+  data = gfc_find_component (sym, "$data", true, true);
+  vptr = gfc_find_component (sym, "$vptr", true, true);
+  if (vptr->ts.u.derived == NULL)
+   {
+ vtab = gfc_find_derived_vtab (data->ts.u.derived, false);
+ gcc_assert (vtab);
+ vptr->ts.u.derived = vtab->ts.u.derived;
+   }
+}

   /* F2008, C432. */
   if (super_type && sym->attr.coarray_comp && !super_type->attr.coarray_comp)
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 159561)
+++ gcc/fortran/parse.c (working copy)
@@ -2110,22 +2110,6 @@ endType:
  || c->attr.access == ACCESS_PRIVATE
  || (c->ts.type == BT_DERIVED && c->ts.u.derived->attr.private_comp))
sym->attr.private_comp = 1;
-
- /* Fix up incomplete CLASS components.  */
- if (c->ts.type == BT_CLASS)
-   {
- gfc_component *data;
- gfc_component *vptr;
- gfc_symbol *vtab;
- data = gfc_find_component (c->ts.u.derived, "$data", true, true);
- vptr = gfc_find_component (c->ts.u.derived, "$vptr", true, true);
- if (vptr->ts.u.derived == NULL)
-   {
- vtab = gfc_find_derived_vtab (data->ts.u.derived, false);
- gcc_assert (vtab);
- vptr->ts.u.derived = vtab->ts.u.derived;
-   }
-   }
 }

   if (!seen_component)


This patch fixes the test case, but has not been regtested yet.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-05-20 19:15:09 |2010-05-20 20:14:13
   date||


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

[Bug fortran/43851] Add _gfortran_error_stop_numeric

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2010-05-20 19:40 
---
Subject: Bug 43851

Author: jvdelisle
Date: Thu May 20 19:40:30 2010
New Revision: 159638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159638
Log:
2010-05-20 Jerry DeLisle 

PR fortran/43851
* runtime/stop.c (stop_string): Make sure nothing is emitted for
blank stop.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/stop.c


-- 


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

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-20 19:38 ---
>xgcc: Internal error: Killed (program cc1)

How much memory do you have?  Do you have virtual memory setup?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

[Bug bootstrap/44220] New: Will not build on CentOS 5.5 (RHEL 5.5)

[jmalcolm at sigphi dot ca]

GCC 4.5 downloaded from http://mirror.csclub.uwaterloo.ca/gnu/ will not build
on my CentOS 5.5 system.

- System has all updates applied as of May 20, 2010
- Only base vendor supplied RPMS except for the following:
- MySQL 5.5.3 as an RPM from OurDelta (unrelated I am sure)
- Mono 2.6.4 built from source (unrelated I am sure)
- GMP 5.0.1 built from source (for this build)
- MPFR 2.4.2 built from source (for this build)
- MPC 0.8.2 built from source (for this build)

All software built from source built with using the following line at the bash
prompt:

./configure --prefix=/usr && make && make install

Compiler used was gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48)
RPM version of GLIBC is 2.5-49

The above was also used for the gcc build.

Last output of compile follows:

/usr/src/gcc/gcc-4.5.0/host-i686-pc-linux-gnu/prev-gcc/xgcc
-B/usr/src/gcc/gcc-4.5.0/host-i686-pc-linux-gnu/prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/bin/
-B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem
/usr/i686-pc-linux-gnu/sys-include -g -O2 -fomit-frame-pointer -DIN_GCC  
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H
-DGENERATOR_FILE  -o build/genattrtab \
build/genattrtab.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/errors.o ../../host-i686-pc-linux-gnu/libiberty/libiberty.a
build/genattrtab ../.././gcc/config/i386/i386.md \
  insn-conditions.md > tmp-attrtab.c
/bin/sh ../.././gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/usr/src/gcc/gcc-4.5.0/host-i686-pc-linux-gnu/prev-gcc/xgcc
-B/usr/src/gcc/gcc-4.5.0/host-i686-pc-linux-gnu/prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/bin/
-B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem
/usr/i686-pc-linux-gnu/sys-include-c  -g -O2 -fomit-frame-pointer -DIN_GCC 
 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H
-I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include
-I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber
-I../.././gcc/../libdecnumber/bid -I../libdecnumber insn-attrtab.c -o
insn-attrtab.o
xgcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See  for instructions.
make[3]: *** [insn-attrtab.o] Error 1
make[3]: Leaving directory `/usr/src/gcc/gcc-4.5.0/host-i686-pc-linux-gnu/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/usr/src/gcc/gcc-4.5.0'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/usr/src/gcc/gcc-4.5.0'
make: *** [all] Error 2


-- 
   Summary: Will not build on CentOS 5.5 (RHEL 5.5)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jmalcolm at sigphi dot ca
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/30298] [4.3/4.4/4.5 regression] ICE with duplicate broken inheritance

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW
Summary|[4.3/4.4/4.5/4.6 regression]|[4.3/4.4/4.5 regression] ICE
   |ICE with duplicate broken   |with duplicate broken
   |inheritance |inheritance


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

[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2010-05-20 19:33 
---
Fixed for 4.6.0.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|4.3.5   |4.6.0


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

[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance

[paolo at gcc dot gnu dot org]

--- Comment #12 from paolo at gcc dot gnu dot org  2010-05-20 19:32 ---
Subject: Bug 30298

Author: paolo
Date: Thu May 20 19:31:47 2010
New Revision: 159637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159637
Log:
/cp
2010-05-20  Paolo Carlini  

PR c++/30298
* decl.c (xref_basetypes): Return false in case of ill-formed
redefinition.

/testsuite
2010-05-20  Paolo Carlini  

PR c++/30298
* g++.dg/inherit/crash1.C: New.
* g++.dg/inherit/crash2.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/inherit/crash1.C
trunk/gcc/testsuite/g++.dg/inherit/crash2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39994] Bounds checking (-fcheck=bounds): "A = [ constructor ]" does not work

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-20 19:19 ---
(In reply to comment #2)
> I believe that this is a duplicate of PR 31059.

Me too.

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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2010-05-20 19:19 ---
*** Bug 39994 has been marked as a duplicate of this bug. ***


-- 

dfranke 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=31059

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-05-20 19:15 ---
Confirmed.

I think the code is valid. At least 'A_type' being defined after 'B_type' is
not a problem, since the Fortran 2003 standard says:

C438 (R440) If the POINTER attribute is not specified for a component,
the declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall
specify an intrinsic type or a previously defined derived type.

C439 (R440) If the POINTER attribute is specified for a component, the
declaration-type-spec in the component-def-stmt shall be CLASS(*) or shall
specify an intrinsic type or any accessible derived type including the type
being defined.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 19:15:09
   date||


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

[Bug c++/44219] Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

--- Comment #3 from zeljkoj at tesla dot rcub dot bg dot ac dot rs  
2010-05-20 19:13 ---

> > class A private members should be seen as private in class B
> 
> No, they are private to A which means only A can access them, not any base
> classes.  If you want that, use protected.

You are right. Thank you for a quick reply.


-- 


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

[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array

[janus at gcc dot gnu dot org]

--- Comment #1 from janus at gcc dot gnu dot org  2010-05-20 19:01 ---
Confirmed. Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0,
ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2497
2497n = se->loop->order[0];
(gdb) bt
#0  0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0,
ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2497
#1  0x00571f17 in gfc_conv_array_ref (se=0x7fffd6a0, ar=0x17f6048,
sym=0x17f4370, where=0x17f40f0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:2550
#2  0x005988e0 in gfc_conv_variable (se=0x7fffd6a0, expr=0x17f40a0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:702
#3  0x005a3712 in gfc_conv_expr (se=0x7fffd6a0, expr=0x17f40a0) at
/home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:4453
#4  0x0059a833 in get_proc_ptr_comp (e=0x17f2560) at
/home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:1529
#5  0x0059a88b in conv_function_val (se=0x7fffdd60, sym=0x17effb0,
expr=0x17f2560) at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:1541
#6  0x0059fe41 in gfc_conv_procedure_call (se=0x7fffdd60,
sym=0x17effb0, arg=0x0, expr=0x17f2560, append_args=0x0)
at /home/jweil/gcc46/trunk/gcc/fortran/trans-expr.c:3323


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to fail||4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 19:01:47
   date||
Summary|ICE with TBP of pointer |[OOP] ICE with TBP of
   |component of derived type   |pointer component of derived
   |array   |type array
   Target Milestone|--- |4.6.0


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

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[ubizjak at gmail dot com]

-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|bootstrap   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 18:52:52
   date||


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

[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

[uros at gcc dot gnu dot org]

--- Comment #27 from uros at gcc dot gnu dot org  2010-05-20 18:52 ---
Subject: Bug 43733

Author: uros
Date: Thu May 20 18:52:03 2010
New Revision: 159636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159636
Log:
PR target/43733
* configure.ac (gcc_cv_as_ix86_sahf): Switch to 64bit mode.
* configure: Regenerate.
* config.in: Regenerate.
* config/i386/i386.md (x86_sahf_1): Conditionally output 0x9e
instead of sahf only for 64bit targets.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/config/i386/i386.md
trunk/gcc/configure
trunk/gcc/configure.ac


-- 


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

[Bug c++/44219] Public inheritance treated as private

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-05-20 18:51 ---
> class A private members should be seen as private in class B

No, they are private to A which means only A can access them, not any base
classes.  If you want that, use protected.


-- 

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

[Bug c++/44219] Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

--- Comment #1 from zeljkoj at tesla dot rcub dot bg dot ac dot rs  
2010-05-20 18:51 ---
Created an attachment (id=20713)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20713&action=view)
Preprocessed source of the test case


-- 


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

[Bug c++/44219] New: Public inheritance treated as private

[zeljkoj at tesla dot rcub dot bg dot ac dot rs]

I apologize if this is not a bug, or if it has been reported (I thoroughly
searched the bug database, but couldn't find anything related).
When class B publicly inherit class A, class A private members should be seen
as private in class B. However, they are not visible in class B (as if "public"
keyword was omitted). Here is the whole example:

class A {
  int x;
};

class B : public A {
  B()
  {
x = 5;
  }

};


int main(int argc, char *argv[])
{
return 0;
}

And here is the compiler output:
g++ -v -save-temps bug1.cpp

Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/specs
Target: x86_64-slackware-linux
Configured with: ../gcc-4.4.4/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib
--with-python-dir=/lib64/python2.6/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose
--disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 4.4.4 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-slackware-linux/4.4.4/cc1plus -E -quiet -v
-D_GNU_SOURCE bug1.cpp -mtune=generic -fpch-preprocess -o bug1.ii
ignoring duplicate directory "/usr/lib64/qt/include"
ignoring duplicate directory "/usr/lib/qt/include"
ignoring nonexistent directory
"/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../x86_64-slackware-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/qt/include
 /usr/lib/qt/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4

/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4/x86_64-slackware-linux

/usr/lib64/gcc/x86_64-slackware-linux/4.4.4/../../../../include/c++/4.4.4/backward
 /usr/local/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/include
 /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
 /usr/libexec/gcc/x86_64-slackware-linux/4.4.4/cc1plus -fpreprocessed bug1.ii
-quiet -dumpbase bug1.cpp -mtune=generic -auxbase bug1 -version -o bug1.s
GNU C++ (GCC) version 4.4.4 (x86_64-slackware-linux)
compiled by GNU C version 4.4.4, GMP version 5.0.1, MPFR version
2.4.2-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: df3503c115036a5e101a3ec035b30ab4
bug1.cpp: In constructor ‘B::B()’:
bug1.cpp:5: error: ‘int A::x’ is private
bug1.cpp:12: error: within this context


-- 
   Summary: Public inheritance treated as private
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeljkoj at tesla dot rcub dot bg dot ac dot rs
 GCC build triplet: x86_64-slackware-linux
  GCC host triplet: x86_64-slackware-linux
GCC target triplet: x86_64-slackware-linux


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

[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-05-20 18:45 ---
Note: The ICE happens with 4.5 and trunk. With 4.4 one gets

allocate(this%list(dim),source=[(i,i=1,dim)])
  1
Error: Syntax error in ALLOCATE statement at (1)

since support for the SOURCE argument was only added in 4.5.


-- 


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

[Bug target/44218] New: Improve powerpc -mrecip support

[meissner at gcc dot gnu dot org]

The current powerpc -mrecip can be improved in several areas.

1) The compiler generates a conditional test to deal with NaN, etc. even though
it is only used with -ffast-math, where the programmer declares that he/she is
not interested in Nan/infinity/etc.  This causes the code to single thread the
approximation, and does not allow the power7 to issue two streams of FRSQRTES
and fixup in parallel.

2) Right now, -mrecip only enables single precision reciprocal square estimate.
 The compiler should be modified so that it also supports double precision
reciprocal estimate on newer machines (power6/power7) that have a high enough
precision FRSQRTE instruction.

3) In addition to optimizing 1/sqrt(x), the compiler should be able to optimize
normal divisions using the FRE/FRES instructions.  Machines with higher
precision FRE instructions should do fewer passes in the fixup than the older
machines.

4) On altivec and VSX systems, the compiler should enable auto vectorization of
the estimate instructions and fixup.

5) The compiler should provide more builtins to allow the user to access to
double reciprocal square root, as well as vector versions.


-- 
   Summary: Improve powerpc -mrecip support
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: meissner at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug target/44217] New: GCC emits cmpxchg16b which Sun as cannot handle

[ro at gcc dot gnu dot org]

On Solaris 11/x86 with Sun as, two 64-bit libgomp testcases fail:

FAIL: libgomp.c/atomic-2.c (test for excess errors)
WARNING: libgomp.c/atomic-2.c compilation failed to produce executable
FAIL: libgomp.c/atomic-5.c (test for excess errors)
WARNING: libgomp.c/atomic-5.c compilation failed to produce executable

In libgomp.log, I find

Excess errors:
Assembler: atomic-2.c
"/var/tmp//ccXCaqFL.s", line 51 : Illegal mnemonic
Near line: "lock cmpxchg16b ld(%rip)"
"/var/tmp//ccXCaqFL.s", line 51 : Syntax error
Near line: "lock cmpxchg16b ld(%rip)"
"/var/tmp//ccXCaqFL.s", line 51 : Illegal mnemonic
Near line: "lock cmpxchg16b ld(%rip)"

>From running strings on the as binary, Sun as simply doesn't know about this
instruction.


-- 
   Summary: GCC emits cmpxchg16b which Sun as cannot handle
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


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

[Bug testsuite/28242] running the testsuite with -fstack-protector fail (not finding libssp)

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-05-20 18:26 ---
This is not an enhancement, but simply a bug: the testsuite should use the
built
libraries, not some version that happens (or not) to be installed on the
system.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
   Severity|enhancement |normal
  Known to fail||4.6.0
   Last reconfirmed|2006-07-04 14:40:54 |2010-05-20 18:26:55
   date||


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-05-20 18:23 ---
If you could, it would be very much appreciated.  Starting 4.4
bootstrap/regtest now.


-- 


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

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2010-05-20 18:23 ---
Paolo, do you happen to have an idea how to handle this cleanly?


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug libgcj/44216] New: [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

[ro at gcc dot gnu dot org]

Since the introduction of the configure check for the --no-merge-exidx-entries
linker option, all libjava tests fail on IRIX 6.5:

output is:
(null): WARNING 1  : Unknown option: -no-merge-exidx-entries (ignored).


FAIL: linking PR9577

The problem is that the SGI ld warns about unknown options as above, but still
exists with status 0.  None of the options to suppress errors/warnings has an
effect on this, neither -LD_MSG:error=1 nor -LD_MSG:off=1 nor -woff 1.

I've found no good way to handle this generically, since the AC_LINK_IFELSE
macro only logs stderr of the link command to conftest,err and the warning
goes to stdout.  I could of course simply set libgcj_cv_exidx=no for
mips-sgi-irix6.5, but perhaps there's a cleaner solution I'm just not seeing?


-- 
   Summary: [4.6 regression] All libjava tests fail on IRIX 6.5: ld
warns about -no-merge-exidx-entries
   Product: gcc
   Version: 4.6.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: 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=44216

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2010-05-20 18:14 ---
Fixed for 4.3.5.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

--- Comment #2 from meissner at gcc dot gnu dot org  2010-05-20 18:02 
---
Created an attachment (id=20712)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20712&action=view)
Example program that shows the issue on powerpc.

Compile with -mcpu=power7 on powerpc.


-- 


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

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

--- Comment #1 from meissner at gcc dot gnu dot org  2010-05-20 18:00 
---
Actually in looking at it further, I was wrong in the initial claim.  Auto
vectorization now handles division by a constant.  Explicit vectors like
PowerPC (and probably SPU) do show the problem.


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[pthaugen at gcc dot gnu dot org]

--- Comment #11 from pthaugen at gcc dot gnu dot org  2010-05-20 17:59 
---
No I didn't bootstrap/regtest. I can take care of trunk if you want to do 4.4.


-- 


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

[Bug c++/42101] Linking failure with static constants and ternary inline function

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2010-05-20 17:53 
---
*** Bug 44215 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||doreille at smr dot ch


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

[Bug c++/44215] undefinied reference with static constant initialized data member in conditional expression

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-05-20 17:53 ---


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


-- 

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

[Bug c++/44215] New: undefinied reference with static constant initialized data member in conditional expression

[doreille at smr dot ch]

The following code raise undefined reference link errors:
toto.C:(.text+0x10): undefined reference to `A::a'
toto.C:(.text+0x18): undefined reference to `B::a'

The code:

struct A {
static const int a = 0;
};

struct B {
static const int a = 1;
};

int main() {
bool b = true;
return b ? A::a : B::a;
}


-- 
   Summary: undefinied reference with static constant initialized
data member in conditional expression
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doreille at smr dot ch


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

[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

[dje at gcc dot gnu dot org]

--- Comment #21 from dje at gcc dot gnu dot org  2010-05-20 17:52 ---
I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR
44132, which was necessary to get back to a sane level of C++ and libgomp
failures on AIX.  The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch did not have
any further affect on AIX testsuite results.


-- 


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

[Bug rtl-optimization/44214] New: Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

[meissner at gcc dot gnu dot org]

If you have code that does division by a constant that can be auto vectorized
by the compiler, the compiler does not convert the division to multiplication
by the reciprocal if -freciprocal-math (or -ffast-math), but instead does the
division.

The bug is in fold-const.c near line 11254, where the code for handling
REAL_CST should be cloned to handle VECTOR_CST (and presumably COMPLEX_CST
also).


-- 
   Summary: Compiler does not optimize vector divide with -
freciprocal-math (or -ffast-math)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at gcc dot gnu dot org
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug tree-optimization/43544] TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION can misoptimize when MD builtins overlap with standard builtins

[meissner at gcc dot gnu dot org]

--- Comment #4 from meissner at gcc dot gnu dot org  2010-05-20 17:39 
---
Fix checked in on March 26, 2010.


-- 

meissner at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-05-20 17:15 ---
Initial patch posted for COMDAT group with Sun as.  Will require an updated
configure test to work on SPARC, though.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||05/msg01365.html
   Keywords||patch


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

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-20 17:06 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-05-20 17:04 ---
The manual documents what is enabled by -Wall and -Wextra and all other groups
options. We will accept patches fixing any missing/mistaken entries. You could
also propose some warnings to be moved to Wextra. Getting into Wall is more
difficult because they have to be pretty clear and serious warnings without few
false positives.

See also the option -fdiagnostics-show-option.

It would be extremely useful to go through the manual and:

* Document which warnings are exactly enabled by -pedantic -Wall and -Wextra.
Wall and Wextra should be ok but could be good to double check them.

* Document which warnings are not enabled by default or by one of the above.
Provide a complete list of those warnings.

* With this list at hand, one could suggest to move some warnings to Wextra
or...

* perhaps provide a "Wparanoid" setting that includes all those warnings.
Although some may be too specific to make sense at all except for very specific
situations. That is why the list might be interesting.

* A list of warnings enabled by default would also be interesting. (They are
mentioned in the manual for each warning, but there is no complete list.)

Instead of -show-warnings, I would propose to extend the current
--help=warnings --verbose. However, that would mean documenting within GCC the
relations between the warnings options. That by itself (even without the
output) would be EXTREMELY useful if done properly, that is, by adding the
information to the *.opt files that define the flags. I can provide pointers on
how this could be implemented. A follow-up patch could even fill the details of
the manual from that information automatically!

So, I think yes, we are interested in any of the above, so if you are
interested in providing patches, choose something small to start with (some
small documentation patch to the manual), and ask whatever you want. You may
ask here or write to me directly.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-05-20 17:04:01
   date||


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

[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-20 17:01 ---
A proper come-on-and-pick-up testcase would be nice ...


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-05-20 17:01 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-20 17:00 ---
Subject: Bug 43521

Author: jakub
Date: Thu May 20 17:00:32 2010
New Revision: 159635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159635
Log:
PR debug/43521
* decl.c (start_java_method): Set DECL_ARTIFICIAL on the 'this'
PARM_DECL.

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


-- 


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-05-20 16:59 ---
Subject: Bug 44178

Author: jakub
Date: Thu May 20 16:58:52 2010
New Revision: 159634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159634
Log:
PR debug/44178
* haifa-sched.c (initiate_bb_reg_pressure_info): Do not call
setup_ref_regs for DEBUG_INSNs.

* g++.dg/debug/pr44178.C: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/pr44178.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/haifa-sched.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #21 from jason at gcc dot gnu dot org  2010-05-20 16:49 ---
The alias_set_subset_of change isn't in 4.5?  Then that's not what's making the
libstdc++ function tests pass with the swap change reverted...:)


-- 


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

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-05-20 16:35 ---
Subject: Bug 44178

Author: jakub
Date: Thu May 20 16:34:43 2010
New Revision: 159632

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159632
Log:
PR debug/44178
* haifa-sched.c (initiate_bb_reg_pressure_info): Do not call
setup_ref_regs for DEBUG_INSNs.

* g++.dg/debug/pr44178.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr44178.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44199] ppc64 glibc miscompilation

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-05-20 16:31 ---
Have you also bootstrapped/regtested the patch?  I can do so (easily for 4.4
branch, with more effort for the trunk), but haven't done that yet.


-- 


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

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2010-05-20 16:25 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dfranke at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-28 17:12:36 |2010-05-20 16:25:56
   date||


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

[Bug target/44199] ppc64 glibc miscompilation

[pthaugen at gcc dot gnu dot org]

--- Comment #9 from pthaugen at gcc dot gnu dot org  2010-05-20 16:23 
---
Spec testing went fine, differences in the noise range.


-- 


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

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

[redi at gcc dot gnu dot org]

--- Comment #3 from redi at gcc dot gnu dot org  2010-05-20 16:14 ---
(In reply to comment #2)
> > -W is a synonym for -Wextra, so it is pointless to use both
> This perfectly illustrates the problem; I have already spend hours digging

Then I have misunderstood the problem. How does this illustrate it?

> into the manual, what I attempted was to have as much warnings as possible.

How does adding the redundant -W help get more warnings if you already have
-Wextra?

> > The manual fairly clearly documents what controls what
> I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
> wouldn't want to rely on the manual to have a clear overview of what happens
> exactly on your build, with a specific file, with your options !

I don't understand what you mean here.
You said you never know what is enabled by -Wall or -Wextra, I pointed out the
manual explains it.
It is quite rare for a -W option to be moved in or out of the -Wall set, so it
doesn't vary between versions.


-- 


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

[Bug debug/44205] Wrong .debug_line for -O0 -g

[jan dot kratochvil at redhat dot com]

--- Comment #3 from jan dot kratochvil at redhat dot com  2010-05-20 16:03 
---
No regressions for FSF GDB HEAD x86_64-linux-gnu with FSF GCC HEAD.


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[rguenther at suse dot de]

--- Comment #20 from rguenther at suse dot de  2010-05-20 15:44 ---
Subject: Re:  Revisit std::function for aliasing issues
 and efficiency

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> --- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 15:40 
> ---
> Aha.  That sounds good to me; I don't expect your testcase to work, because it
> doesn't involve a char buffer.  The copy does need to use the object
> representation, but I think the new-expression should be undefined (though the
> standard needs fixing to make it so--this is core issue 1027).
> 
> So, can we revert the function::swap change for 4.6, then?

Well.  It is probably safe (though I'd like to know how 44164 is
exactly broken - backporting that change doesn't fix that testcase).

Richard.


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 15:40 ---
Aha.  That sounds good to me; I don't expect your testcase to work, because it
doesn't involve a char buffer.  The copy does need to use the object
representation, but I think the new-expression should be undefined (though the
standard needs fixing to make it so--this is core issue 1027).

So, can we revert the function::swap change for 4.6, then?


-- 


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

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-05-20 15:30 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2010-05-20 15:30 ---
Subject: Bug 44185

Author: spop
Date: Thu May 20 15:29:40 2010
New Revision: 159630

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159630
Log:
Fix PR44185: new prefetch test failures.

2010-05-20  Changpeng Fang  

PR middle-end/44185
* gcc.dg/tree-ssa/prefetch-6.c: Add --param
min-insn-to-prefetch-ratio=6.
* gcc.dg/tree-ssa/prefetch-7.c: Remove --param max-unrolled-insns=1 to
allow unrolling, and adjust the movnti count.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/prefetch-7.c


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[rguenther at suse dot de]

--- Comment #18 from rguenther at suse dot de  2010-05-20 15:17 ---
Subject: Re:  Revisit std::function for aliasing issues
 and efficiency

On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote:

> --- Comment #17 from jason at gcc dot gnu dot org  2010-05-20 15:13 
> ---
> Hmm...I tried reverting the change to functional::swap, but all the libstdc++
> tests still pass on x86_64-linux, and I haven't been able to write a failing
> testcase either.  Anyone else have a testcase that still fails with 4.5.1pre 
> or
> trunk?  For instance, this doesn't break when compiled either as C or C++:
> 
> union __attribute ((aligned (__alignof (float U { char c[32]; };

That's because the union now effectively uses alias-set zero after

2010-04-15  Richard Guenther  

* alias.c (alias_set_subset_of): Handle alias-set zero
child properly.

which is also a pessimization (because we use alias-set zero for
structs with chars, not only char lvalues).

A testcase that breaks would use a union without a character member
(where you'd still need to copy the object representation).

So like

union { int i; } u,v;

float *f = new (&u) float(0.0;
v = u;
return (float *)&v;

Richard.


-- 


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

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2010-05-20 15:13 ---
Hmm...I tried reverting the change to functional::swap, but all the libstdc++
tests still pass on x86_64-linux, and I haven't been able to write a failing
testcase either.  Anyone else have a testcase that still fails with 4.5.1pre or
trunk?  For instance, this doesn't break when compiled either as C or C++:

union __attribute ((aligned (__alignof (float U { char c[32]; };

int main ()
{
  union U u1, u2;
  *(float*)(u1.c) = 42.0;
  u2 = u1;
  if (*(float*)(&u2) != 42.0)
return 1;
  return 0;
}


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

[eric dot estievenart at free dot fr]

--- Comment #2 from eric dot estievenart at free dot fr  2010-05-20 15:06 
---
> -W is a synonym for -Wextra, so it is pointless to use both
This perfectly illustrates the problem; I have already spend hours digging
into the manual, what I attempted was to have as much warnings as possible.

> The manual fairly clearly documents what controls what
I know perfectly. Consider 3-4 platforms, 2-3 versions of gcc, and you
wouldn't want to rely on the manual to have a clear overview of what happens
exactly on your build, with a specific file, with your options !

Cheers


-- 


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

[Bug middle-end/44197] [4.6 Regresssion] varpool SEGV

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2010-05-20 14:57 ---
Subject: Bug 44197

Author: hubicka
Date: Thu May 20 14:57:27 2010
New Revision: 159629

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159629
Log:
PR middle-end/44197
* varpool.c (varpool_remove_node): Handle in-varpool aliases.
* gcc.c-torture/compile/pr44197.c: New file.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr44197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c


-- 


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[joakim dot tjernlund at transmode dot se]

--- Comment #9 from joakim dot tjernlund at transmode dot se  2010-05-20 
14:47 ---
(In reply to comment #8)
> Has anyone tested if generating an instruction sequence that uses the carry 
> bit
> actually improves performance on modern POWER processors?  It reduces the
> number of instructions, which is good when optimizing for size, but that may
> not necessarily translate to performance.
> 

On my mpc8321 it is a big difference(don't have numbers handy). Why would
such a simply insn be a problem performance wise?
I know the kernel still uses the carry insn's for calculating the
Internet checksum.

I have also noticed that gcc 4.3.4 prefers to do post increment even
if I write *++buf, why is that?


-- 


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

[Bug debug/44205] Wrong .debug_line for -O0 -g

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-05-20 14:44 ---
Created an attachment (id=20711)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20711&action=view)
gcc46-pr44205.patch

Doing it at gimplification time would be actually very hard, we only create the
continue label after then block is gimplified and only if it could fall
through.

Here is an attempt to fix this by removing forwarder blocks even at -O0 during
tree cfg cleanup if they don't care any useful location info (either everything
is UNKNOWN_LOCATION as in this testcase, or everything has the same location).
The goto to the cont label intentionally has no location:
  g = gimple_build_goto (label_cont);

  /* GIMPLE_COND's are very low level; they have embedded
 gotos.  This particular embedded goto should not be marked
 with the location of the original COND_EXPR, as it would
 correspond to the COND_EXPR's condition, not the ELSE or the
 THEN arms.  To avoid marking it with the wrong location, flag
 it as "no location".  */
  gimple_set_do_not_emit_location (g);
and nothing else on the edges here has any locus either, so I believe nothing
is lost by removing the forwarder block.  We then avoid removing the forwarder
block at RTL cleanup time when the extra jump already has some, in this case
undesirable, location.

This patch definitely needs testing on gdb testsuite if it doesn't regress
anything at -O0 -g.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug fortran/44213] New: [OOP] ICE when extending abstract type

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice_module
  type :: a_type
  end type a_type

  type,extends(a_type),abstract :: b_type
  end type b_type

  type,extends(b_type) :: c_type
  end type c_type
end module ice_module

f951: interner Compiler-Fehler: in ensure_not_abstract, bei
fortran/resolve.c:10559


-- 
   Summary: [OOP] ICE when extending abstract type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug fortran/35849] "wrong" line shown in error message for parameter

[dfranke at gcc dot gnu dot org]

--- Comment #4 from dfranke at gcc dot gnu dot org  2010-05-20 14:33 ---
A similar example:

$ cat conversion.f90
   REAL(8), PARAMETER :: h = HUGE(0.0_8)

   real*4 x
   data x / h /
end

$ gfortran-svn -Wall conversion.f90
conversion.f90:1.28:

   REAL(8), PARAMETER :: h = HUGE(0.0_8)
1
Error: Arithmetic overflow converting REAL(8) to REAL(4) at (1). This check can
be disabled with the option -fno-range-check


The overflowing conversion occurs in the DATA statement ^^


-- 


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

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

[dje at gcc dot gnu dot org]

--- Comment #8 from dje at gcc dot gnu dot org  2010-05-20 14:25 ---
Has anyone tested if generating an instruction sequence that uses the carry bit
actually improves performance on modern POWER processors?  It reduces the
number of instructions, which is good when optimizing for size, but that may
not necessarily translate to performance.


-- 


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

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

--- Comment #19 from jason at gcc dot gnu dot org  2010-05-20 14:01 ---
And changing component to rtl-opt.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |rtl-optimization


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

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

[jason at gcc dot gnu dot org]

--- Comment #18 from jason at gcc dot gnu dot org  2010-05-20 14:00 ---
Unassigning myself.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/44212] New: [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

[boschmann at tp1 dot physik dot uni-siegen dot de]

module ice_module

  type :: B_type
 class(A_type),pointer :: A_comp   ! A_type is not yet defined
  end type B_type

  type :: A_type
  contains
 procedure :: A_proc
  end type A_type

contains

  subroutine A_proc(this)
class(A_type),target,intent(inout) :: this
  end subroutine A_proc

  subroutine ice_proc(this)
class(A_type) :: this
call this%A_proc()
  end subroutine ice_proc

end module ice_module

f951: interner Compiler-Fehler: in gfc_add_component_ref, bei
fortran/class.c:77

Sorry, the error is in german, but you will understand it :)


-- 
   Summary: [OOP] ICE when defining a pointer component before
defining the class and calling a TBP then
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boschmann at tp1 dot physik dot uni-siegen dot de


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

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

[pault at gcc dot gnu dot org]

--- Comment #11 from pault at gcc dot gnu dot org  2010-05-20 13:51 ---
(In reply to comment #10)
Am I right in thinking that -fwhole-file could be enabled by default, if this
PR were to be fixed?  (The appropriate changes in the testsuite would have to
be mad too.)

Paul


-- 


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

[Bug fortran/43851] Add _gfortran_error_stop_numeric

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2010-05-20 13:33 
---
Also have one tweak to do for blank STOP which I will fix shortly and add some
test cases.


-- 


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