[Bug bootstrap/51796] New: [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux

[mikpe at it dot uu.se]

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

 Bug #: 51796
   Summary: [4.7 regression] internal compiler error: in
distribute_notes, at combine.c:13285 for
libgomp/alloc.c on m68k-linux
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se


Created attachment 26276
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26276
preprocessed source for libgomp/alloc.c

Bootstrapping gcc-4.7-20120107 on m68k-linux fails during
all-stage1-target-libgomp with:

/mnt/scratch/objdir47/./gcc/xgcc -B/mnt/scratch/objdir47/./gcc/
-B/mnt/scratch/install47/m68k-unknown-linux-gnu/bin/
-B/mnt/scratch/install47/m68k-unknown-linux-gnu/lib/ -isystem
/mnt/scratch/install47/m68k-unknown-linux-gnu/include -isystem
/mnt/scratch/install47/m68k-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/mnt/scratch/gcc-4.7-20120107/libgomp
-I/mnt/scratch/gcc-4.7-20120107/libgomp/config/posix
-I/mnt/scratch/gcc-4.7-20120107/libgomp -Wall -Werror -pthread
-ftls-model=initial-exec -g -O2 -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c
/mnt/scratch/gcc-4.7-20120107/libgomp/alloc.c -o alloc.o
/mnt/scratch/gcc-4.7-20120107/libgomp/alloc.c: In function 'gomp_malloc':
/mnt/scratch/gcc-4.7-20120107/libgomp/alloc.c:40:1: internal compiler error: in
distribute_notes, at combine.c:13285

The previous weekly snapshot, gcc-4.7-20111231, built fine (once r182819 was
backported to fix PR51725)

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  
2012-01-09 08:37:21 UTC ---
On Thu, 5 Jan 2012, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at gcc dot gnu.org
> 
> --- Comment #21 from Jakub Jelinek  2012-01-05 
> 18:26:17 UTC ---
> But can't a valid code also compare the result from realloc with the old
> pointer, and if they are equal, do something, otherwise do something else?
> I think it is pretty common e.g. if the malloced block contains pointers to
> parts of the malloced area and upon realloc that didn't return the passed
> address wants to adjust all those pointers.

Sure.

> Having a malloc attribute on realloc would still break this.

We cannot use the malloc attribute on realloc, ever.

> I'd say we want realloc attribute and handle it where we currently handle
> BUILT_IN_REALLOC.

Not sure it's worth it besides handling BUILT_IN_REALLOC explicitly.

[Bug c++/23383] builtin array operator new is not marked with malloc attribute

[rguenther at suse dot de]

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

--- Comment #24 from rguenther at suse dot de  
2012-01-09 08:39:37 UTC ---
On Thu, 5 Jan 2012, xinliangli at gmail dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> 
> --- Comment #20 from davidxl  2012-01-05 
> 18:11:18 UTC ---
> (In reply to comment #19)
> > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > 
> > > --- Comment #18 from davidxl  2012-01-04 
> > > 17:11:26 UTC ---
> > > (In reply to comment #17)
> > > > On Wed, 4 Jan 2012, xinliangli at gmail dot com wrote:
> > > > 
> > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
> > > > > 
> > > > > --- Comment #16 from davidxl  2012-01-04 
> > > > > 00:28:55 UTC ---
> > > > > A related topic - aliasing property of realloc -- the malloc 
> > > > > attribute is not
> > > > > applied in the glibc header and the comment is like
> > > > > 
> > > > > /* __attribute_malloc__ is not used, because if realloc returns
> > > > >the same pointer that was passed to it, aliasing needs to be 
> > > > > allowed
> > > > >between objects pointed by the old and new pointers.  *
> > > > > 
> > > > > 
> > > > > It is true that the realloc can return an address is physically 
> > > > > aliased with
> > > > > the pointer passed to it -- but assuming no-alias by the compiler 
> > > > > should cause
> > > > > no harm -- as all code motions/CSEs across the realloc call will not 
> > > > > be
> > > > > possible because realloc may modify/use the memory location.
> > > > > 
> > > > > 
> > > > > Any comment on this? 
> > > > 
> > > > The malloc attribute assumes that the contents of the memory pointed
> > > > to by the return value is undefined, so the comment is inaccurate
> > > > but the malloc attribute can indeed be not used.
> > > 
> > > Which part of the optimizer takes advantage of the 'undefinedness' of 
> > > returned
> > > memory?
> > 
> > points-to analysis.  It assumes that the returned blob of memory
> > points to nothing (yet).  So for
> > 
> >  int i;
> >  int **p = malloc (8);
> >  *p = &i;
> >  int **q = realloc (p, 8);
> > 
> > you'd get that *q points to nothing insteda of i.
> 
> The malloc attribute documentation is confusing:
> 
> malloc
> The malloc attribute is used to tell the compiler that a function may be
> treated as if any non-NULL pointer it returns cannot alias any other pointer
> valid when the function returns. This will often improve optimization. 
> Standard
> functions with this property include malloc and calloc. realloc-like functions
> have this property as long as the old pointer is never referred to (including
> comparing it to the new pointer) after the function returns a non-NULL value. 

Ugh, it should not mention realloc here.

> It does not mention the undefineness explicitly.
> 
> It might be better to fix the semantics of this attribute to only specify the
> aliasing property so that it can also be applied to realloc. Points-to needs 
> to
> be fixed to special case realloc for the initialization.

It can't be "fixed" to not assume the undefinedness and still be useful.
For any non-builtin with the malloc attribute it would need to assume
the pointed to memory points to anything.  That will be pretty useless
once you put pointers in the allocated memory.

I'll fixup the documentation.

[Bug target/51797] New: Arm backend missed the mls related optimization

[carrot at google dot com]

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

 Bug #: 51797
   Summary: Arm backend missed the mls related optimization
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: car...@google.com
Target: arm-linux-androideabi


compile the following code with options -march=armv7-a -mthumb -Os


int t0i(int a, int b)
{
  return a - 368 * b;
}

GCC 4.7 generates:

t0i:
ldrr3, .L2
mlar0, r3, r1, r0
bxlr
.L3:
.align2
.L2:
.word-368


When compiled with -O3, gcc generates:

t0i:
movwr3, #65168
movtr3, 65535
mlar0, r3, r1, r0
bxlr


But an optimized result should be:

t0i:
 movw r3, 368
 mls  r0, r3, r1, r0
 bx   lr

It is faster and smaller than either of Os/O3 result.

[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line

[gfunck at gcc dot gnu.org]

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

--- Comment #6 from gfunck at gcc dot gnu.org 2012-01-09 08:48:51 UTC ---
Author: gfunck
Date: Mon Jan  9 08:48:43 2012
New Revision: 183003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183003
Log:
libcpp/
PR preprocessor/33919
* files.c (_cpp_get_file_name): New. Implement file name
access function.
* internal.h (_cpp_get_file_name): New prototype.
* macro.c (_cpp_builtin_macro_text): Call _cpp_get_file_name()
to use pfile->main_file in lieu of traversing INCLUDED_FROM chain.

gcc/testsuite/
PR preprocessor/33919
* gcc.dg/pr33919.c: New test.
* gcc.dg/pr33919-0.h: New test header file.
* gcc.dg/pr33919-1.h: Ditto.
* gcc.dg/pr33919-2.h: Ditto.

Added:
trunk/gcc/testsuite/gcc.dg/pr33919-0.h
trunk/gcc/testsuite/gcc.dg/pr33919-1.h
trunk/gcc/testsuite/gcc.dg/pr33919-2.h
trunk/gcc/testsuite/gcc.dg/pr33919.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/files.c
trunk/libcpp/internal.h
trunk/libcpp/macro.c

[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug bootstrap/51787] [4.7 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|[4.7.0 Regression] internal |[4.7 Regression] internal
   |compiler error: in  |compiler error: in
   |inline_small_functions, at  |inline_small_functions, at
   |ipa-inline.c:1410   |ipa-inline.c:1410

[Bug bootstrap/51796] [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/51659] ICE in function output_move_double

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose  2012-01-09 
09:18:14 UTC ---
Created attachment 26277
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26277
preprocessed source

[Bug target/51659] ICE in function output_move_double

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #3 from Matthias Klose  2012-01-09 
09:17:44 UTC ---
seen with hard float as well

g++ -c -g -O2 --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
--with-mode=thumb output.ii
In file included from ../../gold/compressed_output.h:33:0,
 from ../../gold/compressed_output.cc:31:
../../gold/output.h: In member function 'virtual bool
gold::Output_section::do_is_section_flag_set(elfcpp::Elf_Xword) const':
../../gold/output.h:3640:40: internal compiler error: in output_move_double, at
config/arm/arm.c:13933
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

[bardeau at iram dot fr]

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

Sebastien Bardeau  changed:

   What|Removed |Added

  Attachment #26153|0   |1
is obsolete||

--- Comment #11 from Sebastien Bardeau  2012-01-09 
09:20:34 UTC ---
Created attachment 26278
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26278
Other program which fails with -O flag under 32 bits systems

[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

[bardeau at iram dot fr]

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

--- Comment #12 from Sebastien Bardeau  2012-01-09 
09:23:41 UTC ---
Dear Tobias,

many thanks for your help and for the many alternatives you gave us. We are
still discussing which one is the best to choose in our context, but at least
we have several solutions to this problem.

A final word: in the new version of the attached program (which also fails with
optimization) I removed as much invalid statements as I could. Only the
"12.4.1.7 restrictions" are still broken, of course. I am surprised to see that
none of the compilers I tested (gfortran, ifort, g95) complain about the fact
that the same variable is used as both intent(in) and intent(out) variable.
Shouldn't it be at least a warning?

And yes, this bug ticket can be closed...

[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  2012-01-09 
09:50:26 UTC ---
Author: ebotcazou
Date: Mon Jan  9 09:50:19 2012
New Revision: 183005

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183005
Log:
PR ada/41929
* config/sparc/sol2-unwind.h (sparc64_is_sighandler): Remove SAVPC and
add CFA.  Revert back to old code for Solaris 8+ multi-threaded.
(sparc_is_sighandler): Likewise.
(MD_FALLBACK_FRAME_STATE_FOR): Adjust call to IS_SIGHANDLER.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/sparc/sol2-unwind.h

[Bug ada/41929] 64-bit null_pointer_deref1 gnat.dg test consumes all available memory

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  2012-01-09 
09:50:47 UTC ---
Author: ebotcazou
Date: Mon Jan  9 09:50:42 2012
New Revision: 183006

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183006
Log:
PR ada/41929
* config/sparc/sol2-unwind.h (sparc64_is_sighandler): Remove SAVPC and
add CFA.  Revert back to old code for Solaris 8+ multi-threaded.
(sparc_is_sighandler): Likewise.
(MD_FALLBACK_FRAME_STATE_FOR): Adjust call to IS_SIGHANDLER.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/sparc/sol2-unwind.h

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Guenther  2012-01-09 
09:58:52 UTC ---
This should not be fixed in the early inliner at all.

[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus  2012-01-09 
10:01:59 UTC ---
(In reply to comment #12)
> I am surprised to see that none of the compilers I tested (gfortran, ifort,
> g95) complain about the fact that the same variable is used as both
> intent(in) and intent(out) variable. Shouldn't it be at least a warning?


gfortran with -Waliasing (or -Wall) actually warns - but not by default:

  call iei4ei(in4,in4)
  1
Warning: Same actual argument associated with INTENT(IN) argument 'inpu' and
INTENT(OUT) argument 'oupu' at (1)


The argument agains warning by default is that one can write perfectly valid
code such as:

call iei4ei(in4, in4, false)
contains
subroutine iei4ei (out, in, mod)
  integer :: out, in
  logical :: mod
  if (mod)
out = 5
end subroutine ie4ei


Nevertheless, one could think of warning by default.

[Bug other/51173] XFAIL: libitm.c++/static_ctor.C

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug other/51124] libitm failures

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #8 from torvald at gcc dot gnu.org 2012-01-09 10:06:53 UTC ---
Can this be closed?

clone-1.c works for me on x86_64 at least, what about the other
architectures/platforms?

static_ctor.C is now PR 51173

[Bug tree-optimization/48625] [trans-mem] Segfault in libitm when compiling with -O2

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||torvald at gcc dot gnu.org
 Resolution||FIXED

--- Comment #4 from torvald at gcc dot gnu.org 2012-01-09 10:17:17 UTC ---
KMeans and other the STAMP applications work now (tested on x86_64 and ppc). 
There were several bugs in libitm, which have been fixed.  The stack slot
save/restore issue was also present but fixed with a workaround (mark
transaction begin as returns-twice).  PR 51771 tracks a proper fix for the
latter.

[Bug other/51124] libitm failures

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  2012-01-09 
10:23:06 UTC ---
libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on
*86*-*-*. From
http://glutton.geoffk.org/HEAD/native-logsum/i686-pc-linux-gnu/libitm/testsuite/libitm.log.gzip
, the failure is

libitm: pr_undoLogCode not supported
FAIL: libitm.c/memcpy-1.c execution test

I also see that on x86_64-apple-darwin10. This comes from line 163 of
libitm/beginend.cc

 // ??? pr_undoLogCode is not properly defined in the ABI. Are barriers
  // omitted because they are not necessary (e.g., a transaction on thread-
  // local data) or because the compiler thinks that some kind of global
  // synchronization might perform better?
  if (unlikely(prop & pr_undoLogCode))
GTM_fatal("pr_undoLogCode not supported");

[Bug tree-optimization/51775] [4.6/4.7 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|ada |tree-optimization

--- Comment #3 from Eric Botcazou  2012-01-09 
10:35:19 UTC ---
Recategorizing.

[Bug other/51124] libitm failures

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  2012-01-09 10:55:06 
UTC ---
Just for once, all the tests pass on powerpc-darwin9 (m32 & m64) [last tested
182949].

[Bug fortran/42954] [4.4/4.5/4.6/4.7 regression] TARGET_*_CPP_BUILTINS issues with gfortran

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P4  |P5
   Target Milestone|4.7.0   |4.8.0
Summary|[4.5/4.6/4.7 regression]|[4.4/4.5/4.6/4.7
   |TARGET_*_CPP_BUILTINS   |regression]
   |issues with gfortran|TARGET_*_CPP_BUILTINS
   ||issues with gfortran

[Bug c++/51773] error building libitm/aatree.cc on ARM

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||MOVED

--- Comment #12 from vries at gcc dot gnu.org 2012-01-09 11:33:46 UTC ---
(In reply to comment #10)
> I'm testing a glibc patch that reenables gets for C++ <= C++11, disables 
> the static_assert define for C++ and disables the char16_t/char32_t 
> typedefs in uchar.h for C++11 (since they are keywords in C++11).

2012-01-06  Joseph Myers  

[BZ #13566]
* assert/assert.h (static_assert): Don't define for C++.
* libio/stdio.h (gets): Do declare for C++ <= C++11.
* wcsmbs/uchar.h (char16_t, char32_t): Don't typedef for C++11.

Given this checkin in glibc, marking this as resolved - moved.

[Bug target/51793] pragma GCC optimize wrapv leads to invalid code on Solaris

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.11 |x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-09
   Host|i386-pc-solaris2.11 |
 Ever Confirmed|0   |1
  Build|i386-pc-solaris2.11 |

--- Comment #1 from Richard Guenther  2012-01-09 
11:59:09 UTC ---
Huh, weird.  Works with GCC 4.3 (which does not implement the pragma).

Confirmed.  At least generic x86 is affected.

[Bug middle-end/51784] [4.7 Regression] FAIL: gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-09
 Ever Confirmed|0   |1

--- Comment #9 from Richard Guenther  2012-01-09 
12:02:44 UTC ---
Dominique, please see why __findenv segfaults.

[Bug tree-optimization/51782] Missing address-space information leads to wrong code

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther  2012-01-09 
12:04:30 UTC ---
Please figure out where the address-space information is lost.

[Bug tree-optimization/49642] constant part of a macro not optimized away as expected due to splitter

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Guenther  2012-01-09 
12:10:50 UTC ---
Fixed for 4.7.

[Bug c++/51777] Errors message show unsigned long template parameters as signed

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-09
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-01-09 
12:13:03 UTC ---
Confirmed.

[Bug tree-optimization/18589] could optimize FP multiplies better

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #6 from Richard Guenther  2012-01-09 
12:20:31 UTC ---
Yeah, reassoc does not canonicalize to pow () so the tree level optimal
expansion does not trigger [in reality reassoc should probably do both
on-the-fly - linearly expand existing pow()s to expose them to multiply
chains and sorting, combine them back and then emit them in optimal form].

Bill, something you want to tackle?

[Bug middle-end/51770] dump gimple lineno when dumping bb

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Richard Guenther  2012-01-09 
12:21:48 UTC ---
Patches should be posted to gcc-patches.  This probably deserves a new
dump-file modifier, -compactlineno or so.

[Bug tree-optimization/51775] [4.6/4.7 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 AssignedTo|ebotcazou at gcc dot|rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Richard Guenther  2012-01-09 
12:23:55 UTC ---
I have a patch (the regression is that DOM no longer catches this).  FRE/PRE
are just too dumb without any good reason.

[Bug bootstrap/51796] [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Mikael Pettersson  2012-01-09 
12:44:35 UTC ---
It's caused by r182924:

Author: jakub
Date: Thu Jan  5 20:47:16 2012
New Revision: 182924

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182924
Log:
PR debug/51762
* calls.c (emit_call_1): For noreturn calls force a REG_ARGS_SIZE
note when !ACCUMULATE_OUTGOING_ARGS.

m68k is !ACCUMULATE_OUTGOING_ARGS, so it triggers this change.

[Bug tree-optimization/18589] could optimize FP multiplies better

[wschmidt at gcc dot gnu.org]

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

--- Comment #7 from William J. Schmidt  2012-01-09 
13:06:34 UTC ---
Sure, I'll at least have a look at it when I get some time.

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-01-09 
13:11:11 UTC ---
Author: burnus
Date: Mon Jan  9 13:11:05 2012
New Revision: 183010

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183010
Log:
2012-01-09  Tobias Burnus  

PR fortran/51578
* gfortran.h (gfc_use_list):
* match.h (gfc_use_module): Rename to ...
(gfc_use_modules): ... this.
* module.c (use_locus, specified_nonint, specified_int): Remove
global variable.
(module_name): Change type to const char*, used with gfc_get_string.
(module_list): New global variable.
(free_rename): Free argument not global var.
(gfc_match_use): Save match to module_list.
(load_generic_interfaces, read_module): Don't free symtree.
(write_dt_extensions, gfc_dump_module): Fix module-name I/O due to the
type change of module_name.
(write_symbol0, write_generic): Optimize due to the type change.
(import_iso_c_binding_module, use_iso_fortran_env_module): Use
locus of rename->where.
(gfc_use_module): Take module_list as argument.
(gfc_use_modules): New function.
(gfc_module_init_2, gfc_module_done_2): Init module_list, rename_list.
* parse.c (last_was_use_stmt): New global variable.
(use_modules): New function.
(decode_specification_statement, decode_statement): Move USE match up
and call use_modules.
(next_free, next_fixed): Call use_modules.
(accept_statement): Don't call gfc_module_use.

2012-01-09  Tobias Burnus  

PR fortran/51578
* gfortran.dg/use_17.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/use_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/match.h
trunk/gcc/fortran/module.c
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51578] [4.3/4.4/4.5/4.6/4.7 Regression] Import of same symbol via different modules and renaming

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|4.6.3   |4.7.0

--- Comment #5 from Tobias Burnus  2012-01-09 
13:13:34 UTC ---
FIXED on the trunk (GCC 4.7). Too big for backporting [esp. as no one has
reported the bug/regression for years].

[Bug bootstrap/51796] [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2012-01-09 
13:19:23 UTC ---
Created attachment 26279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26279
reduced test case

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Tobias Burnus  2012-01-09 
13:28:47 UTC ---
With the patch for PR 51578 (for GCC 4.7), the ICE is fixed. For the lines


integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception) &
use, intrinsic :: iso_c_binding
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
end function vect_Utils_vuNorm_c


one get the errors


   integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)&
   1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression


   real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind
1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression


I think the second one is perfect - there is no "USE ISO_C_Binding" statement
in "function vect_Utils_vuNorm_c".


The first error is not that good as the problem is the "&" in
   function foo() &
 use m

A better error message would be a syntax error, pointing at the "&" - but I
think it is not really needed and also not easy to give a helpful message.

Hence, I close this PR as FIXED. If you think something else should be
improved, feel free to reopen this bug.


Thanks Adrian for reporting the internal compiler error.

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-01-09 
13:38:38 UTC ---
With the following change

--- pr51522.f902011-12-13 00:17:20.0 +0100
+++ pr51522_db.f902012-01-09 12:15:44.0 +0100
@@ -265,9 +266,11 @@ interface
   integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
 use, intrinsic :: iso_c_binding
   end function vect_Utils_vuIsUnit_c
-  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)   
&
+  integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
 use, intrinsic :: iso_c_binding
+  end function vect_Utils_vuTriIneqHolds_c
   real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
+use, intrinsic :: iso_c_binding
   end function vect_Utils_vuNorm_c
 end interface
 end module vect_Utils_F03

the code compiles (with a lot of warnings), but complains at link time:

Undefined symbols:
  "_main", referenced from:
  start in crt1.10.6.o
  "_vect_Utils_getEPV", referenced from:
  ___vect_utils_type_f03_MOD_cache_epv_s in ccxe8Zdc.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status

[Bug fortran/51758] ICE with optional arguments of elemental procedures

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #5 from Mikael Morin  2012-01-09 
13:43:35 UTC ---
I'm taking care.

[Bug fortran/51758] ICE with optional arguments of elemental procedures

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2012-01-09 
13:48:14 UTC ---
See patch at http://gcc.gnu.org/ml/fortran/2012-01/msg00066.html .

[Bug tree-optimization/51775] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P4  |P3
Summary|[4.6/4.7 Regression] FAIL:  |[4.6 Regression] FAIL:
   |gnat.dg/pack9.adb   |gnat.dg/pack9.adb
   |scan-tree-dump-not  |scan-tree-dump-not
   |optimized "gnat_rcheck" |optimized "gnat_rcheck"

--- Comment #6 from Richard Guenther  2012-01-09 
14:07:55 UTC ---
Fixed for trunk sofar.

[Bug tree-optimization/51775] [4.6/4.7 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-01-09 
14:06:41 UTC ---
Author: rguenth
Date: Mon Jan  9 14:06:31 2012
New Revision: 183012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183012
Log:
2012-01-09  Richard Guenther  

PR tree-optimization/51775
* tree-ssa-sccvn.c (visit_use): Value-number throwing stmts.
* tree-ssa-pre.c (eliminate): Properly fixup EH info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c

[Bug c++/50855] [C++0x] Name mangling for late return types invoking constructors not implemented

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Jason Merrill  2012-01-09 
14:16:08 UTC ---
Fixed for 4.7.

[Bug c++/48051] sorry, unimplemented: mangling overload

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2012-01-09 
14:15:26 UTC ---
Created attachment 26280
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26280
testsuite patch showing wrong mangling

The change checked in above fixes this bug in many cases, but this patch shows
a case that we still get wrong.

[Bug c++/51322] [C++11] wrong mangling with argument packs

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jason Merrill  2012-01-09 
14:16:57 UTC ---
Fixed for 4.7. (with -fabi-version=6 or -fabi-version=0).

[Bug fortran/51792] [4.7 regression] fortran bootstrap failure: no previous prototype for 'resolve_typebound_function'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #11 from Patrick Marlier  
2012-01-09 14:27:18 UTC ---
> libitm.c/memcpy-1.c and memset-1.c are still failing in 32 bit mode on
*86*-*-*.
Fix proposed here: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01784.html
Torvald, what was decided about the API?

[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P1  |P2
   Target Milestone|4.7.0   |4.8.0

--- Comment #11 from Richard Guenther  2012-01-09 
14:27:02 UTC ---
Pushing this to 4.8, it requires too invasive surgery.

[Bug libstdc++/51798] New: [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

 Bug #: 51798
   Summary: [4.7 regression] libstdc++ atomicity performance
regression due to __sync_fetch_and_add
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org


libstdc++ uses __sync_fetch_and_add() to provide atomicity for reference
counting.  The semantics of __sync_fetch_and_add() were not explicitly stated. 
libstdc++ apparently requires ACQUIRE semantics for incrementing the reference
count and RELEASE semantics for decrementing the reference and possibly
destroying the object.  The libstdc++ code did not make this distinction, but
__sync_fetch_and_add() generally was implemented as RELEASE semantics, which
was overkill for increment and appropriate for decrement/destroy.

As part of the C++11 memory model changes, __sync_fetch_and_add() atomicity was
changed to use the new, more general atomicity infrastructure with SEQUENTIAL
CONSISTENCY.  This imposes the most strict and heavy-weight barrier.

On architectures with granularity and gradations in the implementation of
atomic instructions, this introduces a severe performance regression.

[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o

[rguenth at gcc dot gnu.org]

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

--- Comment #34 from Richard Guenther  2012-01-09 
14:31:30 UTC ---
Another possible fix is to drop autodetecting the feature (defaulting to
the old behavior) and requiring --enable-init_array at configure time.

HJ, please work on this, this is a real blocker.  I prefer the explicit
configure argument way for 4.7, we can switch to autodetection in a later
release.

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-09
 CC||bergner at gcc dot gnu.org
  Known to work||4.6.0, 4.6.1
   See Also||http://gcc.gnu.org/bugzilla
   ||/show_bug.cgi?id=51766
 Ever Confirmed|0   |1
  Known to fail||4.7.0

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #1 from David Edelsohn  2012-01-09 14:37:35 
UTC ---
Proposed patch:
http://gcc.gnu.org/ml/libstdc++/2012-01/msg00044.html

[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-01-09 
14:41:04 UTC ---
Re-confirmed.  Reduced testcase:

void f (unsigned *s)
{
  int n;
  for (n = 0; n < 256; n++)
s[n] = 0;
}

[Bug other/51124] libitm failures

[torvald at gcc dot gnu.org]

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

torvald at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #12 from torvald at gcc dot gnu.org 2012-01-09 15:03:37 UTC ---
So the variadic-args vs. regparm(2) issue is the only blocker here?

There's no decision yet about this one so far, AFAIK.  As I said before,
combining the vararg with regparm seemed to be a thought-through decision, so
the question is really whether it makes sense conceptually and is just not
implemented properly in GCC, or whether the combination doesn't make sense at
all and we should drop regparm(2) from _ITM_beginTransaction.

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-01-09 
15:14:30 UTC ---
There is a disconnect on how we analyze data-references during SCOP detection
(outermost_loop is the root of the loop tree) and during SESE-to-poly where
outermost is determined by outermost_loop_in_sese_1 ().  That influences
the SCEV result and thus we do not break the SCOP at a stmt we have to break
it.

The following patch fixes this using a sledgehammer - require the
data-ref to be representable if analyzed with respect to all loops
it can nest in.

Index: graphite-scop-detection.c
===
--- graphite-scop-detection.c   (revision 183013)
+++ graphite-scop-detection.c   (working copy)
@@ -258,25 +258,33 @@ graphite_can_represent_expr (basic_block
Graphite.  */

 static bool
-stmt_has_simple_data_refs_p (loop_p outermost_loop, gimple stmt)
+stmt_has_simple_data_refs_p (loop_p outermost_loop ATTRIBUTE_UNUSED,
+gimple stmt)
 {
   data_reference_p dr;
   unsigned i;
   int j;
   bool res = true;
-  VEC (data_reference_p, heap) *drs = VEC_alloc (data_reference_p, heap, 5);
+  VEC (data_reference_p, heap) *drs = NULL;
+  loop_p outer;

-  graphite_find_data_references_in_stmt (outermost_loop,
-loop_containing_stmt (stmt),
-stmt, &drs);
+  for (outer = loop_containing_stmt (stmt); outer; outer = loop_outer (outer))
+{
+  graphite_find_data_references_in_stmt (outer,
+loop_containing_stmt (stmt),
+stmt, &drs);

-  FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
-for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
-  if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
-   {
- res = false;
- goto done;
-   }
+  FOR_EACH_VEC_ELT (data_reference_p, drs, j, dr)
+ for (i = 0; i < DR_NUM_DIMENSIONS (dr); i++)
+   if (!graphite_can_represent_scev (DR_ACCESS_FN (dr, i)))
+ {
+   res = false;
+   goto done;
+ }
+
+  free_data_refs (drs);
+  drs = NULL;
+}

  done:
   free_data_refs (drs);

[Bug tree-optimization/51680] g++ 4.7 fails to inline trivial template stuff

[hubicka at ucw dot cz]

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

--- Comment #17 from Jan Hubicka  2012-01-09 15:18:43 
UTC ---
> This should not be fixed in the early inliner at all.
Well, it is not (just to summarize the disucssion on ML). The change is into
IPA inliner.

Honza

[Bug middle-end/50199] [4.7 Regression] wrong code with -flto -fno-merge-constants

[hubicka at ucw dot cz]

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

--- Comment #12 from Jan Hubicka  2012-01-09 15:19:30 
UTC ---
-flto-partition=none is a workaround for 4.7 compiler.

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #13 from Patrick Marlier  
2012-01-09 15:22:45 UTC ---
As posted here http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01804.html, GCC
explicitly change the calling convention to stdcall when variable arguments in
x86/32 bits mode. So I am sure a calling convention document specifies that
even if I cannot find it.

[Bug fortran/51791] [OOP] Failure to resolve typebound function call with base object in parentheses.

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-01-09 
15:28:31 UTC ---
Approved patch:
  http://gcc.gnu.org/ml/fortran/2012-01/msg00054.html

[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Guenther  2012-01-09 
15:28:01 UTC ---
The asserts in

static inline ppl_dimension_type
psct_dynamic_dim (poly_bb_p pbb, graphite_dim_t level)
{
  graphite_dim_t result = 1 + 2 * level;

  gcc_assert (result < pbb_nb_scattering_transform (pbb));
  return result;
}

static inline ppl_dimension_type
psct_static_dim (poly_bb_p pbb, graphite_dim_t level)
{
  graphite_dim_t result = 2 * level;

  gcc_assert (result < pbb_nb_scattering_transform (pbb));
  return result;
}

are not consistent in case both a dynamic and static dimension should
always exist at the same time.  Changing psct_dynamic_dim to use <=
fixes the issue.

[Bug tree-optimization/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|middle-end  |tree-optimization
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #1 from Richard Guenther  2012-01-09 
15:40:10 UTC ---
The docs of __sync_* say

This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
This means that references after the builtin cannot move to (or be
speculated to) before the builtin, but previous memory stores may not
be globally visible yet, and previous memory loads may not yet be
satisfied.

But it is not exactly clear to which builtins this applies.  Thus, is
the intended behavior actually target depedent?

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rth at gcc dot gnu.org
   Target Milestone|--- |4.7.0

--- Comment #2 from Richard Guenther  2012-01-09 
15:42:35 UTC ---
Related to PR51766.

[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-01-09 
15:45:06 UTC ---
(In reply to comment #1)
> The docs of __sync_* say
> 
> This builtin is not a full barrier, but rather an @dfn{acquire barrier}.
> This means that references after the builtin cannot move to (or be
> speculated to) before the builtin, but previous memory stores may not
> be globally visible yet, and previous memory loads may not yet be
> satisfied.
> 
> But it is not exactly clear to which builtins this applies.  Thus, is
> the intended behavior actually target depedent?

It refers to __sync_lock_test_and_set only (it says "this builtin" and follows
that one)

And "This builtin is not a full barrier, but rather a release barrier." refers
to __sync_lock_release.

All the others are full barriers.  It says above them "In most cases, these
builtins are considered a full barrier." and only __sync_lock_test_and_set and
__sync_lock_release specify different barrier semantics.

[Bug c++/48075] infinite loop when compiling

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #5 from Patrick Marlier  
2012-01-09 15:49:12 UTC ---
Invalid.

[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)

[patrick.marlier at gmail dot com]

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

Patrick Marlier  changed:

   What|Removed |Added

 CC||patrick.marlier at gmail
   ||dot com

--- Comment #10 from Patrick Marlier  
2012-01-09 15:55:52 UTC ---
What's the status of this report?
Do all libitm tests passed on PA? 
Does it still not working on Tru64 UNIX?

Thanks.

[Bug middle-end/51766] [4.7 regression] sync_fetch_and_xxx atomicity

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  2012-01-09 16:49:10 
UTC ---
> It says above them "In most cases, these
> builtins are considered a full barrier." and only __sync_lock_test_and_set and
> __sync_lock_release specify different barrier semantics.

The next sentence is:

"That is, no memory operand will be moved across the operation, either forward
or
backward."

Note that this refers to memory operands, not memory operations -- memory
stores and memory loads referenced in documentation of the other sync builtins.
 In other words, one could interpret "full memory barrier" as:

asm volatile ("" : : : "memory");

that refers to a GCC scheduling barrier.

The GCC documentation references Intel processors, which do not have have a
distinction between instructions for RELEASE, ACQ_REL and SEQ_CST semantics.

The basic problem is that the GCC builtins and atomic instruction semantics
were designed for Intel processors that do not provide the level of granularity
implemented in POWER processors.  The POWER port implemented lighter weight
ACQ_REL semantics. Retrofitting the original builtins on the new C++11 memory
model semantics and imposing SEQ_CST interpretation has changed the behavior
and performance on POWER, but not on other targets.

[Bug bootstrap/51796] [4.7 regression] internal compiler error: in distribute_notes, at combine.c:13285 for libgomp/alloc.c on m68k-linux

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-09 
16:52:57 UTC ---
I guess the assert should be adjusted, from gcc_assert (old_size != args_size);
to gcc_assert (old_size != args_size || find_reg_note (i3, REG_NORETURN,
NULL));
because we add the REG_ARGS_SIZE notes now even to noreturn calls where there
is no difference from previous args size.
Can't test it right now though.

[Bug other/51124] libitm failures

[patrick.marlier at gmail dot com]

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

--- Comment #14 from Patrick Marlier  
2012-01-09 16:52:47 UTC ---
>From http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
regparm (number)
... Functions that take a variable number of arguments will continue to be
passed all of their arguments on the stack.

>From IRC: Do you know if variadic function and regparm(2) are compatible on
x86/32?
Quoting ktietz:
no they aren't (at least for IA-32).  As variadic functions require
reserved-stack-region, as va_list is in fact a stack-pointer for this target.
there might be case variadic could work, but these are exceptions. It depends
on signature. For regparm(2) the varidic would need to be at the 4th argument,
as va_start need prior argument to get proper stack-location. But this is just
a special-case.
it is a consequence of the way variadic is defined for IA-32 targets.
if calling-conventions using register(s) for argument passing, we would need to
know amount of variable part on runtime to calculate stack-clone region for it.
 In fact this would be for IA-32 possible, if function has pascal argument
ordering.

The variadic-args vs. regparm(2) issue is the blocker for
memcpy-1.c/memset-1.c.
No clue for clone-1.c since I cannot reproduce.
The eh-1.C on darwin seems to be a problem with XCode 4+
(http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00329.html). Probably a different
PR should be filled.

Patrick.

[Bug rtl-optimization/38644] [4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code

[ramana at gcc dot gnu.org]

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

--- Comment #62 from Ramana Radhakrishnan  
2012-01-09 16:55:24 UTC ---
Author: ramana
Date: Mon Jan  9 16:55:16 2012
New Revision: 183019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183019
Log:

2012-01-09  Ramana Radhakrishnan  

Backport from mainline
2011-11-04  Jiangning Liu  

PR rtl-optimization/38644
* config/arm/arm.c (thumb1_expand_epilogue): Add memory barrier
for epilogue having stack adjustment.

2012-01-09  Ramana Radhakrishnan  

Backport from mainline:
2011-11-04  Jiangning Liu  

PR rtl-optimization/38644
* gcc.target/arm/stack-red-zone.c: New.



Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.target/arm/stack-red-zone.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/arm/arm.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/51798] [4.7 regression] libstdc++ atomicity performance regression due to __sync_fetch_and_add

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  2012-01-09 17:11:32 
UTC ---
Another alternative is to modify __gnu_cxx::_atomic_add() to perform acquire
semantics for positive increments and release semantics for negative
increments.  That avoid creating a new function in the __gnu_cxx space.

[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr

[zippy at anl dot gov]

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

--- Comment #9 from Tim Williams  2012-01-09 17:15:06 UTC 
---
(In reply to comment #4)
> I forgot to mention that there exist also unofficial binaries for MacOS at:
>   http://gcc.gnu.org/wiki/GFortranBinaries#MacOS
> Thus, that could be an alternative to fixing the MPFR issue.

Thanks, Tobias. I did try out the gfortran 4.6.2 from here, and it does compile
runnable code. Unfortunately, it still does not work with any version of gdb I
have tried on Mac OS X. My end goal in building the whole of gcc 4.6.2 was to
try building a Fortran code and debug it with the latest gdb version (7.3.1).
No luck with this prebuilt gfortran binary either.

[Bug tree-optimization/51799] New: Compiler ICE in vect_is_simple_use_1

[mgretton at sourceware dot org]

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

 Bug #: 51799
   Summary: Compiler ICE in vect_is_simple_use_1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@sourceware.org
Target: arm-*-*


Created attachment 26281
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26281
Failing test case.

The attached test case causes the compiler to ICE as follows:

$ arm-none-eabi-gcc  -O1 -ftree-vectorize -mcpu=cortex-a9 \
  -mfpu=neon -mfloat-abi=softfp ice.c 
ice.c: In function 'f0a':
ice.c:7:1: internal compiler error: in vect_is_simple_use_1, at
tree-vect-stmts.c:5987
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Checked against trunk revision 183018.

[Bug bootstrap/51787] [4.7 Regression] internal compiler error: in inline_small_functions, at ipa-inline.c:1410

[dougmencken at gmail dot com]

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

--- Comment #3 from Douglas Mencken  2012-01-09 
17:43:20 UTC ---
I can re-confirm that snapshots 4.7-20111231, 4.7-20120107 do fail (can't enter
this into "Known to fail" field, because despite that
http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#cf_known_to_fail says that
it is `A custom Free Text field', I'm facing the error: `The value "4.7" used
in the "Known to fail" field is not a valid version for the "gcc" product').

Bootstrapped 4.6.2 successfully (with the same config I'm using for
4.7-prereleases, see initial post), and tried to bootstrap 4.7-20111231 and
4.7-20120107 with that 4.6.2 as stage0 compiler. No success. Same error.



(In reply to comment #2)

> Works for me with GCC 4.7.0 20120107 (experimental) [trunk revision 182980] on
> x86-64-linux

Well, maybe it only fails on 32-bit linux@powerpc systems. (Also I doubt
there's something related to uClibc.)

[Bug fortran/51779] gcc 4.6.2 build fails on Mac OS X Lion w/Xcode 4.2, with gfortran erorr

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth  2012-01-09 
17:45:42 UTC ---
(In reply to comment #9)
> Thanks, Tobias. I did try out the gfortran 4.6.2 from here, and it does 
> compile
> runnable code. Unfortunately, it still does not work with any version of gdb I
> have tried on Mac OS X. My end goal in building the whole of gcc 4.6.2 was to
> try building a Fortran code and debug it with the latest gdb version (7.3.1).
> No luck with this prebuilt gfortran binary either.

   You will need to compile binaries with -Wl,-no_pie if you want to debug in
FSF gdb
under Lion (which defaults to -pie in the linker).  Apple's gdb automatically
disables
aslr under Lion (which can be turned back on by setting the  disable-aslr flag
to 0 within
Apple's gdb). This option doesn't exist in FSF gdb yet as far as I know.

ps There is some discussion of this at
http://reverse.put.as/2011/08/11/how-gdb-disables-aslr-in-mac-os-x-lion/.

[Bug tree-optimization/51775] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck"

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #7 from Eric Botcazou  2012-01-09 
17:53:43 UTC ---
Thanks for the fix.

[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*

[dj at redhat dot com]

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

DJ Delorie  changed:

   What|Removed |Added

 CC||dj at redhat dot com

--- Comment #1 from DJ Delorie  2012-01-09 18:02:53 UTC 
---
See if this helps:

Index: gcc/config/h8300/h8300.h
===
--- gcc/config/h8300/h8300.h  (revision 183004)
+++ gcc/config/h8300/h8300.h(working copy)
@@ -126,12 +126,13 @@ extern const char * const *h8_reg_names;

 /* The return address is pushed on the stack.  */
 #define INCOMING_RETURN_ADDR_RTX   gen_rtx_MEM (Pmode, gen_rtx_REG (Pmode,
STACK_POINTER_REGNUM))
 #define INCOMING_FRAME_SP_OFFSET   (POINTER_SIZE / 8)

 #define DWARF_CIE_DATA_ALIGNMENT   2
+#define DWARF2_ADDR_SIZE   4

 /* Define this if addresses of constant functions
shouldn't be put through pseudo regs where they can be cse'd.
Desirable on machines where ordinary constants are expensive
but a CALL with constant address is cheap.

[Bug fortran/51800] New: Error: Automatic array 'dummy' at (1) cannot have an initializer

[mario-baumann at web dot de]

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

 Bug #: 51800
   Summary: Error: Automatic array 'dummy' at (1) cannot have an
initializer
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mario-baum...@web.de


Created attachment 26282
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26282
fortran90 source file

Hi Gfortran Team,

compilation of the attached source file failed if using the both compiler
options -fno-automatic and -finit-local-zero.

> gfortran -c -m32 -O0 -fno-automatic -finit-local-zero foo.f90
foo.f90:6.27:
  INTEGER :: DUMMY(1:N)
   1
Error: Automatic array 'dummy' at (1) cannot have an initializer

It works fine if removing at least one of the both options above.

---

> uname -a
Linux ahsoka.intec.dom 2.6.32-220.2.1.el6.x86_64 #1 SMP Tue Dec 13 16:21:34 EST
2011 x86_64 x86_64 x86_64 GNU/Linux

> rpm -qa "glibc*" | grep -e 'glibc-[0-9]' | sort -u
glibc-2.12-1.47.el6.i686
glibc-2.12-1.47.el6.x86_64

> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/app2/gcc/4.7.0-20120109-svn183001/i686/libexec/gcc/i686-unknown-linux-gnu/4.7.0/lto-wrapper
Target: i686-unknown-linux-gnu
Configured with: ./configure --prefix=/app2/gcc/4.7.0-20120109-svn183001/i686
--enable-languages=c,c++,fortran --disable-nls
--with-gmp=/app2/gcc/4.7.0-20120109-svn183001/i686/aux
--with-mpfr=/app2/gcc/4.7.0-20120109-svn183001/i686/aux
--with-mpc=/app2/gcc/4.7.0-20120109-svn183001/i686/aux
--with-ppl=/app2/gcc/4.7.0-20120109-svn183001/i686/aux
--with-cloog=/app2/gcc/4.7.0-20120109-svn183001/i686/aux --disable-multilib
--build=i686-unknown-linux-gnu
Thread model: posix
gcc version 4.7.0 20120109 (experimental) (GCC) 

> ld -v
GNU ld (GNU Binutils) 2.22.51.20120109

[Bug fortran/51800] [4.6/4.7 Regression] Error: Automatic array 'dummy' at (1) cannot have an initializer

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||burnus at gcc dot gnu.org,
   ||toon at moene dot org
  Known to work||4.6.2
   Target Milestone|--- |4.6.3
Summary|Error: Automatic array  |[4.6/4.7 Regression] Error:
   |'dummy' at (1) cannot have  |Automatic array 'dummy' at
   |an initializer  |(1) cannot have an
   ||initializer
  Known to fail||4.7.0

--- Comment #1 from Tobias Burnus  2012-01-09 
18:34:52 UTC ---
I think that's due to the patch for PR 51310, i.e. the patches:
 [4.7]  http://gcc.gnu.org/ml/fortran/2011-12/msg00080.html
 [4.6]  http://gcc.gnu.org/ml/fortran/2011-12/msg00119.html

Toon, can you have a look?

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  2012-01-09 
18:40:16 UTC ---
Author: jamborm
Date: Mon Jan  9 18:40:09 2012
New Revision: 183023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183023
Log:
2012-01-09  Martin Jambor  

PR tree-optimization/51759

Backport from mainline
2010-09-15  Martin Jambor  

PR middle-end/45644
* tree-sra.c (create_access): Check for bit-fields directly.

* testsuite/gcc.dg/ipa/pr45644.c: New test.
* testsuite/g++.dg/ipa/pr51759.C: Likewise.


Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ipa/pr51759.C
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ipa/pr45644.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c

[Bug c++/51633] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-01-09
 CC||dodji at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |dodji at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug tree-optimization/51801] [4.7 Regression] ICE in inline_small_functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug middle-end/45644] [4.6 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  2012-01-09 
18:40:17 UTC ---
Author: jamborm
Date: Mon Jan  9 18:40:09 2012
New Revision: 183023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183023
Log:
2012-01-09  Martin Jambor  

PR tree-optimization/51759

Backport from mainline
2010-09-15  Martin Jambor  

PR middle-end/45644
* tree-sra.c (create_access): Check for bit-fields directly.

* testsuite/gcc.dg/ipa/pr45644.c: New test.
* testsuite/g++.dg/ipa/pr51759.C: Likewise.


Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ipa/pr51759.C
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ipa/pr45644.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c

[Bug tree-optimization/51801] New: [4.7 Regression] ICE in inline_small_functions

[jakub at gcc dot gnu.org]

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

 Bug #: 51801
   Summary: [4.7 Regression] ICE in inline_small_functions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: x86_64-linux


Created attachment 26283
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26283
menu.i

The following testcase ICEs at -O3 with:
menu.i:60:1: internal compiler error: in inline_small_functions, at
ipa-inline.c:1410

[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)

[dave.anglin at bell dot net]

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

--- Comment #11 from dave.anglin at bell dot net 2012-01-09 18:44:24 UTC ---
On 1/9/2012 10:55 AM, patrick.marlier at gmail dot com wrote:
> Do all libitm tests passed on PA?
All tm tests pass on PA (well, there is one that fails on 32-bit HP-UX 
due to the limited
alignment of common.  -fno-common should fix this).  As of now, I 
haven't had a chance
to try porting libitm to hppa-linux.  I'm not sure it can be ported to 
hppa-hpux.

[Bug fortran/51758] ICE with optional arguments of elemental procedures

[mikael at gcc dot gnu.org]

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

--- Comment #7 from Mikael Morin  2012-01-09 
19:01:44 UTC ---
Author: mikael
Date: Mon Jan  9 19:01:34 2012
New Revision: 183024

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183024
Log:
2012-01-09  Mikael Morin  

PR fortran/51758
* trans-array.c (gfc_walk_elemental_function_args):
Skip over NULL() actual arguments.

2012-01-09  Tobias Burnus  

PR fortran/51758
* gfortran.dg/optional_absent_2.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/optional_absent_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/50023] FAIL: gcc.dg/graphite/id-pr46845.c (test for excess errors)

[grosser at gcc dot gnu.org]

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

Tobias Grosser  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Tobias Grosser  2012-01-09 
19:20:13 UTC ---
(In reply to comment #2)
> A patch has been submitted at
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00611.html and approved at
> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00612.html . Any reason why it 
> has
> not been committed?

To me it seems it was committed 10.10.2011. Here the relevant commit:
http://gcc.gnu.org/viewcvs?view=revision&revision=179762

Does this commit not show up for you?

I marked this as resolved. If you cannot find the commit, please reopen the
bug.

All the best from ENS Paris
Tobi

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  2012-01-09 
19:52:13 UTC ---
Author: jamborm
Date: Mon Jan  9 19:52:06 2012
New Revision: 183029

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183029
Log:
2012-01-09  Martin Jambor  

PR tree-optimization/51759
* g++.dg/ipa/pr51759.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr51759.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #9 from Tobias Burnus  2012-01-09 
19:54:11 UTC ---
FIXED on the trunk (4.7).

Harald, thanks for the patch!

[Bug fortran/51197] [4.7 Regression] Backtrace information less useful

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-01-09 
19:53:32 UTC ---
Author: burnus
Date: Mon Jan  9 19:53:27 2012
New Revision: 183030

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183030
Log:
2012-01-09  Harald Anlauf  
Tobias Burnus  

PR fortran/51197
* runtime/backtrace.c (show_backtrace): Modify wording written
before the backtrace.
* runtime/compile_options.c (show_signal): New function.
(backtrace_handler): Use it.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/backtrace.c
trunk/libgfortran/runtime/compile_options.c

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  2012-01-09 
20:03:15 UTC ---
Author: jamborm
Date: Mon Jan  9 20:03:08 2012
New Revision: 183031

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183031
Log:
2012-01-09  Martin Jambor  

PR tree-optimization/51759
* g++.dg/ipa/pr51759.C: New test.


Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/ipa/pr51759.C
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/51759] [4.5 Regression] miscompile writes past end of bitfield

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

--- Comment #9 from Martin Jambor  2012-01-09 
20:05:27 UTC ---
I have backported the fix to the 4.5 branch and also committed the testcase to
the the 4.6 branch and trunk.  Still it is a duplicate of PR 45644 and so I'm
closing this as such.

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

[Bug middle-end/45644] [4.6 Regression] 450.soplex in SPEC CPU 2006 is miscompiled

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||nobled at dreamwidth dot
   ||org

--- Comment #11 from Martin Jambor  2012-01-09 
20:05:27 UTC ---
*** Bug 51759 has been marked as a duplicate of this bug. ***

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #33 from Steve Kargl  
2012-01-09 20:13:08 UTC ---
On Fri, Jan 06, 2012 at 04:14:08PM +, bkorb at gnu dot org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #32 from bkorb at gnu dot org 2012-01-06 16:14:08 UTC ---
> (In reply to comment #29)
> > +c_fix_arg = "__attribute__\(\(__noreturn__\)\)";
> 
> In a double quoted string, the backslash quotes always quote
> the character that follows.  Here, it yields a noop, which
> is fine because the "c-fix-arg" is scanned for "%1" type markers,
> not regular expressions.
> 

I used your patch with the above __attribute__ line.  I was
able to boostrap GCC on FreeBSD 10 without a hitch.  Can you
please commit your patch with the above change?

[Bug fortran/51791] [OOP] Failure to resolve typebound function call with base object in parentheses.

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  2012-01-09 20:26:05 
UTC ---
Author: pault
Date: Mon Jan  9 20:25:55 2012
New Revision: 183032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183032
Log:
2012-01-09  Paul Thomas  

PR fortran/51791
* interface.c (matching_typebound_op): Drill down through
possible parentheses to obtain base expression. Do not test for
'class_ok' but, instead for the class structure components.
* resolve.c (resolve_ordinary_assign): Extend error message for
polymorphic assignment to advise checking for specific
subroutine.

PR fortran/51792
* resolve.c (resolve_typebound_function): Restore 'static' to
declaration.

2012-01-09  Paul Thomas  

PR fortran/51791
* gfortran.dg/typebound_operator_7.f03: Insert parentheses
around base object in first assignment in main program.
* gfortran.dg/typebound_operator_10.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_10.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03

[Bug fortran/51792] [4.7 regression] fortran bootstrap failure: no previous prototype for 'resolve_typebound_function'

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  2012-01-09 20:26:14 
UTC ---
Author: pault
Date: Mon Jan  9 20:25:55 2012
New Revision: 183032

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183032
Log:
2012-01-09  Paul Thomas  

PR fortran/51791
* interface.c (matching_typebound_op): Drill down through
possible parentheses to obtain base expression. Do not test for
'class_ok' but, instead for the class structure components.
* resolve.c (resolve_ordinary_assign): Extend error message for
polymorphic assignment to advise checking for specific
subroutine.

PR fortran/51792
* resolve.c (resolve_typebound_function): Restore 'static' to
declaration.

2012-01-09  Paul Thomas  

PR fortran/51791
* gfortran.dg/typebound_operator_7.f03: Insert parentheses
around base object in first assignment in main program.
* gfortran.dg/typebound_operator_10.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/typebound_operator_10.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/typebound_operator_7.f03

[Bug fortran/51791] [OOP] Failure to resolve typebound function call with base object in parentheses.

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paul Thomas  2012-01-09 20:27:50 
UTC ---
Fixed on trunk

Paul

[Bug fortran/51792] [4.7 regression] fortran bootstrap failure: no previous prototype for 'resolve_typebound_function'

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Paul Thomas  2012-01-09 20:28:43 
UTC ---
Fixed on trunk

Paul

[Bug tree-optimization/51782] Missing address-space information leads to wrong code

[gjl at gcc dot gnu.org]

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

--- Comment #8 from Georg-Johann Lay  2012-01-09 
20:30:35 UTC ---
It's scalar replacement of aggregates:

With -O1 code is wrong.
With -O1 -fno-tree-sra code is correct.