[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #12 from Zhendong Su ---
(In reply to Jeffrey A. Law from comment #11)
> I know what's happening here. It's obscure and quite nasty.
>
> We have a jump threading opportunity which requires threading through a
> joiner block. The jump thread leaving one edge of the joiner eventually
> reaches the same block as the joiner's other outgoing edge.
>
> This is all fine and good as the threading code knows the conditions under
> which it's still safe to thread that jump. Specifically it has to look at
> the PHI arguments for the two key edges and verify for each PHI that the
> values associated with the two key edges are the same. This condition is in
> place to make the SSA graph updates easier to deal with.
>
> At the time we discover and register the jump thread the condition holds and
> we're good to go. However a short time later we discover that we can
> propagate a constant to one of those PHI arguments and do so. Now the
> condition we needed for updating the SSA graph was broken. We update the
> SSA graph incorrectly.
>
> I'm going to have to review the SSA graph updating code a bit tomorrow AM.
> In the mean time I'm going to revert the patch.
Jeff, I have another related testcase that only fails for the 32-bit mode (also
at -Os and above). It is a lot more complex, and the root cause is likely the
same as this one. In case it may be of some use to you (at least for testing
your fix), I'm including it below. The body of the conditional, which is not
executed, has an UB (accessing an initialized value: m[0]), which may explain
the difference in -m32 and -m64.
Also btw everyone, does this mean that the whole testcase has UB (thus invalid)
even if the body of the if isn't executed at runtime at all? I'm a bit unclear
on this, so any clarifications would be much appreciated.
--
int printf(const char *, ...);
int a = -1, b = 1, f, **e;
static int c;
int *volatile d;
static void
foo (int p)
{
int g, h, *i, *j = 0, k = g = a == 0 ? 0 : -a;
if (p >= g)
{
int l, n = 0, s = 0, m[7], o[42];
int ***p = 0, q = &p, *r = &l, *v = &h;
int **t[3] = { &i, &r, &j };
int *u[3] = { &n, &k, &s };
e = &v;
i = &o[0];
d && *q;
f = m[0];
b = 0;
}
}
int main ()
{
int x = 0, *y[1] = {&x};
foo (c);
printf ("%d\n", b);
return 0;
}
[Bug c/58409] New: wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409
Bug ID: 58409
Summary: wrong reordering of volatile writes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: francesco.zappa.nardelli at gmail dot com
In the program below, at least according to the C11 standard, there is a
sequence point between the volatile store to g_3[0][0][0] and the volatile
store to *g_6 (that is, to the volatile int g_5). As a consequence, the store
to g_3 should be performed before the store to g_5.
struct {
volatile int f1;
} g_1, *g_2 = &g_1, g_3[1][1][1], **g_4 = &g_2;
volatile int g_5;
static volatile int *g_6 = &g_5;
int func_2 () {
g_3[0][0][0] = **g_4;
return 0;
}
int func_1 () {
*g_6 = func_2 ();
return 0;
}
void main () {
func_1 ();
}
If the program is compiled with a recent svn trunk
$ gcc -v
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-svn/configure --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
gcc version 4.9.0 20130912 (experimental) (GCC)
at optimisation level -O2 or -O3 then the generated assembler swaps the store
to g_5 with the store to g_3:
main:
movqg_4(%rip), %rax
movq(%rax), %rax
movl(%rax), %eax
movl$0, g_5(%rip)
movl%eax, g_3(%rip)
ret
As far as I can tell, this reordering should be considered as a compiler bug.
The same happens with gcc 4.8.1.
[Bug c/58409] wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409 --- Comment #1 from Andrew Pinski --- Does: g_3[0][0][0].f1 = (**g_4).f1; Fix the issue if so it is a dup of bug 47409 really.
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 --- Comment #2 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Fri Sep 13 07:51:07 2013 New Revision: 202557 URL: http://gcc.gnu.org/viewcvs?rev=202557&root=gcc&view=rev Log: 2013-09-13 Christian Bruel PR target/58314 * config/sh/sh.md (mov_reg_reg): Allow memory reloads. Added: trunk/gcc/testsuite/gcc.target/sh/torture/pr58314.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Matt Clarkson changed:
What|Removed |Added
CC||mattyclarkson at gmail dot com
--- Comment #12 from Matt Clarkson ---
Did that patch resolve this bug? I'm using MinGW-builds-4.8.1-x64-posix-seh
and building a project and ended up with the following error:
value.hpp:33:31: error: external linkage required for symbol
'_ZTIN3udp8keystone6binary9arguments5ValueIZNS1_4Main17GetParsedArgumentERKSsE5DummyEE'
because of 'dllexport' attribute class UDP_KEYSTONE_DLL_PUBLIC Value final :
public ValueBase {
Which translates to missing 'dllexport' attribute on 'typeinfo for
udp::keystone::binary::arguments::Value'
But both my Value class and ValueBase classes are marked with
'UDP_KEYSTONE_DLL_PUBLIC' that expands to '__attribute__((dllexport))'
If this is a similar bug and not my error (which I presume it is) I will
resolve a test delta.
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068 --- Comment #13 from Matt Clarkson --- Created attachment 30814 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30814&action=edit missing dllexport on typeinfo output Added an attachment for the full compiler output.
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 --- Comment #3 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Fri Sep 13 08:38:22 2013 New Revision: 202559 URL: http://gcc.gnu.org/viewcvs?rev=202559&root=gcc&view=rev Log: 2013-09-13 Christian Bruel PR target/58314 * config/sh/sh.md (mov_reg_reg): Allow memory reloads. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/sh/torture/pr58314.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sh.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/58314] SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from chrbr at gcc dot gnu.org --- Fixed for 4.8 and 4.9 branches
[Bug fortran/58410] Bogus uninitialized variable warning for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 --- Comment #1 from Vladimir Fuka --- Created attachment 30815 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30815&action=edit uninit.f90
[Bug fortran/58410] New: Bogus uninitialized variable warning for allocatable derived type array function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58410 Bug ID: 58410 Summary: Bogus uninitialized variable warning for allocatable derived type array function result Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com gfortran -c -Wall -O2 uninit.f90 uninit.f90: In function ‘sub’: uninit.f90:22:0: warning: ‘new.dim[0].ubound’ may be used uninitialized in this function [-Wmaybe-uninitialized] new = fun() ^ gfortran -c -Wall -O1 uninit.f90 without warning gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-20130509/configure --enable-languages=c,c++,fortran --with-cloog --prefix=/usr/local/gcc-4.8 Thread model: posix gcc version 4.8.1 20130509 (prerelease) (GCC)
[Bug sanitizer/58411] New: no_sanitize_undefined function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411 Bug ID: 58411 Summary: no_sanitize_undefined function attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jan.sm...@alcatel-lucent.com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Request for a no_sanitize_undefined attribute
[Bug sanitizer/58411] no_sanitize_undefined function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug c/58409] wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409 --- Comment #2 from Francesco Zappa Nardelli --- Yes, it does fix the issue. So this reordering is another effect of gcc not considering accessing volatile fields in non-volatile structs as volatile access (as in bug 47409). Can I ask about gcc plans for bug 47409? It has been opened for a couple of years without a clear decision at the end.
[Bug c++/58412] New: C++11 : numeric_limits::stuff must be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412
Bug ID: 58412
Summary: C++11 : numeric_limits::stuff must be constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pierreblavy at yahoo dot fr
Hello,
numeric_limits::stuff must be constexpr, as required by the C++11 standard
see the C++11 section in
http://www.cplusplus.com/reference/limits/numeric_limits/
Such behaviour is required to use this values as static const variables, or as
default variables for functions.
e.g.
struct A{
static constexpr double NaN=std::numeric_limits::quiet_NaN;
f(double d=NaN){};
};
[Bug c++/58412] C++11 : numeric_limits::stuff must be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412 --- Comment #1 from Marc Glisse --- It's already the case in recent versions, isn't it?
[Bug c/58409] wrong reordering of volatile writes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58409 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- Dup. *** This bug has been marked as a duplicate of bug 47409 ***
[Bug c++/58412] C++11 : numeric_limits::stuff must be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412 --- Comment #2 from Marc Glisse --- I think you forgot () after quiet_NaN and got confused by the error message.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #17 from Richard Biener --- *** Bug 58409 has been marked as a duplicate of this bug. ***
[Bug sanitizer/58413] New: ubsan constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413
Bug ID: 58413
Summary: ubsan constant folding
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
variable-sized object may not be initialized
unsigned short x[128 >> 5] = {};
initializer element is not constant
static int x = ((int)( 0x | ((31 & ((1 << (4)) - 1)) << (((15) + 6) +
4)) | ((0) << ((15) + 6)) | ((0) << (15)) ) );
(yes, auch)
unexpected size of type 'long long unsigned int:40'
uint64_t start_of_buffer = ((res.ptr.s.addr >> 7) - res.ptr.s.back) << 7;
.addr and .back are bitfield members of struct s. ptr is a pointer to an
union.
case label does not reduce to an integer constant
switch(int)
...
case (1<<1):
..
They all seem related.
Thanks!
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409
--- Comment #18 from Richard Biener ---
(In reply to Francesco Zappa Nardelli from comment #16)
> Dear all
>
> a possibly related issue. Consider
>
> struct S1 {
> long f;
> };
> volatile struct S1 g;
>
> struct S1 func_1 () {
> return g;
> }
>
> void main () {
> func_1 ();
> }
>
> This program, if compiled with a recent gcc svn:
>
> $ gcc -v
> Target: x86_64-unknown-linux-gnu
> gcc version 4.9.0 20130625 (experimental) (GCC)
>
> correctly loads the long at g.f at -O0. However the assembly generated at
> -O2:
>
> func_1:
> movqg(%rip), %rax
> ret
> main:
> rep; ret
>
> does not perform the volatile load access, which, as far as I understand, is
> incorrect.
It does starting with GCC 4.8.2 and was a bug in older GCC versions.
Richard.
> -francesco
[Bug sanitizer/58413] ubsan constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug bootstrap/58388] [4.9 Regression] LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with "internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388 Martin Jambor changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-09/msg01010.htm ||l --- Comment #5 from Martin Jambor --- I have posted a patch to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01010.html
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #19 from Francesco Zappa Nardelli --- >> does not perform the volatile load access. > It does starting with GCC 4.8.2 and was a bug in older GCC versions. I just tested my example (comment 16) against yesterday trunk gcc version 4.9.0 20130912 (experimental) (GCC) and indeed the volatile load access is no longer removed. This is a good news. However the code I reported in bug 58409, which has been marked duplicate of this bug, still exhibits the incorrect reordering of volatile accesses. It thus seems to me that either bug 58409 is not a duplicate of this one, or the fix is incomplete. -francesco
[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407 --- Comment #6 from Andrzej Krzemienski --- (In reply to Andrzej Krzemienski from comment #2) > No. Other compilers (Clang and VS 2010) do not emit such warning either. Correction: The newest version of Clang does give a warning: "definition of implicit copy constructor for 'W' is deprecated because it has a user-declared destructor [-Wdeprecated]"
[Bug c++/58412] C++11 : numeric_limits::stuff must be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58412 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Paolo Carlini --- Yeah.
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #13 from Markus Trippelsdorf --- *** Bug 58367 has been marked as a duplicate of this bug. ***
[Bug ipa/58367] [4.9 Regression] lto/pgo bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58367 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Markus Trippelsdorf --- dup *** This bug has been marked as a duplicate of bug 58387 ***
[Bug c++/58408] [C++11] __thread + trivially_constructible -> error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58408
--- Comment #1 from Jonathan Wakely ---
If you make it constexpr, which requires you to initialize the member, then it
works:
class Test {
public:
constexpr Test() = default;
Test(char *b) { }
int i = 0;
};
Clang accepts both that and your original.
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #20 from Richard Biener --- (In reply to Francesco Zappa Nardelli from comment #19) > >> does not perform the volatile load access. > > > It does starting with GCC 4.8.2 and was a bug in older GCC versions. > > I just tested my example (comment 16) against yesterday trunk > >gcc version 4.9.0 20130912 (experimental) (GCC) > > and indeed the volatile load access is no longer removed. This is a good > news. > > However the code I reported in bug 58409, which has been marked duplicate of > this bug, still exhibits the incorrect reordering of volatile accesses. It > thus seems to me that either bug 58409 is not a duplicate of this one, or > the fix is incomplete. It is a duplicate of this one because it is about a volatile struct member in a not volatile object g_3[1][1][1]. And it is about the aggregate assignment to that struct. > -francesco
[Bug bootstrap/58388] [4.9 Regression] LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with "internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388 --- Comment #6 from Martin Jambor --- Author: jamborm Date: Fri Sep 13 12:04:54 2013 New Revision: 202563 URL: http://gcc.gnu.org/viewcvs?rev=202563&root=gcc&view=rev Log: 2013-09-13 Martin Jambor PR bootstrap/58388 * ipa-prop.c (try_make_edge_direct_simple_call): Be less strict in the assert if the edge was a speculative one. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Sep 13 12:42:04 2013 New Revision: 202564 URL: http://gcc.gnu.org/viewcvs?rev=202564&root=gcc&view=rev Log: PR tree-optimization/58392 * tree-cfg.c (move_sese_region_to_fn): Rename loop variable to avoid shadowing of outer loop variable. If saved_cfun->has_simduid_loops or saved_cfun->has_force_vect_loops, replace_by_duplicate_decl simduid of loops that have it set and set dest_cfun->has_simduid_loops and/or dest_cfun->has_force_vect_loops. * omp-low.c (build_outer_var_ref): Call maybe_lookup_decl_in_outer_ctx instead of maybe_lookup_decl. * tree-inline.c (copy_loops): Change blocks_to_copy argument to id. Use id->blocks_to_copy instead of blocks_to_copy. Adjust recursive call. Copy over force_vect and copy and remap simduid. Set cfun->has_simduid_loops and/or cfun->has_force_vect_loops. (copy_cfg_body): Remove blocks_to_copy argument. Use id->blocks_to_copy instead of blocks_to_copy. Adjust copy_loops caller. Don't set cfun->has_simduid_loops and/or cfun->has_force_vect_loops here. (copy_body): Remove blocks_to_copy argument. Adjust copy_cfg_body caller. (expand_call_inline, tree_function_versioning): Adjust copy_body callers. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/tree-cfg.c trunk/gcc/tree-inline.c
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Sep 13 12:46:32 2013 New Revision: 202565 URL: http://gcc.gnu.org/viewcvs?rev=202565&root=gcc&view=rev Log: PR tree-optimization/58392 * testsuite/libgomp.c/pr58392.c: New test. Added: branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/pr58392.c Modified: branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
[Bug rtl-optimization/55342] [4.8/4.9 Regression] [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342 --- Comment #10 from Yuri Rumyantsev --- After fix rev. 202468 assembly looks slightly better but we met with another RA inefficiency which can be illustrated on the attached (t1.c) test compiled with options "-march=atom -mtune=atom -m32 -O2" that upped bound ol loop check is on register but base register for "write" is on stack: .L8: movzbl3(%esp), %edx movl%esi, %ecx cmpb%cl, %dl movl%esi, %edi cmovbe%edx, %edi .L4: movl%esi, %edx movl28(%esp), %esi <-- why write is on stack movl%edi, %ecx addl$4, 28(%esp) <-- perform write incrementation on stack subl%ecx, %edx subl%ecx, %ebx movzbl3(%esp), %ecx movb%dl, (%esi) movl%edi, %edx subl%edx, %ecx movb%bl, 1(%esi) movb%cl, 2(%esi) movl28(%esp), %esi cmpl%ebp, %eax <-- why upper bound is in register? movb%dl, -1(%esi) je.L1 .L5: movzbl(%eax), %esi leal3(%eax), %eax movzbl-2(%eax), %ebx notl%esi notl%ebx movl%esi, %edx movzbl-1(%eax), %ecx cmpb%bl, %dl notl%ecx movb%cl, 3(%esp) jb.L8 movzbl3(%esp), %edx movl%ebx, %edi cmpb%bl, %dl cmovbe%edx, %edi jmp.L4 Is it something wrong in ATOM cost model? But anyway I assume that keeping upper bound on stack is much cheeper then load base with incrementation from stack.
[Bug rtl-optimization/55342] [4.8/4.9 Regression] [LRA,x86] Non-optimal code for simple loop with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55342 --- Comment #11 from Yuri Rumyantsev --- Created attachment 30816 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30816&action=edit test-case to reproduce t1.c must be compiled on x86 with options: -O2 -march=atom -mtune=atom -mfpmath=sse -m32
[Bug bootstrap/58388] [4.9 Regression] LTO profiledbootstrap fails in stage feedback for tree-ssa-structalias.c with "internal compiler error: in try_make_edge_direct_simple_call, at ipa-prop.c:2606"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58388 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Jambor --- Fixed.
[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58094 --- Comment #6 from Jan Hubicka --- Author: hubicka Date: Fri Sep 13 14:35:32 2013 New Revision: 202567 URL: http://gcc.gnu.org/viewcvs?rev=202567&root=gcc&view=rev Log: PR middle-end/58094 * ipa-inline.c (check_callers): New function. (check_caller_edge): Remove. (want_inline_function_to_all_callers_p): Also permit alises that are called dirrectly. (inline_to_all_callers): Terminate the walk when devirtualization introduce new calls. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug c/47409] volatile struct member bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 --- Comment #21 from Francesco Zappa Nardelli --- (In reply to Richard Biener from comment #20) > > However the code I reported in bug 58409, which has been marked duplicate of > > this bug, still exhibits the incorrect reordering of volatile accesses. It > > thus seems to me that either bug 58409 is not a duplicate of this one, or > > the fix is incomplete. > > It is a duplicate of this one because it is about a volatile struct member > in a not volatile object g_3[1][1][1]. And it is about the aggregate > assignment to that struct. Agreed. What I don't understand is the fact that the commits that led to the recent gcc svn trunk gcc version 4.9.0 20130912 (experimental) (GCC) solve the problem with the code in comment 16, but do not prevent the reordering of volatile writes described in bug 58409. As a consequence, it seems to me that gcc does not yet implement a correct semantics for accesses to volatile struct members in non volatile objects. Am I missing something or another fix is to be expected? Thanks. -francesco
[Bug libgcj/58414] New: String.format("%9d",(Long)null) returns null-pointer exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58414
Bug ID: 58414
Summary: String.format("%9d",(Long)null) returns null-pointer
exception
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
Assignee: unassigned at gcc dot gnu.org
Reporter: slatfatf at gmx dot de
Created attachment 30817
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30817&action=edit
minimal example
String.format("%9d",(Long)null) returns null pointer exception but it should
return the text " null".
GCJ Returns the following:
$ gcj --version
gcj (Ubuntu/Linaro 4.6.3-1ubuntu2) 4.6.3
$ gcj -c src/BugReport.javajmueller@calculon:~/workspace/gcjTest$ gcj
--main=BugReport -o BugReport BugReport.o
$ ./BugReport
The programm should return:
null10
but unfortunately it crashes:
Exception in thread "main" java.lang.NullPointerException
at java.util.Formatter.basicIntegralConversion(libgcj.so.12)
at java.util.Formatter.decimalConversion(libgcj.so.12)
at java.util.Formatter.format(libgcj.so.12)
at java.util.Formatter.format(libgcj.so.12)
at java.lang.String.format(libgcj.so.12)
at java.lang.String.format(libgcj.so.12)
at BugReport.main(BugReport)
Whereas OpenJDK returns:
$ /usr/lib/jvm/java-7-openjdk-amd64/bin/java -version
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
$ /usr/lib/jvm/java-7-openjdk-amd64/bin/javac BugReport.java
$ /usr/lib/jvm/java-7-openjdk-amd64/bin/java BugReport
The programm should return:
null10
but unfortunately it crashes:
null10
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #15 from Zhendong Su --- (In reply to Jeffrey A. Law from comment #14) > It's the action of executing the code with undefined behaviour which is the > trigger. ie, if you don't execute the code, then it has no effect on the > defined/undefined state of the program as a whole. > Thanks Jeff; that's what I thought. I noticed a stackoverflow discussion on this very topic: http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior Perhaps you folks could help inject some clarity to that discussion. > It's interesting that you mention undefined behaviour -- the primary > motivation behind the patch that's causing this problem is to better expose > to the analysis and optimization phases of GCC that certain paths, if > executed, result in undefined behaviour. > I see. But would it be better to inform the programmers instead? Please see this recent interesting work to appear at the upcoming SOSP conference: http://css.csail.mit.edu/stack/ "Optimization-unstable code (unstable code for short) is an emerging class of software bugs: code that is unexpectedly eliminated by compiler optimizations due to undefined behavior in the program. Unstable code is present in many systems, including the Linux kernel and the Postgres database server. The consequences of unstable code range from incorrect functionality to missing security checks. STACK is a static checker that detects unstable code in C/C++ programs. Applying STACK to widely used systems has uncovered 150+ new bugs that have been confirmed and fixed by developers." > In particular, propagating NULL pointers into PHI nodes in non-dominated > successors exposes more opportunities to identify paths which, if executed, > would dereference a NULL pointer. We want to then isolate those paths which > exhibit undefined behaviour from the rest of the code. That allows the > "real" code paths to be better optimized and the undefined behaviour paths > to be pulled out of the main instruction stream. > > The same can be done for out-of-bounds array accesses or uninitialized > variables.
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #18 from Jeffrey A. Law --- I'll also note that the plan for the isolated paths that exhibit undefined behaviour is to have them trap/abort at the statement which triggers the undefined behaviour. The original patch from 2011 actually eliminated the undefined behaviour path entirely, that's incorrect in that earlier code in the path might have observable side effects (such as a printf call). It would also make more problems with "optimization unstable code". By unconditionally trapping/aborting at the statement which triggered the undefined behaviour (say a null pointer dereference), we still get any prior observable side effects on the path and we halt the program at the point of undefined behaviour, thus avoiding the multitude of problems around "optimization unstable code".
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #14 from Jeffrey A. Law --- It's the action of executing the code with undefined behaviour which is the trigger. ie, if you don't execute the code, then it has no effect on the defined/undefined state of the program as a whole. It's interesting that you mention undefined behaviour -- the primary motivation behind the patch that's causing this problem is to better expose to the analysis and optimization phases of GCC that certain paths, if executed, result in undefined behaviour. In particular, propagating NULL pointers into PHI nodes in non-dominated successors exposes more opportunities to identify paths which, if executed, would dereference a NULL pointer. We want to then isolate those paths which exhibit undefined behaviour from the rest of the code. That allows the "real" code paths to be better optimized and the undefined behaviour paths to be pulled out of the main instruction stream. The same can be done for out-of-bounds array accesses or uninitialized variables.
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #21 from Whitequill Riclo --- The patch worked for me, but now I'm getting a new error that looks like Bug 47052 accept the proposed fix doesn't work because is says DW2 isn't suppored on 64-bit yet. I can get around this if I change "--enable-languages=c,c++" to "--enable-languages=c", but I don't really want to, cause then I don't have a c++ compiler. checking whether the /home/lfs/build.gcc1/./gcc/xgcc -shared-libgcc -B/home/lfs/build.gcc1/./gcc -nostdinc++ -L/home/lfs/build.gcc1/x86_64-w64-mingw32/libstdc++-v3/src -L/home/lfs/build.gcc1/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/tools/x86_64-w64-mingw32/lib -L/tools/mingw/lib -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/mingw/include -B/tools/x86_64-w64-mingw32/bin/ -B/tools/x86_64-w64-mingw32/lib/ -isystem /tools/x86_64-w64-mingw32/include -isystem /tools/x86_64-w64-mingw32/sys-includelinker (/home/lfs/build.gcc1/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... Win32 ld.exe checking how to hardcode library paths into programs... immediate checking for exception model to use... call frame checking for compiler with PCH support... yes checking for enabled PCH... yes checking for thread model used by GCC... single checking for atomic builtins for bool... yes checking for atomic builtins for short... yes checking for atomic builtins for int... yes checking for atomic builtins for long long... yes checking for ISO/IEC TR 24733 ... no checking for __int128... yes checking for __float128... yes checking for g++ that supports -ffunction-sections -fdata-sections... yes checking for underlying I/O to use... stdio checking for C locale to use... generic checking for std::allocator base class... new configure: "C" header strategy set to c_global checking for enabled long long specializations... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for mbstate_t... yes checking wctype.h usability... yes checking wctype.h presence... yes checking for wctype.h... yes checking for enabled wchar_t specializations... yes checking for ISO C99 support in ... yes checking tgmath.h usability... yes checking tgmath.h presence... yes checking for tgmath.h... yes checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for ISO C99 support in ... yes checking for fully enabled ISO C99 support... yes configure: Debug build flags set to -gdwarf-4 -g3 -O0 checking for additional debug build... no configure: target-libgomp not built checking for parallel mode support... no checking for extra compiler flags for building... checking for extern template support... yes checking for custom python install directory... no checking for -Werror... yes checking for gets declaration... yes checking for EOWNERDEAD... no checking for ENOTRECOVERABLE... no checking for ENOLINK... no checking for EPROTO... no checking for ENODATA... no checking for ENOSR... no checking for ENOSTR... no checking for ETIME... no checking for EBADMSG... no checking for ECANCELED... no checking for EOVERFLOW... no checking for ENOTSUP... no checking for EIDRM... no checking for ETXTBSY... no checking for ECHILD... yes checking for ENOSPC... yes checking for EPERM... yes checking for ETIMEDOUT... no checking for EWOULDBLOCK... no checking for int64_t... yes checking for int64_t as long... checking for int64_t as long long... yes checking for LFS support... yes checking sys/ioctl.h usability... no checking sys/ioctl.h presence... no checking for sys/ioctl.h... no checking sys/filio.h usability... no checking sys/filio.h presence... no checking for sys/filio.h... no checking for poll... no checking for S_ISREG or S_IFREG... S_ISREG checking sys/uio.h usability... no checking sys/uio.h presence... no checking for sys/uio.h... no checking for writev... no checking for complex.h... (cached) yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking fenv.h usability... yes checking fenv.h presence... yes checking for fenv.h... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for ISO C99 support to TR1 in ... yes checking for wchar_t ISO C99 support to TR1 in ... yes checking stdbool.h usability... yes checking stdbool.h presence... yes checking for stdbool.h... yes checking stdalign.h usability... yes checking stdalign.h presence... yes checking for stdalign.h... yes checking for the value of EOF... -1 checking for the value of SEEK_CUR... 1 checking for the value of SEEK_END... 2 checking for gettimeofday... checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #16 from Jeffrey A. Law --- The optimization came out of building additional warnings for GCC. It's safe to assume that there'll be an option to enable a warning that the compiler was able to identify and isolate a path with undefined behaviour. Sadly these paths are not uncommon and it is often exceedingly difficult to prove if the path is truly unexecutable or not. The net result is there's going to be a fair amount of noise from this warning when tested on real world code. To give you a sense of scale, there's thousands of these paths in GCC itself. I analyzed many of them. To date I haven't found a single one that was actually executable at run time -- but to prove the paths are unexecutable we have to have analysis that can span multiple compilation units and a much more powerful mechanism to replace the jump threading code. However, each of these instances certainly represents an opportunity to do some real in depth analysis and potentially improve GCC's analysis/optimization and/or restructure the source in such ways as to avoid the problematic paths. In both instances the resulting compiler is marginally faster. And, yes, if you look at something like Coverity, these are precisely the kinds of things it's warning about as well.
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-13 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/58415] New: __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
Bug ID: 58415
Summary: __sso_string_base move constructor does not null
terminate local data when moving from empty string
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mkirzinger at gmail dot com
When doing a move construct using a sso_string_base versa_string where it is
moving from an empty string, the contents of the string it is moving from are
not copied, leaving the local data uninitialized (and later calling c_str() on
it may produce invalid output).
Code that demonstrates one of the situations this problem can show up (compile
with -std=c++11):
--
#include
#include
typedef __gnu_cxx::__versa_string string;
int main(int argc, char* argv[])
{
string s1("string");
string s2("");
std::swap(s1, s2);
printf("%s%s\n", s1.c_str(), s2.c_str());
}
--
Expected output:
string
Actual output:
stringstring
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #17 from joseph at codesourcery dot com --- On Fri, 13 Sep 2013, su at cs dot ucdavis.edu wrote: > I noticed a stackoverflow discussion on this very topic: > > http://stackoverflow.com/questions/7961067/how-undefined-is-undefined-behavior > That doesn't really seem to get into the distinction that in some cases where the C standard says something is undefined, what it says is undefined is a property of an execution of a program, while in some cases it's a property of the program itself. In the case discussed there, the undefinedness is a property of an execution of the program, but in some cases (e.g. where one translation unit contains the declaration "extern int i;" and another contains "extern char i;") it's a property of the program. You need to read the C standard carefully in each case to work out which it is.
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #19 from Marc Glisse --- (In reply to Jeffrey A. Law from comment #18) > I'll also note that the plan for the isolated paths that exhibit undefined > behaviour is to have them trap/abort at the statement which triggers the > undefined behaviour. Not even a -fif-it-is-undefined-I-deserve-what-I-get option (or -fmy-program-will-not-abort which turns __builtin_abort into __builtin_unreachable)? I understand that if I try to debug a program by adding printf to check that this branch is not taken and it is taken but nothing is printed, I'll be confused. But don't we lose a large part of the benefit by only propagating the detection of undefined behavior forward (abort) and not also backward (unreachable)?
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-13 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Urgh, thanks for your report. The move constructor is wrongly setting the length "by hand" instead of using _M_set_length, per the below. I'm going to commit the fix momentarily to mainline and 4_8-branch. Thanks again. Index: include/ext/sso_string_base.h === --- include/ext/sso_string_base.h (revision 202561) +++ include/ext/sso_string_base.h (working copy) @@ -362,8 +362,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION } _M_length(__rcs._M_length()); - __rcs._M_length(0); __rcs._M_data(__rcs._M_local_data); + __rcs._M_set_length(0); } #endif
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Sep 13 18:32:42 2013 New Revision: 202574 URL: http://gcc.gnu.org/viewcvs?rev=202574&root=gcc&view=rev Log: 2013-09-13 Paolo Carlini PR libstdc++/58415 * include/ext/sso_string_base.h (__sso_string_base<>:: __sso_string_base(__sso_string_base&&)): Fix thinkos about _M_length vs _M_set_length. * testsuite/ext/vstring/cons/58415-1.cc: New. * testsuite/ext/vstring/cons/58415-2.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/ext/vstring/cons/58415-1.cc trunk/libstdc++-v3/testsuite/ext/vstring/cons/58415-2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/sso_string_base.h
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Sep 13 18:33:17 2013 New Revision: 202575 URL: http://gcc.gnu.org/viewcvs?rev=202575&root=gcc&view=rev Log: 2013-09-13 Paolo Carlini PR libstdc++/58415 * include/ext/sso_string_base.h (__sso_string_base<>:: __sso_string_base(__sso_string_base&&)): Fix thinkos about _M_length vs _M_set_length. * testsuite/ext/vstring/cons/58415-1.cc: New. * testsuite/ext/vstring/cons/58415-2.cc: Likewise. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/ext/vstring/cons/58415-1.cc branches/gcc-4_8-branch/libstdc++-v3/testsuite/ext/vstring/cons/58415-2.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/ext/sso_string_base.h
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.8.2 --- Comment #6 from Paolo Carlini --- Fixed mainline and 4.8.2.
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415 --- Comment #3 from Paolo Carlini --- Ok, thanks.
[Bug libstdc++/58415] __sso_string_base move constructor does not null terminate local data when moving from empty string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58415
--- Comment #2 from Michael Kirzinger ---
There appears to be one additional problem: if __rcs._M_is_local() is true, but
__rcs._M_length() is false, the buffer of the string being created is never
null terminated/zeroed.
Example:
--
#include
#include
#include
#include
typedef __gnu_cxx::__versa_string string;
int main()
{
char buf[sizeof(string)+1] = "stringstringstring";
string s1;
string* s2 = new (buf) string(std::move(s1));
printf("%s\n", s2->c_str());
}
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #22 from Kai Tietz --- Author: ktietz Date: Fri Sep 13 17:28:25 2013 New Revision: 202572 URL: http://gcc.gnu.org/viewcvs?rev=202572&root=gcc&view=rev Log: PR target/57848 * c-decl.c (c_builtin_function_ext_scope): Remove wrong assumption that it is never called on prexisting symbol. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Kai Tietz --- So issue concerning this bug is fixed. I close this bug.
[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909 Dean Churchill changed: What|Removed |Added CC||dc7000 at att dot com --- Comment #3 from Dean Churchill --- I am trying to apply this patch on OSX Lion (10.8.5) to gcc 4.6.2, but the diff command on OSX doesn't accept the --git option, and am not sure how to rewrite the patch for Lion. Can you help?
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #20 from Jeffrey A. Law --- I think an option to eliminate the path entire like the first iteration of the change did could be easily added later. In fact it would be fairly easy to add. Basically we'd arrange to mark the isolated path with a flag on the block. We then have a pass which looks for those flags and eliminates the edge upon which those blocks are control dependent. That's really it. That'll eliminate the condition and expose the path as unreachable. Are we leaving most of the benefit on the table without that option, maybe, maybe not. I was pleasantly surprised to see that just the isolation aspect of this work does simplify things enough to allow the main path to optimize better.
[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909 --- Comment #4 from Dominique d'Humieres --- > I am trying to apply this patch on OSX Lion (10.8.5) to gcc 4.6.2, > but the diff command on OSX doesn't accept the --git option, > and am not sure how to rewrite the patch for Lion. Can you help? If the patch applies cleanly on 4.6.2, from the source directory patch -p0 -i patch_name should work.
[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Sep 13 19:11:23 2013 New Revision: 202576 URL: http://gcc.gnu.org/viewcvs?rev=202576&root=gcc&view=rev Log: PR c++/58273 * pt.c (any_type_dependent_elements_p): Actually check for type-dependence, not value-dependence. Added: trunk/gcc/testsuite/g++.dg/template/inherit9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 --- Comment #21 from Marc Glisse --- Thanks Jeff, sounds great :-) Even if we mark that a statement is not reachable, we probably won't eliminate many functions with side-effects executed before, since (I guess) we must be able to prove that they always return normally (no longjmp or throwing an exception or going into an infinite loop or anything fancy that would avoid coming back to execute the undefined-behavior statement), and I don't know if we can prove that for more than a few builtins and inline functions (maybe more with LTO). PS: I secretly hope that one of your jump-threading improvements will magically help with PR 55860 ;-)
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #9 from Jason Merrill --- Created attachment 30818 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30818&action=edit patch Can you verify that this patch fixes the issue?
[Bug sanitizer/58413] ubsan constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413 --- Comment #2 from Marek Polacek --- A patch that hopefully fixes the integer constant expression issues posted: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01057.html
[Bug target/58416] New: Incorrect x87-based union copying code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416
Bug ID: 58416
Summary: Incorrect x87-based union copying code
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stichnot at google dot com
Created attachment 30819
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30819&action=edit
.ii file generated from nantest1.cpp
The program below produces incorrect code on x86-32 with gcc 4.6.3. (It was
also found to fail in 4.7 but succeed in 4.8.)
The problem happens when:
1. The union is initialized via its 64-bit double field
2. The union is then updated via its 64-bit integer field
3. The union is copied to another variable
When this happens, the 64-bit copy in step 3 is done via the x87 fldl/fstpl
instructions. If the 64-bit integer value in step 2 happens to be an sNaN
pattern, the fldl instruction transforms it to a qNaN pattern and the fstpl
instruction writes the wrong value.
If step 1 is omitted, the x87 instructions are not used and the code is
correct. This suggests that the optimization of using x87 for 64-bit transfers
is enabled when a use of the double field is found, whereas it should probably
only happen if a *live* use of the double field is found.
// Compile with g++ -O3 -m32
// -O[123] all exhibit the problem.
#include
#include
#include
union MyClass {
MyClass() : DoubleVal(0.0) {} // this ctor causes failure
//MyClass() : IntVal(0) {} // this ctor works correctly
int64_t IntVal;
double DoubleVal;
};
__attribute__((noinline)) void create(MyClass &dest, int64_t Val) {
MyClass MCOp;
MCOp.IntVal = Val;
dest = MCOp;
}
int main(int argc, char **argv) {
MyClass copy;
int64_t magic = 0xfff1; // happens to be sNaN
create(copy, magic); // copy is changed to qNaN
printf("magic=%llx\ncopy= %llx\n", magic, copy.IntVal);
assert(magic == copy.IntVal);
return 0;
}
$ g++ -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -O3 -m32
nantest1.cpp
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-O3' '-m32' '-shared-libgcc' '-mtune=generic' '-march=i686'
/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1plus -E -quiet -v -imultilib 32
-imultiarch i386-linux-gnu -D_GNU_SOURCE nantest1.cpp -m32 -mtune=generic
-march=i686 -Wall -Wextra -fno-strict-aliasing -fwrapv -O3 -fpch-preprocess
-fstack-protector -o nantest1.ii
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i386-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.6
/usr/include/c++/4.6/x86_64-linux-gnu/32
/usr/include/c++/4.6/backward
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-O3' '-m32' '-shared-libgcc' '-mtune=generic' '-march=i686'
/usr/lib/gcc/x86_64-linux-gnu/4.6/cc1plus -fpreprocessed nantest1.ii -quiet
-dumpbase nantest1.cpp -m32 -mtune=generic -march=i686 -auxbase nantest1 -O3
-Wall -Wextra -version -fno-strict-aliasing -fwrapv -fstack-protector -o
nantest1.s
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (x86_64-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 65b5171ac1bd7b3f07dbea6bdb24be3d
nantest1.cpp:21:5: warning
[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50909 --- Comment #5 from Dean Churchill --- That worked. thanks
[Bug c++/58417] New: Incorrect optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417
Bug ID: 58417
Summary: Incorrect optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mirzayanovmr at gmail dot com
Created attachment 30820
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30820&action=edit
Compile it with "g++ -O2 a.cpp" and run. It will output 0 instead of 10.
The following code writes 0 (but 10 is expected) with -O1 or -O2. Checked on
4.7.2 and 4.8.1 (mingw), on Fedora with g++ (GCC) 4.8.1 20130603 (Red Hat
4.8.1-1).
Command line to compile: g++ -O2 a.cpp
Code:
#include
using namespace std;
long long arr[6] = {0, 1, 2, 3, 4, 5};
int main()
{
int n = 5;
long long sum = 0, prevsum = 0;
for(int i = 1; i <= n; i++)
{
cout << "sum = " << sum << endl;
sum = (i - 1) * arr[i] - prevsum;
// cout<<"sum : "<
[Bug c/57657] [regression from 4.7] Reports incorrect cache sizes on corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657 Jorge Aparicio changed: What|Removed |Added CC||jorge.aparicio.r at gmail dot com --- Comment #1 from Jorge Aparicio --- I can confirm this gcc-4.8.1 regression on three different Intel CPUs (core i3 2nd gen, core i5 1rst gen and core i7 4th gen), but the regression actually comes from gcc-4.8.0 CONCLUSION: gcc-4.8.0 reports the correct cache sizes when -march=native is used gcc-4.8.1 always reports 1) l1 cache size = 0, 2) l1 line cache size = 0 and 3) l2 cache size = 256; when -march=native is used OBSERVATIONS: Processor 1 $ lscpu | grep 'name\|cache' Model name:Intel(R) Core(TM) i7-4702MQ CPU @ 2.20GHz L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K $ gcc 4.8.0 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 ... $ gcc 4.8.1 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 ... Processor 2 $ lscpu | grep 'name\|cache' Model name:Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K $ gcc-4.8.0 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 ... $ gcc 4.8.1 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 ... Processor 3 $ lscpu | grep 'name\|cache' Model name:Intel(R) Core(TM) i3-2330M CPU @ 2.20GHz L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 3072K $ gcc 4.8.0 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 ... $ gcc 4.8.1 -march=native -E -v - &1 | grep cc1 ... --param l1-cache-size=0 --param l1-cache-line-size=0 --param l2-cache-size=256 ... GCC version information $ gcc-4.8.1 -v Using built-in specs. COLLECT_GCC=gcc-4.8.1 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-4.8.1/configure --disable-libssp --disable-multilib --enable-version-specific-runtime-libs --enable-libmudflap --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4.8 --enable-__cxa_atexit --enable-clocale=gnu --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-ppl --disable-cloog --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-lto --with-bugurl=http://bugs.funtoo.org --with-pkgversion='Funtoo 4.8.1' --with-mpfr-include=/var/tmp/portage/sys-devel/gcc-4.8.1/work/gcc-4.8.1/mpfr/src --with-mpfr-lib=/var/tmp/portage/sys-devel/gcc-4.8.1/work/objdir/mpfr/src/.libs --enable-libstdcxx-time --enable-libgomp --enable-languages=c,c++,fortran --disable-libgcj --disable-esp Thread model: posix gcc version 4.8.1 (Funtoo 4.8.1) $ gcc-4.8.0 -v Using built-in specs. COLLECT_GCC=gcc-4.8.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-isl-version-check --with-cloog --enable-lto --disable-nls --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --disable-multilib --with-multilib-list=m64 --disable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0 p1.1, pie-0.5.5' Thread model: posix gcc version 4.8.0 (Gentoo 4.8.0 p1.1, pie-0.5.5)
[Bug c/57657] [regression from 4.7] Reports incorrect cache sizes on corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-13 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- I can't reproduce it with GCC 4.8.2 20130715 on Sandy Bridge, Ivy Bridge nor Haswell. It may be fixed by http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00243.html
[Bug target/58416] Incorrect x87-based union copying code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58416 --- Comment #1 from H.J. Lu --- This may be related to PR57484.
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Jeffrey A. Law changed:
What|Removed |Added
CC||kazu at gcc dot gnu.org,
||law at redhat dot com
--- Comment #5 from Jeffrey A. Law ---
Kazu, you added these patterns many years ago... Your thoughts would be
appreciated.
Compile the attached code with -O2 -mh -mint32 on the H8 port, using the trunk.
It'll fail due to an insn not matching its constraints problem.
The H8 port has the following insn:
(define_insn_and_split "*tstsi_variable_bit_qi"
[(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (match_operand:QI 0
"general_operand_src" "r,U,mn>"))
(const_int 1)
(and:SI (match_operand:SI 1
"register_operand" "r,r,r")
(const_int 7)))
(const_int 0)))
(clobber (match_scratch:QI 2 "=X,X,&r"))]
"TARGET_H8300H || TARGET_H8300S"
"@
btst\\t%w1,%X0
btst\\t%w1,%X0
#"
"&& reload_completed
&& !satisfies_constraint_U (operands[0])"
[(set (match_dup 2)
(match_dup 0))
(parallel [(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (match_dup 2))
(const_int 1)
(and:SI (match_dup 1)
(const_int 7)))
(const_int 0)))
(clobber (scratch:QI))])]
""
[(set_attr "length" "2,8,10")
(set_attr "cc" "set_zn,set_zn,set_zn")])
Now assume that operand 0 is initially a pseudo, something like this;
(insn 50 49 51 5 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (reg:QI 37 [ D.1545
]))
(const_int 1 [0x1])
(and:SI (reg:SI 59 [ D.1543 ])
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) j.c:36 113 {*tstsi_variable_bit_qi}
(expr_list:REG_DEAD (reg:SI 59 [ D.1543 ])
(expr_list:REG_DEAD (reg:QI 37 [ D.1545 ])
(nil
That looks fine and good. Now assume reg:37 doesn't get a hard reg. reload
will replace the reg with its equivalent stack slot resulting in:
(insn 50 116 51 5 (parallel [
(set (cc0)
(compare (zero_extract:SI (zero_extend:SI (mem/c:QI (plus:SI
(reg/f:SI 6 r6)
(const_int -17 [0xffef])) [7
%sfp+-9 S1 A8]))
(const_int 1 [0x1])
(and:SI (reg:SI 3 r3)
(const_int 7 [0x7])))
(const_int 0 [0])))
(clobber (scratch:QI))
]) j.c:36 113 {*tstsi_variable_bit_qi}
(nil))
Note that the insn no longer matches its strict constraints. It doesn't match
alternatives 0 or 1 because of operand 0. It doesn't match alternative 2
because the SCRATCH is not a REG.
I'm guessing you wanted reload to give you a scratch register that you could
use for generating code when operand0 wasn't a suitable source for a single bit
extraction. You'd then split the insn at insn output time using the scratch
register to effectively reload operand0 yourself?
Note there's another pattern tst_extzv_1_n that has potentially the same
problem.
The fundamental issue is that once reload is done, all insns must always
satisfy their constraints, no exceptions.
Thoughts on how this is supposed to work?
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #6 from Jeffrey A. Law ---
Reduced testcase:
static __inline__ __attribute__((always_inline))
__attribute__((no_instrument_function)) int test_bit(int nr, const unsigned
long* addr)
{
return (*((volatile unsigned char *)addr +
((nr >> 3) ^ 3)) & (1UL << (nr & 7))) != 0;
}
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) int test_bit_le(int nr, const void
*addr)
{
return test_bit(nr ^ ((32 -1) & ~0x7), addr);
}
typedef int ext4_grpblk_t;
struct ext4_group_info {
unsigned long bb_state;
ext4_grpblk_t bb_counters[];
};
struct ext4_buddy {
struct super_block *bd_sb;
struct ext4_group_info *bd_info;
};
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) void *mb_correct_addr_and_bit(int *bit,
void *addr)
{
*bit += ((unsigned long) addr & 3UL) << 3;
return addr;
}
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) int mb_test_bit(int bit, void *addr)
{
addr = mb_correct_addr_and_bit(&bit, addr);
return test_bit_le(bit, addr);
}
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) void mb_clear_bit(int bit, void *addr)
{
addr = mb_correct_addr_and_bit(&bit, addr);
__clear_bit_le(bit, addr);
}
static inline __attribute__((always_inline))
__attribute__((no_instrument_function)) int mb_buddy_adjust_border(int* bit,
void* bitmap, int side)
{
if (mb_test_bit(*bit + side, bitmap)) {
mb_clear_bit(*bit, bitmap);
}
}
static void mb_buddy_mark_free(struct ext4_buddy *e4b, int first)
{
int max;
int order = 1;
void *buddy = bar ();
while (buddy) {
void *buddy2;
e4b->bd_info->bb_counters[order] += mb_buddy_adjust_border(&first, buddy,
-1);
order++;
buddy = buddy2;
}
}
void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
int first, int count)
{
int last = first + count - 1;
int block;
struct super_block *sb = e4b->bd_sb;
block = foo();
if (!!(block != -1))
mb_regenerate_buddy();
mb_buddy_mark_free(e4b, first >> 1);
}
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 Ever confirmed|0 |1
[Bug c/58401] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ocfs2/dlm/dlmdomain.c: In function 'dlm_query_join_handler'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #6 from Jeffrey A. Law --- Same root cause as 58400. *** This bug has been marked as a duplicate of bug 58400 ***
[Bug c/58400] gcc for h8300 internal compiler error: insn does not satisfy its constraints at fs/ext4/mballoc.c: In function 'mb_free_blocks':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400 --- Comment #7 from Jeffrey A. Law --- *** Bug 58401 has been marked as a duplicate of this bug. ***
[Bug c/57657] [regression from 4.7] Reports incorrect cache sizes on corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57657 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #3 from H.J. Lu --- It was introduced by r199017 and fixed by r200782.
[Bug middle-end/58418] New: wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
Bug ID: 58418
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in
32-bit mode)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk produces wrong code for the attached testcase on
x86_64-linux-gnu when compiled at -O2 and -O3 in 32-bit mode.
It appears to be a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130913 (experimental) [trunk revision 202556] (GCC)
$
$ gcc-trunk -m32 -O1 small.c
$ a.out
0
$ gcc-4.8 -m32 -O2 small.c
$ a.out
0
$ gcc-trunk -m64 -O2 small.c
$ a.out
0
$ gcc-trunk -m32 -O2 small.c
$ a.out
1
$
--
int printf (const char *, ...);
int a, b, *c = &b, d = -1, e, f, *g, *h = &f, **i = &g, j;
unsigned int
foo (unsigned int p)
{
return p == 0 ? 0 : 1 / p;
}
static int *
bar ()
{
*c = *h = foo (d) & (-9 < d);
for (e = 0; e; e++)
;
return 0;
}
int
main ()
{
for (; j; j++)
for (;; a--)
;
*i = bar ();
printf ("%d\n", f);
return 0;
}
[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-09-13
CC||ccoutant at google dot com,
||jason at redhat dot com,
||law at redhat dot com
Ever confirmed|0 |1
--- Comment #6 from Jeffrey A. Law ---
Reduced testcase. Appears to be blowing up in the dwarf2 bits.
Compile with -Os -mint32 -mh -fomit-frame-pointer -g
typedef _Bool bool;
typedef unsigned short umode_t;
enum {
false = 0,
true = 1
};
struct dentry {
struct inode *d_inode;
};
struct path {
struct dentry *dentry;
};
extern int vfs_create(struct inode *, struct dentry *, umode_t, bool);
long SYSC_mknodat(int dfd, const char * filename, umode_t mode, unsigned dev)
{
struct dentry *dentry;
struct path path;
int error;
unsigned int lookup_flags = 0;
switch (mode & 0017) {
case 0: case 010:
error = vfs_create(path.dentry->d_inode,dentry,mode,true);
break;
case 002: case 006:
error = vfs_mknod(path.dentry->d_inode,dentry,mode, new_decode_dev(dev));
break;
}
}
[Bug tree-optimization/58417] Incorrect optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 Component|c++ |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Confirmed with trunk and 4.4. sccp for some reason decides that after the loop sum is 0.
[Bug middle-end/58418] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 CC||vmakarov at redhat dot com Target Milestone|--- |4.9.0 Summary|wrong code at -O2 and -O3 |[4.9 Regression] wrong code |on x86_64-linux-gnu (in |at -O2 and -O3 on |32-bit mode)|x86_64-linux-gnu (in 32-bit ||mode) Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r202468.
[Bug tree-optimization/55860] Turn segmented iteration into nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #2 from Jeffrey A. Law --- My current work won't help this PR. edge equivalences are not well handled for threading. While the edge containing the equivalence for jlk < n dominates the true arm of the condition, it does not dominate the join point where the true/else arms meet. So it's not going to be available in the expression hash table when we try to thread the true arm. dom_opt_leave_block does some work to recover edge equivalences, but only for the edge from the block we're leaving to its successor blocks. The edge equivalence is higher up in the chain. In theory we could walk up the CFG and add more stuff to the tables, which would probably help. Assuming that worked, I still doubt threading is going to be successful as we have to thread through the backedge in the CFG and we're currently very conservative with that, both in terms of recording jump threads and in terms of which jump threads we'll ultimately realize. In this particular case, threading from the true arm through the backedge will create a new, inner loop which the threading code tries really hard not to do because it doesn't know how to update all the various loop structures. We have the same problem for the FSA optimization, but in that case I'm tempted to just throw away all the loop information -- if we thread a backedge and eliminate a switch, that's huge from a performance standpoint and we can probably afford to just throw away the loop info at that point.
[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Sep 13 22:22:31 2013 New Revision: 202580 URL: http://gcc.gnu.org/viewcvs?rev=202580&root=gcc&view=rev Log: PR c++/58273 * pt.c (any_type_dependent_elements_p): Actually check for type-dependence, not value-dependence. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/inherit9.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/pt.c
[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Sep 13 22:38:42 2013 New Revision: 202583 URL: http://gcc.gnu.org/viewcvs?rev=202583&root=gcc&view=rev Log: PR c++/58273 * pt.c (any_type_dependent_elements_p): Actually check for type-dependence, not value-dependence. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/inherit9.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/58273] [4.7/4.8/4.9 Regression] Segmentation fault with C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58273 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 4.7.4/4.8.2/4.9.0.
[Bug middle-end/58419] New: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419
Bug ID: 58419
Summary: wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk mis-compiles the following code on x86_64-linux at -O3 in
32-bit mode.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130913 (experimental) [trunk revision 202556] (GCC)
$ gcc-trunk -m32 -O2 small.c
$ a.out
0
$ gcc-4.8 -m32 -O3 small.c
$ a.out
0
$ gcc-trunk -m64 -O3 small.c
$ a.out
0
$ gcc-trunk -m32 -O3 small.c
$ a.out
Segmentation fault (core dumped)
$
---
int printf(const char *, ...);
int a, g, i, k, *p;
char b, e;
short c, h;
static short *d = &c;
char
foo (int p1, int p2)
{
return p1 - p2;
}
int
bar ()
{
short *q = &c;
*q = 1;
*p = 0;
return 0;
}
int
main ()
{
for (b = -22; b >= -29; b--)
{
short *l = &h;
char *m = &e;
*l = a;
g = foo (*m = k && *d, 1 > i) || bar ();
}
printf("0\n");
return 0;
}
[Bug sanitizer/58420] New: internal compiler error: in ubsan_type_descriptor, at ubsan.c:280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420
Bug ID: 58420
Summary: internal compiler error: in ubsan_type_descriptor, at
ubsan.c:280
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
stl.46/bits/locale_facets.h:1585:46: internal compiler error: in
ubsan_type_descriptor, at ubsan.c:280
Line 1585 is '_CharT _M_atoms_out[__num_base::_S_oend];'
template
struct __numpunct_cache : public locale::facet
{
const char* _M_grouping;
size_t_M_grouping_size;
bool _M_use_grouping;
const _CharT* _M_truename;
size_t_M_truename_size;
const _CharT* _M_falsename;
size_t_M_falsename_size;
_CharT_M_decimal_point;
_CharT_M_thousands_sep;
// A list of valid numeric literals for output: in the standard
// "C" locale, this is "-+xX0123456789abcdef0123456789ABCDEF".
// This array contains the chars after having been passed
// through the current locale's ctype<_CharT>.widen().
_CharT_M_atoms_out[__num_base::_S_oend];
// A list of valid numeric literals for input: in the standard
// "C" locale, this is "-+xX0123456789abcdefABCDEF"
// This array contains the chars after having been passed
// through the current locale's ctype<_CharT>.widen().
_CharT_M_atoms_in[__num_base::_S_iend];
bool _M_allocated;
__numpunct_cache(size_t __refs = 0)
: facet(__refs), _M_grouping(0), _M_grouping_size(0),
_M_use_grouping(false),
_M_truename(0), _M_truename_size(0), _M_falsename(0),
_M_falsename_size(0), _M_decimal_point(_CharT()),
_M_thousands_sep(_CharT()), _M_allocated(false)
{ }
~__numpunct_cache();
void
_M_cache(const locale& __loc);
private:
__numpunct_cache&
operator=(const __numpunct_cache&);
explicit
__numpunct_cache(const __numpunct_cache&);
};
[Bug middle-end/58419] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-13 CC||vmakarov at redhat dot com Target Milestone|--- |4.9.0 Summary|wrong code at -O3 on|[4.9 Regression] wrong code |x86_64-linux-gnu in 32-bit |at -O3 on x86_64-linux-gnu |mode|in 32-bit mode Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r202468.
[Bug middle-end/58419] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58419 --- Comment #2 from Zhendong Su --- (In reply to H.J. Lu from comment #1) > It is caused by r202468. So it may have been a dup of 58418?
[Bug sanitizer/58420] internal compiler error: in ubsan_type_descriptor, at ubsan.c:280
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58420 --- Comment #1 from Jan Smets --- This may be because of the (not yet committed) patch for ubsan vla bounds checking. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg61427.html Probably another one for Marek Polacek. - Jan
[Bug sanitizer/58411] no_sanitize_undefined function attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58411 --- Comment #2 from Jan Smets --- Please also think of the other -fsanitize= options.
