[Bug libstdc++/26458] Passing a NULL char* into output stream now breaks the output stream

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #11 from Ian Lance Taylor  2011-03-13 06:04:06 
UTC ---
I don't think the C++ standard requires this behaviour at all when using
operator<< with NULL.  The standard says that a pointer value is required to be
non-NULL.  That means that passing a pointer value of NULL is undefined
behaviour.  The standard imposes no requirement at all.

I think it would be much better if libstdc++ printed "(null)" here as the glibc
printf function does.  If that it not acceptable for some odd reason, then I
think we should throw an exception.  I think the current behaviour is worse
than useless in practice.

[Bug target/48053] ICE in in build_int_cst_wide, when building cpu2000 galgel/equake/ammp/fma3d/sixtrack

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Peter Bergner  2011-03-13 
04:11:14 UTC ---
Fixed.

[Bug target/48053] ICE in in build_int_cst_wide, when building cpu2000 galgel/equake/ammp/fma3d/sixtrack

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  2011-03-13 
04:06:46 UTC ---
Author: bergner
Date: Sun Mar 13 04:06:41 2011
New Revision: 170920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170920
Log:
gcc/
PR target/48053
* config/rs6000/predicates.md (easy_vector_constant_add_self,
easy_vector_constant_msb): Do not handle V2DImode and V2DFmode.
* config/rs6000/rs6000.c (const_vector_elt_as_int): Add assert that
mode is not V2DImode or V2DFmode.
(vspltis_constant): Do not handle V2DImode and V2DFmode.
(rs6000_expand_vector_init): Replace copy_to_reg with copy_to_mode_reg.
* config/rs6000/rs6000.md (movdi_internal32): Allow setting VSX
registers to 0.
(movdi_internal64): Likewise.

gcc/testsuite/
PR target/48053
* gcc/testsuite/gcc.target/powerpc/pr48053-1.c: New test.
* gcc/testsuite/gcc.target/powerpc/pr48053-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr48053-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr48053-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/32385] g++ rejects struct in default argument of template function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code,  |
   |monitored   |
 CC||jason at gcc dot gnu.org
   Target Milestone|4.3.6   |---
Summary|[4.3/4.4/4.5/4.6|g++ rejects struct in
   |regression] ICE with struct |default argument of
   |in default argument of  |template function
   |template function   |

--- Comment #7 from Jason Merrill  2011-03-13 
01:21:41 UTC ---
Only the ICE was a regression; that's fixed, so this is no longer a regression
bug.

[Bug c++/47125] [4.5/4.6 Regression] ICE occurs in combination with partial specialization and invalid template function.

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-03-13 
01:17:17 UTC ---
Author: jason
Date: Sun Mar 13 01:17:14 2011
New Revision: 170919

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170919
Log:
PR c++/47125
* pt.c (tsubst) [TYPENAME_TYPE]: Only give errors if tf_error.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/error45.C
Modified:
branches/gcc-4_5-branch/gcc/cp/ChangeLog
branches/gcc-4_5-branch/gcc/cp/pt.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/45273] [4.4/4.5/4.6 Regression] The compiler depends on the host double (-fprofile-corection only)

[steven at gcc dot gnu.org]

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

--- Comment #4 from Steven Bosscher  2011-03-13 
00:32:06 UTC ---
Created attachment 23643
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23643
Use mpfr in predict.c instead of sreal, and in mcf.c instead of host double

This completely untested patch shows what I'd like to do: Use mpfr instead of
sreal and host double. Comments on the approach welcome.

[Bug lto/48100] [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev  
2011-03-13 00:06:08 UTC ---
Created attachment 23642
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23642
Testcase

[Bug lto/48100] New: [4.6 Regression] Assertion failed in lto_varpool_replace_node, at lto-symtab.c:304

[d.g.gorbachev at gmail dot com]

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

   Summary: [4.6 Regression] Assertion failed in
lto_varpool_replace_node, at lto-symtab.c:304
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com


Created attachment 23641
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23641
Backtrace

[Bug tree-optimization/48098] internal compiler error: in build_vector_from_val, at tree.c:1380

[schnetter at gmail dot com]

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

--- Comment #1 from Erik Schnetter  2011-03-12 
23:30:41 UTC ---
Here is a reduced test case:

void BndRot180VI ()
{
  static char *restrict * slab_setups;
  static int num_slab_setups = 0;
  num_slab_setups = GetRefinementLevels (0);
  slab_setups = malloc (num_slab_setups);
  for (int rl=0; rl

[Bug fortran/48066] [4.3/4.4/4.5 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  2011-03-12 
23:18:11 UTC ---
Author: tkoenig
Date: Sat Mar 12 23:18:09 2011
New Revision: 170913

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170913
Log:
2011-03-12  Thomas Koenig  

PR libfortran/48066
* gfortran.dg/intrinsic_ifunction_2.f90:  Correct PR number.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/intrinsic_ifunction_2.f90

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig  2011-03-12 
23:14:37 UTC ---
Wrong PR number for the previous commit.

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  2011-03-12 
23:13:58 UTC ---
Author: tkoenig
Date: Sat Mar 12 23:13:56 2011
New Revision: 170912

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170912
Log:
2011-03-12  Thomas Koenig  

PR libfortran/40866
* libgfortran/ChangeLog:  Correct PR number.
* gcc/testsuite/ChangeLog:  Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog

[Bug c++/48074] [trans-mem] regular function used instead of clone in a transaction

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Richard Henderson  2011-03-12 
22:59:09 UTC ---
Fixed.

[Bug c++/48074] [trans-mem] regular function used instead of clone in a transaction

[rth at gcc dot gnu.org]

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

--- Comment #2 from Richard Henderson  2011-03-12 
22:58:25 UTC ---
Author: rth
Date: Sat Mar 12 22:58:23 2011
New Revision: 170911

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170911
Log:
PR 48074
* trans-mem.c (ipa_tm_transform_transaction): Don't break after
processing an irrevocable region.

Modified:
branches/transactional-memory/gcc/ChangeLog.tm
branches/transactional-memory/gcc/trans-mem.c

[Bug middle-end/48099] Evaluation order of arguments in a call expression

[ibuclaw at ubuntu dot com]

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

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #23639|0   |1
is obsolete||

--- Comment #2 from Iain Buclaw  2011-03-12 22:56:20 
UTC ---
Created attachment 23640
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23640
corrected diff for 48099

(In reply to comment #1)
> Created attachment 23639 [details]
> diff for 48099

Should be !flag_evaluation_order, sorry.

[Bug middle-end/48099] Evaluation order of arguments in a call expression

[ibuclaw at ubuntu dot com]

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

--- Comment #1 from Iain Buclaw  2011-03-12 22:52:59 
UTC ---
Created attachment 23639
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23639
diff for 48099

[Bug middle-end/48099] New: Evaluation order of arguments in a call expression

[ibuclaw at ubuntu dot com]

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

   Summary: Evaluation order of arguments in a call expression
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ibuc...@ubuntu.com


Using flag_evaluation_order instead of PUSH_ARGS_REVERSE in gimplify_call_expr
shouldn't have any effect on the actual order arguments are actually written,
and gives correct behaviour for frontends that require left-to-right evaluation
of arguments in a call expression. ie:

  i = 1;
  foo(i++, i++, i++); // foo(1,2,3)

Regards

[Bug fortran/48066] [4.3/4.4/4.5 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[4.3/4.4/4.5/4.6|[4.3/4.4/4.5 Regression]
   |Regression] Segfault with   |Segfault with SUM of
   |SUM of zero-sized array |zero-sized array
  Known to fail|4.6.0   |

--- Comment #11 from Thomas Koenig  2011-03-12 
22:50:29 UTC ---
Fixed on 4.6, backport to 4.5 yet to come.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth  2011-03-12 
22:49:40 UTC ---
Opened radar Bug ID# 9126174 for this issue with builtin-attr-1.s attached as
the example of the potential assembler bug in Xcode 3.2.6 and 4.0.1.

[Bug tree-optimization/48098] New: internal compiler error: in build_vector_from_val, at tree.c:1380

[schnetter at gmail dot com]

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

   Summary: internal compiler error: in build_vector_from_val, at
tree.c:1380
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schnet...@gmail.com


Created attachment 23638
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23638
Failing preprocessed source coden

I am using

$ /Users/eschnett/gcc/bin/gcc --version
gcc (GCC) 4.6.0 20110311 (experimental)

$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 170879
Node Kind: directory
Schedule: normal
Last Changed Author: jsm28
Last Changed Rev: 170879
Last Changed Date: 2011-03-11 11:51:29 -0500 (Fri, 11 Mar 2011)

I issue the command

$ /Users/eschnett/gcc/bin/gcc -std=gnu99 -O3 -c rotatingsymmetry180.i

and I receive the error message

/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:
In function ‘BndRot180VI’:
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:495:11:
warning: passing argument 1 of ‘free’ discards ‘restrict’ qualifier from
pointer target type [enabled by default]
/usr/include/stdlib.h:160:6: note: expected ‘void *’ but argument is of type
‘struct slabsetup * restrict* restrict’
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:514:12:
warning: passing argument 5 of ‘Slab_MultiTransfer_Apply’ from incompatible
pointer type [enabled by default]
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/Slab/src/slab.h:113:1:
note: expected ‘const void * const restrict* const restrict’ but argument is of
type ‘void * restrict* restrict’
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:521:12:
warning: passing argument 7 of ‘Slab_MultiTransfer’ from incompatible pointer
type [enabled by default]
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/Slab/src/slab.h:128:1:
note: expected ‘const void * const restrict* const restrict’ but argument is of
type ‘void * restrict* restrict’
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:544:10:
warning: passing argument 10 of ‘Hyperslab_GlobalMappingByIndex’ from
incompatible pointer type [enabled by default]
/Users/eschnett/EinsteinToolkit-hg/configs/sim-gcc46/bindings/include/RotatingSymmetry180_Prototypes.h:61:5:
note: expected ‘int *’ but argument is of type ‘int (*)[3]’
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:716:3:
warning: passing argument 1 of ‘free’ discards ‘restrict’ qualifier from
pointer target type [enabled by default]
/usr/include/stdlib.h:160:6: note: expected ‘void *’ but argument is of type
‘void * restrict* restrict’
/Users/eschnett/EinsteinToolkit-hg/arrangements/CactusNumerical/RotatingSymmetry180/src/rotatingsymmetry180.c:19:5:
internal compiler error: in build_vector_from_val, at tree.c:1380
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The same code compiles fine with gcc 4.5.2. It also compiles fine if I use -O2
instead of -O3.

[Bug c++/40866] [4.5 Regression] ICE in create_tmp_var, at gimplify.c:504

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  2011-03-12 
22:39:38 UTC ---
Author: tkoenig
Date: Sat Mar 12 22:39:33 2011
New Revision: 170908

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170908
Log:
2011-03-12  Thomas Koenig  

PR libfortran/40866
* m4/ifunction.m4:  If return array is empty, return.
* m4/ifunction_logical.m4:  Likewise.
* generated/all_l16.c: Regenerated.
* generated/all_l1.c: Regenerated.
* generated/all_l2.c: Regenerated.
* generated/all_l4.c: Regenerated.
* generated/all_l8.c: Regenerated.
* generated/any_l16.c: Regenerated.
* generated/any_l1.c: Regenerated.
* generated/any_l2.c: Regenerated.
* generated/any_l4.c: Regenerated.
* generated/any_l8.c: Regenerated.
* generated/count_16_l.c: Regenerated.
* generated/count_1_l.c: Regenerated.
* generated/count_2_l.c: Regenerated.
* generated/count_4_l.c: Regenerated.
* generated/count_8_l.c: Regenerated.
* generated/maxloc1_16_i16.c: Regenerated.
* generated/maxloc1_16_i1.c: Regenerated.
* generated/maxloc1_16_i2.c: Regenerated.
* generated/maxloc1_16_i4.c: Regenerated.
* generated/maxloc1_16_i8.c: Regenerated.
* generated/maxloc1_16_r10.c: Regenerated.
* generated/maxloc1_16_r16.c: Regenerated.
* generated/maxloc1_16_r4.c: Regenerated.
* generated/maxloc1_16_r8.c: Regenerated.
* generated/maxloc1_4_i16.c: Regenerated.
* generated/maxloc1_4_i1.c: Regenerated.
* generated/maxloc1_4_i2.c: Regenerated.
* generated/maxloc1_4_i4.c: Regenerated.
* generated/maxloc1_4_i8.c: Regenerated.
* generated/maxloc1_4_r10.c: Regenerated.
* generated/maxloc1_4_r16.c: Regenerated.
* generated/maxloc1_4_r4.c: Regenerated.
* generated/maxloc1_4_r8.c: Regenerated.
* generated/maxloc1_8_i16.c: Regenerated.
* generated/maxloc1_8_i1.c: Regenerated.
* generated/maxloc1_8_i2.c: Regenerated.
* generated/maxloc1_8_i4.c: Regenerated.
* generated/maxloc1_8_i8.c: Regenerated.
* generated/maxloc1_8_r10.c: Regenerated.
* generated/maxloc1_8_r16.c: Regenerated.
* generated/maxloc1_8_r4.c: Regenerated.
* generated/maxloc1_8_r8.c: Regenerated.
* generated/maxval_i16.c: Regenerated.
* generated/maxval_i1.c: Regenerated.
* generated/maxval_i2.c: Regenerated.
* generated/maxval_i4.c: Regenerated.
* generated/maxval_i8.c: Regenerated.
* generated/maxval_r10.c: Regenerated.
* generated/maxval_r16.c: Regenerated.
* generated/maxval_r4.c: Regenerated.
* generated/maxval_r8.c: Regenerated.
* generated/minloc1_16_i16.c: Regenerated.
* generated/minloc1_16_i1.c: Regenerated.
* generated/minloc1_16_i2.c: Regenerated.
* generated/minloc1_16_i4.c: Regenerated.
* generated/minloc1_16_i8.c: Regenerated.
* generated/minloc1_16_r10.c: Regenerated.
* generated/minloc1_16_r16.c: Regenerated.
* generated/minloc1_16_r4.c: Regenerated.
* generated/minloc1_16_r8.c: Regenerated.
* generated/minloc1_4_i16.c: Regenerated.
* generated/minloc1_4_i1.c: Regenerated.
* generated/minloc1_4_i2.c: Regenerated.
* generated/minloc1_4_i4.c: Regenerated.
* generated/minloc1_4_i8.c: Regenerated.
* generated/minloc1_4_r10.c: Regenerated.
* generated/minloc1_4_r16.c: Regenerated.
* generated/minloc1_4_r4.c: Regenerated.
* generated/minloc1_4_r8.c: Regenerated.
* generated/minloc1_8_i16.c: Regenerated.
* generated/minloc1_8_i1.c: Regenerated.
* generated/minloc1_8_i2.c: Regenerated.
* generated/minloc1_8_i4.c: Regenerated.
* generated/minloc1_8_i8.c: Regenerated.
* generated/minloc1_8_r10.c: Regenerated.
* generated/minloc1_8_r16.c: Regenerated.
* generated/minloc1_8_r4.c: Regenerated.
* generated/minloc1_8_r8.c: Regenerated.
* generated/minval_i16.c: Regenerated.
* generated/minval_i1.c: Regenerated.
* generated/minval_i2.c: Regenerated.
* generated/minval_i4.c: Regenerated.
* generated/minval_i8.c: Regenerated.
* generated/minval_r10.c: Regenerated.
* generated/minval_r16.c: Regenerated.
* generated/minval_r4.c: Regenerated.
* generated/minval_r8.c: Regenerated.
* generated/product_c10.c: Regenerated.
* generated/product_c16.c: Regenerated.
* generated/product_c4.c: Regenerated.
* generated/product_c8.c: Regenerated.
* generated/product_i16.c: Regenerated.
* generated/product_i1.c: Regenerated.
* generated/product_i2.c: Regenerated.
* generated/product_i4.c: Regenerated.
* generated/product_i8.c: Regenerated.
* generated/product_r10.c: Regenerated.
* generated/product_r16.c: Regenerated.
* generated/product_r4.c: Regenerated.
* generated/product_r8.c: Regenerated.
* generated/sum_c10.c: Regenerated.
* generated/sum_c16.c: Regenerated.
* generated/sum_c4.c: Regenerated.
* generated/sum_c8.c: Regenerated.
* generated/sum_i16.c: Regenerated.
   

[Bug c++/48074] [trans-mem] regular function used instead of clone in a transaction

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.12 22:23:34
 AssignedTo|unassigned at gcc dot   |rth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Henderson  2011-03-12 
22:23:34 UTC ---
Confirmed.

The dumps suggest that it we intended to mark the first transaction
as pr_uninstrumentedCode, so that the transaction begins as serial
irrevocable.  The second transaction does get so marked; the first 
does not.

[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Sebastian Pop  2011-03-12 22:06:22 
UTC ---
Fixed.

[Bug middle-end/47127] gcc.dg/graphite/id-14.c ICEs with cloog-parma

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  2011-03-12 22:05:41 
UTC ---
Author: spop
Date: Sat Mar 12 22:05:38 2011
New Revision: 170907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170907
Log:
Fix PR47127: call cloog_state_malloc and cloog_state_free only once.

2011-03-12  Sebastian Pop  

PR tree-optimization/47127
* graphite-clast-to-gimple.c (build_cloog_prog): Removed state
parameter.
(set_cloog_options): Same.
(scop_to_clast): Same.
(print_clast_stmt): Do not call cloog_state_malloc and
cloog_state_free.
(print_generated_program): Same.
(gloog): Same.
* graphite-clast-to-gimple.h (cloog_state): Declared.
(scop_to_clast): Adjust declaration.
* graphite.c (cloog_state): Defined here.
(graphite_initialize): Call cloog_state_malloc.
(graphite_finalize): Call cloog_state_free.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-clast-to-gimple.c
trunk/gcc/graphite-clast-to-gimple.h
trunk/gcc/graphite.c

[Bug c++/48075] [trans-mem] infinite loop when compiling

[rth at gcc dot gnu.org]

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

--- Comment #1 from Richard Henderson  2011-03-12 
22:03:29 UTC ---
It is not TM related.  If you remove the TM constructs, the test case
still crashes with stack overflow in mainline.  Of course, there are
a number of errors produced beforehand, which puts this as an 
ice-on-illegal test, which would be lower priority.

Can you reduce this test case again without the errors?

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |tkoenig at gcc dot gnu.org
   |gnu.org |

--- Comment #10 from Thomas Koenig  2011-03-12 
21:42:39 UTC ---
Mine.

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth  2011-03-12 
21:31:36 UTC ---
The same executable examined with Xcode 4.0's lldb shows...


[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] howarth%
/Developer/usr/bin/lldb ./Throw_2.exe
Current executable set to './Throw_2.exe' (x86_64).
(lldb) r
Process 36422 launched:
'/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe'
(x86_64)
(lldb) 1
(lldb) Process 36422 stopped
1 of 2 threads stopped with reasons:
* thread #1: tid = 0x2d03, 0x00010043aa70 libgcj.12.dylib`int
java::lang::String::length() at String.java:451, stop reason = EXC_BAD_ACCESS
(code=1, address=0x14)
 448  */
 449 public int length()
 450 {
 451 ->return count;
 452 }
 453   
 454 /**
(lldb) bt
thread #1: tid = 0x2d03, stop reason = EXC_BAD_ACCESS (code=1, address=0x14)
  frame #0: 0x00010043aa70 libgcj.12.dylib`int java::lang::String::length()
at String.java:451
  frame #1: 0x000100072ca9 libgcj.12.dylib`double
java::lang::VMDouble::parseDouble(java::lang::String*) + 25 at
natVMDouble.cc:165
  frame #2: 0x0001004391ba libgcj.12.dylib`double
java::lang::Double::parseDouble(java::lang::String*) + 26 at Double.java:348
  frame #3: 0x00011adc Throw_2.exe`void
Throw_2::main(JArray*) + 474 at Throw_2.java:47
  frame #4: 0x00010006695e libgcj.12.dylib`void
gnu::java::lang::MainThread::call_main() + 206 at natMainThread.cc:54
  frame #5: 0x0001000d1e44 libgcj.12.dylib`void
gnu::java::lang::MainThread::run() + 68 at MainThread.java:106
  frame #6: 0x00010007785a
libgcj.12.dylib`_Jv_ThreadRun(java::lang::Thread*) + 42 at natThread.cc:335
  frame #7: 0x00010002b322 libgcj.12.dylib`_Jv_RunMain(_Jv_VMInitArgs*,
java::lang::Class*, char const*, int, char const**, bool) + 306 at
prims.cc:1789
  frame #8: 0x00010002b51a libgcj.12.dylib`_Jv_RunMain(java::lang::Class*,
char const*, int, char const**, bool) + 26 at prims.cc:1814
  frame #9: 0x00010002b553 libgcj.12.dylib`JvRunMain + 19 at prims.cc:1820
  frame #10: 0x0001189f Throw_2.exe`main + 61 at ccP0miy8.i:11
  frame #11: 0x00011840 Throw_2.exe`start + 52
(lldb)

[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2011-03-12 
21:26:32 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ../gcc-4.6-20110311/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

--- Comment #6 from Mikael Pettersson  2011-03-12 
21:19:40 UTC ---
The test case was fixed for 4.6 by r159644.  However, that patch
 was described as a
minor improvement to double-word register allocation and not a correctness fix,
so the underlying bug may be latent on trunk.

I'll investigate some more tomorrow.

[Bug target/48097] New: new Throw_2 failures in libjava under Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

   Summary: new Throw_2 failures in libjava under Xcode 4.0
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The libjava testsuite exhibits four new execution failures for Throw_2 when
Xcode 4.0 is installed...


FAIL: Throw_2 execution - source compiled test
FAIL: Throw_2 -findirect-dispatch execution - source compiled test
FAIL: Throw_2 -O3 execution - source compiled test
FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test

These are not present when Xcode 3.2.5 is used for cctools. These fail as
follows...

[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root#
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/../libtool
--silent --tag=GCJ --mode=link
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/gcj
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/bin/
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/lib/ -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/include -isystem
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/sys-include--encoding=UTF-8
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/libjava/testsuite/libjava.lang/Throw_2.jar
 -w  -bind_at_load -multiply_defined suppress -Wl,-allow_stack_execute
--main=Throw_2 -g 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libjava/.libs
-lm   -m64 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe
[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root# ./Throw_2.exe
1
Abort

It is interesting that the gdb from Xcode 4.0 doesn't like this executable...


[MacPro:x86_64-apple-darwin10.7.0/libjava/testsuite] root# gdb ./Throw_2.exe
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries 
warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/iconv.o" - no debug
information available for "./iconv.c".


warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/localcharset.o" -
no debug information available for "./../libcharset/lib/localcharset.c".


warning: Could not find object file
"/sw/src/fink.build/libiconv-1.12-4/libiconv-1.12/lib/.libs/relocatable.o" - no
debug information available for "./relocatable.c".

.. done

gdb stack crawl at point of internal error:
0   gdb-i386-apple-darwin   0x00010010a10a internal_vproblem +
308
1   gdb-i386-apple-darwin   0x00010010a2e4 internal_verror + 27
2   gdb-i386-apple-darwin   0x00010010a382 align_down + 0
3   gdb-i386-apple-darwin   0x0001000b4426
find_partial_die_in_comp_unit + 88
4   gdb-i386-apple-darwin   0x0001000bff8b find_partial_die +
628
5   gdb-i386-apple-darwin   0x0001000bffd8 fixup_partial_die +
55
6   gdb-i386-apple-darwin   0x0001000c06cd scan_partial_symbols
+ 58
7   gdb-i386-apple-darwin   0x0001000c15a9
dwarf2_build_psymtabs + 3006
8   gdb-i386-apple-darwin   0x00010014e1e0 macho_symfile_read +
299
9   gdb-i386-apple-darwin   0x00010004fe18 syms_from_objfile +
1403
10  gdb-i386-apple-darwin   0x0001000508bb
symbol_file_add_with_addrs_or_offsets_using_objfile + 780
11  gdb-i386-apple-darwin   0x000100050872
symbol_file_add_with_addrs_or_offsets_using_objfile + 707
12  gdb-i386-apple-darwin   0x000100050b69
symbol_file_add_name_with_addrs_or_offsets + 119
13  gdb-i386-apple-darwin   0x000100051031
symbol_file_add_main_1 + 207
14  gdb-i386-apple-darwin   0x00010007 catch_command_errors
+ 65
/SourceCache/gdb/gdb-1518/src/gdb/dwarf2read.c:8388: internal-error: could not
find partial DIE in cache

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

(gdb) r
Starting program:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libjava/testsuite/Throw_2.exe
 
Reading symbols for shared libraries . done
Reading

[Bug target/48096] gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE fails with Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2011-03-12 
21:10:27 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ../gcc-4.6-20110311/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

[Bug target/48096] gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE fails with Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

--- Comment #2 from Jack Howarth  2011-03-12 
21:12:40 UTC ---
A similar failure is seen for  g++.dg/tree-prof/partition1.C compilation,  -g 
-fprofile-use...


Executing on host:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/g++.dg/tree-prof/partition1.C
 -nostdinc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/include/x86_64-apple-darwin10.7.0
-I/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/libstdc++-v3/testsuite/util
-fmessage-length=0  -g  -O2 -freorder-blocks-and-partition -fprofile-use   
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libstdc++-v3/src/.libs

-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libstdc++-v3/src/.libs

-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/./libiberty
 -multiply_defined suppress -lm   -m64 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/g++/partition1.x02
   (timeout = 300)
Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-123.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1512.^M
0  0x10001286c  __assert_rtn + 76^M
1  0x100043bc9 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1097^M
2  0x10001ed87  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 295^M
3  0x1000183ef  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 159^M
4  0x1000727a1  ld::tool::InputFiles::makeFile(Options::FileInfo const&) +
497^M
5  0x100073f79  ld::tool::InputFiles::InputFiles(Options&, char const**) +
697^M
6  0x100012a97  main + 311^M
7  0x10e14  start + 52^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-123.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1512.^M
0  0x10001286c  __assert_rtn + 76^M
1  0x100043bc9 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1097^M
2  0x10001ed87  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 295^M
3  0x1000183ef  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 159^M
4  0x1000727a1  ld::tool::InputFiles::makeFile(Options::FileInfo const&) +
497^M
5  0x100073f79  ld::tool::InputFiles::InputFiles(Options&, char const**) +
697^M
6  0x100012a97  main + 311^M
7  0x10e14  start + 52^M
collect2: ld returned 1 exit status^M

FAIL: g++.dg/tree-prof/partition1.C compilation,  -g  -fprofile-use
UNRESOLVED: g++.dg/tree-prof/partition1.C execution,-g  -fprofile-use

[Bug target/48096] New: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE fails with Xcode 4.0

[howarth at nitro dot med.uc.edu]

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

   Summary: gcc.dg/tree-prof/bb-reorg.c compilation,
-fprofile-use -D_PROFILE_USE fails with Xcode 4.0
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


The new Xcode 4.0 linker causes the gcc.dg/tree-prof/bb-reorg.c compilation, 
-fprofile-use -D_PROFILE_USE test case to fail as follows...


Running
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp
...Executing on host:
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/tree-prof/bb-reorg
.c   -O2 -freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE 
-lm   -m64 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gcc/bb-reorg.x01
   (timeout = 300)
PASS: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-generate
-D_PROFILE_GENERATE
Setting LD_LIBRARY_PATH to
:/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc::/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc
PASS: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-generate
-D_PROFILE_GENERATE
Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20110311/gcc/testsuite/gcc.dg/tree-prof/bb-reorg
.c   -O2 -freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE  -lm  
-m64 -o
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/testsuite/gcc/bb-reorg.x02
   (timeout = 300)
Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-123.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1512.^M
0  0x10001286c  __assert_rtn + 76^M
1  0x100043bc9 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1097^M
2  0x10001ed87  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 295^M
3  0x1000183ef  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 159^M
4  0x1000727a1  ld::tool::InputFiles::makeFile(Options::FileInfo const&) +
497^M
5  0x100073f79  ld::tool::InputFiles::InputFiles(Options&, char const**) +
697^M
6  0x100012a97  main + 311^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse,
file /SourceCache/ld64/ld64-123.2/src/ld/parsers/macho_relocatable_file.cpp,
line 1512.^M0  0x10001286c  __assert_rtn + 76^M1  0x100043bc9 
mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions
const&) + 1097^M
2  0x10001ed87  mach_o::relocatable::Parser::parse(unsigned char
const*, unsigned long long, char const*, long, unsigned int,
mach_o::relocatable::ParserOptions const&) + 295^M
3  0x1000183ef  mach_o::relocatable::parse(unsigned char const*, unsigned long
long, char const*, long, unsigned int, mach_o::relocatable::ParserOptions
const&) + 159^M
4  0x1000727a1  ld::tool::InputFiles::makeFile(Options::FileInfo const&) +
497^M
5  0x100073f79  ld::tool::InputFiles::InputFiles(Options&, char const**) +
697^M6  0x100012a97  main + 311^Mcollect2: ld returned 1 exit status^M

FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use
-D_PROFILE_USE

Either we are generating invalid mach-o or have exposed a bug in Xcode 4.0's
linker.

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Iain Sandoe  2011-03-12 18:34:51 
UTC ---
(In reply to comment #2)

> (b) the second needs more checking - the tests pass on darwin9 (and darwin10
> with 3.2.5 - last time I tried)

it looks like the .lazy_reference to . objc_class_name_myRootObject is getting
dropped somewhere;
in this instance, because the code is self-contained, it works OK (when ld
doesn't barf).

... in other cases in the test-suite, the only external object is usually
"Object" which is in libobjc and therefore it also works.

I have an idea about getting rid of the TARGET_ASM method to make these
references and use a real variable to carry the information (just make it
zero-sized, and use that + a meta-data tag to emit the efficient asm).   I was
intending to make that a stage-1 investigation -- but perhaps it might warrant
trying sooner.

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.03.12 17:48:56
 Ever Confirmed|0   |1

--- Comment #2 from Iain Sandoe  2011-03-12 17:48:56 
UTC ---

(a) the first is because LTO has produced two image_info instances with
different mangled names ...

 e.g. L_OBJC_ImageInfo.2044 / L_OBJC_ImageInfo.2048

 this is visible on darwin 9 (although it does not produce an error).

(b) the second needs more checking - the tests pass on darwin9 (and darwin10
with 3.2.5 - last time I tried)

[Bug fortran/48095] [OOP] Invalid assignment to procedure pointer component not rejected

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org 2011-03-12 17:46:44 UTC ---
(In reply to comment #0)
> I think it is invalid, because the PPC 'get_special_area' is declared to 
> expect
> a CLASS argument, but then the procedure it points to has a TYPE argument.
> 
> One should check the standard on this.

The relevant F08 quote is:

"7.2.2.4 Procedure pointer assignment"
[...]
"If the pointer object has an explicit interface, its characteristics shall be
the same as the pointer target except that the pointer target may be pure even
if the pointer object is not pure and the pointer target may be an elemental
intrinsic procedure even if the pointer object is not elemental."


cf. also PR 46990 comment 6.

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2011-03-12 
17:38:12 UTC ---
Created attachment 23637
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23637
standalone test case

Reduced standalone test case.  Fails with gcc-4.5-20110310 -march=armv5t, works
with -march=armv5te.  Also works with gcc-4.4 and gcc-4.6.

[Bug fortran/48095] New: [OOP] Invalid assignment to procedure pointer component not rejected

[janus at gcc dot gnu.org]

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

   Summary: [OOP] Invalid assignment to procedure pointer
component not rejected
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


Reported by Arjen Markus at
http://gcc.gnu.org/ml/fortran/2011-03/msg00057.html:

The following program (slightly modified from the original) does not produce
the expected result:


module proc_pointers

  implicit none

  type :: rectangle
real :: width, height
procedure(get_area), pointer, pass(this) :: get_special_area => get_my_area
  end type rectangle

  abstract interface
real function get_area( this )
  import   :: rectangle
  class(rectangle), intent(in) :: this
end function get_area
  end interface

contains

  real function get_my_area( this )
type(rectangle), intent(in) :: this
write(*,*) 'This: ', this%width, this%height
get_my_area = 3.0 * this%width * this%height
  end function get_my_area

end module proc_pointers


program test_objects

   use proc_pointers
   implicit none

   type(rectangle) :: rect
   real:: area

   rect  = rectangle (1.0,2.0)
   write(*,*) 'Rect: ', rect%width, rect%height
   area = rect%get_special_area()
   write(*,*) 'Special area:', area

end program test_objects


I think it is invalid, because the PPC 'get_special_area' is declared to expect
a CLASS argument, but then the procedure it points to has a TYPE argument.

One should check the standard on this.

[Bug lto/48094] ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[howarth at nitro dot med.uc.edu]

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

--- Comment #1 from Jack Howarth  2011-03-12 
17:32:18 UTC ---
Using built-in specs.
COLLECT_GCC=gcc-4
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.7.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.7.0
Configured with: ../gcc-4.6-20110311/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.6 --enable-checking=yes --enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.0 20110312 (experimental) (GCC)

[Bug lto/48094] New: ld: warning: section has unexpectedly large size errors in objc/obj-c++ lto

[howarth at nitro dot med.uc.edu]

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

   Summary: ld: warning: section has unexpectedly large size
errors in objc/obj-c++ lto
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


A large number of new failures occur in the objc/obj-c++ testsuite when built
under Xcode 4.0 on x86_64-apple-darwin10. These failures are all of the form...

Executing on host: /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ objc_lto_trivial-1_0.o
 -O0 -flto -flto-partition=none -fnext-runtime  
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs
 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/i386/libobjc/.libs
  -lobjc -m32 -o objc-dg-lto-trivial-1-21(timeout = 300)
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccMlEsXS.lto.o^M
Undefined symbols for architecture i386:^M
  ".objc_class_name_myRootObject", referenced from:^M
  pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
  pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
ld: symbol(s) not found for architecture i386^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
ld: warning: section __OBJC/__image_info has unexpectedly large size 16 in
/var/tmp//ccMlEsXS.lto.o^M
Undefined symbols for architecture i386:^M
  ".objc_class_name_myRootObject", referenced from:^M
  pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
  pointer-to-literal-objc-class-name in ccMlEsXS.lto.o^M
ld: symbol(s) not found for architecture i386^M
collect2: ld returned 1 exit status^M

FAIL: objc.dg/lto/trivial-1 objc_lto_trivial-1_0.o-objc_lto_trivial-1_0.o link,
-O0 -flto -flto-partition=none -fnext-runtime

The ld warning for "unexpectedly large size" is always associated with an
undefined symbol for .objc_class_name_myRootObject.

[Bug fortran/47845] [OOP] Polymorphic deferred function: Not matched class

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from janus at gcc dot gnu.org 2011-03-12 17:23:17 UTC ---
(In reply to comment #3)
> Are there other issues in the bug report? From comment 0 it is a bit unclear 
> to
> me what the issue is - besides the non-issue mentioned in comment 1.
> 
> If there is no issue left, I would like to close this problem report (PR).

Closing as invalid.

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  2011-03-12 
17:22:50 UTC ---
This one looks better:

Index: m4/ifunction_logical.m4  
===
--- m4/ifunction_logical.m4 (Revision 170897)  
+++ m4/ifunction_logical.m4 (Arbeitskopie) 
@@ -149,7 +149,7 @@

   dest = retarray->data;  

-  continue_loop = 1;  
+  continue_loop = len > 0;
   while (continue_loop)   
 { 
   const GFC_LOGICAL_1 * restrict src; 
@@ -158,17 +158,12 @@  
   {   
 ')dnl 
 define(START_ARRAY_BLOCK, 
-`if (len <= 0)
- *dest = '$1`;
-   else   
+`  for (n = 0; n < len; n++, src += delta)
  {
-   for (n = 0; n < len; n++, src += delta)
- {
 ')dnl 
 define(FINISH_ARRAY_FUNCTION, 
-`  }  
-   *dest = result;
- }
+`}
+   *dest = result;
   }   
   /* Advance to the next element.  */ 
   count[0]++; 
Index: m4/ifunction.m4
===
--- m4/ifunction.m4 (Revision 170897)
+++ m4/ifunction.m4 (Arbeitskopie)
@@ -122,7 +122,7 @@
   base = array->data;
   dest = retarray->data;

-  continue_loop = 1;
+  continue_loop = len > 0;
   while (continue_loop)
 {
   const atype_name * restrict src;
@@ -131,18 +131,13 @@
   {
 ')dnl
 define(START_ARRAY_BLOCK,
-`  if (len <= 0)
- *dest = '$1`;
-   else
+`  for (n = 0; n < len; n++, src += delta)
  {
-   for (n = 0; n < len; n++, src += delta)
- {
 ')dnl
 define(FINISH_ARRAY_FUNCTION,
-`}
-   '$1`
-   *dest = result;
- }
+`}
+   '$1`
+   *dest = result;
   }
   /* Advance to the next element.  */
   count[0]++;

Let's see if it survives regression-testing.

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #14 from janus at gcc dot gnu.org 2011-03-12 17:01:20 UTC ---
Fixed with r170906. Thanks for the report, Hans!

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org 2011-03-12 16:58:36 UTC ---
Author: janus
Date: Sat Mar 12 16:58:33 2011
New Revision: 170906

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170906
Log:
2011-03-12  Janus Weil  

PR fortran/48059
* trans-expr.c (gfc_apply_interface_mapping_to_expr): Replace base type
for polymorphic arguments.

2011-03-12  Janus Weil  

PR fortran/48059
* gfortran.dg/class_41.f03: New.

Added:
trunk/gcc/testsuite/gfortran.dg/class_41.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[mikestump at comcast dot net]

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

--- Comment #11 from Mike Stump  2011-03-12 
16:23:45 UTC ---
Ok for the patch in comment #9.

[Bug other/48093] New: -mtls-dialect= is undocumented

[hjl.tools at gmail dot com]

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

   Summary: -mtls-dialect= is undocumented
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: aol...@gcc.gnu.org


Gcc supports -mtls-dialect=gnu2.  But it is undocumented.

[Bug fortran/48059] [4.6 Regression][OOP] ICE in in gfc_conv_component_ref: character function of extended type

[paul.richard.thomas at gmail dot com]

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

--- Comment #12 from paul.richard.thomas at gmail dot com  2011-03-12 16:07:47 UTC ---
Ha! That's what I suspected.

Good.  I'll OK the submission.

Thanks

Paul

PS I'll keep quiet about it being a bit of a dubious "regression" :-)

On Fri, Mar 11, 2011 at 4:57 PM, janus at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
>
> --- Comment #10 from janus at gcc dot gnu.org 2011-03-11 15:57:47 UTC ---
> (In reply to comment #9)
>> That looks like the right way to go.  Do you understand how this can
>> be a regression, whilst the correct interface mapping was previously
>> not present :-)  ?
>
> Well, I think gfortran 4.5 just silently produced wrong code, and then
> Michael's patch triggered the ICE (uncovering a bug that had been there
> before).
>
> The dump with my patch shows
>
>      D.1574 = D.1572->_data->a_type.length;
>
> while 4.5 gives:
>
>      D.1565 = D.1563->$data->length;
>
> (missing the "a_type" parent reference).
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
>

[Bug target/48084] [x32] internal compiler error: in copy_to_mode_reg, at explow.c:630

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  2011-03-12 
15:50:41 UTC ---
Author: hjl
Date: Sat Mar 12 15:50:38 2011
New Revision: 170904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170904
Log:
Convert to Pmode if needed.

gcc/

2011-03-12  H.J. Lu  

PR target/48084
* explow.c (copy_addr_to_reg): Convert to Pmode if needed.

gcc/testsuite/

2011-03-12  H.J. Lu  

PR target/48084
* gcc.target/i386/pr48084-5.c: New.

Added:
branches/x32/gcc/testsuite/gcc.target/i386/pr48084-5.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/explow.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  2011-03-12 
15:42:13 UTC ---
I have a runtime test case (given test file + separate file with main and
missing support functions) that works with gcc-4.5-20110310 -march=armv5te but
fails with -march=armv5t.  gcc-4.4.5 and 4.6-20110305 work with both armv5te
and armv5t.

[Bug target/48084] [x32] internal compiler error: in copy_to_mode_reg, at explow.c:630

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  2011-03-12 
15:41:24 UTC ---
Author: hjl
Date: Sat Mar 12 15:41:20 2011
New Revision: 170902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170902
Log:
Convert memory to Pmode if needed.

gcc/

2011-03-11  H.J. Lu  

PR target/48084
* config/i386/i386.c (ix86_expand_special_args_builtin): Convert
memory to Pmode if needed.
(ix86_expand_builtin): Likewise.

gcc/testsuite/

2011-03-11  H.J. Lu  

PR target/48084
* gcc.target/i386/pr48084-1.c: New.
* gcc.target/i386/pr48084-2.c: Likewise.
* gcc.target/i386/pr48084-3.c: Likewise.
* gcc.target/i386/pr48084-4.c: Likewise.

Added:
branches/x32/gcc/testsuite/gcc.target/i386/pr48084-1.c
branches/x32/gcc/testsuite/gcc.target/i386/pr48084-2.c
branches/x32/gcc/testsuite/gcc.target/i386/pr48084-3.c
branches/x32/gcc/testsuite/gcc.target/i386/pr48084-4.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/config/i386/i386.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug libfortran/47439] Fun with scratch files on Windows MKTEMP only allows for 26 files

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
URL||http://gcc.gnu.org/ml/fortr
   ||an/2011-03/msg00102.html
   Last reconfirmed||2011.03.12 15:22:42
 Ever Confirmed|0   |1

--- Comment #2 from Francois-Xavier Coudert  
2011-03-12 15:22:42 UTC ---
A patch for the first half of the PR can be found here:
http://gcc.gnu.org/ml/fortran/2011-03/msg00102.html

[Bug target/48084] [x32] internal compiler error: in copy_to_mode_reg, at explow.c:630

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2011-03-12 15:22:11 
UTC ---
Another one

[hjl@gnu-6 ilp32-31]$ cat r.i
 int
_rdrand16_step (unsigned short *__P)
{
  return __builtin_ia32_rdrand16_step (__P);
}
[hjl@gnu-6 ilp32-31]$ make r.s
/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o r.s -mx32  -march=k8
-msse4a -m3dnow -mavx -mfma4 -mxop -maes -mpclmul -mpopcnt -mabm -mbmi -mtbm
-mlwp -mfsgsbase -mrdrnd -mf16c  r.i
r.i: In function \u2018_rdrand16_step\u2019:
r.i:4:3: internal compiler error: in copy_to_mode_reg, at explow.c:630
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [r.s] Error 1
[hjl@gnu-6 ilp32-31]$

[Bug tree-optimization/48092] New: associative property of sqrt

[vincenzo.innocente at cern dot ch]

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

   Summary: associative property of sqrt
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch


Is there any reason why (with -Ofast or -ffast-math) associative properties of
sqrt are not exploited as for instance those of division?

examples
division (ok)

float div1(float a, float x, float y) {
   return a/x/y;
   0:   f3 0f 59 ca mulss  %xmm2,%xmm1
   4:   f3 0f 5e c1 divss  %xmm1,%xmm0
}

sqrt

float sqrt1(float a, float x, float y) {
   return a*std::sqrt(x)*std::sqrt(y);
  10:   f3 0f 51 d2 sqrtss %xmm2,%xmm2
  14:   f3 0f 51 c9 sqrtss %xmm1,%xmm1
  18:   f3 0f 59 ca mulss  %xmm2,%xmm1
  1c:   f3 0f 59 c8 mulss  %xmm0,%xmm1
}
  20:   0f 28 c1movaps %xmm1,%xmm0

and


float rsqrt1(float a, float x, float y) {
   return a/std::sqrt(x)/std::sqrt(y);
  30:   f3 0f 51 c9 sqrtss %xmm1,%xmm1
  34:   f3 0f 51 d2 sqrtss %xmm2,%xmm2
  38:   f3 0f 59 d1 mulss  %xmm1,%xmm2
  3c:   f3 0f 5e c2 divss  %xmm2,%xmm0
}

in this second case I would have at least expected the use of 
"rsqrtss" to take precedence above the associative property of "div"
emitting the same code as below

float rsqrt2(float a, float x, float y) {
   return a/sqrtf(x*y);
  70:   f3 0f 59 ca mulss  %xmm2,%xmm1
  74:   f3 0f 52 d9 rsqrtss %xmm1,%xmm3
  78:   f3 0f 59 cb mulss  %xmm3,%xmm1
  7c:   f3 0f 59 cb mulss  %xmm3,%xmm1
  80:   f3 0f 59 1d 00 00 00mulss  0(%rip),%xmm3# 88 
  87:   00 
84: R_X86_64_PC32   .LC1+0xfffc
  88:   f3 0f 58 0d 00 00 00addss  0(%rip),%xmm1# 90 
  8f:   00 
8c: R_X86_64_PC32   .LC0+0xfffc
  90:   f3 0f 59 cb mulss  %xmm3,%xmm1
  94:   f3 0f 59 c8 mulss  %xmm0,%xmm1
}
  98:   0f 28 c1movaps %xmm1,%xmm0

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  2011-03-12 13:45:38 
UTC ---
patch @ comment #9 works for me on *-darwin9 (places the strings in .cstring).

I would propose this rather than the one in comment #2.

[Bug c/48088] -Werror=frame-larger-than=100 does not work as expected

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  2011-03-12 
13:45:09 UTC ---
I think in general Werror= doesn't work for options that take arguments.

[Bug c++/48089] [C++0x] ICE on in(?)valid in constexpr constructors

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-03-12 
13:20:53 UTC ---
N.B. I don't think there's any GCC extension involving initializing class
members with themselves. Doing so is almost certainly a mistake.

[Bug c++/48089] [C++0x] ICE on in(?)valid in constexpr constructors

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.12 13:11:18
Version|unknown |4.6.0
Summary|ICE on in(?)valid in|[C++0x] ICE on in(?)valid
   |constexpr constructors  |in constexpr constructors
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-03-12 
13:11:18 UTC ---
I guess an ICE is one way to solve the missing diagnostic for PR 18016 ;)

4.5 didn't ICE, but then constexpr was ignored so I'm not sure it counts as a
regression

[Bug inline-asm/37895] AVR inline assembly clobbers input value

[avr at gjlay dot de]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||eric.weddington at atmel
   ||dot com

--- Comment #2 from Georg-Johann Lay  2011-03-12 13:01:13 
UTC ---
I can not confirm the problems for WinAVR-20071221 (gcc 4.2.2)

With the following function

int32_t test_mul (void)
{
int32_t res = mul_16_8(0x1234, 0x56);
return res;
}

Both the generated code and the result of the computation (400760 in that
specific case) are as expected.

Presumably there is an error in your code outside the snippet (which we aren't
allowed to see), maybe some signed/undigned clashes, promotion problems,
overflows, etc.

The code compiles with 
  -S -Os -mmcu=atmega88 -fverbose-asm
to


test_mul:
/* prologue: frame size=0 */
/* prologue end (size=0) */
ldi r24,lo8(4660) ;  tmp43,
ldi r25,hi8(4660) ;  tmp43,
ldi r18,lo8(86) ;  tmp44,
movw r20,r24 ; , tmp43
/* #APP */
clr r24; ;  res
clr r25; ;  res
mul r20, r18; ; , tmp44
movw r22, r0; ;  res
mul r21, r18; ; , tmp44
add r23, r0; ;  res
adc r24, r1; ;  res
clr __zero_reg__

/* #NOAPP */
/* epilogue: frame size=0 */
ret

which is correct. gcc respects the early-clobber, i.e. the output operand
(r22-r25) does not overlap an input operand (r20-r21 and r18).

IMO this bug is invalid and can be closed.

Johann

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[arnaud.pat...@rtp-net.org]

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

--- Comment #3 from arnaud patard  2011-03-12 
12:16:12 UTC ---
(In reply to comment #2)
> I get correct-looking code on armv5tel-linux with vanilla gcc-4.6-20110305 and
> gcc-4.5-20110310, with 4.4 the code looks different but not obviously broken.

I said -march=armv5t (or -march=armv4t I guess). It's important as
-march=armv5te won't trigger the bug.

>
> Can you make the test case standalone and include a runtime check for the
> possible miscompilation?

My test case was to build tar and run the delete01.at check but it's not really
a standalone test.
So far, I've not managed to have a test case small than compiling the
preprocessed file.

> 
> How was your gcc configured?

I reproduce it with my gcc and debian gcc 4.5.2 so I believe this rules out
misconfiguration.

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson  2011-03-12 
12:03:18 UTC ---
I get correct-looking code on armv5tel-linux with vanilla gcc-4.6-20110305 and
gcc-4.5-20110310, with 4.4 the code looks different but not obviously broken.

Can you make the test case standalone and include a runtime check for the
possible miscompilation?

How was your gcc configured?

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin10   |*-apple-darwin{9,10}
   Host|x86_64-apple-darwin10   |*-apple-darwin{9,10}
  Build|x86_64-apple-darwin10   |*-apple-darwin{9,10}

--- Comment #5 from Iain Sandoe  2011-03-12 11:31:37 
UTC ---
to clarify/as a reminder;

-  this limitation (n_sect  8 bits) is the reason that GNU_LTO sections are
kept separate and emitted at the end of the object file on Darwin.
 - there are no symbols in these sections, so they will not be referred to in
the symtab - therefore, we should never overflow the section reference.

we need to investigate if something is broken in those assumptions - or whether
'as' is just telling us something we already knew.

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Priority|P2  |P3
 CC||rguenth at gcc dot gnu.org,
   ||steven at gcc dot gnu.org

--- Comment #11 from Steven Bosscher  2011-03-12 
11:08:20 UTC ---
Why is this not a P1 bug? Seems to me it fits the criteria for that:

1. mipsisa64-elf is a primary target and afaiu mipsisa64-elf is in mips*-*
2. this is a wrong-code bug
3. it is a regression from earlier GCC releases

Adding RM to CC and "downgrading" to P3 to bring this bug up on the RM's radar.

[Bug middle-end/47691] [4.6 Regression] ICE: in create_linear_expr_from_tree, at graphite-sese-to-poly.c:1138 with -fgraphite-identity -ffast-math -fno-tree-scev-cprop

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug libfortran/48054] Documentation for LOG intrinsic function is ambiguous

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||documentation
 CC||fxcoudert at gcc dot
   ||gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.6.0
   Severity|normal  |minor

--- Comment #2 from Francois-Xavier Coudert  
2011-03-12 10:39:19 UTC ---
Fixed on trunk, thanks for the bug report!

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #6 from Francois-Xavier Coudert  
2011-03-12 10:35:59 UTC ---
Fixed on trunk. CTIME is a little used intrinsic, and we don't actually have
any example of real-world failure, so I don't plan on backporting the patch.

[Bug libfortran/48054] Documentation for LOG intrinsic function is ambiguous

[fxcoudert at gcc dot gnu.org]

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

--- Comment #1 from Francois-Xavier Coudert  
2011-03-12 10:33:56 UTC ---
Author: fxcoudert
Date: Sat Mar 12 10:33:54 2011
New Revision: 170899

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170899
Log:
PR fortran/48054
* intrinsic.texi: Clarify doc of logarithm functions.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  
2011-03-12 10:28:04 UTC ---
Author: fxcoudert
Date: Sat Mar 12 10:28:01 2011
New Revision: 170898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170898
Log:
PR fortran/47552
* trans-intrinsic.c (gfc_conv_intrinsic_ctime): Fix type of
the string length variable.

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

[Bug fortran/48025] Unnecessary function evaluations in arguments to size and ubound

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.12 10:20:01
 CC||fxcoudert at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

[Bug fortran/46411] MOVE_ALLOC wrongly rejected as impure

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot
   ||gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #5 from Francois-Xavier Coudert  
2011-03-12 10:18:19 UTC ---
Two months and a half have passed, noone has proposed a backport, and 4.6.0
should be released soon (reducing the incentive for backporting). Thus,
closing. Please reopen if you want to backport.

[Bug fortran/47722] With -static "__mingw_vsprintf" on MinGW32 is not found

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||WORKSFORME

--- Comment #5 from Francois-Xavier Coudert  
2011-03-12 10:17:13 UTC ---
(In reply to comment #4)
> I would like to know if this problem remains with the currently available
> install package.

I don't see it with your latest installer, so I'm closing. Vivek, please reopen
if it's not gone for you with a fresh install of the latest build.

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  2011-03-12 
10:15:59 UTC ---
(In reply to comment #7)

> --- m4/ifunction_logical.m4 (Revision 170320)
> +++ m4/ifunction_logical.m4 (Arbeitskopie)
> @@ -49,8 +49,8 @@
>src_kind = GFC_DESCRIPTOR_SIZE (array);
> 
>len = GFC_DESCRIPTOR_EXTENT(array,dim);
> -  if (len < 0)
> -len = 0;
> +  if (len <= 0)
> +return;

... probably would not work for printing empty arrays.

[Bug fortran/45909] [4.4/4.5] internal compiler error

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot
   ||gnu.org
 Resolution||FIXED
   Target Milestone|--- |4.6.0

--- Comment #3 from Francois-Xavier Coudert  
2011-03-12 10:15:24 UTC ---
Two months and a half have passed, noone has proposed a backport, and 4.6.0
should be released soon (reducing the incentive for backporting). Thus,
closing. Please reopen if you want to backport.

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  2011-03-12 
10:10:46 UTC ---
(In reply to comment #6)
> Of course, the patch does not work as "dest" is not NULL ...
> 
> I wonder whether a patch like the following would be correct.

Probably, although it might be easier just to do

Index: m4/ifunction_logical.m4
===
--- m4/ifunction_logical.m4 (Revision 170320)
+++ m4/ifunction_logical.m4 (Arbeitskopie)
@@ -49,8 +49,8 @@
   src_kind = GFC_DESCRIPTOR_SIZE (array);

   len = GFC_DESCRIPTOR_EXTENT(array,dim);
-  if (len < 0)
-len = 0;
+  if (len <= 0)
+return;

   delta = GFC_DESCRIPTOR_STRIDE_BYTES(array,dim);

Index: m4/ifunction.m4
===
--- m4/ifunction.m4 (Revision 170320)
+++ m4/ifunction.m4 (Arbeitskopie)
@@ -46,8 +46,9 @@
   rank = GFC_DESCRIPTOR_RANK (array) - 1;

   len = GFC_DESCRIPTOR_EXTENT(array,dim);
-  if (len < 0)
-len = 0;
+  if (len <= 0)
+return;
+
   delta = GFC_DESCRIPTOR_STRIDE(array,dim);

   for (n = 0; n < dim; n++)

[Bug target/47997] gcc on macosx: "ld: warning: -fwritable-strings not compatible with literal CF/NSString"

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  2011-03-12 10:08:56 
UTC ---
(In reply to comment #8)

firstly, I don't think you need to worry overly about the warning (we do place
the strings in the __TEXT segment, just not in the __cfstring section).  IMO ld
is being somewhat picky ... 
(but perhaps there is good reason for some future plans we're not aware of)

> What are the plans? Are you going to submit the fix to 4.6?

I doubt I'll have a chance before 4.6 forks -- we must be pretty close to that
... but ...

I'm currently testing a less intrusive patch (if people would like to check
this with different variants of XCode - and Mike approves it - perhaps it could
be done in time):

Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 170897)
+++ gcc/config/darwin.c (working copy)
@@ -1195,7 +1195,11 @@ static section *
 darwin_mergeable_string_section (tree exp,
 unsigned HOST_WIDE_INT align)
 {
-  if (flag_merge_constants
+  /* Darwin's ld expects to see non-writable string literals in the .cstring 
+ section.  Later versions of ld check and complain when CFStrings are 
+ enabled.  Therefore we shall force the strings into .cstring since we
+ don't support writable ones anyway.  */
+  if ((darwin_constant_cfstrings || flag_merge_constants)
   && TREE_CODE (exp) == STRING_CST
   && TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE
   && align <= 256

[Bug libfortran/47883] libgfortran configuration should use AC_LINK_IFELSE instead of AC_TRY_LINK

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.12 09:58:42
 CC||fxcoudert at gcc dot
   ||gnu.org
 AssignedTo|unassigned at gcc dot   |fxcoudert at gcc dot
   |gnu.org |gnu.org
 Ever Confirmed|0   |1
   Severity|trivial |enhancement

--- Comment #1 from Francois-Xavier Coudert  
2011-03-12 09:58:42 UTC ---
AC_TRY_COMPILE should be replaced with AC_COMPILE_IFELSE, and AC_TRY_RUN should
be replaced by AC_RUN_IFELSE.

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  2011-03-12 09:56:07 
UTC ---
confirmed that:
(a) we create too many sections for the gcc.dg/torture/builtin-attr-1.c
testcase (598)
(b) that 'as' does not detect this @XCode 3.2.5

looking at the output of otool -l, we have all the sections preserved in the
initial .o files;

I guess this is because 'as' places all the output in one segment and encodes
the seg/sect information manually.

The next question is 'do we ever present too many sections to the final (post
LTO) link?' 
(and, if so, why?)

[it might be that we can live with excess sections in the intermediate objects
(the extras are all in GNU_LTO) - so long as those are removed before we try to
carry out the final link].

[Bug fortran/48066] [4.3/4.4/4.5/4.6 Regression] Segfault with SUM of zero-sized array

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-03-12 
09:38:18 UTC ---
Of course, the patch does not work as "dest" is not NULL ...

I wonder whether a patch like the following would be correct. One probably
needs to go through all the users of ifunction{,_logical}.m4 and check what is
the correct solution, which might or might not be the one below:

@@ -143,9 +143,7 @@ sum_r4 (gfc_array_r4 * const restrict retarray,
   {

   result = 0;
-   if (len <= 0)
- *dest = 0;
-   else
+   if (len > 0)
  {
for (n = 0; n < len; n++, src += delta)
  {

[Bug c/48091] New: No warning when given function arguments mismatch earlier, old style K&R function definition

[eerott at gmail dot com]

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

   Summary: No warning when given function arguments mismatch
earlier, old style K&R function definition
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eer...@gmail.com


Program:
--
int test(a, b)
int a;
int b;
{
return a+b;
}
int main(void)
{
return test("foo");
}
--

With all of these compiler options:
- gcc -Wall -Wextra --std=c99 -pedantic -O test.c

The expected output is similar to other compilers i.e.:
- a warning about arguments mismatching
  (As all argument types and number of them are fully specified), or
- warning about incomplete function definition

Actual outcome:
- No warnings about anything

(With -O2, GCC inlines the function and then finds a mismatch and I of course
can use -Wold-style-definition warning option, but that's beside the point.)

GCC version:
- 4.4.5 in Debian Squeeze

[Bug lto/48086] bootstrap-lto creates c-common.s with too many sections on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.12 09:11:09
 Ever Confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  2011-03-12 
09:11:09 UTC ---
This is also true for Xcode 3.2.6 and causes the following failures

FAIL: gcc.dg/torture/builtin-attr-1.c  -O2 -flto -flto-partition=none  (test
for excess errors)
FAIL: gcc.dg/torture/builtin-attr-1.c  -O2 -flto  (test for excess errors)
FAIL: g++.dg/torture/pr31863.C  -O2 -flto -flto-partition=none  (test for
excess errors)
FAIL: g++.dg/torture/pr31863.C  -O2 -flto  (test for excess errors)

for both -m32 and -m64.

[Bug c/48090] gcc 4.5.2 miscompilation when building on arm

[arnaud.pat...@rtp-net.org]

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

--- Comment #1 from arnaud patard  2011-03-12 
09:02:30 UTC ---
Created attachment 23636
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23636
test file

[Bug c++/48074] [trans-mem] regular function used instead of clone in a transaction

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

   Severity|normal  |critical

[Bug c/48090] New: gcc 4.5.2 miscompilation when building on arm

[arnaud.pat...@rtp-net.org]

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

   Summary: gcc 4.5.2 miscompilation when building on arm
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arnaud.pat...@rtp-net.org


With gcc-4.5.2, even with gcc-4.5-20110310, the following line of code gets
miscompiled (See attachment) :

size -= nblk * 512;

size and nblk are 64 bits.
gcc tries to compute -nblk. nblk is stored in r0,r1. gcc produces the following
asm code :

rsbsr1, r0, #0
rsc r2, r1, #0

So r1 gets corrupted by the rsbs insn, thus getting wrong value in r2.

I'm building the asm code with :
gcc -O2  -march=armv5t list2.i -o - -S

When I use :
gcc -O2 -fno-cse-follow-jumps  -march=armv5t list2.i -o - -S

I get :

rsbsr0, r0, #0
rsc r1, r1, #0

which is fine.

[Bug c++/48089] New: ICE on in(?)valid in constexpr constructors

[gcc at magfr dot user.lysator.liu.se]

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

   Summary: ICE on in(?)valid in constexpr constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@magfr.user.lysator.liu.se


Created attachment 23635
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23635
Example showing the problem

Trying to mark a value as don't care using the gcc extension of initializing it
with itself triggers an ICE in lookup_parameter_binding.

[Bug fortran/47552] CTIME: Valgrind warning "depends on uninitialised value"

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-03-12 
08:03:37 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> Which is wrong. This is fixed by the patch:

The patch is OK with a changelog and CCing the patch to gcc-patches@/fortran@