[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 Alexey Pavlov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Alexey Pavlov 2012-11-21 08:02:29 UTC --- Fixed in mingw-w64 trunk
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 Gilles Pion changed: What|Removed |Added CC||gilles.pion at gmail dot ||com --- Comment #24 from Gilles Pion 2012-11-21 08:02:41 UTC --- I have the exact same problem on AIX 5.3 trying to bootstrat GCC but with version 4.7.2. in my case I have to admit that I don't understand all the issues described here but since I've been able to bootstrap 7.2.1 without any problem I'm a bit surprised.
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 --- Comment #2 from niXman 2012-11-21 08:09:40 UTC --- (In reply to comment #1) > Fixed in mingw-w64 trunk Strange that the mingw-w64 developers didn't report that the bug is fixed.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #19 from Jakub Jelinek 2012-11-21 08:40:52 UTC --- (In reply to comment #18) > For actual ThreadSanitizer runtime -fPIC -ftls-model=initial-exec causes > degradation of generated code. Linker emits the same tls access code in all > cases, but the compiler generates worse code. -fPIC -ftls-model=initial-exec is by definition almost equivalent to -fPIE, the only exceptions are: 1) -fPIE code is allowed to assume globally visible symbols aren't interposed 2) if TLS vars are defined locally (or hidden visibility), then local-exec model can be used instead of initial-exec (one less dereference) As for 2), I've explained already that by linking -fPIC code into the executable if the TLS var is defined in the executable, linker TLS transition transform all other TLS models (even global and local dynamic) into local-exec, just might result in some nops or for IE->LE setting of a register to an immediate and using that register as opposed to just using the immediate in the %fs: prefixed insn. And for 1), for the fast path, for any symbols on the fast path that shouldn't be interposeable and that are defined in libtsan, you should be able to just use visibility attributes and get the same effect. -fPIE flag simply isn't usable for a library that is to be used also by shared libraries. How do you link -fsanitize=thread shared libraries anyway? Just don't link libtsan in for -static-libtsan, and rely on the executable being linked against it? Such libraries will fail to link with -Wl,-z,defs ... Of course, having multiple tsan TLS roots in the same process isn't a good idea either (which is why I think we can't default to -static-libtsan).
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #20 from Dmitry Vyukov 2012-11-21 09:04:07 UTC --- (In reply to comment #19) > (In reply to comment #18) > > For actual ThreadSanitizer runtime -fPIC -ftls-model=initial-exec causes > > degradation of generated code. Linker emits the same tls access code in all > > cases, but the compiler generates worse code. > > -fPIC -ftls-model=initial-exec is by definition almost equivalent to -fPIE, > the > only exceptions are: > 1) -fPIE code is allowed to assume globally visible symbols aren't interposed > 2) if TLS vars are defined locally (or hidden visibility), then local-exec >model can be used instead of initial-exec (one less dereference) What I see is that it also affect code generation (register allocation). Do we need to file a bug on that? > As for 2), I've explained already that by linking -fPIC code into the > executable if the TLS var is defined in the executable, linker TLS transition > transform all other TLS models (even global and local dynamic) into > local-exec, > just might result in some nops or for IE->LE setting of a register to an > immediate and using that register as opposed to just using the immediate in > the > %fs: prefixed insn. > > And for 1), for the fast path, for any symbols on the fast path that shouldn't > be interposeable and that are defined in libtsan, you should be able to just > use visibility attributes and get the same effect. > > -fPIE flag simply isn't usable for a library that is to be used also by shared > libraries. How do you link -fsanitize=thread shared libraries anyway? Just > don't link libtsan in for -static-libtsan, and rely on the executable being > linked against it? Yes, we rely on the library being linked into the executable, because we want the runtime be linked statically. For dynamic libraries that are loaded into a non-instrumented executable (e.g. swig so preloaded into python process), we statically link the tsan runtime into the so. > Such libraries will fail to link with -Wl,-z,defs ... > Of course, having multiple tsan TLS roots in the same process isn't a good > idea > either (which is why I think we can't default to -static-libtsan).
[Bug tree-optimization/55424] New: [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning line 23 on ARM/Cortex-M0/-Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55424
Bug #: 55424
Summary: [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning
line 23 on ARM/Cortex-M0/-Os
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
The test case require optimization level "-O2" and it passes on ARM/cortex-m0
with "-O2", but the failure with "-Os" does reveal potential bug in
tree-ssa-uninit.c
Test command line:
arm-none-eabi-gcc ./uninit-pred-8_b.c -fno-diagnostics-show-caret
-Wuninitialized -fno-tree-dominator-opts -S-mthumb -mcpu=cortex-m0 -Os -o
uninit-pred-8_b.s
The warning info:
.../trunk-orig/gcc/gcc/testsuite/gcc.dg/uninit-pred-8_b.c: In function 'foo':
.../trunk-orig/gcc/gcc/testsuite/gcc.dg/uninit-pred-8_b.c:23:11: warning: 'v'
may be used uninitialized in this function [-Wmaybe-uninitialized]
.../trunk-orig/gcc/gcc/testsuite/gcc.dg/uninit-pred-8_b.c: In function 'foo_2':
.../trunk-orig/gcc/gcc/testsuite/gcc.dg/uninit-pred-8_b.c:42:11: warning: 'v'
may be used uninitialized in this function [-Wmaybe-uninitialized]
This failure occurs after checking in r193687. The patch prefers to generate
branches on ARM/cortex-m0.
After investigating tree dump of tree-ssa-uninit.c, I think:
tree-ssa-uninit.c computes control dependent chain for uses/def of variable and
checks whether each use is guarded by def. It has a upper bound on the number
of control dependent chains(MAX_NUM_CHAINS==8) and just retreat to false
warning if the number of chains exceeds MAX_NUM_CHAINS. In our scenario, the
number of chains exceeds MAX_NUM_CHAINS because we prefer short circuit now,
resulting in false warning information. These false warning cannot be fully
removed if the MAX_NUM_CHAINS exists, but we can improve it in following way:
There are lots of invalid control dependent chains computed in
tree-ssa-uninit.c now and should be pruned. I have already implemented a quick
fix and it works for our scenario.
I am not sure it should be fixed in this way, so please comments if you have
any opinions.
Thanks
Dump of tree-ssa-uninit.c:
;; Function foo (foo, funcdef_no=0, decl_uid=4065, cgraph_uid=0)
Use in stmt v_24 = PHI
is guarded by :
(.NOT.) if (m_6(D) != 0)
Operand defs of phi v_1 = PHI
is guarded by :
(.NOT.) if (n_5(D) <= 9)
(.AND.)
(.NOT.) if (m_6(D) > 100)
(.AND.)
if (r_7(D) <= 19)
(.OR.)
if (n_5(D) <= 9)
(.OR.)
(.NOT.) if (n_5(D) <= 9)
(.AND.)
(.NOT.) if (m_6(D) > 100)
(.AND.)
(.NOT.) if (r_7(D) <= 19)
(.AND.)
if (l_8(D) != 0)
foo (int n, int l, int m, int r)
{
int v;
int g.1;
int g.0;
:
if (n_5(D) <= 9)
goto ;
else
goto ;
:
if (m_6(D) > 100)
goto ;
else
goto ;
:
if (r_7(D) <= 19)
goto ;
else
goto ;
:
if (l_8(D) != 0)
goto ;
else
goto ;
:
:
# v_1 = PHI
if (m_6(D) != 0)
goto ;
else
goto ;
:
# v_25 = PHI
g.0_11 = g;
g.1_12 = g.0_11 + 1;
g = g.1_12;
goto ;
:
bar ();
:
# v_24 = PHI
if (n_5(D) <= 9)
goto ;
else
goto ;
:
if (m_6(D) > 100)
goto ;
else
goto ;
:
if (r_7(D) <= 19)
goto ;
else
goto ;
:
if (m_6(D) > 100)
goto ;
else
goto ;
:
blah (v_24);
if (n_5(D) <= 9)
goto ;
else
goto ;
:
blah (v_24);
goto ;
:
if (r_7(D) <= 9)
goto ;
else
goto ;
:
return 0;
:
# v_22 = PHI
goto ;
}
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #21 from Jakub Jelinek 2012-11-21 09:23:56 UTC --- (In reply to comment #20) > What I see is that it also affect code generation (register allocation). Do we > need to file a bug on that? If you see a code generation difference even with -ftls-model=local-exec -fPIC vs. -fPIE, then it must mean you don't have visibility attributes on the symbols used in the fast path. For initial-exec, the RA effects should be minimal, the TLS offset load from got is usually very close to the actual TLS memory load (or lea), and thus it will just pick up some short lived scratch register. Generally in GCC, -fPIE sets flag_pic and not flag_shlib, while -fPIC sets flag_pic and flag_shlib. flag_pic is about whether position independent code needs to be generated, flag_shlib is about whether locally defined symbols can be interposed (plus it affects TLS model default choice). > For dynamic libraries that are loaded into a non-instrumented executable (e.g. > swig so preloaded into python process), we statically link the tsan runtime > into the so. And you don't get linker errors from that? That must be by pure luck.
ARM/NEON: vld1q_dup_s64 builtin
Hi,
I have encountered a following ICE on arm big endian target
{{{
neon-vld1_dupQ.c: In function ‘main’:
neon-vld1_dupQ.c:24:1: error: unrecognizable insn:
(insn 94 93 31 (set (subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 0)
(subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 8))
/home/armbe/toolchain/armeb-tools/bin/../lib/gcc/armeb-montavista-linux-gnueabi/4.7.0/include/arm_neon.h:8214
-1
(nil))
neon-vld1_dupQ.c:24:1: internal compiler error: in extract_insn, at recog.c:2123
Please submit a full bug report,
}}}
My initial investigation shows that the following patch (split insn)
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01131.html is causing
this failure.
I think the CANNOT_CHANGE_MODE_CLASS macro is present and also plays a
role in not allowing the mov of DImode in this case.
If I revert the patch then I do not encounter this problem. Could you help
me with the pointers to solve this problem.
Regards,
Manjunath S Matti.
[Bug libgomp/55411] OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55411 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-21 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek 2012-11-21 10:31:33 UTC --- Created attachment 28752 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28752 gcc48-pr55411.patch Untested fix.
[Bug c/55420] Gcc produces an internal compiler error (nested function with variably modified return)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55420 --- Comment #1 from Mikael Pettersson 2012-11-21 10:34:00 UTC --- ICEs gcc-4.6, but not 4.7 or 4.8.
[Bug c++/55423] internal compiler error: tree check: expected string_cst, have error_mark in finish_static_assert, at cp/semantics.c:5170
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55423 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #1 from Jakub Jelinek 2012-11-21 10:39:31 UTC --- Should be fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190182 .
[Bug c++/55419] [4.7/4.8 Regression] ICE in gimplify_init_ctor_preeval, at gimplify.c:3587
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55419
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |4.8.0
Summary|[4.8 Regression] ICE in |[4.7/4.8 Regression] ICE in
|gimplify_init_ctor_preeval, |gimplify_init_ctor_preeval,
|at gimplify.c:3587 |at gimplify.c:3587
--- Comment #2 from Jakub Jelinek 2012-11-21
11:08:46 UTC ---
Reduced testcase:
struct P
{
P () = default;
explicit constexpr P (int x) : p (x) {}
int p;
};
struct Q
{
constexpr Q () : q (0x7f) {}
int q;
};
struct R
{
Q q;
P p;
};
void
foo (R *x)
{
*x = {};
}
Started ICEing with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177997
[Bug c++/55419] [4.7/4.8 Regression] ICE in gimplify_init_ctor_preeval, at gimplify.c:3587
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55419 --- Comment #3 from Jakub Jelinek 2012-11-21 11:18:22 UTC --- /* We always set TREE_SIDE_EFFECTS so that expand_expr does not ignore the TARGET_EXPR. If there really turn out to be no side-effects, then the optimizer should be able to get rid of whatever code is generated anyhow. */ TREE_SIDE_EFFECTS (t) = 1; + if (literal_type_p (type)) +TREE_CONSTANT (t) = TREE_CONSTANT (value); So we end up with TARGET_EXPR with TREE_SIDE_EFFECTS, but TREE_CONSTANT set too, which is what the gimplifier is complaining about. constants shouldn't have side-effects. If this is some trick internal to the C++ FE, then at least the genericizer should drop TREE_CONSTANT from TARGET_EXPRs with TREE_SIDE_EFFECTS set that are passed down to the middle-end.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 Jonathan Wakely changed: What|Removed |Added Severity|blocker |normal --- Comment #16 from Jonathan Wakely 2012-11-21 11:19:54 UTC --- When LINKER=$(CXX) you do not "link with a C++ compiler" you still link with the linker, ld, but the g++ driver passes it additional libs including -lstdc++. That means you can't fine-tune which libstdc++ is used, defeating the purpose of --with-host-libstdcxx. To allow fine-tuning the libs, you need the additional libs to not be used, which implies not linking with g++. If you use --with-host-libstdcxx then you need to get the argument right. (In reply to comment #8) > After that, I'll try to use a newer GCC on CentoS Linux i386 and try again > with > --with-host-libstdcxx='-static-libgcc -static-libstdc++ -lm'. This seems to > be > the more modern equivalent on more recent gcc/g++ compilers. No, it's not equivalent, -static-libstdcxx does not imply -lstdc++, which is why you get missing symbols. Why not just use the Sourcery configuration that works?
[Bug c/55422] gcc does not diagnose change of linkage for a function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek 2012-11-21 11:29:41 UTC --- GCC 4.4.3 is unsupported. But the behavior is the same as with trunk GCC.
[Bug c++/55425] New: constexpr does not work in many situations (both built-in and user supplied)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
Bug #: 55425
Summary: constexpr does not work in many situations (both
built-in and user supplied)
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m8r-ug8...@mailinator.com
constexpr expressions/functions do not work in many cases because of compiler
wrongly interpreting the code. Seen in gcc-MinGW 4.7.0 and 4.7.1.
Situation 1: __func__
--
A return statement is not a return statement if the returned value is __func__
(also true for non-standard identifiers like __PRETTY_FUNCTION__).
// good
//static const char func[] = "function-name";
//constexpr const char* x() { return func; }
// bad
constexpr const char* x() { return __func__;}
int main() { __builtin_puts(x()); return 0; }
Compiler output:
error: body of constexpr function 'constexpr const char* x()' not a
return-statement
Cross-reference to corresponding MinGW ticket:
http://sourceforge.net/tracker/index.php?func=detail&aid=3471328&group_id=2435&atid=102435
Situation 2: user literals
--
The (obviously constant) string that the compiler builds from the literal is
not constant according to the compiler:
#include
constexpr int valid_bin_number(const char* c) { return *c ? ((*c == '1' || *c
== '0') ? valid_bin_number(c+1) : false ) : true; }
unsigned int operator"" _bin(const char* str)
{
static_assert(valid_bin_number(str), "not a binary number");
unsigned int ret = 0;
for(unsigned int i = 0; str[i] != '\0'; ++i)
{
char digit = str[i];
ret = ret * 2 + (digit - '0');
}
return ret;
}
int main()
{
unsigned int a = 1_bin;
(void) a;
return 0;
}
Compiler output:
In function 'unsigned int operator"" _bin(const char*)':
error: non-constant condition for static assertion
error: 'str' is not a constant expression
Cross-reference to corresponding MinGW ticket:
http://sourceforge.net/tracker/?func=detail&atid=102435&aid=3582841&group_id=2435
Situation 3: __m128i type
--
Assigning a literal value to a constexpr __m128 fails because the literal is
not a literal.
#include
constexpr unsigned int a[] = { 5, 3}; // works (of course)
constexpr floatb[] = { 1.1, 3.7 }; // works, and no warning?!
__m128i c[] = { { 0x55633cd9, 0x88ca7a96 }, { 0x0ed8c2a8,
0x7795b179 } };
const __m128i d[] = { { 0x55633cd9, 0x88ca7a96 }, { 0x0ed8c2a8,
0x7795b179 } };
static const __m128i e[] = { { 0x55633cd9, 0x88ca7a96 }, { 0x0ed8c2a8,
0x7795b179 } };
namespace { const __m128i f[] = { { 0x55633cd9, 0x88ca7a96 }, { 0x0ed8c2a8,
0x7795b179 } }; }
constexpr __m128i g[] = { { 0x55633cd9, 0x88ca7a96 }, { 0x0ed8c2a8,
0x7795b179 } };// < fails
int main() { return 0; }
Compiler output:
error: the type 'const __m128i [] {aka const __vector(2) long long int []}' of
constexpr variable 'g' is not literal
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 Kai Tietz changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-11-21 CC||ktietz at gcc dot gnu.org Resolution|WONTFIX | Ever Confirmed|0 |1 --- Comment #3 from Kai Tietz 2012-11-21 11:53:53 UTC --- (In reply to comment #2) > Strange that the mingw-w64 developers didn't report that the bug is fixed. It isn't fixed. We added to mingw-w64's trunk the POSIX feature of signgam. By this reason things are working again, if you are using recent mingw-w64's trunk version. I re-open bug as there is actual a fix pending
[Bug c++/55425] constexpr does not work in many situations (both built-in and user supplied literals)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
--- Comment #1 from Jonathan Wakely 2012-11-21
12:12:19 UTC ---
(In reply to comment #0)
>
> A return statement is not a return statement if the returned value is __func__
> (also true for non-standard identifiers like __PRETTY_FUNCTION__).
>
> // good
> //static const char func[] = "function-name";
> //constexpr const char* x() { return func; }
>
> // bad
> constexpr const char* x() { return __func__;}
>
> int main() { __builtin_puts(x()); return 0; }
The standard says __func__ is a function-local variable, defined as if by
constexpr const char* x() {
static const char __func__[] = "function-name ";
return __func__;
}
Clearly this is not a valid constexpr function.
Changing this would be an extension.
> Situation 2: user literals
> --
>
> The (obviously constant) string that the compiler builds from the literal is
> not constant according to the compiler:
>
> #include
>
> constexpr int valid_bin_number(const char* c) { return *c ? ((*c == '1' || *c
> == '0') ? valid_bin_number(c+1) : false ) : true; }
>
> unsigned int operator"" _bin(const char* str)
> {
> static_assert(valid_bin_number(str), "not a binary number");
'str' is not a constant expression, so 'valid_bin_number(str)' is not a
constant expression either. This is not a bug.
> Situation 3: __m128i type
> --
>
> Assigning a literal value to a constexpr __m128 fails because the literal is
> not a literal.
No, the error says __m128 is not a literal type, which I assume is true.
Changing that would be an enhancement request.
[Bug c++/55425] constexpr does not work in many situations (both built-in and user supplied literals)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425 --- Comment #2 from Jonathan Wakely 2012-11-21 12:19:06 UTC --- (In reply to comment #1) > > Situation 3: __m128i type > > -- > > > > Assigning a literal value to a constexpr __m128 fails because the literal is > > not a literal. > > No, the error says __m128 is not a literal type, which I assume is true. > Changing that would be an enhancement request. With G++ 4.8 __m128i is a literal type, so this example works.
[Bug middle-end/55421] [4.8 Regression] ICE in adjust _address_1, at emit-rtl.c:2180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55421 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from John David Anglin 2012-11-21 12:40:20 UTC --- Fixed.
[Bug c++/55425] constexpr does not work in many situations (both built-in and user supplied literals)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
--- Comment #3 from Jakub Jelinek 2012-11-21
12:40:29 UTC ---
1) is not valid constexpr IMHO, as the standard says that __func__ works as if
static const char __func__[] = "function-name";
has been provided, but when it is provided, it is not valid constexpr.
2) I don't see why you think you could use something like this at all.
You are defining a non-constexpr operator "", so str there definitely isn't
pointer to a string literal, it is a standalone function that might be
inlined if the inliner choses so. So it is obvious the static_assert
which must be evaluated before the optimizations, without depending on
whether the function is inlined or not, must fail.
You want something like:
constexpr int
cstrlen (const char *c)
{
return *c ? cstrlen (c + 1) + 1 : 0;
}
constexpr unsigned int
bin_number (const char *c)
{
return *c ? (*c == '1' ? (1U << cstrlen (c + 1)) : *c == '0' ? 0 : throw 0) +
bin_number (c + 1) : 0;
}
constexpr unsigned int
operator"" _bin (const char *c)
{
return bin_number (c);
}
int
main ()
{
constexpr unsigned int a = 1_bin;
(void) a;
return 0;
}
instead, then you can verify it the same at compile time.
[Bug c/55422] gcc does not diagnose change of linkage for a function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422 --- Comment #3 from Marek Polacek 2012-11-21 12:44:31 UTC --- Looks like the first example is just an undefined behavior in which case GCC isn't obliged to issue an error.
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #3 from John David Anglin 2012-11-21 13:01:33 UTC --- Created attachment 28753 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28753 Tree dump
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #4 from John David Anglin 2012-11-21 13:02:32 UTC --- Created attachment 28754 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28754 Tree dump
[Bug tree-optimization/55424] [4.8 Regression]gcc.dg/uninit-pred-8_b.c bogus warning line 23 on ARM/Cortex-M0/-Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55424 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Andrew Pinski 2012-11-21 13:07:00 UTC --- The issue is the same as PR 49498. *** This bug has been marked as a duplicate of bug 49498 ***
[Bug tree-optimization/49498] [4.7/4.8 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #18 from Andrew Pinski 2012-11-21 13:07:00 UTC --- *** Bug 55424 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #5 from John David Anglin 2012-11-21 13:13:22 UTC --- Get the same with stage1 compiler. Maybe this is a HWI32 issue?
[Bug tree-optimization/49498] [4.7/4.8 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 --- Comment #19 from bin.cheng 2012-11-21 13:24:02 UTC --- (In reply to comment #18) > *** Bug 55424 has been marked as a duplicate of this bug. *** Just for the record. If the analysis I gave in Comment #17 is right, this PR reveals another bug in tree-ssa-uninit.c, apart from the limitation of MAX_NUM_CHAINS, while PR55424 is only about MAX_NUM_CHAINS.
[Bug target/55426] New: gcc.target/arm/neon-vld1_dupQ.c ICEs on armeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55426
Bug #: 55426
Summary: gcc.target/arm/neon-vld1_dupQ.c ICEs on armeb
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mmatti@gmail.com
CC: christophe.l...@st.com, ramana.radhakrish...@arm.com
Host: Scientific Linux 6.3
Target: arm big-endian
Build: Scientific Linux 6.3
Hi,
I have encountered a following ICE on arm big endian target
{{{
neon-vld1_dupQ.c: In function ‘main’:
neon-vld1_dupQ.c:24:1: error: unrecognizable insn:
(insn 94 93 31 (set (subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 0)
(subreg:DI (reg:V2DI 95 d16 [orig:137 D.14400 ] [137]) 8))
/home/armbe/toolchain/armeb-tools/bin/../lib/gcc/armeb-none-linux-gnueabi/4.7.0/include/arm_neon.h:8214
-1
(nil))
neon-vld1_dupQ.c:24:1: internal compiler error: in extract_insn, at
recog.c:2123
Please submit a full bug report,
}}}
My initial investigation shows that the following patch (split insn)
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01131.html is causing
this failure.
I think the CANNOT_CHANGE_MODE_CLASS macro is present and also plays a
role in not allowing the mov of DImode in this case.
If I revert the patch then I do not encounter this problem.
I can propose a solution, which may fix this problem.
In case of little endian the compiler generates,
{{{
insn 93 26 94 (set (reg:DI 95 d16 [orig:137 D.14400 ] [137])
(vec_duplicate:DI (mem:DI (reg/f:SI 2 r2 [155]) [0 *(const
__builtin_neon_di[1] *) __a_5+0 S8 A64])))
/home/armbe/toolchain/arm-tools/bin/../lib/gcc/arm-montavista-linux-gnueabi/4.7.0/include/arm_neon.h:8214
1606 {neon_vld1_dupdi}
(nil))
vld1.64 {d16}, [r2:64] @ 93neon_vld1_dupdi [length = 4]
(insn 94 93 31 (set (reg:DI 97 d17 [ D.14400+8 ])
(reg:DI 95 d16 [orig:137 D.14400 ] [137]))
/home/armbe/toolchain/arm-tools/bin/../lib/
}}}
But incase of big endian the vmov\t%f0, %e0 is missing there is no
pattern in the neon.md file.
Adding this may solve the problem. Something like this
(define_insn "*neon_subreg_di"
[(set (match_operand:DI 0 "s_register_operand" "=w")
(match_operand:DI 1 "s_register_operand" "w"))]
"TARGET_NEON"
"vmov\t%1, %0"
)
Kindly comment on this patch or could you please help me with the
pointers to solve this problem.
Regards,
Manjunath S Matti.
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
Jakub Jelinek changed:
What|Removed |Added
Target|hppa*-*-* (32-bit) |
Status|WAITING |NEW
Host|hppa*-*-* (32-bit) |
Build|hppa*-*-* (32-bit) |
--- Comment #6 from Jakub Jelinek 2012-11-21
13:36:56 UTC ---
Reproduced with
extern void abort (void);
__attribute__ ((noinline))
unsigned __int128
foo (__int128 ixi, unsigned ctr)
{
unsigned __int128 irslt = 1;
__int128 ix = ixi;
for (; ctr; ctr--)
{
irslt *= ix;
ix *= ix;
}
if (irslt != 14348907)
abort ();
return irslt;
}
int
main ()
{
unsigned __int128 res;
res = foo (3, 4);
return 0;
}
on x86_64-linux at -O2, seems to be a VRP bug.
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 --- Comment #4 from Tobias Burnus 2012-11-21 13:46:41 UTC --- Author: burnus Date: Wed Nov 21 13:46:34 2012 New Revision: 193695 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193695 Log: 2012-11-21 Tobias Burnus PR libquadmath/55225 * math/lgammaq.c (lgammaq): Use local variable if math.h does not provide signgam. * acinclude.m4 (LIBQUAD_CHECK_MATH_H_SIGNGAM): New check. * configure.ac: Use it. * configure: Regenerate. * config.h.in: Regenerate. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/acinclude.m4 trunk/libquadmath/config.h.in trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libquadmath/math/lgammaq.c
[Bug libquadmath/55225] Fail to build lgammaq.c from trunk with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55225 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #5 from Tobias Burnus 2012-11-21 13:48:48 UTC --- FIXED on the trunk (4.8), which was only affected. While POSIX requires that signgam is used for lgamma and, hence, math.h includes it. C99 doesn't have signgam. Thus, even if MinGW-w64 now supports it, a configure check makes sense as other systems might not (yet?) support it.
[Bug c++/55425] constexpr does not work in many situations (both built-in and user supplied literals)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek 2012-11-21
13:50:43 UTC ---
Or more efficiently
constexpr unsigned int
bin_number (const char *c, unsigned int x)
{
return *c ? bin_number (c + 1, (x << 1) + (*c == '0' || *c == '1' ? *c - '0'
: throw 0)) : x;
}
constexpr unsigned int
operator"" _bin (const char *c)
{
return bin_number (c, 0);
}
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471 --- Comment #7 from Jakub Jelinek 2012-11-21 13:55:59 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190125
[Bug c++/55418] Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55418 --- Comment #1 from Markus Trippelsdorf 2012-11-21 14:08:12 UTC --- The following trivial patch fixes the issue: diff --git a/gcc/cp/method.c b/gcc/cp/method.c index 6dcb63a..3cb4ace 100644 --- a/gcc/cp/method.c +++ b/gcc/cp/method.c @@ -1518,7 +1518,7 @@ implicitly_declare_fn (special_function_kind kind, tree type, tree name; HOST_WIDE_INT saved_processing_template_decl; bool deleted_p; - bool trivial_p; + bool trivial_p = false; bool constexpr_p; /* Because we create declarations for implicitly declared functions
[Bug middle-end/55407] stack-buffer-overflow in compute_working_sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55407 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from H.J. Lu 2012-11-21 14:28:00 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55417 ***
[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55417 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu 2012-11-21 14:28:01 UTC --- *** Bug 55407 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55417 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-21 Ever Confirmed|0 |1 --- Comment #4 from H.J. Lu 2012-11-21 14:29:02 UTC --- There is a simple testcase in PR 55407.
[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55417 --- Comment #5 from Markus Trippelsdorf 2012-11-21 14:34:24 UTC --- Teresa, your patch fixes the issue. Happy Thanksgiving.
[Bug fortran/55427] New: ICE class pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Bug #: 55427 Summary: ICE class pointer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: valerywe...@hotmail.com Dear All Is that known? gcc version 4.8.0 20121121 (experimental) (GCC) Valery !>>>>>>> MODULE base_types IMPLICIT NONE TYPE :: base_type END TYPE base_type TYPE, extends( base_type ) :: integer_type integer :: i END TYPE integer_type contains FUNCTION points_to ( this ) RESULT( reslt ) CLASS( base_type ), DIMENSION( : ), TARGET :: this CLASS( base_type ), DIMENSION( : ), POINTER :: reslt reslt => this END FUNCTION points_to END MODULE base_types program bug use base_types implicit none CLASS( base_type ), POINTER, DIMENSION( : ) :: reslt CLASS( base_type ), ALLOCATABLE, DIMENSION( : ) :: val type(integer_type) :: i i%i=12345 ALLOCATE( val(10), source=i ) reslt => points_to ( val ) write(*,*) associated(reslt) select type( p=> reslt ) type is(integer_type) write(*,*) 'p=',p(2)%i class default stop 666 end select end program bug != gfortran-trunk bug4.f90 bug4.f90: In function ‘bug’: bug4.f90:24:0: internal compiler error: in fold_convert_loc, at fold-const.c:1857 reslt => points_to ( val ) ^ 0x83cb322 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc-trunk/gcc/fold-const.c:1856 0x81eff63 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-expr.c:6350 0x81f34a5 gfc_trans_class_assign(gfc_expr*, gfc_expr*, gfc_exec_op) ../../gcc-trunk/gcc/fortran/trans-expr.c:888 0x81b1dda trans_code ../../gcc-trunk/gcc/fortran/trans.c:1322 0x81dcf17 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:5349 0x816f1c5 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:4467 0x816f1c5 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:4681 0x81acbca gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:191 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. !<<<<<<<<<
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #8 from Jakub Jelinek 2012-11-21
14:42:13 UTC ---
Created attachment 28755
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28755
gcc48-pr54471.patch
Untested fix. I believe the bug is in invalid canonicalization. When
sizem1 is { -1, -1 } double_int, sizem1 + double_int_one is { 0, 0 }, as it
wrapped, instead of { 0, 0, 1, 0 } quad_int. And if min0 or min1 is zero, then
size - min{0,1} is also zero, and so is very likely smaller than max{0,1}
(unless min{0,1} == max{0,1}), but we still don't want to "canonicalize" that
to signed. IMHO testing min2.is_zero () is sufficient, as min0 or min1 should
be a valid double_int in the range 0 to { -1, -1 }, which is always smaller
than the maximum unsigned integer + 1 in infinite precision and thus min2
should never be zero, unless size overflowed to 0 and min{0,1} is zero.
[Bug c/55428] New: -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428
Bug #: 55428
Summary: -mms-bitfields hides -mno-align-double option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kasber...@heidenhain.de
i686-pc-linux-gbu-gcc -mno-align-double -mms-bitfields test.cpp
("-mno-align-double" is the equivalent to /zp4)
This command line ignores the "-mno-align-double" option.
With -mno-align-double standalone it will do the correct double alignments but
no the ms bitfield alignment (What is expected)
If I add -mms-bitfields the alignment for bitfields will be correct but the
"-mno-align-double" is now gone
Here the program I have tested. Is it possible to achieve binary compatibility
to ms compiler with option /zp4 enabled
i686-pc-linux-gbu-gcc -mno-align-double -mms-bitfields test.cpp
test.cpp:48:58: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
test.cpp:54:54: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
i686-pc-linux-gbu-gcc -mno-align-double test.cpp
test.cpp:52:53: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
test.cpp:58:53: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
i686-pc-linux-gbu-gcc -mms-bitfields test.cpp
test.cpp:48:58: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
test.cpp:54:54: warning: large integer implicitly truncated to unsigned type
[-Woverflow]
// 8
typedef struct _jhtest1 {
unsigned long bf_1 : 12;
unsigned long : 0;
unsigned long bf_2 : 12;
} jhtest1;
//??
typedef struct _jhtest2 {
char foo : 4;
short : 0;
char bar;
} jhtest2;
//??
typedef struct _jhtest3 {
char foo : 4;
short : 0;
double bar;
} jhtest3;
//4
typedef struct _jhtest4 {
char foo : 6;
long : 0;
} jhtest4;
// 2
typedef struct _jhtest5 {
char foo;
long : 0;
char bar;
} jhtest5;
typedef struct _jhtest {
double xx;
char y;
double yy;
long z;
} jhtest;
unsigned char jh_double = (sizeof (double) == 8 )?1:111;
unsigned char jh_test0 = (sizeof (jhtest) == (8*2+8) )?1:111;
unsigned char jh_test1 = (sizeof (jhtest1) == 8 )?1:111;
unsigned char jh_test2 = (sizeof (jhtest2) == 4 )?1:111; // VC++
unsigned char jh_test3 = (sizeof (jhtest3) == 12 )?1:111;
unsigned char jh_test4 = (sizeof (jhtest4) == 4 )?1:111;
unsigned char jh_test5 = (sizeof (jhtest5) == 2 )?1:111; // VC++
int main()
{
}
[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55417 --- Comment #6 from Jakub Jelinek 2012-11-21 15:04:58 UTC --- Author: jakub Date: Wed Nov 21 15:04:45 2012 New Revision: 193697 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193697 Log: PR gcov-profile/55417 * profile.c (compute_working_sets): Check index first to avoid out-of-bounds array access. Modified: trunk/gcc/ChangeLog trunk/gcc/profile.c
[Bug c/55428] -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-11-21 15:20:41 UTC --- Possibly related to PR52991 (-mms-bitfields breaks attribute((packed))).
[Bug libstdc++/55429] New: new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 Bug #: 55429 Summary: new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu At r193675, a new set of failures appear in the x86_64-apple-darwin12 testsuite results at both -m32 and -m64... UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIfE4realB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIdE4realB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexI[eg]E4realB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIiE4realB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIfE4imagB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIdE4imagB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexI[eg]E4imagB5cxx11Ev UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIiE4imagB5cxx11Ev Compiler version: 4.8.0 20121120 (experimental) (GCC) Platform: x86_64-apple-darwin12.2.0 configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 --disable-cloog-version-check --disable-isl-version-check
[Bug c/55428] -mms-bitfields hides -mno-align-double option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #2 from Kai Tietz 2012-11-21 15:30:12 UTC --- Hmm, it seems that for ms-bitfields the default-field-alignment overrides all field-local alignments. I wouldn't assume that __attribute__((packed)) is directly related to this issue, but of course it is close to it. For the packed-case the issue seems to be that it isn't used for the fields, but for the last element in struct/union. Btw the testcase works nice, if you use in front a #pragma pack(4).
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf 2012-11-21 15:30:35 UTC --- The last error is reproducible with e.g.: % /var/tmp/gcc_valgrind/usr/local/bin/gcc -w -O2 -c /home/markus/gcc/libiberty/cp-demangle.c ==6842== Invalid read of size 4 ==6842==at 0xD20A91: rest_of_handle_ree() (ree.c:615) ==6842==by 0x826B2A: execute_one_pass(opt_pass*) (passes.c:2327) ==6842==by 0x826FA4: execute_pass_list(opt_pass*) (passes.c:2387) ==6842==by 0x826FB6: execute_pass_list(opt_pass*) (passes.c:2388) ==6842==by 0x826FB6: execute_pass_list(opt_pass*) (passes.c:2388) ==6842==by 0x5EC801: expand_function(cgraph_node*) (cgraphunit.c:1641) ==6842==by 0x5EE5C6: compile() (cgraphunit.c:1745) ==6842==by 0x5EEC69: finalize_compilation_unit() (cgraphunit.c:2120) ==6842==by 0x4D52EB: c_write_global_declarations() (c-decl.c:10120) ==6842==by 0x8C845C: compile_file() (toplev.c:559) ==6842==by 0x8CA319: toplev_main(int, char**) (toplev.c:1881) ==6842==by 0x4ECD894: (below main) (libc-start.c:258) ==6842== Address 0x5b37f51 is 2,577 bytes inside a block of size 2,580 alloc'd ==6842==at 0x4026BA4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==6842==by 0xDFABD8: xcalloc (xmalloc.c:162) ==6842==by 0xD211C6: rest_of_handle_ree() (ree.c:884) ==6842==by 0x826B2A: execute_one_pass(opt_pass*) (passes.c:2327) ...
[Bug libstdc++/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 --- Comment #1 from Jack Howarth 2012-11-21 15:35:21 UTC --- This error appears in libstdc++.log as... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/g++ -shared-libgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src -L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/ -B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem /sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include -m32 -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.2.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121120/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121120/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121120/libstdc++-v3/testsuite/util /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121120/libstdc++-v3/testsuite/26_numerics/complex/abi_tag.cc -std=c++11 -S -m32 -o abi_tag.s(timeout = 600) PASS: 26_numerics/complex/abi_tag.cc (test for excess errors) 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIfE4realB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIdE4realB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexI[eg]E4realB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIiE4realB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIfE4imagB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIdE4imagB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexI[eg]E4imagB5cxx11Ev 20_util/enable_shared_from_this/cons/constexpr.cc: output file does not exist UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler _ZNKSt7complexIiE4imagB5cxx11Ev extra_tool_flags are: -include bits/stdc++.h
[Bug target/55426] gcc.target/arm/neon-vld1_dupQ.c ICEs on armeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55426 --- Comment #1 from christophe.lyon at st dot com 2012-11-21 15:50:14 UTC --- Reverting the definition of CANNOT_CHANGE_MODE_CLASS introduced on 2012-10-22 at rev #192687 avoids the ICE too.
[Bug c++/55418] Valgrind: Conditional jump or move depends on uninitialised value(s) in implicitly_declare_fn() method.c:1623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55418 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson 2012-11-21 15:51:08 UTC --- I haven't (In reply to comment #1) > The following trivial patch fixes the issue: I haven't looked at the context so I feel free to say it looks a bit obvious...
[Bug gcov-profile/55417] [4.8 Regression] AddressSanitizer reports stack-buffer-overflow in profiling code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55417 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Markus Trippelsdorf 2012-11-21 16:06:41 UTC --- Fixed.
[Bug c++/55245] [4.6/4.7/4.8 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #5 from davidxl 2012-11-21 16:17:27 UTC --- Should the main variant types gets laid out in gimplify_type_sizes, when the variant's type has size, but the main variant is incomplete? David
[Bug libstdc++/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 --- Comment #2 from Jonathan Wakely 2012-11-21 16:44:41 UTC --- Do you mean at exactly r193675 or at some point prior to that? obviously not a libstdc++ bug in any case
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 --- Comment #2 from Markus Trippelsdorf 2012-11-21 16:52:59 UTC --- ==13066== Conditional jump or move depends on uninitialised value(s) ==13066==at 0x56333A: pp_c_specifier_qualifier_list(c_pretty_print_info*, tree_node*) (c-pretty-print.c:449) ==13066==by 0x563668: pp_c_type_id(c_pretty_print_info*, tree_node*) (c-pretty-print.c:621) ==13066==by 0x4FF780: c_tree_printer(pretty_print_info*, text_info*, char const*, int, bool, bool, bool) (c-objc-common.c:149) ==13066==by 0xDB6682: pp_base_format(pretty_print_info*, text_info*) (pretty-print.c:509) ==13066==by 0xDB4478: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:756) ==13066==by 0xDB5043: error_at(unsigned int, char const*, ...) (diagnostic.c:1036) ==13066==by 0x4EA6BA: build_component_ref(unsigned int, tree_node*, tree_node*) (c-typeck.c:2156) ==13066==by 0x50968B: c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr) (c-parser.c:6946) ==13066==by 0x501568: c_parser_postfix_expression(c_parser*) (c-parser.c:6779) ==13066==by 0x502F22: c_parser_unary_expression(c_parser*) (c-parser.c:5978) ==13066==by 0x50733E: c_parser_cast_expression(c_parser*, c_expr*) (c-parser.c:5830) ==13066==by 0x502E06: c_parser_unary_expression(c_parser*) (c-parser.c:5892) ==13066== ==13066== Conditional jump or move depends on uninitialised value(s) ==13066==at 0x5633C8: pp_c_specifier_qualifier_list(c_pretty_print_info*, tree_node*) (c-pretty-print.c:497) ==13066==by 0x563668: pp_c_type_id(c_pretty_print_info*, tree_node*) (c-pretty-print.c:621) ==13066==by 0x4FF780: c_tree_printer(pretty_print_info*, text_info*, char const*, int, bool, bool, bool) (c-objc-common.c:149) ==13066==by 0xDB6682: pp_base_format(pretty_print_info*, text_info*) (pretty-print.c:509) ==13066==by 0xDB4478: diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) (diagnostic.c:756) ==13066==by 0xDB5043: error_at(unsigned int, char const*, ...) (diagnostic.c:1036) ==13066==by 0x4EA6BA: build_component_ref(unsigned int, tree_node*, tree_node*) (c-typeck.c:2156) ==13066==by 0x50968B: c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr) (c-parser.c:6946) ==13066==by 0x501568: c_parser_postfix_expression(c_parser*) (c-parser.c:6779) ==13066==by 0x502F22: c_parser_unary_expression(c_parser*) (c-parser.c:5978) ==13066==by 0x50733E: c_parser_cast_expression(c_parser*, c_expr*) (c-parser.c:5830) ==13066==by 0x502E06: c_parser_unary_expression(c_parser*) (c-parser.c:5892) ==13066==
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2012-11-21 CC||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 Summary|ICE class pointer |[OOP] ICE with ||class-array-pointer result --- Comment #1 from janus at gcc dot gnu.org 2012-11-21 16:52:56 UTC --- (In reply to comment #0) > Is that known? Not that I know of. Reduced version: MODULE base_types IMPLICIT NONE TYPE :: base_type END TYPE contains FUNCTION points_to () RESULT (reslt) CLASS(base_type), DIMENSION(:), POINTER :: reslt END FUNCTION END MODULE program bug use base_types implicit none CLASS(base_type), POINTER, DIMENSION(:) :: reslt reslt => points_to() end ICEs with trunk and 4.7.
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | --- Comment #2 from Aldy Hernandez 2012-11-21 16:57:53 UTC --- Mine.
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 --- Comment #6 from Martin Jambor 2012-11-21 17:03:46 UTC --- This is the second fix, as posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01724.html also slightly related is: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01758.html
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 --- Comment #7 from Martin Jambor 2012-11-21 17:04:54 UTC --- Author: jamborm Date: Wed Nov 21 17:04:45 2012 New Revision: 193700 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193700 Log: 2012-11-21 Martin Jambor PR tree-optimization/55260 * ipa-cp.c (intersect_aggregates_with_edge): New function. (find_aggregate_values_for_callers_subset): Part moved to the function above. Call it. (cgraph_edge_brings_all_agg_vals_for_node): Reimplemented using intersect_aggregates_with_edge. * testsuite/g++.dg/torture/pr55260-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr55260-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug other/55430] New: [4.8 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430 Bug #: 55430 Summary: [4.8 Regression Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: hjl.to...@gmail.com, h...@gcc.gnu.org, mar...@trippelsdorf.de Depends on: 55358 +++ This bug was initially created as a clone of Bug #55358 +++ With revision 193546, valgrind reports: ==26359== Invalid read of size 4 ==26359==at 0xB58AEE: rest_of_handle_ree() (ree.c:617) ==26359==by 0x74ADA3: execute_one_pass(opt_pass*) (passes.c:2339) ==26359==by 0x74B174: execute_pass_list(opt_pass*) (passes.c:2400) ==26359==by 0x74B186: execute_pass_list(opt_pass*) (passes.c:2401) ==26359==by 0x74B186: execute_pass_list(opt_pass*) (passes.c:2401) ==26359==by 0x5AB16D: expand_function(cgraph_node*) (cgraphunit.c:1643) ==26359==by 0x5AC786: compile() (cgraphunit.c:1747) ==26359==by 0x5ACBA9: finalize_compilation_unit() (cgraphunit.c:2122) ==26359==by 0x4E47DF: c_write_global_declarations() (c-decl.c:10128) ==26359==by 0x7D7F4C: compile_file() (toplev.c:559) ==26359==by 0x7D9AA7: toplev_main(int, char**) (toplev.c:1881) ==26359==by 0x38F3A21674: (below main) (in /usr/lib64/libc-2.15.so) ==26359== Address 0x4e10d51 is 2,785 bytes inside a block of size 2,788 alloc'd ==26359==at 0x4A06B0F: calloc (vg_replace_malloc.c:593) ==26359==by 0xC0F708: xcalloc (xmalloc.c:162) ==26359==by 0xB59070: rest_of_handle_ree() (ree.c:886)
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Martin Jambor 2012-11-21 17:10:05 UTC --- Fixed.
[Bug middle-end/55430] [4.8 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
Jakub Jelinek changed:
What|Removed |Added
Target||x86_64-linux
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-21
Component|other |middle-end
CC||vmakarov at redhat dot com
Ever Confirmed|0 |1
Target Milestone|--- |4.8.0
--- Comment #1 from Jakub Jelinek 2012-11-21
17:16:00 UTC ---
This ree.c:61X failure is a LRA caused miscompilation of ree.c apparently.
Reduced self-contained testcase:
struct S
{
unsigned int s1 : 8;
unsigned int s2 : 2;
};
int
foo (int x, int y, struct S *z, unsigned int w)
{
if (z[y].s2 == x && z[y].s1 == w)
return 1;
return 0;
}
#ifdef FULL
#include
#include
int foo (int, int, struct S *, unsigned int) __attribute__((noinline,
noclone));
int
main ()
{
unsigned long ps = sysconf (_SC_PAGE_SIZE);
char *p = mmap (NULL, 8 * ps, PROT_READ, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED)
return 0;
if (mprotect (p + 4 * ps, 4 * ps, PROT_NONE))
return 0;
if ((4 * ps / sizeof (struct S)) * sizeof (struct S) != 4 * ps)
return 0;
struct S *s = (struct S *) (p + 4 * ps);
return foo (0, 0, s - 1, 0) != 1;
}
#endif
compile with -O2 on x86_64-linux, and you can see (or when compiled with -O2
-DFULL watch at runtime) that before LRA merge, code like:
movzbl 1(%rdx), %eax
andl$3, %eax
has been generated to read the s2 bitfield, while with LRA it is
movl1(%rdx), %esi
andl$3, %esi
instead (note movl instead of movzbl). But the structure (in ree.c s2 is kind
and struct S is struct ext_modified) is 4 bytes long, thus reading 4 bytes from
the start of the structure + 1 byte is potentially going to trap if the
structure is at the end of some page (as -DFULL shows).
In *.ira we have:
(insn 15 12 16 2 (set (reg:QI 80 [ *_6+1 ])
(mem:QI (plus:DI (reg/f:DI 62 [ D.1744 ])
(const_int 1 [0x1])) [2 *_6+1 S1 A8])) reetest.c:10 67
{*movqi_internal}
(expr_list:REG_EQUIV (mem:QI (plus:DI (reg/f:DI 62 [ D.1744 ])
(const_int 1 [0x1])) [2 *_6+1 S1 A8])
(nil)))
(note 16 15 17 2 NOTE_INSN_DELETED)
(insn 17 16 7 2 (parallel [
(set (reg:SI 81 [ D.1742 ])
(and:SI (subreg:SI (reg:QI 80 [ *_6+1 ]) 0)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) reetest.c:10 376 {*andsi_1}
(expr_list:REG_DEAD (reg:QI 80 [ *_6+1 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
which *.reload turns into:
(insn 43 16 17 2 (set (reg:SI 4 si [orig:81 D.1742 ] [81])
(mem:SI (plus:DI (reg/f:DI 1 dx [orig:62 D.1744 ] [62])
(const_int 1 [0x1])) [2 *_6+1 S4 A8])) reetest.c:10 65
{*movsi_internal}
(nil))
(insn 17 43 44 2 (parallel [
(set (reg:SI 4 si [orig:81 D.1742 ] [81])
(and:SI (reg:SI 4 si [orig:81 D.1742 ] [81])
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) reetest.c:10 376 {*andsi_1}
(nil))
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 --- Comment #3 from Markus Trippelsdorf 2012-11-21 17:17:23 UTC --- I hope it's OK to just dump the errors here as I encounter them. This one looks similar to the rest_of_handle_ree() issue: ==23637== Invalid write of size 8 ==23637==at 0xCF9951: rest_of_handle_dse() (dse.c:2874) ==23637==by 0x826B2A: execute_one_pass(opt_pass*) (passes.c:2327) ==23637==by 0x826FA4: execute_pass_list(opt_pass*) (passes.c:2387) ==23637==by 0x826FB6: execute_pass_list(opt_pass*) (passes.c:2388) ==23637==by 0x5EC801: expand_function(cgraph_node*) (cgraphunit.c:1641) ==23637==by 0x5EE5C6: compile() (cgraphunit.c:1745) ==23637==by 0x5EEC69: finalize_compilation_unit() (cgraphunit.c:2120) ==23637==by 0x4D52EB: c_write_global_declarations() (c-decl.c:10120) ==23637==by 0x8C845C: compile_file() (toplev.c:559) ==23637==by 0x8CA319: toplev_main(int, char**) (toplev.c:1881) ==23637==by 0x4ECD894: (below main) (libc-start.c:258) ==23637== Address 0x69fdd50 is 112 bytes inside a block of size 11,208 alloc'd ==23637==at 0x4028ECB: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==23637==by 0xDFAB97: xmalloc (xmalloc.c:147) ==23637==by 0x57E6C8: pool_alloc(alloc_pool_def*) (alloc-pool.c:282) ==23637==by 0xCF8F1C: record_store(rtx_def*, bb_info*) (dse.c:1544) ==23637==by 0xCF9D14: rest_of_handle_dse() (dse.c:2676) ==23637==by 0x826B2A: execute_one_pass(opt_pass*) (passes.c:2327) ==23637==by 0x826FA4: execute_pass_list(opt_pass*) (passes.c:2387) ==23637==by 0x826FB6: execute_pass_list(opt_pass*) (passes.c:2388) ==23637==by 0x5EC801: expand_function(cgraph_node*) (cgraphunit.c:1641) ==23637==by 0x5EE5C6: compile() (cgraphunit.c:1745) ==23637==by 0x5EEC69: finalize_compilation_unit() (cgraphunit.c:2120) ==23637==by 0x4D52EB: c_write_global_declarations() (c-decl.c:10120) ==23637==
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
--- Comment #9 from Marc Glisse 2012-11-21 17:18:47
UTC ---
Jakub, your patch makes sense to me (or min0.is_zero() and min1.is_zero()). I
am ashamed I managed to get products with [0,n] (with n larger than MAX/2)
wrong. Good thing Kenneth Zadeck's wide_int will soon allow us to remove most
of this horrible code.
Another test that shows the error (optimizes away the call to g):
void g();
void h();
void f(unsigned __int128 x){
if(x>(unsigned __int128)(-3))return;
unsigned __int128 y=2*x;
if(y==42) g();
else h();
}
[Bug other/55358] Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2012-11-21 17:20:02 UTC --- The ree.c miscompilation tracked in PR55430 now.
[Bug tree-optimization/54471] [4.8 Regression] FAIL: gcc.dg/sms-8.c execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54471
--- Comment #10 from Jakub Jelinek 2012-11-21
17:31:58 UTC ---
Thanks, I'm going to include your test too then:
--- gcc/testsuite/gcc.dg/tree-ssa/vrp86.c.jj2012-11-21 18:27:53.389280736
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp86.c2012-11-21 18:27:47.0
+0100
@@ -0,0 +1,26 @@
+/* PR tree-optimization/54471 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1" } */
+
+#ifdef __SIZEOF_INT128__
+#define T __int128
+#else
+#define T long long
+#endif
+
+void fn1call ();
+void fn2call ();
+void f (unsigned T x)
+{
+ if (x > (unsigned T) -3)
+return;
+ unsigned T y = 2 * x;
+ if (y == 42)
+fn1call ();
+ else
+fn2call ();
+}
+
+/* { dg-final { scan-tree-dump "fn1call" "vrp1"} } */
+/* { dg-final { scan-tree-dump "fn2call" "vrp1"} } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */
[Bug target/55431] New: Invalid auxv search in ppc linux-unwind code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55431 Bug #: 55431 Summary: Invalid auxv search in ppc linux-unwind code. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: bug...@aerifal.cx config/rs6000/linux-unwind.h contains a function ppc_linux_aux_vector which searches for the aux vector based on __libc_stack_end; the only use of this function is to lookup the AT_HWCAP bitfield provided by the kernel. The results seem to be used only for premature optimization: optimizing out copying register sets that aren't used on the current cpu model. Unfortunately, the method used to search for auxv is invalid at the time the call to ppc_linux_aux_vector is made. The array pointed to by extern char **environ; may be modified by the application; for example it may be truncated to clear the environment by writing *environ = 0; In this case, the old, no-longer-used part of the environ array will be incorrectly interpreted as the aux vector, causing the unwind code not to find the hwcap values and thus not to save the register sets it needs to save. I found this bug while debugging a report that gcc couldn't be built for powerpc on musl libc due to missing __libc_stack_end symbol. I don't see anywhere that it's documented that __libc_stack_end points to the original argc slot passed from the kernel, rather than some arbitrary address between main's stack frame and argv[], so I think it's very bad design to be relying on this implementation-detail anyway. The fix I would like to see is the complete removal of ppc_linux_aux_vector and updating ppc_fallback_frame_state not to care which register sets are actually in use.
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785 Jan Hubicka changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #35 from Jan Hubicka 2012-11-21 17:56:04 UTC --- Too bad, we really need to make some model on how many PHI copies we introduce... I agree with Richard's comment that Joern's patch is rather bad in respect to optimization oppurtunities. This is more or less register pressure problem. I will try think about it a bit more ;)
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785 --- Comment #36 from Jorn Wolfgang Rennecke 2012-11-21 17:59:10 UTC --- (In reply to comment #35) > Too bad, we really need to make some model on how many PHI copies we > introduce... I agree with Richard's comment that Joern's patch is rather bad > in > respect to optimization oppurtunities. This is more or less register > pressure > problem. I will try think about it a bit more ;) This is not just register pressure, these constant loads and register-register copies do not come free, either.
[Bug c++/450] global variable treated as a local variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=450 --- Comment #3 from Tyheem Backer 2012-11-21 18:40:08 UTC --- Created attachment 28756 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28756 1
[Bug fortran/55427] [OOP] ICE with class-array-pointer result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55427 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2012-11-21 18:44:45 UTC --- For trans-expr.c:6350 in gfc_trans_pointer_assignment: 6349 gfc_add_modify (&block, lse.expr, 6350 fold_convert (TREE_TYPE (lse.expr), rse.expr)); TREE_TYPE(LHS) is:
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #4 from rsandifo at gcc dot gnu.org 2012-11-21 18:56:23 UTC --- Please provide preprocessed source
[Bug c++/450] global variable treated as a local variable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=450 Jonathan Wakely changed: What|Removed |Added Attachment #28756|0 |1 is obsolete|| Attachment #28756|application/xml |text/plain mime type|| Attachment #28756|1 |[spam] description|| --- Comment #4 from Jonathan Wakely 2012-11-21 19:07:11 UTC --- Comment on attachment 28756 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28756 [spam] [deleted spam attachment]
[Bug c/55420] Gcc produces an internal compiler error (nested function with variably modified return)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55420 --- Comment #2 from Mikael Pettersson 2012-11-21 20:20:43 UTC --- FWIW, the ICE was cured for 4.7 by Joseph Myer's "Don't use pending_sizes list for C" patch in r173422: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00319.html http://gcc.gnu.org/ml/gcc-cvs/2011-05/msg00197.html
[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 --- Comment #6 from hjl at gcc dot gnu.org 2012-11-21 20:21:02 UTC --- Author: hjl Date: Wed Nov 21 20:20:42 2012 New Revision: 193704 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193704 Log: Define __SANITIZE_ADDRESS__ for -fsanitize=address PR c/55397 * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Define __SANITIZE_ADDRESS__ for flag_asan. Modified: trunk/gcc/ChangeLog trunk/gcc/cppbuiltin.c
[Bug rtl-optimization/55396] -O2 -m32 -fno-omit-frame-pointer: internal compiler error: in check_rtl, at lra.c:2007
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55396 Sebastian Andrzej Siewior changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Sebastian Andrzej Siewior 2012-11-21 20:24:54 UTC --- (In reply to comment #2) > Author: vmakarov > Date: Tue Nov 20 21:32:59 2012 > New Revision: 193678 yup, that works. Thanks. Sebastian
[Bug c/55397] [asan] -faddress-sanitizer should define a CPP macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from H.J. Lu 2012-11-21 20:28:52 UTC --- Fixed.
[Bug libgomp/55411] OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55411 --- Comment #5 from Jakub Jelinek 2012-11-21 20:29:28 UTC --- Author: jakub Date: Wed Nov 21 20:29:14 2012 New Revision: 193706 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193706 Log: PR libgomp/55411 * team.c (gomp_free_thread): Decrease gomp_managed_threads if pool had any threads_used. Modified: trunk/libgomp/ChangeLog trunk/libgomp/team.c
[Bug libgomp/55411] OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55411 --- Comment #6 from Jakub Jelinek 2012-11-21 20:31:43 UTC --- Author: jakub Date: Wed Nov 21 20:31:31 2012 New Revision: 193707 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193707 Log: PR libgomp/55411 * team.c (gomp_free_thread): Decrease gomp_managed_threads if pool had any threads_used. Modified: branches/gcc-4_7-branch/libgomp/ChangeLog branches/gcc-4_7-branch/libgomp/team.c
[Bug c++/55425] constexpr does not work in many situations (both built-in and user supplied literals)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55425 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #5 from Marc Glisse 2012-11-21 20:52:13 UTC --- (In reply to comment #2) > (In reply to comment #1) > > No, the error says __m128 is not a literal type, which I assume is true. > > Changing that would be an enhancement request. > > With G++ 4.8 __m128i is a literal type, so this example works. PR 53094 shows that many other vector things don't work with constexpr though.
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #5 from Mikael Pettersson 2012-11-21 21:00:00 UTC --- Created attachment 28757 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28757 preprocessed libstdc++-v3/libsupc++/dyncast.cc Full configuration options: /mnt/scratch/gcc-4.8-r193687/configure --prefix=/mnt/scratch/install48 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.0.5 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.1 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.1 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++ --build=sparc-unknown-linux --target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all --disable-libsanitizer
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #6 from Mikael Pettersson 2012-11-21 21:09:34 UTC --- Oh, I uploaded dyncast.i because that was the most recent ICE on my screen just now. It ICEs with the same message as class_type_info.cc so it should be Ok as a test case. Sorry about the confusion.
[Bug pch/55399] pch tests fail on mips-mti-linux-gnu target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55399 --- Comment #6 from Steve Ellcey 2012-11-21 21:28:41 UTC --- Author: sje Date: Wed Nov 21 21:28:30 2012 New Revision: 193709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193709 Log: 2012-11-21 Steve Ellcey PR pch/55399 * files.c (pch_open_file): Fix check for implicit_preinclude. Modified: trunk/libcpp/ChangeLog trunk/libcpp/files.c
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 --- Comment #17 from Larry Baker 2012-11-21 21:37:26 UTC --- Jonathan, Yes, I should have said "link with a C++ driver" instead of "link with a C++ compiler". >No, it's not equivalent, -static-libstdcxx does not imply -lstdc++, > which is why you get missing symbols. -static-libstdcxx has nothing to do with why I get the missing symbols. I get the missing symbols because the LINKER changed from $(CC) to $(CXX). >Why not just use the Sourcery configuration that works? Why change the LINKER for a C++ program from $(CXX) to $(CC)? That is what causes the link to fail. The g++ driver may have any number of built-in ld options that differ from the gcc driver. Why should I care? The point of using the g++ driver for a C++ program is that it takes care of all that for me. If I get everything working for my cross compiler without using --with-host-libstdcxx, then the LINKER is $(CXX), which implies -lstdc++. Now, suppose I want to eliminate the dependencies of my cross compiler on the libc and llibc++ shared libraries that happen to be on my Linux system, so that my cross compiler will run on many Linux systems with possibly different libc's and libc++'s. In that case, I do not want to select different library (e.g., a debug variant), I want to select the .a variant in place of the .so variant. If I were writing my own link command, I would use g++ to do the linking with the options "-static-libgcc -static-libstdc++". So, how to do the same when building a GCC cross compiler? The GCC installation notes, http://gcc.gnu.org/install/configure.html, offer only one method to add linker options to build GCC: --with-host-libstdcxx. The example given there is `-Wl,-Bstatic,-lstdc++,-Bdynamic -lm', which is equivalent to g++ -static-libstdc++ (plus -lm, which I have no idea why it is there). (As far as I can tell, Sourcery copied this example verbatim, including the unnecessary -lm.) This example was likely written before the g++ -static-libstdc++ options existed, and certainly was written before the GCC implementation language was changed from C to C++. What is not mentioned is the side effect that the LINKER will change from $(CXX) to ($CC). >To allow fine-tuning the libs, you need the >additional libs to not be used, which implies not linking with g++. Then they should specify CXX=gcc (since there is no way to specify the LINKER directly). All this will be moot, I think, when others start bumping into GCC builds that fail as more of GCC is implemented in C++.
[Bug pch/55399] pch tests fail on mips-mti-linux-gnu target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55399 Steve Ellcey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Steve Ellcey 2012-11-21 21:41:49 UTC --- Patch for this has been checked in.
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795 --- Comment #14 from Markus Trippelsdorf 2012-11-21 21:52:26 UTC --- LTO gets miscompiled. If I configure with: ~/gcc/configure --disable-bootstrap --disable-werror --disable-multilib --enable-languages=c,c++ --enable-checking=yes,valgrind and build with gcc-4.7, then the bad memory access in LTO vanishes. This could be a dup of Bug 55430 (LRA miscompilation issue).
[Bug c/55422] gcc does not diagnose change of linkage for a function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422 --- Comment #4 from cookevillain at yahoo dot com 2012-11-21 21:53:48 UTC --- (In reply to comment #3) > Looks like the first example is just an undefined behavior in which case GCC > isn't obliged to issue an error. Quite true. I just thought that the diagnostic should be consistent. In addition, it is rare to use extern at block scope but a function declaration is automatically `extern'ed in such case so this linkage inconsistency is even harder to spot without a diagnostic when the inner `extern' is omitted.
[Bug c++/55432] New: Too much constexpr makes the compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432
Bug #: 55432
Summary: Too much constexpr makes the compiler crash
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akrze...@gmail.com
The following short code crashes the compiler:
struct tag_t{} tag{};
constexpr tag_t const& pass(tag_t & t)
{
return t;
}
struct S
{
constexpr S(tag_t) {};
};
struct T
{
S mem;
T( tag_t & args ) : mem(pass(args)) {}
};
T t(tag);
int main() {}
[Bug c++/55432] Too much constexpr makes the compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55432 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-11-21 22:08:55 UTC --- This seems to be fixed in 4.8.0 HEAD
[Bug fortran/55352] [4.7/4.8 Regression] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 --- Comment #8 from janus at gcc dot gnu.org 2012-11-21 22:20:05 UTC --- Author: janus Date: Wed Nov 21 22:19:51 2012 New Revision: 193711 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193711 Log: 2012-11-21 Janus Weil PR fortran/55352 * trans-decl.c (generate_local_decl): Don't warn for explicitly imported but unused module variables which are in a namelist or common block. 2012-11-21 Janus Weil PR fortran/55352 * gfortran.dg/namelist_76.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_76.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55414] spec2006 416.gamess compilation fails on LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55414 --- Comment #1 from Vladimir Makarov 2012-11-21 22:22:32 UTC --- Author: vmakarov Date: Wed Nov 21 22:22:11 2012 New Revision: 193712 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193712 Log: 2012-11-21 Vladimir Makarov PR rtl-optimization/55414 * lra-constraints.c (Index): New function. (lra_constraints): Check dead equiv init insns. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug testsuite/55429] new UNRESOLVED: 20_util/enable_shared_from_this/cons/constexpr.cc scan-assembler on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55429 Dominique d'Humieres changed: What|Removed |Added Target|x86_64-apple-darwin12 |*-apple-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-21 Component|libstdc++ |testsuite Host|x86_64-apple-darwin12 |*-apple-darwin* Ever Confirmed|0 |1 Build|x86_64-apple-darwin12 |*-apple-darwin* --- Comment #3 from Dominique d'Humieres 2012-11-21 22:31:46 UTC --- > Do you mean at exactly r193675 or at some point prior to that? This appeared between revisions 193417 (OK) and 193542 (UNRESOLVED) for serial testing. I don't see it if I do a parallel testing (-j2). > obviously not a libstdc++ bug in any case I agree and I changed the component to testsuite. What it is strange is that 26_numerics/complex/abi_tag.cc is supposed to scan assembler (abi_tag.s), but look at 20_util/enable_shared_from_this/cons/constexpr.cc. Is there people around running the testsuite serially on non-darwin platform?
[Bug target/55433] New: [4.8 Regression] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433
Bug #: 55433
Summary: [4.8 Regression] ICE on excessive reloads
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: phhargr...@lbl.gov
CC: g...@intrepid.com, ne...@intrepid.com
The 9-line stand-alone test case at the end of this report fails as show below
on MacOS (at least versions 10.6 and 10.8) on x86-64 machines when targeting
the ILP32 ABI. It notably does NOT fail on Linux/x86-64.
This was seen in SVN r193679 (on MacOSX 10.6) and r193709 (on MacOSX 10.8).
--cut--
$ gcc -m32 -O1 -fpreprocessed -c testcase.c
testcase.c: In function 'test':
testcase.c:10:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)
}
^
testcase.c:9:1: internal compiler error: Abort trap
gcc: internal compiler error: Abort trap (program cc1)
Abort trap
--cut--
Note that while the error message is the same as bug 55247, I have confirmed
that the test case attached to that bug report has NOT regressed. Therefore, I
believe this is a different bug (though possibly related).
Some additional data:
+ -m32 is required (no bug seen w/ -m64)
+ Linux host is fine (w/ -m32 and -m64)
+ -O1 is sufficient, but -O2 and -O3 fail in the same manner
+ removing "unsigned" from the typedef eliminates the problem
+ adding -mno-sse to the command line eliminates the problem
The testcase:
typedef unsigned long long tick_t; // NOTE: no bug if "unsigned" is removed
extern int foo(void);
extern tick_t tick(void);
double test(void) {
struct { tick_t ticks; } st;
st.ticks = tick();
foo(); // NOTE: no bug if this call is removed
return (double)st.ticks;
}
[Bug target/55433] [4.8 Regression] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433 --- Comment #1 from Paul H. Hargrove 2012-11-21 22:48:05 UTC --- Minor correction: The line or error output in the Description that reads testcase.c:10:1: internal compiler error: [...] should instead read testcase.c:9:1: internal compiler error: [...] [line number off-by-one due to "pilot error" when entering the report]
[Bug bootstrap/55388] [4.8 regression] ICE in int_mode_for_mode at stor-layout.c:423 breaks sparc64-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55388 --- Comment #7 from rsandifo at gcc dot gnu.org 2012-11-21 23:28:47 UTC --- (In reply to comment #5) > Created attachment 28757 [details] > preprocessed libstdc++-v3/libsupc++/dyncast.cc > > Full configuration options: > /mnt/scratch/gcc-4.8-r193687/configure --prefix=/mnt/scratch/install48 > --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.0.5 > --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.1 > --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.1 --enable-multilib > --disable-plugin --disable-lto --disable-nls --enable-threads=posix > --enable-checking=release --disable-libmudflap --enable-languages=c,c++ > --build=sparc-unknown-linux --target=sparc-unknown-linux --with-cpu=ultrasparc > --enable-targets=all --disable-libsanitizer Thanks. After trying and failing to convince it to fail in cross environment, it finally dawned on me that the failure was during stage 2, so presumably this is a miscompile of cc1plus. Sorry for the runaround. I'll try to reproduce the failure on gcc62, but I'm guessing it will take a while to reach the failure point.
[Bug c++/55434] New: const array with elements initialized by constructor marked non-const in debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55434
Bug #: 55434
Summary: const array with elements initialized by constructor
marked non-const in debug info
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t56xjcu...@snkmail.com
Created attachment 28758
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28758
C++ source file
In this code:
struct s
{
int i1, i2;
};
const s c1 = { 1, 2 };
const s ca1[] = { { 1, 2} };
const s c2 = c1;
const s ca2[] = { c1 };
int main(void)
{
return 0;
}
gdb sees all variables as const except for ca2:
(gdb) ptype ca1
type = const struct s {
int i1;
int i2;
} [1]
(gdb) ptype ca2
type = struct s {
int i1;
int i2;
} [1]
The problem seems to be in split_nonconstant_init() in cp/typeck2.c; when
TREE_READONLY (dest) is set to zero, the information that it was ever read-only
is lost before the DWARF record is written.
The following patch seems to fix the problem. I would not be surprised if
there were a more elegant way of doing this.
(You might be wondering: How did I find this, and why do I care? I've been
working on something to read object files and then flag variables that raise
thread-safety issues because they are (1) global or static and (2) not const.
Reading DWARF records works really well, except for this particular problem.)
Index: gcc/cp/typeck2.c
===
--- gcc/cp/typeck2.c(revision 193640)
+++ gcc/cp/typeck2.c(working copy)
@@ -633,6 +633,7 @@
init = NULL_TREE;
code = pop_stmt_list (code);
DECL_INITIAL (dest) = init;
+ TREE_WASREADONLY (dest) = TREE_READONLY (dest);
TREE_READONLY (dest) = 0;
}
else
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c(revision 193640)
+++ gcc/dwarf2out.c(working copy)
@@ -18031,7 +18031,9 @@
if (decl_by_reference_p (decl_or_origin))
add_type_attribute (var_die, TREE_TYPE (type), 0, 0, context_die);
else
-add_type_attribute (var_die, type, TREE_READONLY (decl_or_origin),
+add_type_attribute (var_die, type,
+TREE_READONLY (decl_or_origin) ||
+TREE_WASREADONLY (decl_or_origin),
TREE_THIS_VOLATILE (decl_or_origin), context_die);
}
Index: gcc/tree.h
===
--- gcc/tree.h(revision 193640)
+++ gcc/tree.h(working copy)
@@ -464,8 +464,9 @@
unsigned packed_flag : 1;
unsigned user_align : 1;
unsigned nameless_flag : 1;
+ unsigned wasreadonly_flag : 1;
- unsigned spare : 12;
+ unsigned spare : 11;
/* This field is only used with type nodes; the only reason it is present
in tree_base instead of tree_type is to save space. The size of the
@@ -1344,6 +1345,7 @@
Nonzero in a FUNCTION_DECL means this function should be treated
as "const" function (can only read its arguments). */
#define TREE_READONLY(NODE) (NON_TYPE_CHECK (NODE)->base.readonly_flag)
+#define TREE_WASREADONLY(NODE) (NON_TYPE_CHECK (NODE)->base.wasreadonly_flag)
/* Value of expression is constant. Always on in all ..._CST nodes. May
also appear in an expression or decl where the value is constant. */
[Bug c++/55434] const array with elements initialized by constructor marked non-const in debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55434 --- Comment #1 from Louis Krupp 2012-11-22 00:37:04 UTC --- Created attachment 28759 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28759 Proposed patch I wouldn't describe this as elegant, but it seems to work.
[Bug c++/55434] const array with elements initialized by constructor marked non-const in debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55434 --- Comment #2 from Louis Krupp 2012-11-22 00:40:49 UTC --- g++ -v output from a version known to have this problem: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #18 from Ian Lance Taylor 2012-11-22 00:50:46 UTC --- You can also add linker options via the configure options --with-stage1-ldflags and --with-boot-ldflags, q.v. Although it is not documented specifically for GCC, you can also set LDFLAGS when running make, as you can for all GNU programs.
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #3 from John David Anglin 2012-11-22 03:13:32 UTC --- In expand_expr_real: (gdb) p debug_rtx (orig_op0) (mem/c:BLK (plus:SI (reg/f:SI 91 virtual-stack-vars) (const_int 48 [0x30])) [6 v+0 S16 A64]) $25 = 10 (gdb) p debug_rtx (op0) (mem/c:BLK (plus:SI (reg/f:SI 91 virtual-stack-vars) (const_int 48 [0x30])) [6 v+0 S16 A64]) $26 = 10 (gdb) p mode1 $27 = TFmode (gdb) p must_force_mem $28 = 1 (gdb) p offset $29 = (tree) 0x0 (gdb) p mode2 $30 = BLKmode (gdb) p bitpos $31 = 0 (gdb) p bitsize $32 = 128 (gdb) p modifier $41 = EXPAND_MEMORY (gdb) p target $42 = (rtx) 0x0 (gdb) p ext_mode $43 = TFmode (gdb) bt #0 _Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_ (exp=0x7af2d2a0, target=0x0, tmode=VOIDmode, modifier=EXPAND_MEMORY, alt_rtl=0x0) at ../../gcc/gcc/expr.c:10006 #1 0x0045c3b8 in _Z16expand_expr_realP9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_ (exp=0x7af2d2a0, target=0x0, tmode=VOIDmode, modifier=EXPAND_MEMORY, alt_rtl=0x0) at ../../gcc/gcc/expr.c:7816 #2 0x0092f538 in _ZL11expand_exprP9tree_nodeP7rtx_def12machine_mode15expand_modifier (exp=0x7af2d2a0, target=0x0, mode=VOIDmode, modifier=EXPAND_MEMORY) at ../../gcc/gcc/expr.h:444 #3 0x00933588 in _ZL19expand_asm_operandsP9tree_nodeS0_S0_S0_S0_ij ( string=0x7af6cf78, outputs=0x0, inputs=0x7af2e288, clobbers=0x0, labels=0x0, vol=1, locus=2147483912) at ../../gcc/gcc/stmt.c:890 #4 0x00934698 in _Z15expand_asm_stmtP18gimple_statement_d (stmt=0x7af3c7e0) at ../../gcc/gcc/stmt.c:1153 #5 0x0028ad94 in _ZL20expand_gimple_stmt_1P18gimple_statement_d ( stmt=0x7af3c7e0) at ../../gcc/gcc/cfgexpand.c:2150 #6 0x0028b554 in _ZL18expand_gimple_stmtP18gimple_statement_d ( stmt=0x7af3c7e0) at ../../gcc/gcc/cfgexpand.c:2305 #7 0x00292b8c in _ZL25expand_gimple_basic_blockP15basic_block_defb ( bb=0x7af42b00, disable_tail_calls=false) at ../../gcc/gcc/cfgexpand.c:4084 #8 0x00294ecc in gimple_expand_cfg() () at ../../gcc/gcc/cfgexpand.c:4603 #9 0x007ddd44 in _Z16execute_one_passP8opt_pass ( pass=0x40033b20 ) at ../../gcc/gcc/passes.c:2327 ---Type to continue, or q to quit--- #10 0x007de108 in _Z17execute_pass_listP8opt_pass ( pass=0x40033b20 ) at ../../gcc/gcc/passes.c:2387 #11 0x002d6130 in _ZL15expand_functionP11cgraph_node (node=0x7aed22a0) at ../../gcc/gcc/cgraphunit.c:1641 #12 0x002d6718 in _ZL20expand_all_functionsv () at ../../gcc/gcc/cgraphunit.c:1745 #13 0x002d7734 in _Z7compilev () at ../../gcc/gcc/cgraphunit.c:2043 #14 0x002d79ac in finalize_compilation_unit() () at ../../gcc/gcc/cgraphunit.c:2120 #15 0x00079300 in _Z27c_write_global_declarationsv () at ../../gcc/gcc/c/c-decl.c:10120 #16 0x00957404 in _ZL12compile_filev () at ../../gcc/gcc/toplev.c:559 #17 0x0095abbc in _ZL10do_compilev () at ../../gcc/gcc/toplev.c:1881 #18 0x0095aed0 in _Z11toplev_mainiPPc (argc=14, argv=0x7eff052c) at ../../gcc/gcc/toplev.c:1957 #19 0x00dc62c4 in main (argc=14, argv=0x7eff052c) at ../../gcc/gcc/main.c:36 (gdb) c Continuing. Breakpoint 9, _Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_ (exp=0x7af2d2a0, target=0x0, tmode=VOIDmode, modifier=EXPAND_MEMORY, alt_rtl=0x0) at ../../gcc/gcc/expr.c:10011 10011if (TREE_CODE (type) == RECORD_TYPE && BYTES_BIG_ENDIAN (gdb) p debug_rtx (op0) (reg:TF 767) $44 = 10 Think the problem is this asm operand is being treated as bitfield.
[Bug other/55435] New: [asan] implement an attribute to disable asan instrumentation for a particular function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55435 Bug #: 55435 Summary: [asan] implement an attribute to disable asan instrumentation for a particular function Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dnovi...@google.com, dseke...@redhat.com, dvyu...@google.com, hjl.to...@gmail.com, ja...@redhat.com, w...@gcc.gnu.org The clang implementation of asan has __attribute__((no_address_safety_analysis)): (http://clang.llvm.org/docs/AddressSanitizer.html#no_address_safety_analysis) Some code should not be instrumented by AddressSanitizer. One may use the function attribute no_address_safety_analysis to disable instrumentation of a particular function. This attribute may not be supported by other compilers, so we suggest to use it together with __has_feature(address_sanitizer). Note: currently, this attribute will be lost if the function is inlined. The gcc implementation needs a similar attribute (preferably, with the same syntax and semantics) One example where this attribute is used: V8 stack profiler which touches random bytes on the stack.
