[Bug tree-optimization/50078] [4.6/4.7 Regression] combine wrong code: volatile accesses optimized out

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 AssignedTo|matz at gcc dot gnu.org |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek  2011-11-28 
09:12:39 UTC ---
Created attachment 25929
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25929
gcc47-pr50078.patch

IMHO it is a forwprop bug, which changes a MEM_REF in this case into an
ARRAY_REF (with MEM_REF operand), but copies TREE_THIS_VOLATILE from the
original MEM_REF not to the ARRAY_REF, but to the inner MEM_REF.

[Bug c/51330] New: Compiling issue that seems specific to i586 with gcc 4.6

[remy.garrigue at gmail dot com]

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

 Bug #: 51330
   Summary: Compiling issue that seems specific to i586 with gcc
4.6
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: remy.garri...@gmail.com


I'm currently in charge of packaging some sources code, and I've an issue that
SEEMS to be related to gcc 4.6. Not sure thou, I'm not an expert either in the
code nor c/c++

You can find the packaging here:
https://build.opensuse.org/package/show?package=xtreemfs-1.2.3&project=home%3Axtreemfs

As you can see there, packaging for latest opensuse (12.1, factory,
tumbleweed), ubuntu 11.10 and fedora (15, 16) fails under i586 arch. Clic on
the red "failed" or the green "succeeded", then "download log file" and you'll
have the full log, with environment (and gcc) installation plus compilation. 

My point is, with gcc 4.5 older distro packaging is doing fine. With gcc 4.6,
latest one fails on i586. It may be something else, but this is as far as I can
diagnose.

I'm available to give a hand to set up an environment to reproduce my issue and
will be glad of any further information to solve my issue.

Regards,
Rémy

[Bug target/51330] Compiling issue that seems specific to i586 with gcc 4.6

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  2011-11-28 
09:35:35 UTC ---
>share/google-breakpad/src/client/linux/handler/linux_thread.cc:251:3: error: 
>expected primary-expression before 'struct'

Can you attach the preprocessed source?  

#define GET_DR(name, num)\
  name->dr##num = ptrace(PTRACE_PEEKUSER, pid,\
 offsetof(struct user, u_debugreg[num]), NULL)
  GET_DR(regs, 0);


Where is struct user supposed to be defined?  This looks rather like a header
not being included correctly and not really GCC issue.

[Bug ada/51307] [4.7 Regression] s-taprop.adb:676:25: "CLOCK_RT_Ada" not declared in "OS_Constants"

[charlet at gcc dot gnu.org]

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

Arnaud Charlet  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||charlet at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |charlet at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Arnaud Charlet  2011-11-28 
09:48:39 UTC ---
Here is the patch from Thomas Quinot fixing this issue, I'll commit it
when I get a chance, feel free to use it/test it in the mean time:

Modified: trunk/gnat/s-oscons-tmplt.c
===
--- trunk/gnat/s-oscons-tmplt.c 2011-11-28 09:36:54 UTC (rev 180967)
+++ trunk/gnat/s-oscons-tmplt.c 2011-11-28 09:42:49 UTC (rev 180968)
@@ -1343,7 +1343,9 @@

 */

-#ifdef CLOCK_REALTIME
+/* Note: On HP-UX, CLOCK_REALTIME is an enum, not a macro. */
+
+#if defined(CLOCK_REALTIME) || defined (__hpux__)
 CND(CLOCK_REALTIME, "System realtime clock")
 #endif

@@ -1377,7 +1379,7 @@
 # define CLOCK_RT_Ada "CLOCK_MONOTONIC"
 # define NEED_PTHREAD_CONDATTR_SETCLOCK

-#elif defined(CLOCK_REALTIME)
+#elif defined(CLOCK_REALTIME) || defined (__hpux__)
 /* By default use CLOCK_REALTIME */
 # define CLOCK_RT_Ada "CLOCK_REALTIME"
 #endif

[Bug c++/51329] O3 optimizes away a loop

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  2011-11-28 
10:08:19 UTC ---
(In reply to comment #2)
> Thanks, will report to apple.

Reporting to Apple is useless, they have long moved to Clang, so they won't fix
bugs in GCC. By extension, advising someone to report GCC bugs to Apple is
doubly-useless. You are basically telling them "Forget about GCC, use Clang!"
because this is what Apple will tell them.

A better advice is to try to install a newer GCC on your own

http://gcc.gnu.org/install/

or using macports:

http://www.macports.org/install.php

I am sure you can find plenty of information on the net.

If the bug is still there, reopen this report.

[Bug middle-end/50907] [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2011-11-28 
10:25:26 UTC ---
Created attachment 25930
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25930
gcc47-pr50907.patch

Untested fix.

[Bug target/51330] Compiling issue that seems specific to i586 with gcc 4.6

[remy.garrigue at gmail dot com]

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

--- Comment #2 from Rémy  2011-11-28 10:38:53 
UTC ---
Package source are available in the "source" panel here:
https://build.opensuse.org/package/files?package=xtreemfs-1.2.3&project=home%3Axtreemfs

The most accurate way to reproduce the build would be to install osc (opensuse
build service command line tools) and type the following
osc co home:xtreemfs xtreemfs-1.2.3  
cd home:xtreemfs/xtreemfs-1.2.3 
osc build openSUSE_12.1 i586 xtreemfs.spec

I spent a couple of hour again trying to fix that issue, adding #include
 for example, nothing so far. I've no idea where struct user is
defined, but if x86_64 build work with the same source, why i586 wouldn't...
I'm at a lost here

[Bug c++/51323] g++ confuses this with function argument in optimized call

[dak at gnu dot org]

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

--- Comment #1 from David Kastrup  2011-11-28 11:32:46 UTC 
---
-fno-optimize-sibling-calls avoids the problematic optimization.  For no good
reason at all, -fkeep-inline-functions, documented to do a completely unrelated
non-optimization (namely emitting inline functions even when all uses of them
had been inlined), will also switch off the problematic tail call optimization.

[Bug target/51330] Compiling issue that seems specific to i586 with gcc 4.6

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-11-28
 Ever Confirmed|0   |1

--- Comment #3 from Jonathan Wakely  2011-11-28 
11:35:43 UTC ---
(In reply to comment #2)
> The most accurate way to reproduce the build would be to install osc (opensuse
> build service command line tools) and type the following
> osc co home:xtreemfs xtreemfs-1.2.3  
> cd home:xtreemfs/xtreemfs-1.2.3 
> osc build openSUSE_12.1 i586 xtreemfs.spec

GCC devs do not want to install new packages and download new files for every
bug report, please attach preprocessed source for the failing file.

http://gcc.gnu.org/bugs/

[Bug c++/51331] New: bad code generated when explicitly calling auto-generated constructor of virtual base

[zhezherun at yandex dot ru]

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

 Bug #: 51331
   Summary: bad code generated when explicitly calling
auto-generated constructor of virtual base
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhezhe...@yandex.ru


If a virtual base class has an auto-generated default constructor, explicitly
calling it from the derived class' constructor can result in bad code. The
following stripped-down example reproduces the issue:


#include 

struct A {
A(): x(10) {}
virtual ~A() {}

int x;
};

struct B: public virtual A {
};

struct C: public virtual A {
};

struct D: public B, virtual public C {
D(): B(), C() {}  // note an explicit call to C() which is auto-generated
};

int main() {
D* d = new D();
std::cout << d->x << std::endl;

// Crashes here with the following message:
// *** glibc detected *** ./test: free(): invalid next size (fast)
delete d;
}


This code used to work correctly in gcc 4.1.2 but crashes in gcc 4.6.2 on i386
(both -m32 and -m64).

[Bug c/51332] New: __sync_add_and_fetch segfaults when -fPIC is enabled

[luca.martini at tin dot it]

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

 Bug #: 51332
   Summary: __sync_add_and_fetch segfaults when -fPIC is enabled
Classification: Unclassified
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: luca.mart...@tin.it


Created attachment 25931
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25931
preprocessor output

The code generated from compiler intrinsic __sync_add_and_fetch (on a 64bit
value) is erroneous when the -fPIC switch is enabled.

It seems that when the -fPIC switch is enabled, instruction CMPXCHG8B
references register EBX as a base pointer for the memory operand, whereas EBX
must contain part of the value to be incremented.

See a minimal reproducible example in attachment.

We experienced the problem when compiling with the following flags:

gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
 /usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -E -quiet -v main.c -m32
-march=i686 -fPIC -fworking-directory -fpch-preprocess -o main.i

the generated instruction is
lock cmpxchg8b(%ebx)
and should have been
lock cmpxchg8b(%esi)


we could not reproduce the bug with the gcc 4.4.4

[Bug c/51332] __sync_add_and_fetch segfaults when -fPIC is enabled

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Jonathan Wakely  2011-11-28 
12:06:34 UTC ---
4.1.2 is no longer supported and no bugs in that version will ever get fixed
now.  You've already stated there's no problem with a current release.

If you got the compiler from Red Hat and want it fixed then report it to them.

[Bug c++/51323] g++ confuses this with function argument in optimized call

[dak at gnu dot org]

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

David Kastrup  changed:

   What|Removed |Added

  Known to work|4.5.0   |4.5.2

--- Comment #2 from David Kastrup  2011-11-28 12:17:52 UTC 
---
This particular code generation bug is responsible for at least half a dozen
problems in the code base of Lilypond and causes a number of regression test
failures.

We will have to add respective compiler options based on the version number of
gcc.  If anybody knowing the responsible compiler internals can construct a
self-contained test case that does not require manually inspecting the
generated code for errors, we could at least add an autoconf test specifically
tailored to the occurence of this bug instead of basing the workaround compiler
options on the version number.

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[oleg.e...@t-online.de]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #25848|0   |1
is obsolete||

--- Comment #17 from Oleg Endo  2011-11-28 12:26:42 UTC 
---
Created attachment 25932
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25932
Proposed patch to add QImode displacement addressing

An updated version of the patch.  Tested against rev 181404, resolves some
previous failures for SH2A but also introduces the following libstdc++ related
failures:

FAIL: 22_locale/ctype/is/wchar_t/11740.cc (test for excess errors)
FAIL: 22_locale/money_get/get/char/5.cc execution test
FAIL: 22_locale/money_put/put/char/12971.cc execution test
FAIL: 22_locale/money_put/put/char/39168.cc execution test
FAIL: 22_locale/money_put/put/char/4.cc execution test
FAIL: 22_locale/money_put/put/char/5.cc execution test
FAIL: 22_locale/money_put/put/char/6.cc execution test
FAIL: 22_locale/money_put/put/wchar_t/12971.cc execution test
FAIL: 22_locale/money_put/put/wchar_t/39168.cc execution test
FAIL: 22_locale/money_put/put/wchar_t/4.cc execution test
FAIL: 22_locale/money_put/put/wchar_t/5.cc execution test
FAIL: 22_locale/money_put/put/wchar_t/6.cc execution test

Still investigating...

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-28 12:42:17 UTC ---
> --- Comment #13 from Jonathan Wakely  2011-11-26 
> 15:18:40 UTC ---
> Does this reduced test work with -std=gnu++11 -pthread ?

Unfortunately not, I still get

22 : Invalid argument

Only if I add an explicit call to pthread_mutex_init does the testcase
work.

I've no real idea why this happens.  pthread_mutex_init(3) states

  Use the PTHREAD_MUTEX_INITIALIZER macro to statically initialize a mutex
  without calling this routine. Statically initialized mutexes need not be
  destroyed using pthread_mutex_destroy(3). Use this macro as follows:

  pthread_mutex_t mutex= PTHREAD_MUTEX_INITIALIZER

  Only normal mutexes can be statically initialized.

While I do have Tru64 UNIX sources, libpthread is only partially
included and the implementation of pthread_mutex_lock is missing.

Rainer

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-11-28 
13:11:49 UTC ---
Created attachment 25933
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25933
gcc47-pr50317-1.patch

One way to fix this regression is schedule another update_addresses_taken
before cddce.  Already in *copyprop1 the var has address taken only solely in
debug stmts, and by dropping TREE_ADDRESSABLE on it the right thing happens
(except that {CLOBBER} stuff messes it up, see patch I'm going to attach
momentarily).

I've tried:

--- gcc/tree-ssa-dce.c.jj 2011-11-08 23:35:12.0 +0100
+++ gcc/tree-ssa-dce.c  2011-11-28 12:35:55.745657320 +0100
@@ -1215,6 +1215,25 @@ remove_dead_stmt (gimple_stmt_iterator *
  ei_next (&ei);
 }

+  /* If this is a store into a variable that is being optimized away,
+ add a debug bind stmt if possible.  */
+  if (MAY_HAVE_DEBUG_STMTS
+  && gimple_assign_single_p (stmt)
+  && is_gimple_val (gimple_assign_rhs1 (stmt)))
+{
+  tree lhs = gimple_assign_lhs (stmt);
+  if ((TREE_CODE (lhs) == VAR_DECL || TREE_CODE (lhs) == PARM_DECL)
+ && !DECL_IGNORED_P (lhs)
+ && is_gimple_reg_type (TREE_TYPE (lhs))
+ && !DECL_HAS_VALUE_EXPR_P (lhs))
+   {
+ tree rhs = gimple_assign_rhs1 (stmt);
+ gimple note
+   = gimple_build_debug_bind (lhs, unshare_expr (rhs), stmt);
+ gsi_insert_after (i, note, GSI_SAME_STMT);
+   }
+}
+
   unlink_stmt_vdef (stmt);
   gsi_remove (i, true);
   release_defs (stmt);

as an alternative, but leads to ICEs, at some later point we'd need to
somewhere determine if the var mentioned in the debug stmts on the RHS which is
still TREE_ADDRESSABLE is ever referenced in non-debug stmts or not.  If not,
we'd want to drop TREE_ADDRESSABLE bit from it, otherwise e.g. at expansion
time we could just ignore the debug stmt, because it is not
target_for_debug_bind when it is TREE_ADDRESSABLE.

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-11-28 
13:17:02 UTC ---
Created attachment 25934
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25934
gcc47-pr50317-2.patch

Patch to drop ={v} {CLOBBER} stmts when the lhs lost TREE_ADDRESSABLE bit
during execute_update_addresses_taken.  If I remember well, Micha said that
CLOBBERs for SSA_NAMEs are undesirable and indeed for debug stmts they are just
harmful - the end of the scope is better to be determined from where the scope
in the debug info ends, when we add DEBUG var => {CLOBBER}, it might be still
before a few stmts such as GIMPLE_RETURN in this testcase where it is still
valid.

[Bug libstdc++/51288] [C++0x] get_money implementation is missing the sentry object (does not skip leading whitespace)

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2011-11-28 13:24:29 UTC ---
Author: paolo
Date: Mon Nov 28 13:24:23 2011
New Revision: 181775

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181775
Log:
2011-11-28  Paolo Carlini  

PR libstdc++/51288
* include/std/iomanip (get_money, put_money): Use sentry.
* testsuite/27_io/manipulators/extended/get_money/char/51288.cc: New.
* testsuite/27_io/manipulators/extended/get_money/wchar_t/51288.cc:
Likewise.
* testsuite/27_io/manipulators/extended/put_money/char/51288.cc:
Likewise.
* testsuite/27_io/manipulators/extended/put_money/wchar_t/51288.cc:
Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_money/char/51288.cc
   
trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/get_money/wchar_t/51288.cc
   
trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_money/char/51288.cc
   
trunk/libstdc++-v3/testsuite/27_io/manipulators/extended/put_money/wchar_t/51288.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/iomanip

[Bug libstdc++/51288] [C++0x] get_money implementation is missing the sentry object (does not skip leading whitespace)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2011-11-28 
13:25:05 UTC ---
Fixed for 4.7.0.

[Bug target/50814] SH Target: SHAD / SHLD instructions not used on SH2A

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  2011-11-28 
13:43:16 UTC ---
BTW, when regtesting, I've found that there are many ICEs at -O0.
A typical one is gcc.c-torture/compile/2923-1.c with -m2a -O0:

...: error: insn does not satisfy its constraints:
(insn 142 34 35 (set (mem/c:SI (plus:SI (reg/f:SI 14 r14)
(const_int 36 [0x24])) [0 %sfp+-16 S4 A32])
(reg:SI 150 fpul)) ... {movsi_ie}
 (nil))
...: internal compiler error: in extract_constrain_insn_cached, at recog.c:2052

which is solved by the hunk in the patch against PR50751

--- gcc/config/sh/sh.c.orig2011-11-28 10:03:04.0 +0900
+++ gcc/config/sh/sh.c2011-11-28 15:09:01.0 +0900
@@ -12432,6 +12432,10 @@ sh_secondary_reload (bool in_p, rtx x, r
   if (rclass != GENERAL_REGS && REG_P (x)
   && TARGET_REGISTER_P (REGNO (x)))
 return GENERAL_REGS;
+  /* If here fall back to loading FPUL register through general regs. 
+ Happens when FPUL has to be loaded from a reg allocated on the stack.  */
+  if (rclass == FPUL_REGS && !REG_P (x))
+return GENERAL_REGS;
   return NO_REGS;
 }

Oleg, it seems that this is the right patch for an independent issue
described in your comment.  Could you please file it to the bugzilla
and propose that patch to the gcc-patch list?

[Bug c++/51333] New: cxxabi.h incompatible with -fkeep-inline-functions at link time

[dak at gnu dot org]

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

 Bug #: 51333
   Summary: cxxabi.h incompatible with -fkeep-inline-functions at
link time
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gnu.org


Created attachment 25935
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25935
File failing at link time

The following file fails, when compiled with -fkeep-inline-functions, at link
time with the error

g++ -fkeep-inline-functions abi.cc
/tmp/ccI7H3ZL.o: In function
`__gnu_cxx::recursive_init_error::recursive_init_error()':
abi.cc:(.text._ZN9__gnu_cxx20recursive_init_errorC2Ev[_ZN9__gnu_cxx20recursive_init_errorC5Ev]+0x16):
undefined reference to `vtable for __gnu_cxx::recursive_init_error'
collect2: ld returned 1 exit status

Compilation exited abnormally with code 1 at Mon Nov 28 14:41:24

Version is
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz  2011-11-28 13:46:45 
UTC ---
(In reply to comment #6)
> Patch to drop ={v} {CLOBBER} stmts when the lhs lost TREE_ADDRESSABLE bit
> during execute_update_addresses_taken.

Actually it's not only the loss of TREE_ADDRESSABLE, but more specifically
that the symbol is marked for renaming now (i.e. will become a SSA name).
There are other decls (not of gimple_reg type) that aren't marked addressed
but still aren't renamed (and therefore the clobbers are still useful).

I see that your patch does the right thing for this, but just wanted to
mention it because it's really the renaming, not the loss of TREE_ADDRESSABLE
that makes removing the clobber a good idea.  I think your condition is a bit
too verbose.  marked_for_renaming implies !TREE_ADDRESSABLE, and a clobber
statement should always have a gimple_vdef.

Then, adding another IL walk just for this?  Why does your first patch ICE?
Can't that be fixed up somehow?

[Bug fortran/51308] PARAMETER attribute conflicts with SAVE attribute

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-11-28 13:58:02 UTC ---
On Mon, Nov 28, 2011 at 07:51:02AM +, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51308
> 
> --- Comment #3 from Tobias Burnus  2011-11-28 
> 07:51:02 UTC ---
> (In reply to comment #2)
> > -  conf2 (is_bind_c);
> > +  if (!(name && (strcmp(name, "c_null_ptr") == 0 || strcmp(name,
> > "c_null_funptr") == 0)))
> > +conf2 (is_bind_c);
> 
> I think one should use "if (!is_iso_c)". And why do you keep the save
> attribute? I think the following should work as well.

I kept the SAVE attribute because the comment (which you remove
in your patch) claims that it is needed to actually allow the 
the compiler to initialize c_null_ptr and c_null_funptr to NULL.
I did not go through the code to validate the comment's claim.

I did not use is_iso_c because I forgot about its existence.
If your patch passes regression testing, go ahead and commit it.

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-11-28 
14:10:40 UTC ---
Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var into
SSA instead.

As for gcc47-pr50317-1.patch, the another walk isn't because of the CLOBBERs,
what it tries to solve is drop the ADDRESSABLE bit before CDDCE decides to
instead optimize all the stores away as unnecessary (the former does the right
thing for debug info, the latter does not).

The reason why the gcc/tree-ssa-dce.c change doesn't work is that currently we
rely on the var in debug stmts to be target_for_debug_bind (which among other
conditions means is_gimple_reg).  That patch emits debug stmts even for cases
where the var is not is_gimple_reg because of TREE_ADDRESSABLE.  As nothing
drops the TREE_ADDRESSABLE bit later on (on this testcase we could do it
somewhere, but not generally, consider e.g. where the first store into some
addressable var is necessary, but last store is not).  DCE at this point
doesn't know if it is removing all references of the addressable var from the
IL.
Passes that are upset about the !target_for_debug_bind var in debug stmts/debug
insns are expansion (it doesn't ICE, but doesn't create the implicit pointer
because the var whose address is taken is addressable) and var-tracking (for
which it leads to ICEs because VALUE is propagated through into the notes).

[Bug fortran/51308] PARAMETER attribute conflicts with SAVE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-11-28 
14:17:50 UTC ---
(In reply to comment #4)
> I kept the SAVE attribute because the comment (which you remove
> in your patch) claims that it is needed to actually allow the 
> the compiler to initialize c_null_ptr and c_null_funptr to NULL.

Well, an initialization (sym->value) can only be only used for PARAMETERs or
for variables in static memory ("SAVE"). Having both "SAVE" and "PARAMETER"
does not really make sense. I assume that first the SAVE was added - and only
later PARAMETER (with a similar comment and many lines later in the file).

I have submitted the patch for approval at
  http://gcc.gnu.org/ml/fortran/2011-11/msg00234.html
and given your approval in comment 4 I will commit it. Thanks for looking
through my patch and for debugging and creating the draft patch of comment 2.

[Bug fortran/51308] PARAMETER attribute conflicts with SAVE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2011-11-28 
14:21:38 UTC ---
Author: burnus
Date: Mon Nov 28 14:21:33 2011
New Revision: 181778

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181778
Log:
2011-11-28  Tobias Burnus  
Steven G. Kargl  

PR fortran/51308
* symbol.c (check_conflict): Ignore BIND(C) + PARAMETER
conflicts for ISO_C_BINDING variables.
(gen_special_c_interop_ptr): Don't mark c_ptr_null/c_funptr_null
as SAVE.

2011-11-28  Tobias Burnus  

PR fortran/51308
* gfortran.dg/iso_c_binding_compiler_4.f90: New.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  2011-11-28 
14:22:24 UTC ---
(In reply to comment #14)
> > --- Comment #13 from Jonathan Wakely  2011-11-26 
> > 15:18:40 UTC ---
> > Does this reduced test work with -std=gnu++11 -pthread ?
> 
> Unfortunately not, I still get
> 
> 22 : Invalid argument

IMHO it's fortunate since it's not just problem in the std::mutex code ;)

> Only if I add an explicit call to pthread_mutex_init does the testcase
> work.

Very strange, especially since the definitions you gave in comment 9 don't seem
to do anything complicated.

Does this work?

#include 
#include 
#include 

struct M {
  pthread_mutex_t m;
  M() noexcept {
   pthread_mutex_t tmp = PTHREAD_MUTEX_INITIALIZER;
   m = tmp;
  }
};

int main()
{
   M m;
   int e = pthread_mutex_lock(&m.m);
   if (e)
 printf("%d : %s\n", e, strerror(e));
   return e;
}

If that works, we might be able to fix it using fixincludes (similar to PR
50982 comment 32)

Otherwise I suppose we must not define __GTHREAD_MUTEX_INIT on Tru64, causing
std::mutex to use the init function instead.

[Bug fortran/40958] module files too large

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #4 from Joost VandeVondele  
2011-11-28 14:24:02 UTC ---
Just for reference, compiling CP2K_2009-05-01.f90 results in 684 modules,
stracing yields something like 12000 calls to open, and 148'847'399 calls to
lseek.

Clearly anything reducing the number of seeks is likely to have a good impact
on compile time.

For this particular case, caching modules would help a lot as well. However,
our usual pattern is to have a single module per file, and all use statements
at the top of the module. Caching would be of little help for this style. An
efficient encoding of the information in the module would help.

The idea of writing the module compressed, and decompressing it as a big string
to memory for reading and parsing, seems appealing to me.

Concerning a change of format, it would be important to keep one of gfortran's
nice features, that is, the ability to use the modification time of the .mod
files to avoid recompilation cascades. If .mod files would contain a reference
to other .mod files (instead of containing the info directly), this property
might be at risk.

[Bug fortran/51308] PARAMETER attribute conflicts with SAVE attribute

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus  2011-11-28 
14:27:22 UTC ---
FIXED on the trunk (4.7).

Thanks Matthias for reporting the bug; it is now fixed at the development
branch, which will be released around March 2012 as GCC 4.7.0.

See http://gcc.gnu.org/wiki/GFortranBinaries for some regular binary builds
(some updated nightly, others lagging behind). The page also contains a link
for building it manually from source or links to Linux distributions (at least
SUSE has already 4.7-devel snapshots on their build server).

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-28 14:34:38 UTC ---
> Does this work?

No, I still get EINVAL.

> Otherwise I suppose we must not define __GTHREAD_MUTEX_INIT on Tru64, causing
> std::mutex to use the init function instead.

The strange thing is that is seems to have worked so far without issues,
e.g. in emutls.c.

Rainer

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  2011-11-28 
14:36:53 UTC ---
Created attachment 25936
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25936
gcc47-pr50317-3.patch

Alternative to gcc47-pr50317-3.patch (everything untested), which adds some
hacks so that the DCE hunk works on this testcase.  I'm a little bit worried
that it could create too many debug bind stmts which might turn out to be
useless (as not all of references to the var will be removed).

[Bug c++/51333] cxxabi.h incompatible with -fkeep-inline-functions at link time

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-11-28 
14:38:15 UTC ---
works with -lsupc++ but I'm not sure why it fails without

[Bug libstdc++/51296] Several 30_threads tests FAIL on Tru64 UNIX

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2011-11-28 
14:40:21 UTC ---
(In reply to comment #16)
> The strange thing is that is seems to have worked so far without issues,
> e.g. in emutls.c.

and in libstdc++-v3/include/ext/concurrence.h

maybe the difference is -std=c++11

[Bug fortran/51308] PARAMETER attribute conflicts with SAVE attribute

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2011-11-28 
14:47:45 UTC ---
Author: burnus
Date: Mon Nov 28 14:47:39 2011
New Revision: 181779

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181779
Log:
Really commit the test case:

2011-11-28  Tobias Burnus  

PR fortran/51308
* gfortran.dg/iso_c_binding_compiler_4.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/iso_c_binding_compiler_4.f90

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[matz at gcc dot gnu.org]

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

--- Comment #10 from Michael Matz  2011-11-28 14:52:50 
UTC ---
(In reply to comment #8)
> Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var
> into SSA instead.

I think your current patch is better, no use in slowing down the SSA renamer,
there aren't that many points where a var can suddenly become renamed
when it couldn't before.  I think you should send it to gcc-patches
independent if it fixes this one or not.

> As for gcc47-pr50317-1.patch, the another walk isn't because of the
> CLOBBERs, what it tries to solve is drop the ADDRESSABLE bit before
> CDDCE decides to instead optimize all the stores away as unnecessary
> (the former does the right thing for debug info, the latter does not).

But conceivably we can have other passes than CDDCE which can remove
stores, including the last one, so IMO the latter should better be made to
work.  As in, update_address_taken should purely be an optimization, it should
never be required for correct operation.

> The reason why the gcc/tree-ssa-dce.c change doesn't work is that currently we
> rely on the var in debug stmts to be target_for_debug_bind (which among other
> conditions means is_gimple_reg).  That patch emits debug stmts even for cases
> where the var is not is_gimple_reg because of TREE_ADDRESSABLE.  As nothing
> drops the TREE_ADDRESSABLE bit later on (on this testcase we could do it
> somewhere, but not generally, consider e.g. where the first store into some
> addressable var is necessary, but last store is not).  DCE at this point
> doesn't know if it is removing all references of the addressable var from the
> IL.
> Passes that are upset about the !target_for_debug_bind var in debug 
> stmts/debug
> insns are expansion (it doesn't ICE, but doesn't create the implicit pointer
> because the var whose address is taken is addressable) and var-tracking (for
> which it leads to ICEs because VALUE is propagated through into the notes).

Okay, so there are multiple ways out:
1) accept also TREE_ADDRESSABLES in target_for_debug_bind;
   why is it rejecting the needs_to_live_in_memory objects?
2) drop TREE_ADDRESSABLE for unreferenced variables
   (remove_unused_locals, but that again should only be an optimization,
   not a correctness measure)
3) Accept variables in DEBUG_BIND unconditionally if they are
   target_for_debug_bind or not.  Presumably the one creating the debug
   bind will have known what he was doing.

I think (3) looks most sensible?

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

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  2011-11-28 
15:10:00 UTC ---
Created attachment 25937
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25937
gcc47-pr50237.patch

Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
either.

[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64 with -fPIC

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  2011-11-28 
15:15:32 UTC ---
See http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02413.html

[Bug middle-end/49719] [4.7 Regression] test gcc.target/arm/sibcall-1.c fails for ARM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-11-28 
15:15:22 UTC ---
See http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02413.html

[Bug debug/47858] [4.5/4.6/4.7 Regression] IPA-SRA decreases quality of debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jakub Jelinek  2011-11-28 
15:16:59 UTC ---
Fixed.

[Bug c++/51333] cxxabi.h incompatible with -fkeep-inline-functions at link time

[dak at gnu dot org]

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

David Kastrup  changed:

   What|Removed |Added

  Known to work|4.5.2   |

--- Comment #2 from David Kastrup  2011-11-28 15:25:03 UTC 
---
I am more surprised that actual demangling applications work without -lsupc++
as long as -fkeep-inline-functions is not used.

It is good to have a solution (even if its necessity depends on the compilation
options in a non-obvious way), but the actual error message certainly does not
particularly help in figuring out the problem.

I have to take back "works with 4.5.2" since I forgot that I used
-fkeep-inline-functions only once I needed to work around a 4.6.1 bug.  So I
actually have no data point when this option would have worked with the given
test file.

Probably that renders this particular report "invalid", but somebody really
should try making the link error message more intelligible.

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-11-28 
15:32:18 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> > Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var
> > into SSA instead.
> 
> I think your current patch is better, no use in slowing down the SSA renamer,
> there aren't that many points where a var can suddenly become renamed
> when it couldn't before.  I think you should send it to gcc-patches
> independent if it fixes this one or not.

Yeah, I played with it and doing it in the renamer wouldn't be very trivial and
very surprising for various passes if the renamer removes stmts.
Will bootstrap/regtest it.

> > As for gcc47-pr50317-1.patch, the another walk isn't because of the
> > CLOBBERs, what it tries to solve is drop the ADDRESSABLE bit before
> > CDDCE decides to instead optimize all the stores away as unnecessary
> > (the former does the right thing for debug info, the latter does not).
> 
> But conceivably we can have other passes than CDDCE which can remove
> stores, including the last one, so IMO the latter should better be made to
> work.  As in, update_address_taken should purely be an optimization, it should
> never be required for correct operation.

Well, the another scheduled in updates_address_taken wasn't a correctness
issue, just a nice to have thing which improves debug info in that case.  The
debug info isn't incorrect, just less complete (and the regression is in the
debug info quality).

> Okay, so there are multiple ways out:
> 1) accept also TREE_ADDRESSABLES in target_for_debug_bind;
>why is it rejecting the needs_to_live_in_memory objects?
> 2) drop TREE_ADDRESSABLE for unreferenced variables
>(remove_unused_locals, but that again should only be an optimization,
>not a correctness measure)
> 3) Accept variables in DEBUG_BIND unconditionally if they are
>target_for_debug_bind or not.  Presumably the one creating the debug
>bind will have known what he was doing.
> 
> I think (3) looks most sensible?

What I have in the last patch is roughly accepting those TREE_ADDRESSABLES in
there while in GIMPLE IL (== 1) ), dropping TREE_ADDRESSABLE in
remove_unused_locals as an optimization (== 2) ) and avoiding creation of the
debug insns during expansion if they don't still satisfy target_for_debug_bind
(correctness issue).

[Bug c++/51289] [C++0x] Template template alias causes ICE

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-28
 Ever Confirmed|0   |1

--- Comment #1 from Dodji Seketeli  2011-11-28 
15:33:39 UTC ---
I am testing a patch for this.

[Bug c++/51289] [C++0x] Template template alias causes ICE

[dodji at gcc dot gnu.org]

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

Dodji Seketeli  changed:

   What|Removed |Added

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

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-11-28 15:40:32 UTC ---
> Getting rid of the attribute constructor in libcpp/lex.c isn't that hard
> either.

... but doesn't help for the Go comparison failures.

Rainer

[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  2011-11-28 
15:55:35 UTC ---
So can this be closed now?

[Bug fortran/51056] [4.7 Regression][OOP] Bogus "Unused module variable '__vtab_domain_Domain_container'"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug other/51022] powerpc libgcc static-object.mk error

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth  2011-11-28 16:02:16 UTC 
---
Author: ro
Date: Mon Nov 28 16:02:10 2011
New Revision: 181782

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181782
Log:
Cleanup rs6000/t-ppccomm configurations (PR other/51022)

PR other/51022
* config/rs6000/t-savresfgpr: New file.
* config/rs6000/t-ppccomm (LIB2ADD_ST): Remove all but
$(srcdir)/config/rs6000/eabi.S.
* config/rs6000/t-ppccomm-ldbl: Remove.
* config.host (powerpc-*-freebsd*): Add rs6000/t-savresfgpr to
tmake_file.
(powerpc-*-eabispe*): Likewise.
(powerpc-*-eabi*): Likewise.
(powerpc-*-linux*, powerpc64-*-linux*): Likewise.
(powerpc-wrs-vxworks, powerpc-wrs-vxworksae): Add rs6000/t-ppccomm
to tmake_file, remove rs6000/t-ppccomm-ldbl.
(powerpc-*-eabisimaltivec*): Remove rs6000/t-ppccomm-ldbl from
tmake_file.
(powerpc-*-eabisim*): Likewise.
(powerpc-*-elf*): Likewise.
(powerpc-*-eabialtivec*): Likewise.
(powerpc-xilinx-eabi*): Likewise.
(powerpc-*-rtems*): Likewise.
(powerpcle-*-elf*): Likewise.
(powerpcle-*-eabisim*): Likewise.
(powerpcle-*-eabi*): Likewise.

Added:
trunk/libgcc/config/rs6000/t-savresfgpr
  - copied, changed from r181779, trunk/libgcc/config/rs6000/t-ppccomm
Removed:
trunk/libgcc/config/rs6000/t-ppccomm-ldbl
Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.host
trunk/libgcc/config/rs6000/t-ppccomm

[Bug other/51022] powerpc libgcc static-object.mk error

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Rainer Orth  2011-11-28 16:09:38 UTC 
---
Fixed for 4.7.0.

[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay  2011-11-28 
16:21:24 UTC ---
Yes from my side.

[Bug middle-end/49629] [4.7 Regression] ICE: in df_refs_verify, at df-scan.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #11 from Jakub Jelinek  2011-11-28 
16:30:15 UTC ---
Closing then.

[Bug fortran/51334] New: [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:55

[burnus at gcc dot gnu.org]

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

 Bug #: 51334
   Summary: [OOP] ICE with type-bound operator: tree check:
expected record_type or union_type or qual_union_type,
have function_type in gfc_conv_component_ref, at
fortran/trans-expr.c:556
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Created attachment 25938
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25938
Failing program

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d9df983132fcc643

Arjen Markus reports there that his program ICEs with GCC 4.6; it also does so
with GCC the trunk. It does compile with ifort 12.1 (but not with 12.0);
however, there are unresolved symbols with ifort 12.1. It fails to compile with
PGI 11.5 and crayftn 7.1.4.111, but those errors look bogus.


In gfortran 4.7:

Test.f90: In function ‘test_pde_solver’:
Test.f90:375:0: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have function_type in gfc_conv_component_ref, at
fortran/trans-expr.c:556


The line of interest is:
deriv= diff * solution%nabla2()

The ICE is in gfc_conv_component_ref; debugging shows:

(gdb) p c->name
$2 = 0x2cf09050 "_vptr"

(gdb) p debug_tree(decl)
 

[Bug bootstrap/50993] IRIX: fails to build in lto for sgi1.0 linker flag

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #1 from Rainer Orth  2011-11-28 16:44:46 UTC 
---
Please try with gas, but SGI ld.  I cannot even bootstrap with gld 2.20 (cf.
PR target/43533).

[Bug fortran/40958] module files too large

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Joost VandeVondele  
2011-11-28 17:05:05 UTC ---
(In reply to comment #4)
> Just for reference, compiling CP2K_2009-05-01.f90 results in 684 modules,
> stracing yields something like 12000 calls to open, and 148'847'399 calls to
> lseek.

With Thomas patch (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958) the
number of seeks drops to 19'557'182, which quite an improvement. In the trace
output, there are still very long sequences of identical lseek, without any
other intermediate call.

[Bug fortran/51334] [OOP] ICE with type-bound operator: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_conv_component_ref, at fortran/trans-expr.c:556

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Depends on||46328

--- Comment #1 from Tobias Burnus  2011-11-28 
17:39:08 UTC ---
The issue seems to be again the nested operators. One has for:
  deriv= diff * solution%nabla2()

an outer obj_assign_obj(obj1, obj2) operator and as inner operator the RHS ==
obj2, which is "real_times_obj", defined as:
function real_times_obj( factor, obj ) result(newobj)
real, intent(in):: factor
class(base_pde_object), intent(in)  :: obj
class(base_pde_object), allocatable :: newobj
As further nesting level, there is the inner nabla2() function, which returns
again at CLASS:
  function nabla2( obj )
class(base_pde_object), intent(in)  :: obj
class(base_pde_object), allocatable :: nabla2

And at some point one needs to access (expr->vtab->(procedure))(expr->value)
which fails without a temporary.

Thus, I think this bug is effectively a duplicate of PR 46328.

[Bug middle-end/51323] g++ confuses this with function argument in optimized call

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-28
 CC||jakub at gcc dot gnu.org
  Component|c++ |middle-end
 Ever Confirmed|0   |1

--- Comment #3 from Jakub Jelinek  2011-11-28 
17:54:05 UTC ---
Can't reproduce this with 4.6, but can with the trunk.

/* PR middle-end/51323 */

extern void abort (void);
struct S { int a, b, c; };
int v;

__attribute__((noinline, noclone)) void
foo (int x, int y, int z)
{
  if (x != v || y != 0 || z != 9)
abort ();
}

static inline int
baz (const struct S *p)
{
  return p->b;
}

__attribute__((noinline, noclone)) void
bar (int x, struct S y)
{
  foo (baz (&y), 0, x);
}

int
main ()
{
  struct S s;
  v = 3; s.a = v - 1; s.b = v; s.c = v + 1;
  bar (9, s);
  v = 17; s.a = v - 1; s.b = v; s.c = v + 1;
  bar (9, s);
  return 0;
}

at -O2 -m32 fails.  My http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02413.html
seems to fix this.

[Bug bootstrap/51335] New: [4.7 Regression] --enable-languages=c --disable-bootstrap doesn't work

[hjl.tools at gmail dot com]

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

 Bug #: 51335
   Summary: [4.7 Regression] --enable-languages=c
--disable-bootstrap doesn't work
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, when gcc is configured with

.../configure --enable-languages=c --disable-bootstrap  --prefix=/usr/gcc-4.7.0
--with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse

revision 181782 gave

/export/gnu/import/git/gcc/libitm/libitm.h:154:82: error: ‘transaction_pure’
attribute directive ignored [-Werror=attributes]
/export/gnu/import/git/gcc/libitm/libitm.h:157:68: error: ‘transaction_pure’
attribute directive ignored [-Werror=attributes]
/export/gnu/import/git/gcc/libitm/libitm.h:160:68: error: ‘transaction_pure’
attribute directive ignored [-Werror=attributes]
/export/gnu/import/git/gcc/libitm/libitm.h:162:64: error: ‘transaction_pure’
attribute directive ignored [-Werror=attributes]

Only C is enabled, but libitm is in C++.

[Bug bootstrap/51335] [4.7 Regression] --enable-languages=c --disable-bootstrap doesn't work

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2011-11-28 17:58:52 
UTC ---
We should either enable C++ or disable libitm in this case.

[Bug c++/51329] O3 optimizes away a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2011-11-28 
18:23:05 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Thanks, will report to apple.
> 
> Reporting to Apple is useless, they have long moved to Clang, so they won't 
> fix
> bugs in GCC. By extension, advising someone to report GCC bugs to Apple is
> doubly-useless. You are basically telling them "Forget about GCC, use Clang!"
> because this is what Apple will tell them.
> 

Actually this is incorrect because Apple needs to know that a lot of folks
still use GCC and want to use GCC but that is all offtopic here really.  The
thing is that Apple supplied the GCC they are using and it is heavily modified
so Apple needs to support what they provided.

[Bug middle-end/51323] g++ confuses this with function argument in optimized call

[dak at gnu dot org]

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

--- Comment #4 from David Kastrup  2011-11-28 18:24:10 UTC 
---
I can confirm that my version of gcc identifying itself as
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
makes your test program abort under -O2.  If you _cannot_ confirm this with
your version 4.6.1 but with the trunk, it would appear that Ubuntu 11.10 (or
its upstream Debian) has imprudently integrated unstable code from the 4.7
branch into the version of gcc they choose to distribute with the release.

If your test program can reasonably be considered as perfectly correlated with
the occurence of the bug (I don't have the expertise), I'll be using it as an
autoconf test in Lilypond for deciding whether to compile with
-fno-optimize-sibling-calls instead of the current test just checking the
version.

Thanks.

[Bug bootstrap/51335] [4.7 Regression] --enable-languages=c --disable-bootstrap doesn't work

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-11-28 
18:24:56 UTC ---
dup of PR 51072 ?

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-11-28
 CC||jakub at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

[Bug c++/51336] New: [C++11] is_abstract and sfinae

[marc.glisse at normalesup dot org]

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

 Bug #: 51336
   Summary: [C++11] is_abstract and sfinae
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


#include 
template
struct A {
template::value>::type>
A(A const&){}
};
constexpr bool b = std::is_abstract>::value;

$ g++ -std=c++0x n.cc -c
n.cc: In instantiation of 'struct A':
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:530:12:
  required from 'struct std::is_abstract >'
n.cc:7:47:   required from here
n.cc:5:3: error: no type named 'type' in 'struct std::enable_if'

I am not sure what is supposed to happen (that's why I tried), but this result
doesn't seem right. Filed under C++ because is_abstract directly forwards to
the __is_abstract builtin, but feel free to reassign to libstdc++ if you think
the problem is there somehow.

I first tried it with is_copy_constructible (which indirectly calls is_abstract
through is_destructible) to check the value it would give (clang+libc++ says
is_copy_constructible is true).

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[howarth at nitro dot med.uc.edu]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #2 from Jack Howarth  2011-11-28 
19:14:33 UTC ---
PR51279 may be related as the solnScatPot.ii testcase also ICEs the compiler in
apply_opt_in_copies, at loop-unroll.c:2283 on x86_64-apple-darwin11.

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2011-11-28 
19:16:25 UTC ---
Note, like PR51279, the testcases both ICE the compiler at -O1 -g
-funroll-loops but not at -O0 -g -funroll-loops on x86_64-apple-darwin11.

[Bug target/50906] e500 exception unwinding under "-Os" causes SIGSEGV

[Kyle.D.Moffett at boeing dot com]

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

--- Comment #18 from Kyle Moffett  2011-11-28 
19:30:07 UTC ---
I am happy to report that your updated 4.6.2 patch seems to be 100% functional
on e500/SPE.

I get identical "test-summary" reports for patched-4.6.2 with and without
BOOT_CFLAGS="-g -Os", apart from the different build directory paths (EG:
/srv/build/gcc-4.6-normal versus /srv/build/gcc-4.6-Os), 

As before, the following testsuite failures are fixed relative to unpatched
4.6.2:
-FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test
-FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test
-FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test
-FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test

And again, as before, the following 64-bit-only tests are erroneously run on
32-bit e500 CPUs, although they were inexplicably successful during a previous
build.
+FAIL: gcc.target/powerpc/ppc-fma-5.c execution test
+FAIL: gfortran.dg/pr47614.f  -O0 execution test
+FAIL: gfortran.dg/pr47614.f  -O1 execution test
+FAIL: gfortran.dg/pr47614.f  -O2 execution test
+FAIL: gfortran.dg/pr47614.f  -O3 -fomit-frame-pointer execution test
+FAIL: gfortran.dg/pr47614.f  -O3 -fomit-frame-pointer -funroll-loops
+FAIL: gfortran.dg/pr47614.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions execution test
+FAIL: gfortran.dg/pr47614.f  -O3 -g execution test
+FAIL: gfortran.dg/pr47614.f  -Os execution test

Thanks again for your help!

Cheers,
Kyle Moffett

[Bug middle-end/51323] g++ confuses this with function argument in optimized call

[dak at gnu dot org]

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

--- Comment #5 from David Kastrup  2011-11-28 19:33:26 UTC 
---
Question: the proposed fix is in gcc/calls.c which looks somewhat architecture
independent.  Am I right in assuming that this means that the bug may manifest
itself under architectures different from i686 given different conditions?

In that case, I would tend to just unconditionally do
-fno-optimize-sibling-calls in our autoconf checks for all respective gcc
versions independent from tests and architecture since I don't have the
hardware for other platforms in order to figure out compiler bugs, and since
the bug tends to hide its cause in the resulting segfault, as it occurs only
with tail jumps, meaning that the responsible function is not even visible in
the stack traceback.

[Bug driver/28718] Call to -lgcc added prior to user libraries

[j at uriah dot heep.sax.de]

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

--- Comment #11 from Joerg Wunsch  2011-11-28 
19:45:51 UTC ---
(In reply to comment #10)
> Jörg, could you prepare a list of functions that shall be excluded from 
> libgcc?
> You can also answer to my mail "PR28718 Infos?" from 2011-11-10.

Well, perhaps.  However, the AVR-part is not the main subject of my
complaint here.  The subject of my complaint was/is that a call to
*any* library is added *prior* to the list of user-supplied libaries
(from -l options).  The point of -l options is to give the users an
override option, which is completely defeated by the current way
libstdc++ is handled.

The fact that the AVR (currently) lacks a libstdc++, and thus libgcc
is linked instead, caused this bug to be escalated due to the side
effects, but this is not the main point here.

This becomes even more puzzling now: apparently, this reordering of
the libraries *only* applies to -lm.  When specifying any other
library, the processing works as one would expect it to be.

The code for this is in gcc/cp/g++spec.c, around line 270:

  /* Make sure -lstdc++ is before the math library, since libstdc++
 itself uses those math routines.  */
  if (!saw_math && (args[i] & MATHLIB) && library > 0)
{
  --j;
  saw_math = &decoded_options[i];
}

OK, now the reason is clear.  However, this doesn't handle the case
very well where no libstdc++ is available at all: inserting libgcc in
place of libstdc++ is just a simple workaround, and apparently a too
simple one in our case.  A correct implementation would not try to add
anything at all when libstdc++ is unavailable (and thus have no need
to reorder).

I don't know how many targets are affected at all by the lack of
libstdc++.  If AVR is indeed the only target where this applies to,
then the way you outlined (a configurable list of functions to omit
from libgcc) might be the best compromise.

(Sorry it took me so long to reply, Johan, but I knew it would take me
some time to research all this again, and then create the reply.)

[Bug c++/51289] [C++0x] Template template alias causes ICE

[dodji at seketeli dot org]

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

--- Comment #2 from dodji at seketeli dot org  
2011-11-28 20:12:38 UTC ---
A candidate patch for this was submitted to
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02488.html

[Bug rtl-optimization/51014] [4.7 Regression] ICE: in apply_opt_in_copies, at loop-unroll.c:2283 with -O2 -g -funroll-loops

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-11-28 
20:12:10 UTC ---
Created attachment 25939
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25939
gcc47-pr51014.patch

Untested fix.

[Bug middle-end/51323] g++ confuses this with function argument in optimized call

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-11-28 
20:38:59 UTC ---
That would be too big hammer approach.  While the fix is in arch independent
code, on most architectures you could hit it only with > 6 resp. > 8 arguments
and with similar scenario earlier callee argument stack slot initialized from
later caller's argument stack slot.  Furthermore I don't think you could hit it
before 4.6 because MEM_REF wasn't supported there, so the address would be
expanded without a temporary pseudo and the checking routine would see it right
away.
Using this testcase and perhaps a modified one additionally too which will have
in both the caller and tail callee say 16 extra dummy integer arguments passed
through should be more than enough.  Not to mention that having workarounds for
such compiler bugs in packages is just weird, if the compiler is buggy, the
user should just upgrade it to a fixed version.

[Bug c++/51336] [C++11] is_abstract and sfinae

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2011-11-28 20:49:52 UTC ---
(In reply to comment #0)
> #include 
> template
> struct A {
> template std::enable_if::value>::type>
> A(A const&){}
> };
> constexpr bool b = std::is_abstract>::value;

I *think* the compiler is right to reject this as it currently does, we have
*no* sfinae here. When you instantiate A, the declaration of the
template constructor is also instantiated, but at that point A is an
incomplete type.

IMO you need one further indirection, e.g.

template
struct A {
  template::value>::type
  >
  A(A const&){}
};

Btw.: Neither of these forms can ever prevent the "real" copy constructor to be
declared, defined, and used by the compiler.

> I am not sure what is supposed to happen (that's why I tried), but this result
> doesn't seem right. Filed under C++ because is_abstract directly forwards to
> the __is_abstract builtin, but feel free to reassign to libstdc++ if you think
> the problem is there somehow.

Lets look what the compiler-intrinsic people say, above is my first guess on
that.

[Bug tree-optimization/50682] [4.7 Regression] ICE: SIGSEGV in main_block_label with -O2 -fnon-call-exceptions -ftracer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2011-11-28 
21:02:33 UTC ---
Author: jakub
Date: Mon Nov 28 21:02:27 2011
New Revision: 181785

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181785
Log:
PR tree-optimization/50682
* tree-eh.c (maybe_remove_unreachable_handlers): New function.
* tree-flow.h (maybe_remove_unreachable_handlers): New prototype.
* tree-optimize.c (execute_cleanup_cfg_post_optimizing): Call it.

* g++.dg/opt/pr50682.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr50682.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-flow.h
trunk/gcc/tree-optimize.c

[Bug debug/50317] [4.7 Regression] missing DW_OP_GNU_implicit_pointer

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  2011-11-28 
21:04:49 UTC ---
Author: jakub
Date: Mon Nov 28 21:04:45 2011
New Revision: 181788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181788
Log:
PR debug/50317
* tree-ssa.c (execute_update_addresses_taken): Remove
var ={v} {CLOBBER} stmts instead of rewriting them into
var_N ={v} {CLOBBER}.

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

[Bug middle-end/50907] [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-11-28 
21:04:15 UTC ---
Author: jakub
Date: Mon Nov 28 21:04:10 2011
New Revision: 181787

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181787
Log:
PR middle-end/50907
* function.c (convert_jumps_to_returns): When redirecting an edge
succ to EXIT_BLOCK_PTR, clear EDGE_CROSSING flag.

* gcc.dg/tree-prof/pr50907.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-prof/pr50907.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/51335] [4.7 Regression] --enable-languages=c --disable-bootstrap doesn't work

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from H.J. Lu  2011-11-28 21:05:33 
UTC ---
Dup.

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

[Bug tree-optimization/50078] [4.6/4.7 Regression] combine wrong code: volatile accesses optimized out

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  2011-11-28 
21:03:16 UTC ---
Author: jakub
Date: Mon Nov 28 21:03:11 2011
New Revision: 181786

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181786
Log:
PR tree-optimization/50078
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Copy over
TREE_THIS_VOLATILE also from the old to new lhs resp. rhs.

* gcc.dg/pr50078.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr50078.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug bootstrap/51072] Build with --disable-bootstrap fails in libitm

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #8 from H.J. Lu  2011-11-28 21:05:33 
UTC ---
*** Bug 51335 has been marked as a duplicate of this bug. ***

[Bug fortran/51338] New: seg fault in gfc_dep_compare_expr with -O2

[dcb314 at hotmail dot com]

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

 Bug #: 51338
   Summary: seg fault in gfc_dep_compare_expr with -O2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com

[Bug target/51337] New: SH Target: Various testsuite ICEs for -m2a -O0

[oleg.e...@t-online.de]

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

 Bug #: 51337
   Summary: SH Target: Various testsuite ICEs for -m2a -O0
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh2a-*-*


There are various testsuite ICEs for -m2a -mb -O0, which look similar to the
following:

gcc.c-torture/compile/2923-1.c:

...: error: insn does not satisfy its constraints:
(insn 142 34 35 (set (mem/c:SI (plus:SI (reg/f:SI 14 r14)
(const_int 36 [0x24])) [0 %sfp+-16 S4 A32])
(reg:SI 150 fpul)) ... {movsi_ie}
 (nil))
...: internal compiler error: in extract_constrain_insn_cached, at recog.c:2052

The problem seems to be the movsi_ie insn, for which reload thinks it is
possible to load the FPUL register from a stack allocated reg using SImode
displacement addressing, which is actually not possible.

The following patch seems to help the issues...

--- gcc/config/sh/sh.c.orig2011-11-28 10:03:04.0 +0900
+++ gcc/config/sh/sh.c2011-11-28 15:09:01.0 +0900
@@ -12432,6 +12432,10 @@ sh_secondary_reload (bool in_p, rtx x, r
   if (rclass != GENERAL_REGS && REG_P (x)
   && TARGET_REGISTER_P (REGNO (x)))
 return GENERAL_REGS;
+  /* If here fall back to loading FPUL register through general regs. 
+ Happens when FPUL has to be loaded from a reg allocated on the stack.  */
+  if (rclass == FPUL_REGS && !REG_P (x))
+return GENERAL_REGS;
   return NO_REGS;
 }

However, I think the following should be a better way to check the condition in
question...

+  if (rclass == FPUL_REGS && true_regnum (x) == -1)
+return GENERAL_REGS;

I'll submit a patch once testing is completed.

[Bug tree-optimization/50078] [4.6 Regression] combine wrong code: volatile accesses optimized out

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.6/4.7 Regression]|[4.6 Regression] combine
   |combine wrong code: |wrong code: volatile
   |volatile accesses optimized |accesses optimized out
   |out |

--- Comment #12 from Jakub Jelinek  2011-11-28 
21:09:57 UTC ---
Fixed on the trunk so far.

[Bug tree-optimization/50682] [4.7 Regression] ICE: SIGSEGV in main_block_label with -O2 -fnon-call-exceptions -ftracer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jakub Jelinek  2011-11-28 
21:08:07 UTC ---
Fixed.

[Bug middle-end/50907] [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jakub Jelinek  2011-11-28 
21:08:42 UTC ---
Fixed.

[Bug fortran/51338] seg fault in gfc_dep_compare_expr with -O2

[dcb314 at hotmail dot com]

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

--- Comment #1 from dcb  2011-11-28 21:10:25 UTC ---
Created attachment 25940
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25940
preprocessed Fortran code

[Bug c++/51336] [C++11] is_abstract and sfinae

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse  2011-11-28 
21:17:30 UTC ---
(In reply to comment #1)
> IMO you need one further indirection, e.g.

Ah, yes, makes sense (although clang accepts both versions).

> Btw.: Neither of these forms can ever prevent the "real" copy constructor to 
> be
> declared, defined, and used by the compiler.

I was experimenting with it because I don't understand why this code (your
fixed version) is valid if that declaration has no effect... (well, it does
remove the implicit A(), but that doesn't count)

Maybe I should ask for a warning?

[Bug fortran/51338] seg fault in gfc_dep_compare_expr with -O2

[bdavis at gcc dot gnu.org]

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

Bud Davis  changed:

   What|Removed |Added

 CC||bdavis at gcc dot gnu.org

--- Comment #2 from Bud Davis  2011-11-28 21:40:40 
UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x081bc9af in gfc_dep_compare_expr (e1=0x0, e2=0x0) at
../../gcc/gcc/fortran/dependency.c:242
242{
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6_0.5.i686
(gdb) bt
#0  0x081bc9af in gfc_dep_compare_expr (e1=0x0, e2=0x0) at
../../gcc/gcc/fortran/dependency.c:242
#1  0x081bd105 in are_identical_variables (e1=0x905d440, e2=0x905c520) at
../../gcc/gcc/fortran/dependency.c:177
#2  gfc_dep_compare_expr (e1=0x905d440, e2=0x905c520) at
../../gcc/gcc/fortran/dependency.c:438
#3  0x081be244 in gfc_dep_compare_functions (e1=0x905d668, e2=0x905d2f0,
impure_ok=true)
at ../../gcc/gcc/fortran/dependency.c:221
#4  0x0823bf67 in cfe_expr_0 (e=0x905cdb8, walk_subtrees=0xbfffee3c, data=0x0)
at ../../gcc/gcc/fortran/frontend-passes.c:386
#5  0x0823bbd6 in gfc_expr_walker (e=0x905cdb8, exprfn=0x823bea0
, data=0x0)
at ../../gcc/gcc/fortran/frontend-passes.c:1039
#6  0x0823c72c in gfc_code_walker (c=0x905c4b8, codefn=0x823ae40
, 
exprfn=0x823bea0 , data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1361
#7  0x0823c70e in gfc_code_walker (c=0x905c670, codefn=0x823ae40
, 
exprfn=0x823bea0 , data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#8  0x0823c70e in gfc_code_walker (c=0x905c150, codefn=0x823ae40
, 
exprfn=0x823bea0 , data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#9  0x0823c70e in gfc_code_walker (c=0x9058620, codefn=0x823ae40
, 
exprfn=0x823bea0 , data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#10 0x0823c70e in gfc_code_walker (c=0x9057608, codefn=0x823ae40
, 
exprfn=0x823bea0 , data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#11 0x0823d25c in optimize_namespace (ns=0x9055320) at
../../gcc/gcc/fortran/frontend-passes.c:510
#12 0x0823d2ea in gfc_run_passes (ns=0x9055320) at
../../gcc/gcc/fortran/frontend-passes.c:80
#13 0x0818a4b9 in resolve_all_program_units () at
../../gcc/gcc/fortran/parse.c:4342
#14 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4608
#15 0x081c641d in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250
#16 0x085a97c5 in compile_file (argc=21, argv=0xb1f4) at
../../gcc/gcc/toplev.c:565

[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure

[vmakarov at redhat dot com]

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

--- Comment #4 from Vladimir Makarov  2011-11-28 
21:48:20 UTC ---

(In reply to comment #2)
> 
> Also, I have a question about the following fields of `ira_allocno':
>   /* The number of objects tracked in the following array.  */
>   int num_objects;
>   /* An array of structures describing conflict information and live
>  ranges for each object associated with the allocno.  There may be
>  more than one such object in cases where the allocno represents a
>  multi-word register.  */
>   ira_object_t objects[2];
> --^
> The SImode for AVR consists of 4 words, but only 2 objects in allocno
> structure.
> Is this right ?
> 
> 

Yes, that is right.  IRA objects were introduced by By Bernd Schmidt. 
Unfortunately, I did not review his patch.  Probably, Bernd decided that 2 hard
regs allocno covers most cases (and may be he is right).  Other multi regs
allocno is processed as one object (it means that all one register parts
conflict with all another one register parts even if in reality one part does
not conflict with another allocno part).

Wrong profitable hard regs calculation for register files requiring aligned
start register was a merging problem with a patch for allocation without cover
classes.

I'll try make a patch this week to solve the problem.

Dennis, thanks for detail analysis of the problem.  It saved my time.

[Bug middle-end/51339] New: [4.6/4.7 Regression] ICE: in convert_move, at expr.c:326 with -fopenmp and parallel for

[zsojka at seznam dot cz]

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

 Bug #: 51339
   Summary: [4.6/4.7 Regression] ICE: in convert_move, at
expr.c:326 with -fopenmp and parallel for
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 25941
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25941
reduced testcase (from libgomp.c/pr26943-4.c)

Compiler output:
$ gcc -fopenmp testcase.c 
testcase.c: In function 'foo._omp_fn.0':
testcase.c:7:9: internal compiler error: in convert_move, at expr.c:330
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r181770 - crash
4.6 r180325 - crash
4.5 r180325 - crash
4.4 r180325 - crash

[Bug fortran/51338] seg fault in gfc_dep_compare_expr with -O2

[bdavis at gcc dot gnu.org]

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

--- Comment #3 from Bud Davis  2011-11-28 21:59:02 
UTC ---
Reduced:

  SUBROUTINE PAXCUT(CHIN,CHOUT)
  CHARACTER*(*) CHIN,CHOUT
  IF(INDEX(CHOUT(K:),'.OR.').EQ.INDEX(CHOUT(K:),'.AND.')) THEN
  ENDIF
  END

[Bug libstdc++/41975] [C++0x] [DR579] unordered_set::erase performs worse when nearly empty

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|4.5.3   |4.7.0

--- Comment #34 from Paolo Carlini  2011-11-28 
22:10:00 UTC ---
Fixed for 4.7.0.

[Bug target/51340] New: SH Target: Make -mfused-madd enabled by default

[oleg.e...@t-online.de]

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

 Bug #: 51340
   Summary: SH Target: Make -mfused-madd enabled by default
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*


Currently the FMAC insn has to be enabled by specifying the -mfused-madd
option.  Is there any particular reason why this should not be enabled by
default for SH targets that support the FMAC insn?

[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-11-28
 CC||tkoenig at gcc dot gnu.org
Summary|seg fault in|[4.6/4.7 Regression] seg
   |gfc_dep_compare_expr with   |fault in
   |-O2 |gfc_dep_compare_expr with
   ||-O2
 Ever Confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  2011-11-28 
22:22:59 UTC ---
Workaround -fno-frontend-optimize.

Revision 164728 (20100929) is OK
revision 165415 (20101013) gives the segmentation fault.

Likely

Revision 165248

Author:tkoenig
Date:Sun Oct 10 09:52:46 2010 UTC (13 months, 2 weeks ago)
Changed paths:7
Log Message:
2010-10-09  Thomas Koenig  

* frontend-passes.c:  Include opts.h.
(optimize_comparison):  Renamed from optimize_equality.
Change second argument to operation to be compared.
Use flag_finite_math_only to avoid comparing REAL and
COMPLEX only when NANs are honored.  Simplify comparing
of string concatenations where left or right operands are
equal.  Simplify all comparison operations, based on the result
of gfc_dep_compare_expr.
* dependency.c:  Include arith.h.
(gfc_are_identical_variables):  Volatile variables should not
compare equal to themselves.
(gfc_dep_compare_expr):  Handle string constants and string
concatenations.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[oleg.e...@t-online.de]

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

--- Comment #8 from Oleg Endo  2011-11-28 22:31:44 UTC 
---
(In reply to comment #7)
> The problem is that SH target can't do those simple array accesses
> well at QI/HImode because of the lack of displacement addressing
> for those modes.

In these particular cases, this is true.  Even if there was a working QI/HImode
displacement addressing, it would most likely result in worse code compared to
post-inc / pre-dec addressing opportunities, because of register pressure on
R0.  Apart from that there is no displacement addressing for FPU loads/stores,
which also misses some opportunities:

float test_func_5 (float* p, int c)
{
  float r = 0;
  do
  {
r += *p++;
r += *p++;
r += *p++;
  } while (--c);
  return r;
}

Compiled with -Os -m4-single:

fldi0fr0
.L11:
movr4,r1
fmov.s@r1+,fr1
dtr5
faddfr1,fr0
fmov.s@r1,fr1
movr4,r1
add#8,r1
add#12,r4
faddfr1,fr0
fmov.s@r1,fr1
bf/s.L11
faddfr1,fr0
rts
nop


..could be:
fldi0fr0
.L11:
fmov.s@r4+,fr1
dtr5
faddfr1,fr0
fmov.s@r4+,fr1
faddfr1,fr0
fmov.s@r4+,fr1
bf/s.L11
faddfr1,fr0
rts
nop


Specifying -fno-tree-forwprop doesn't seem to have any effect on these cases.

[Bug c++/51341] New: make cannot detect head file change by dependency file with gcc 4.6.1 on ubuntu 11.10

[dx_zhou at hotmail dot com]

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

 Bug #: 51341
   Summary: make cannot detect head file change by dependency file
with gcc 4.6.1 on ubuntu 11.10
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dx_z...@hotmail.com


The issue is that make command cannot detect changes in head file. i.e, if I
touch "test.h", make command will not recompile. 

This works with gcc 4.5.4 on the same OS.

--test.h--
#include 
void hello()
{
std::cout << "Hello\n";
}

--test.cc--
#include "test.h"
int main()
{
hello();
}

--Makefile--
sources := test.cc
objects := test.o
depends := test.d
main := test

$(main) : % : %.o 
g++ $< -o $@

%.o : %.cc
g++ -c -MMD -MP -MF"$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" $< -o $@

clean :
-rm -rf $(objects) $(depends) $(main)

ifneq ($(MAKECMDGOALS),clean)
-include $(depends)
endif

[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2

[bdavis at gcc dot gnu.org]

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

--- Comment #5 from Bud Davis  2011-11-28 22:49:33 
UTC ---
Index: gcc/gcc/fortran/dependency.c
===
--- gcc/gcc/fortran/dependency.c(revision 181789)
+++ gcc/gcc/fortran/dependency.c(working copy)
@@ -245,6 +245,10 @@
   int i;
   gfc_expr *n1, *n2;

+  /* nothing to do here, move along */
+  if (e1 == NULL && e2 == NULL)
+ return 0;
+
   n1 = NULL;
   n2 = NULL;

[Bug preprocessor/51341] make cannot detect head file change by dependency file with gcc 4.6.1 on ubuntu 11.10

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |preprocessor

--- Comment #1 from Andrew Pinski  2011-11-28 
22:54:33 UTC ---
-MT changes the target to the .d rather than adding it to the .o one.

[Bug preprocessor/51341] make cannot detect head file change by dependency file with gcc 4.6.1 on ubuntu 11.10

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-11-28 
22:57:30 UTC ---
This was an expected change, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448 .  Which says you need
another -MT option to include the .o target.

[Bug target/51340] SH Target: Make -mfused-madd enabled by default

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  2011-11-28 
23:09:32 UTC ---
(In reply to comment #0)
> Is there any particular reason why this should not be enabled by
> default for SH targets that support the FMAC insn?

PR29100?

BTW, if SH fmac satisfies the semantics for fused multiplication and
add operation, the fmaf4 instruction pattern would be better now.

[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2

[bdavis at gcc dot gnu.org]

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

--- Comment #6 from Bud Davis  2011-11-28 23:20:27 
UTC ---
The above patch has no new testsuite regressions.
If someone wants to check and make sure the optimisation(s) that could or were
being done is still correct, and check this in, feel free to do so.

1 Hour 40 minutes after bug posted.  not bad.

--bud

[Bug other/50775] Register allocator sets up frame and frame pointer with low register pressure

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  2011-11-28 
23:26:18 UTC ---
(In reply to comment #4)

> Wrong profitable hard regs calculation for register files requiring aligned
> start register was a merging problem with a patch for allocation without cover
> classes.
> 
> I'll try make a patch this week to solve the problem.

Thanks you are taking care of this.  Will it also improve the situation for
3-byte types as introduced in PR50931? 3-byte types also start in even
registers.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[kkojima at gcc dot gnu.org]

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

--- Comment #9 from Kazumoto Kojima  2011-11-28 
23:29:57 UTC ---
(In reply to comment #8)
> Specifying -fno-tree-forwprop doesn't seem to have any effect on these cases.

For that function, -fdump-tree-all shows that the tree loop ivopts
optimization does it.  Try -fno-tree-forwprop -fno-ivopts.