[Bug bootstrap/53468] debian/ubuntu changed the location of libraries on the disk which broke bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53468
--- Comment #3 from Matthias Klose 2012-08-07
10:29:45 UTC ---
Comment on attachment 27825
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27825
multiarch-2012-07-08
>2012-06-25 Matthias Klose
>
> * doc/invoke.texi: Document -print-multiarch.
> * doc/install.texi: Document --enable-multiarch.
> * doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
> * configure.ac: Add --enable-multiarch option.
> * configure.in: Regenerate.
> * Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
> enable_multiarch, with_float: New macros.
> if_multiarch: New macro, define in terms of enable_multiarch.
> * genmultilib: Add new argument for the multiarch name.
> * gcc.c (multiarch_dir): Define.
> (for_each_path): Search for multiarch suffixes.
> (driver_handle_option): Handle multiarch option.
> (do_spec_1): Pass -imultiarch if defined.
> (main): Print multiarch.
> (set_multilib_dir): Separate multilib and multiarch names
> from multilib_select.
> (print_multilib_info): Ignore multiarch names in multilib_select.
> * incpath.c (add_standard_paths): Search the multiarch include dirs.
> * cppdeault.h (default_include): Document multiarch in multilib
> member.
> * cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
>include directory for multiarch directories.
> * common.opt: New options --print-multiarch and -imultilib.
> * config.gcc (tmake_file):
> Include i386/t-linux.
>(tmake_file):
> Include i386/t-kfreebsd.
>(tmake_file): Include i386/t-gnu.
> * config/i386/t-linux64: Add multiarch names in
> MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
> * config/i386/t-gnu: New file.
> * config/i386/t-kfreebsd: Likewise.
> * config/i386/t-linux: Likewise.
>
>
>Index: configure.ac
>===
>--- configure.ac (revision 188931)
>+++ configure.ac (working copy)
>@@ -623,6 +623,21 @@
> [], [enable_multilib=yes])
> AC_SUBST(enable_multilib)
>
>+# Determine whether or not multiarch is enabled.
>+AC_ARG_ENABLE(multiarch,
>+[AS_HELP_STRING([--enable-multiarch],
>+ [enable support for multiarch paths])],
>+[case "${withval}" in
>+yes|no|auto-detect) enable_multiarch=$withval;;
>+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
>+esac], [enable_multiarch=auto-detect])
>+AC_MSG_CHECKING(for multiarch configuration)
>+AC_SUBST(enable_multiarch)
>+AC_MSG_RESULT($enable_multiarch)
>+
>+# needed for setting the multiarch name on ARM
>+AC_SUBST(with_float)
>+
> # Enable __cxa_atexit for C++.
> AC_ARG_ENABLE(__cxa_atexit,
> [AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
>Index: cppdefault.c
>===
>--- cppdefault.c (revision 188931)
>+++ cppdefault.c (working copy)
>@@ -63,6 +63,7 @@
> #endif
> #ifdef LOCAL_INCLUDE_DIR
> /* /usr/local/include comes before the fixincluded header files. */
>+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
> { LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
> #endif
> #ifdef PREFIX_INCLUDE_DIR
>@@ -90,6 +91,7 @@
> #endif
> #ifdef NATIVE_SYSTEM_HEADER_DIR
> /* /usr/include comes dead last. */
>+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
> { NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
> #endif
> { 0, 0, 0, 0, 0, 0 }
>Index: cppdefault.h
>===
>--- cppdefault.h (revision 188931)
>+++ cppdefault.h (working copy)
>@@ -43,9 +43,11 @@
> C++. */
> const char add_sysroot; /* FNAME should be prefixed by
> cpp_SYSROOT. */
>- const char multilib;/* FNAME should have the multilib path
>- specified with -imultilib
>- appended. */
>+ const char multilib;/* FNAME should have appended
>+ - the multilib path specified with -imultilib
>+ when 1 is passed,
>+ - the multiarch path specified with
>+ -imultiarch, when 2 is passed. */
> };
>
> extern const struct default_include cpp_include_defaults[];
>Index: Makefile.in
>===
>--- Makefile.in(revision 188931)
>+++ Makefile.in(working copy)
>@@ -350,6 +350,17 @@
>
> enable_plugin = @enable_plugin@
>
>+# Multiarch support
>+enable_multiarch = @enable_multiarch@
>+with_float = @with_float@
>+ifeq ($(enable_multiarch),yes)
>+ if_multiarch = $(1)
>+else ifeq ($(enable_m
[Bug c++/54191] New: [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 Bug #: 54191 Summary: [C++11] SFINAE does not handle conversion to inaccessible base Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ai.az...@gmail.com The attached code includes some test cases for SFINAE on expressions necessitating conversion from (a pointer to) an object of a derived class to (a pointer to) an object of an inaccessible base class, or inverse of such conversion. All the static_asserts in the attached code should be well-formed according to the specification, but fail with GCC 4.8.0 20120805. I think this PR is closely related to PR51213.
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 --- Comment #1 from Ai Azuma 2012-08-07 11:19:03 UTC --- Created attachment 27955 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27955 Some test cases for SFINAE on conversion to inaccessible base
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 --- Comment #2 from Ai Azuma 2012-08-07 11:21:36 UTC --- Created attachment 27956 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27956 Output of -v option
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Richard Guenther changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #27 from Richard Guenther 2012-08-07 11:59:07 UTC --- Martin, can you look at comment #14 and the patch? I think what we want to do in flatten_function is before inline_call (e, true, NULL, NULL); reset the edge predicates so that inline_merge_summary becomes very cheap. Unfortunately that beast seems to have no early out (but instead uses true_predicate () ...). Can we speed it up for the case where we just want "fast" operation rather than precise accounting of sizes/time in the inlined-to caller?
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-07 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini 2012-08-07 12:22:58 UTC --- Ok, thanks. Interestingly, 4.7 (which doesn't have the 51213 changes) behaves exactly in the same way. Some of the tests actually produces access control diagnostics, some just fail the assertion, thus looks like simply we haven't been doing access control at all (-> I'm afraid fully implementing the correct behavior for access control under SFINAE may also require fixing long standing cases where we aren't doing access control with templates, issues beyond access control under SFINAE proper. But at least the cases where we actually produce the diagnostics now, should be easy to fix. I'm adding Jason in CC, I'd like to hear him about my more general considerations)
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 Severity|minor |normal --- Comment #4 from Paolo Carlini 2012-08-07 12:27:31 UTC --- Looking into this.
[Bug other/54182] -fPIE -pie shouldn't disable -fvisibility=hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54182 wbrana changed: What|Removed |Added Keywords|build | Summary|enable -fvisibility=hidden |-fPIE -pie shouldn't |with -fPIE -pie |disable -fvisibility=hidden --- Comment #5 from wbrana 2012-08-07 12:34:36 UTC --- updated
[Bug c/54192] New: -fno-trapping-math by default?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 Bug #: 54192 Summary: -fno-trapping-math by default? Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: gli...@gcc.gnu.org Hello, I am not sure about the "component" (I am actually more interested in the C++ behavior, but I assume C and C++ will remain the same), or about posting this to bugzilla instead of the mailing-list. I would like to know people's opinion about making -fno-trapping-math the default. One strong argument in favor is that -fno-rounding-math is the default. The 2 options are quite similar. They both affect "special" use of maths, they both inhibit a number of optimizations, and they both have bugs (not trying to offend anyone here, it is already great that the options are as far as they are). As someone who needs -frounding-math and for whom -fno-trapping-math is safe and helps performance, you can see why I'd like to change it ;-)
[Bug c/54192] -fno-trapping-math by default?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 --- Comment #1 from Richard Guenther 2012-08-07 12:50:16 UTC --- The current reasoning is that the C standard allows the implementation to say that only round-to-nearest is supported but not that the trapping parts of IEEE are not honored. The default should always be standard conformant behavior.
[Bug c/54192] -fno-trapping-math by default?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 --- Comment #2 from Marc Glisse 2012-08-07 13:13:46 UTC --- Don't you need to tell the compiler (with the FENV_ACCESS pragma) that you are going to look at flags, just like you tell it that you are going to use non-default rounding modes? "In general, if the state of FENV_ACCESS is ‘‘off’’, the translator can assume that default modes are in effect and the flags are not tested." The compiler would also need to #undef FE_DOWNWARD in fenv.h if it wants to pretend that it only supports round-to-nearest (there is an "if and only if" in the standard). I think I see what you mean: if there is only one rounding-mode, then the pragma has no effect on rounding so you can pretend that it is on. But then the same applies to trapping, since the standard explicitly allows for FE_ALL_EXCEPT==0.
[Bug middle-end/54193] New: dump_gimple_assign raw can't handle 4 operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193
Bug #: 54193
Summary: dump_gimple_assign raw can't handle 4 operands
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
#include
__m128d
f (__m128d x)
{
__m128i m = {0, 1};
return __builtin_shuffle (x, m);
}
$ gcc sh.c -c -fdump-tree-optimized-raw
sh.c: In function 'f':
sh.c:4:1: internal compiler error: in dump_gimple_assign, at
gimple-pretty-print.c:485
f (__m128d x)
^
Please submit a full bug report,
which is fairly natural with code like:
if (gimple_num_ops (gs) == 2)
last = NULL_TREE;
else if (gimple_num_ops (gs) == 3)
last = gimple_assign_rhs2 (gs);
else
gcc_unreachable ();
(the non-raw version below goes up to 4)
I guess the -raw option doesn't see much use these days. I was trying it
because sometimes it isn't obvious what tree code is meant by the C-like
representation.
[Bug c++/54191] [C++11] SFINAE does not handle conversion to inaccessible base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54191 --- Comment #5 from Paolo Carlini 2012-08-07 14:36:19 UTC --- For the cases where we are producing inaccessible base diagnostics in SFINAE context, the issue is that lookup_base is called by functions getting a complain argument always in the same way irrespective of complain. Not sure at the moment if simply changing the callers to pass what they are currently passing | ba_quiet whenever !(complain & tf_error) is enough or there are subtleties.
[Bug middle-end/54193] dump_gimple_assign raw can't handle 4 operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54193 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-07 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-08-07 15:12:54 UTC --- Confirmed (patches welcome ;))
[Bug c++/54194] New: GCC 4.8 gives misleading suggestion about arithmetic in operand of '|'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194
Bug #: 54194
Summary: GCC 4.8 gives misleading suggestion about arithmetic
in operand of '|'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: csaba...@yahoo.co.uk
Using gcc version 4.8.0 20120806 (experimental) (GCC),
Target: x86_64-unknown-linux-gnu
to compile the following code:
int main()
{
char in[4]={0}, out[6];
out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2);
}
results in a misleading warning (misplaced caret):
$ g++-48 -c -Wall -Werror w.cc
w.cc: In function 'int main()':
w.cc:4:45: error: suggest parentheses around arithmetic in operand of '|'
[-Werror=parentheses]
out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2);
^
The problematic operand is the left operand of '|', but the caret appears to be
pointing at the right operand.
For example, clang version 3.2 (trunk 161319) gives
$ clang++ -c -Wall -Werror w.cc
w.cc:4:16: error: '&' within '|' [-Werror,-Wbitwise-op-parentheses]
out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2);
~~^~ ~
w.cc:4:16: note: place parentheses around the '&' expression to silence this
warning
out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2);
^
( )
[Bug c++/54194] GCC 4.8 gives misleading suggestion about arithmetic in operand of '|'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-07 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-08-07 15:34:53 UTC --- Confirmed. Manu, is there anything that can be done without huge changes?
[Bug fortran/54195] New: [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 Bug #: 54195 Summary: [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface" Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: dam...@rouson.net, ja...@gcc.gnu.org Reported by Damian at http://gcc.gnu.org/ml/fortran/2012-08/msg00041.html The following program fails with: generic :: operator(-) => unary 1 Error: Entity 'unary' at (1) is already present in the interface It works if one replaces "IMPORT :: foo" by "IMPORT". module import_clashes_with_generic type ,abstract :: foo contains procedure :: unary generic :: operator(-) => unary end type abstract interface integer function bar() import :: foo end function end interface contains integer function unary(rhs) class(foo) ,intent(in) :: rhs end function end module
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-07 Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-08-07 16:44:48 UTC --- First guess: http://gcc.gnu.org/viewcvs?view=revision&revision=189022
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #2 from Tobias Burnus 2012-08-07 16:47:10 UTC --- It works with the snapshot GCC 4.8.0 20120624 and fails with the one from 20120701. The changelog lists only one entry in that period, namely: Author: janus Date: Wed Jun 27 17:38:00 2012 New Revision: 189022 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189022 Log: 2012-06-27 Janus Weil PR fortran/41951 PR fortran/49591 * interface.c (check_new_interface): Rename, add 'loc' argument, make non-static. (gfc_add_interface): Rename 'check_new_interface' * gfortran.h (gfc_check_new_interface): Add prototype. * resolve.c (resolve_typebound_intrinsic_op): Add typebound operator targets to non-typebound operator list.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #3 from janus at gcc dot gnu.org 2012-08-07 18:12:07 UTC --- (In reply to comment #2) > The changelog lists only one entry in that period, namely: > > Author: janus > Date: Wed Jun 27 17:38:00 2012 > New Revision: 189022 Yeah, I knew it ;) I just verified that reverting the resolve.c part of this commit makes the error go away.
[Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135 --- Comment #8 from Alexandre Oliva 2012-08-07 18:47:16 UTC --- For those running into the problem, analternative to patching GCC isto reduce the maximum expression depth for var-traking with --param max-vartrack-expr-depth=11
[Bug c++/54196] New: gcc doesn't find incompatible exception specification for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196
Bug #: 54196
Summary: gcc doesn't find incompatible exception specification
for operator
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mib.bugzi...@gmail.com
It look like g++ emit error for regular functions but not for new. Here is the
example:
For following test case g++ emit error for foo but not for operator new.
class bad_alloc
{
public:
bad_alloc() throw() { }
};
struct nothrow_t { };
extern const nothrow_t nothrow;
typedef unsigned long size_t;
//void* operator new(size_t) noexcept;
void* operator new(size_t, const nothrow_t&);
void foo();
int main(int argc, char *argv[])
{
void* (*pf)(size_t) throw (bad_alloc) = operator new;
void* (*pf1)() throw (bad_alloc) = foo;
}
[Bug c++/54197] New: [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197
Bug #: 54197
Summary: [4.7/4.8 regression] Lifetime of reference not
properly extended
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
We've noticed this with 4.7 branch, confirmed present in current trunk (rev.
190209).
When calling a static member function returning an object (string below)
through an unnamed function pointer, and binding the result to a reference, the
lifetime of the returned temporary is not properly extended.
--- cut ---
#include
#include
#include
struct string {
string(const char *s) {
s_ = strdup(s);
}
~string() {
memset((void*)s_, 'a', strlen(s_));
}
string(const string& rhs) {
s_ = strdup(rhs.s_);
}
string& operator=(const string& rhs) {
if (&rhs != this) {
free((void*)s_);
s_ = strdup(rhs.s_);
}
return *this;
}
const char *c_str() const { return s_; }
const char *s_;
};
struct Foo {
static string foo() { return "abcd"; }
};
Foo foo_g;
struct scoped_ptr {
Foo* operator->() const { return &foo_g; }
Foo* get() const { return &foo_g; }
};
Foo *get() { return &foo_g; }
int main()
{
scoped_ptr f;
const string& ref1 = f->foo(); // BAD
const string& ref2 = f.get()->foo(); // BAD
const string& ref3 = get()->foo(); // BAD
const string& ref4 = Foo::foo(); // OK
Foo *pf = f.get();
const string& ref5 = pf->foo(); // OK
printf("ref1: %p (%s)\n", ref1.c_str(), ref1.c_str());
printf("ref2: %p (%s)\n", ref2.c_str(), ref2.c_str());
printf("ref3: %p (%s)\n", ref3.c_str(), ref3.c_str());
printf("ref4: %p (%s)\n", ref4.c_str(), ref4.c_str());
printf("ref5: %p (%s)\n", ref5.c_str(), ref5.c_str());
}
--- cut ---
Result from gcc-4.6:
ref1: 0x5a8030 (abcd)
ref2: 0x5a8070 (abcd)
ref3: 0x5a80b0 (abcd)
ref4: 0x5a80d0 (abcd)
ref5: 0x5a80f0 (abcd)
Result from gcc-4.7 / 4.8
ref1: 0xe18010 () << BUG
ref2: 0xe18030 () << BUG
ref3: 0xe18050 () << BUG
ref4: 0xe18070 (abcd)
ref5: 0xe18090 (abcd)
Changing Foo::foo to be non-static (and commenting out ref4), the bug
disappears:
ref1: 0x1eb3010 (abcd)
ref2: 0x1eb3030 (abcd)
ref3: 0x1eb3050 (abcd)
ref5: 0x1eb3070 (abcd)
Google ref: b/6946758
[Bug c++/54196] gcc doesn't find incompatible exception specification for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196 --- Comment #1 from mib.bugzilla at gmail dot com 2012-08-07 18:57:28 UTC --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/site/spt/rdrive/ref/gcc/4.7.0/efi2/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/myuser/d/gcc_src/gcc-4.7.0/configure --prefix=/rdrive/ref/gcc/4.7.0/efi2 --enable-languages=c,c++,objc,fortran --disable-multilib --enable-bootstrap --target=x86_64-unknown-linux-gnu --disable-bootstrap --enable-decimal-float --with-gmp=/home/myuser/d/gcc_src/lib/efi2 --with-mpfr=/home/myuser/d/gcc_src/lib/efi2 --with-mpc=/home/myuser/d/gcc_src/lib/efi2 Thread model: posix gcc version 4.7.0 (GCC) g++ -c fubar.cpp fubar.cpp: In function âint main(int, char**)â: fubar.cpp:16:40: error: invalid conversion from âvoid (*)()â to âvoid* (*)()â [-fpermissive]
[Bug c++/54194] GCC 4.8 gives misleading suggestion about arithmetic in operand of '|'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54194 --- Comment #2 from Manuel López-Ibáñez 2012-08-07 19:35:45 UTC --- Use warning_at and pass down the correct location of the operator if possible, otherwise input_location? Of course, it would be nice to have ranges but I have given up on that.
[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54197 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-07 CC||jason at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2012-08-07 19:55:37 UTC --- It is caused by revision 180944: http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00230.html
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #28 from Steven Bosscher 2012-08-07
19:58:00 UTC ---
To illustrate the rewrite_into_closed_loop_ssa problem, consider this test
case:
extern void use1 (int);
extern void use2 (int);
extern int confuse_loop (void);
void
foo (void)
{
int i, j, k;
for (i = 0; i < 100; i++)
{
for (j = 0; j < 100; j++)
{
k = i + j;
if (j > 2)
use1 (k);
if (confuse_loop ())
break;
}
use2 (k);
}
}
The only PHI needed for loop-closed SSA is one for k before "use2(k)".
One problem is that GCC ends up inserting two PHI nodes (one on the exit after
confuse_loop(), which is wasteful if the exit block is empty. So problem 1 is
that too many PHIs are inserted.
The second problem is that with multiple loop exits, a large part of the CFG is
walked in compute_global_livein. The CFG for the test case (compiled with
-fno-tree-ch) looks like this:
+---< 14 --<-+
E / \ E
N /\ X
T -> 2 - 9 --> 3 --> 4 --> 5 -> 11 --> 7 -> 8 -> I
R / \ / \ / T
Y / +-> 10 -+ +-> 6 -> 13 ->--+
\ /
+<-- 12 --<---+
And the following blocks are visited (with a patch I will attach in a minute --
without the patch even more blocks are visited). Block 3 is the block
containing the def, so the CFG walk ends there.
XXX visiting block 7
XXX visiting block 13
XXX visiting block 6
XXX visiting block 5
XXX visiting block 4
XXX visiting block 10
XXX visiting block 11
;; Created LCSSA PHI: k_4 = PHI
;; Created LCSSA PHI: k_8 = PHI
;; Resulting GIMPLE function IR:
foo ()
{
int k;
int j;
int i;
int D.1727;
:
goto ;
:
:
# j_29 = PHI
k_14 = i_28 + j_29;
if (j_29 > 2)
goto ;
else
goto ;
:
goto ;
:
use1 (k_14);
:
D.1727_17 = confuse_loop ();
if (D.1727_17 != 0)
goto ;
else
goto ;
:
# k_4 = PHI
goto ;
:
j_18 = j_29 + 1;
if (j_18 <= 99)
goto ;
else
goto ;
:
# k_8 = PHI
:
# k_21 = PHI
use2 (k_21);
i_20 = i_28 + 1;
if (i_20 <= 99)
goto ;
else
goto ;
:
return;
:
:
# i_28 = PHI
goto ;
}
[Bug debug/54177] [4.8 Regression]: Segfault in cselib_lookup due to NULL_RTX passed from vt_add_function_parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54177 --- Comment #3 from Alexandre Oliva 2012-08-07 20:08:27 UTC --- Having reviewed teh other uses of var_lowpart, I hereby approve the patch if it passes regstrap. Thanks!
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195
--- Comment #4 from janus at gcc dot gnu.org 2012-08-07 20:23:26 UTC ---
My first attempt to fix it would be something like this:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 190186)
+++ gcc/fortran/resolve.c (working copy)
@@ -11448,7 +11448,7 @@
/* Add target to non-typebound operator list. */
if (!target->specific->deferred && !derived->attr.use_assoc
- && p->access != ACCESS_PRIVATE)
+ && !derived->attr.imported && p->access != ACCESS_PRIVATE)
{
gfc_interface *head, *intr;
if (gfc_check_new_interface (derived->ns->op[op], target_proc,
This indeed makes the error in comment #0 go away, and does not seem to
introduce any regressions in the typebound_* test cases.
However: Witout the patch, the code guarded by the IF statement above is called
twice (which leads to the error). But with the patch, it is not called at all
any more (while it should be called once!). So the patch can not be fully
correct.
What I do not understand is: The symbol 'foo' exists in the module namespace,
as well as in the namespace of 'bar'. But in both it has the 'imported'
attribute, which sounds wrong to me (or at least contra-intuitive).
[Bug middle-end/54114] [4.8 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 --- Comment #4 from Alexandre Oliva 2012-08-07 20:28:05 UTC --- It seems quite clear to me that the new cost arises due to clobber_overlapping_mems, a relatively expensive operation that fixes a debug info correctness bug and that we just didn't do before. I'm afraid I can't think of a way to do it in a way that is significantly more efficient, so we'll have to choose between this additional cost, or living with debug locations that are no longer valid due to overlapping stores :-( I'm tempted to mark this as WONTFIX, but I thought I'd leave this open for a bit in case anyone else wants to give it a try.
[Bug libstdc++/53579] libstdc++ configure atomicity tests use CXXFLAGS instead of CXXFLAGS_FOR_TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53579 Benjamin Kosnik changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #1 from Benjamin Kosnik 2012-08-07 20:53:26 UTC --- Some notes. src/Makefile.am does not export CXXFLAGS_FOR_TARGET, only CFLAGS_FOR_TARGET. The problem is that configure CXXFLAGS ends up being different than build CXXFLAGS. And configure flags don't play with CXXFLAGS_FOR_TARGET (but build flags do.) gcc/Makefile.in has the pass down for target libs: EXTRA_TARGET_FLAGS = \ 'AR=$$(AR_FOR_TARGET)' \ 'AS=$(COMPILER_AS_FOR_TARGET)' \ 'CC=$$(CC_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ 'CFLAGS=$$(CFLAGS_FOR_TARGET)' \ 'CXX=$$(CXX_FOR_TARGET) $$(XGCC_FLAGS_FOR_TARGET) $$(TFLAGS)' \ 'CXXFLAGS=$$(CXXFLAGS_FOR_TARGET)' \ This is what is expected and needed for build, but for configure the situation is not working in an equivalent manner. config/mt-gnu: CXXFLAGS_FOR_TARGET = $(CXXFLAGS) -D_GNU_SOURCE configure.ac: if test "x$CXXFLAGS_FOR_TARGET" = x; then CXXFLAGS_FOR_TARGET=$CXXFLAGS case " $CXXFLAGS " in *" -O2 "*) ;; *) CXXFLAGS_FOR_TARGET="-O2 $CXXFLAGS_FOR_TARGET" ;; esac case " $CXXFLAGS " in *" -g "* | *" -g3 "*) ;; *) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS_FOR_TARGET" ;; esac fi AC_SUBST(CXXFLAGS_FOR_TARGET) ie, CXXFLAGS_FOR_TARGET is what should be used, not CXXFLAGS There are a lot of C++ configure tests in libstdc++ (and other target libs!) that use CXXFLAGS assuming it's the real thing used to build the library. Not just atomicity. A consistent solution would be nice here. Possible solutions: 1) Setup GLIBCXX_CONFIGURE to export GLIBCXX_CXXFLAGS, which is then used consistently during configure only, and incorporates CXXFLAGS_FOR_TARGET. (Makefiles still use CXXFLAGS). 2) use CFLAGS_FOR_TARGET in libstdc++ config 3) like one, but have something like CXXFLAGS_EXTRA_FOR_TARGET which (unlike CXXFLAGS_FOR_TARGET) is not supposed to replace CXXFLAGS, but instead is always added to CXXFLAGS, not substituted for it.
[Bug c++/54196] gcc doesn't find incompatible exception specification for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54196 --- Comment #2 from Jonathan Wakely 2012-08-07 20:55:36 UTC --- N.B. there are various overloads of operator new that are implicitly declared in every translation unit, including (in C++03) void* operator new(std::size_t) throw(std::bad_alloc) which would be ok except for the std:: qualification
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #5 from janus at gcc dot gnu.org 2012-08-07 20:57:47 UTC ---
Second attempt:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 190186)
+++ gcc/fortran/resolve.c(working copy)
@@ -11448,7 +11448,7 @@ resolve_typebound_intrinsic_op (gfc_symbol* derive
/* Add target to non-typebound operator list. */
if (!target->specific->deferred && !derived->attr.use_assoc
- && p->access != ACCESS_PRIVATE)
+ && p->access != ACCESS_PRIVATE && derived->ns == gfc_current_ns)
{
gfc_interface *head, *intr;
if (gfc_check_new_interface (derived->ns->op[op], target_proc,
As the first attempt, it fixes the error in comment 0 and survives the
typebound_* test cases, but it also results in the code in question being
called exactly once for the test case in comment 0.
Will start a full regtest now ...
[Bug debug/54177] [4.8 Regression]: Segfault in cselib_lookup due to NULL_RTX passed from vt_add_function_parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54177 --- Comment #4 from Uros Bizjak 2012-08-07 21:07:53 UTC --- Author: uros Date: Tue Aug 7 20:57:56 2012 New Revision: 190212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190212 Log: * var-tracking.c (var_lowpart): Exit early for matched modes. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug debug/54177] [4.8 Regression]: Segfault in cselib_lookup due to NULL_RTX passed from vt_add_function_parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54177 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-08/msg00387.htm ||l Resolution||FIXED --- Comment #5 from Uros Bizjak 2012-08-07 21:09:07 UTC --- Fixed.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #6 from janus at gcc dot gnu.org 2012-08-07 21:21:23 UTC --- (In reply to comment #4) > However: Witout the patch, the code guarded by the IF statement above is > called > twice (which leads to the error). But with the patch, it is not called at all > any more (while it should be called once!). So the patch can not be fully > correct. > > What I do not understand is: The symbol 'foo' exists in the module namespace, > as well as in the namespace of 'bar'. But in both it has the 'imported' > attribute, which sounds wrong to me (or at least contra-intuitive). As I just learned from Tobias, this problem is probably related to PR53537.
[Bug fortran/54195] [4.8 Regression][OOP] IMPORT fails with GENERIC TBP: "is already present in the interface"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54195 --- Comment #7 from janus at gcc dot gnu.org 2012-08-07 22:05:49 UTC --- (In reply to comment #5) > Will start a full regtest now ... Completed successfully.
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #29 from Steven Bosscher 2012-08-07 22:28:11 UTC --- Created attachment 27957 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27957 Do not traverse sibling loops The idea here is to note that for a nested loop we know for sure that the loop exits into a common loop father must all need PHI nodes, because we have have loop pre-headers. I'm not sure what the effect of this is on irreducible loops, and I haven't tested this much yet. Comments sought...
[Bug c++/53661] [gcc-4.7/4.8 regression] Wrong narrowing conversion warning with -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53661 Sriraman Tallam changed: What|Removed |Added Component|c |c++ Summary|Wrong narrowing conversion |[gcc-4.7/4.8 regression] |warning with -std=c++11 |Wrong narrowing conversion ||warning with -std=c++11 --- Comment #1 from Sriraman Tallam 2012-08-07 22:33:58 UTC --- Tip of trunk still fails.
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #30 from Steven Bosscher 2012-08-07 22:36:30 UTC --- > Created attachment 27957 [details] With the attachment, time spent in rewrite_into_loop_closed_ssa is almost 0 (and that includes the time in the verifier). Compile time for the test case (still with only "check();") is now 924s wall time. Top spenders: integrated RA : 224.26 (24%) tree SSA incremental: 75.07 ( 8%) df live&initialized regs: 69.58 ( 8%) df live regs: 66.19 ( 7%) remove unused locals: 53.43 ( 6%) out of ssa : 51.93 ( 6%)
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #1 from Benjamin Kosnik 2012-08-07 23:04:05 UTC --- Author: bkoz Date: Tue Aug 7 23:03:55 2012 New Revision: 190216 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190216 Log: 2012-08-07 Benjamin Kosnik PR libstdc++/54005 * include/std/atomic: Use __atomic_always_lock_free. * include/bits/atomic_base.h: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h trunk/libstdc++-v3/include/std/atomic
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #31 from Steven Bosscher 2012-08-08 06:28:16 UTC --- Author: steven Date: Wed Aug 8 06:28:10 2012 New Revision: 190222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190222 Log: PR middle-end/54146 * ifcvt.c: Include pointer-set.h. (cond_move_process_if_block): Change type of then_regs and else_regs from alloca'd array to pointer_sets. (check_cond_move_block): Update for this change. (cond_move_convert_if_block): Likewise. * Makefile.in: Fix dependencies for ifcvt.o. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ifcvt.c
[Bug tree-optimization/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #31 from Steven Bosscher 2012-08-08 06:28:16 UTC --- Author: steven Date: Wed Aug 8 06:28:10 2012 New Revision: 190222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190222 Log: PR middle-end/54146 * ifcvt.c: Include pointer-set.h. (cond_move_process_if_block): Change type of then_regs and else_regs from alloca'd array to pointer_sets. (check_cond_move_block): Update for this change. (cond_move_convert_if_block): Likewise. * Makefile.in: Fix dependencies for ifcvt.o. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ifcvt.c --- Comment #32 from Steven Bosscher 2012-08-08 06:29:16 UTC --- Author: steven Date: Wed Aug 8 06:29:12 2012 New Revision: 190223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190223 Log: PR middle-end/54146 * ira.c (init_live_subregs): Take live_subregs_used as a bitmap. (build_insn_chain): Make live_subregs_used a bitmap. Use SBITMAP_SIZE to ignore the paradoxical bytes of subregs. Use sbitmap_free to free the live_subreg sbitmaps. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #31 from Steven Bosscher 2012-08-08 06:28:16 UTC --- Author: steven Date: Wed Aug 8 06:28:10 2012 New Revision: 190222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190222 Log: PR middle-end/54146 * ifcvt.c: Include pointer-set.h. (cond_move_process_if_block): Change type of then_regs and else_regs from alloca'd array to pointer_sets. (check_cond_move_block): Update for this change. (cond_move_convert_if_block): Likewise. * Makefile.in: Fix dependencies for ifcvt.o. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ifcvt.c --- Comment #32 from Steven Bosscher 2012-08-08 06:29:16 UTC --- Author: steven Date: Wed Aug 8 06:29:12 2012 New Revision: 190223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190223 Log: PR middle-end/54146 * ira.c (init_live_subregs): Take live_subregs_used as a bitmap. (build_insn_chain): Make live_subregs_used a bitmap. Use SBITMAP_SIZE to ignore the paradoxical bytes of subregs. Use sbitmap_free to free the live_subreg sbitmaps. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug middle-end/54146] Very slow compile with attribute((flatten))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #32 from Steven Bosscher 2012-08-08 06:29:16 UTC --- Author: steven Date: Wed Aug 8 06:29:12 2012 New Revision: 190223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190223 Log: PR middle-end/54146 * ira.c (init_live_subregs): Take live_subregs_used as a bitmap. (build_insn_chain): Make live_subregs_used a bitmap. Use SBITMAP_SIZE to ignore the paradoxical bytes of subregs. Use sbitmap_free to free the live_subreg sbitmaps. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
