[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #28 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #27) I (OP) suppose we can WONTFIX that one. Thanks. Well, there is a fix - which is to update /usr/lib/libgcc_s.dylib to a non-buggy version. I can give you instructions on how to achieve that (and would be willing to provide a ready-made suitable binary) - but don't have anywhere suitable to host it.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #43 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Emil Styrke from comment #42) Anyway, after manually fixing up the install it seems to work alright. If this looks like a reasonable way forward, I'd be happy to improve the patch after feedback or leave this embryo in the hands of someone more knowledgeable. I would welcome such a solution very much. From looking at the patch, it seems a relatively small amount of work for a significant benefit. I hope you get some feedbackhelp from libgomp/sanitizer experts.
[Bug tree-optimization/59903] [4.8/4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59903 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|ICE on valid code at -O3 on |[4.8/4.9 Regression] ICE on |x86_64-linux-gnu (affecting |valid code at -O3 on |trunk and 4.8.x)|x86_64-linux-gnu (affecting ||trunk and 4.8.x) --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r195609.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #29 from Denis Excoffier g...@denis-excoffier.org --- (In reply to Iain Sandoe from comment #28) Well, there is a fix - which is to update /usr/lib/libgcc_s.dylib to a non-buggy version. I had understood that it was desirable not to replace libgcc_s.dylib. Personally, i use the sed command (shown in comment #17) to create my own libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and try to always link with it (and usually succeed since i don't use any libraries that are already linked with /usr/lib/libgcc_s.dylib). For security matters, that's like replacing, however. In any case, that bug is not NEW any more.
[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-22 Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Andrey Belevantsev abel at gcc dot gnu.org --- Created attachment 31915 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31915action=edit proposed patch
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #7 from Denis Excoffier g...@denis-excoffier.org --- The bug is no longer present in GCC 4.8.2 (tested today under Cygwin 1.7.27 XP 32bits). Please someone to update the WAITING field into RESOLVED (or WORKSFORME etc.).
[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org --- Well, I guess one is responsible for what one has tamed, so reproduced now. The issue is actually simple -- we add new blocks when scheduling (they are recovery blocks for speculation insns) and for them we do not calculate DF_LIVE_IN bitmaps so we segfault when we try to read those bitmaps in the sched pressure info initialization code. I see the following possible fixes: 1) calculate liveness for the new blocks via the DF interface. Now it doesn't look like anyone is using the partial analysis interface via df_set_blocks nowadays, and the new blocks do not form a loop so df_analyze_loop Richard has added would not work. What can be done is gather the new blocks in a separate bitmap and add their preds/succs which should hopefully have the right liveness info, so partial df_analyze on those can do the trick. 2) manually calculate liveness for the new blocks. Again DF doesn't offer much for this, you'd need to df_grow_block_info for df_live and then try deriving the liveness information from the original block's successor. This will need some manual propagation through the new block as we do in the selective scheduler. 3) decide that the recovery code is supposed to be cold enough so we don't care about applying register pressure sensitive code to it, thus reset sched_pressure to SCHED_PRESSURE_NONE for all newly created regions. The patch from the previous comment does just that; we only need to free the sched-pressure data immediately at this point as we later fail to do that and ICE in IRA later. I had to factorize the finalization code in a separate function for that. The patch supports only blocks ending up in the new region, not the same region, but it looks like the current code always puts recovery blocks in the new region. Vlad, what's your opinion on this?
[Bug middle-end/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to janus from comment #0) with -O2 and -O3, while 4.8 did not do that. Probably the warning is ok, since the test case is supposed to trigger a runtime error (Index '5' of dimension 2 of array 'a' outside of expected range (4:1)). Of course the warning is correct. However, I see three possible problems: 1) The question is why it only happens with SAVE. I get the warning also without SAVE. Furthermore, the warning is not guaranteed for all undefined behaviors in the loop of course, only if the loop has known constant number of iterations, no early exits and is known to trigger selected kinds of undefined behavior in some of the iterations. 2) I don't understand why the warning has 'iteration 4'. Shouldn't iteration 5 be the problem? This is a middle-end warning, I don't see how the middle-end could find out that the frontend wants to count the iterations differently. 3) The warning appears twice. For that I have an untested fix: 2014-01-22 Jakub Jelinek ja...@redhat.com PR middle-end/59561 * cfgloopmanip.c (copy_loop_info): If loop-warned_aggressive_loop_optimizations, make sure the flag is set in target loop too. --- gcc/cfgloopmanip.c.jj2014-01-03 11:40:33.0 +0100 +++ gcc/cfgloopmanip.c2014-01-22 10:21:54.057871045 +0100 @@ -1022,6 +1022,8 @@ copy_loop_info (struct loop *loop, struc target-any_estimate = loop-any_estimate; target-nb_iterations_estimate = loop-nb_iterations_estimate; target-estimate_state = loop-estimate_state; + target-warned_aggressive_loop_optimizations +|= loop-warned_aggressive_loop_optimizations; } /* Copies copy of LOOP as subloop of TARGET loop, placing newly
[Bug c/59891] [4.7/4.8/4.9 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine for now.
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
Elias Pipping pipping at exherbo dot org changed:
What|Removed |Added
CC||pipping at exherbo dot org
--- Comment #18 from Elias Pipping pipping at exherbo dot org ---
I'm a bit confused here. Please consider the following piece of code:
SNIP
template typename T struct A {
typedef int type;
};
template typename T struct B : public AT {
using typename AT::type;
static const int block_size = type::block_size;
};
SNAP
Compiling it with gcc 4.8.2 yields
foo.hh:9:33: error: ‘type’ is not a class, namespace, or enumeration
whereas clang 3.4 will happily accept it(*).
At a first glance, this bug appears to address issues such as this, so that gcc
4.8.2 should be fine. This does not seem to be the case, however -- the test
case provided by Jim Apple compiles but the one above does not; I'll have to
assume the bug was only partly fixed?
(*) I orginally thought this was not valid and filed a clang bug:
http://llvm.org/bugs/show_bug.cgi?id=18574
[Bug tree-optimization/59903] [4.8/4.9 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59903 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #11 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31916 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31916action=edit More robust check Does this look reasonable? Should also work for cross-builds.
[Bug c++/53492] internal compiler error: in retrieve_specialization, at cp/pt.c:985
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53492 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||burrows.labs at gmail dot com --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 59901 has been marked as a duplicate of this bug. ***
[Bug c++/59901] internal compiler error: in retrieve_specialization cp/pt.c:1012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59901 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 53492 ***
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Yury Gribov from comment #11) Created attachment 31916 [details] More robust check Does this look reasonable? Should also work for cross-builds. 1) these syscalls are only needed on Linux, not on Darwin I think, so you change would disable libsanitizer on Darwin (not that I care about it) 2) I think it is undesirable to put this check into toplevel configure, I'd say the determination when to make the whole libsanitizer UNSUPPORTED should be limited to target triplet checking. I think my preference would be to test this in libsanitizer/configure* and just make even the asan etc. conditional on an automake conditional.
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org --- That example's a bit misleading, because 'int' really isn't a class, namespace or enumeration, but the error's wrong because there could be a specialization of A, and the same error is produced even if AT::type is a class type. Fabien, the fix doesn't seem to work with nested-name-specifiers, do you remember if there's another bug report about that case?
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #20 from fabien at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #19) Fabien, the fix doesn't seem to work with nested-name-specifiers, do you remember if there's another bug report about that case? Yes, it's probably PR58047.
[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Thanks Paul. You mentioned a proposed patch, are you working on that? From a quick look I didn't see how to fix it without adding a _Sp_counted_base::_M_add_ref_lock_nothrow() function and adding new constructors taking an additional std::nothrow_t argument to the whole class hierarchy. Did you have a simpler fix in mind?
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31916|0 |1 is obsolete|| --- Comment #13 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31917 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31917action=edit Second try (In reply to Jakub Jelinek from comment #12) 1) these syscalls are only needed on Linux, not on Darwin I think, so you change would disable libsanitizer on Darwin (not that I care about it) Fixed. 2) I think it is undesirable to put this check into toplevel configure I'd say the determination when to make the whole libsanitizer UNSUPPORTED should be limited to target triplet checking. I see. I think my preference would be to test this in libsanitizer/configure* and just make even the asan etc. conditional on an automake conditional. Makes sense. Something like this then?
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258
--- Comment #21 from Elias Pipping pipping at exherbo dot org ---
(In reply to Jonathan Wakely from comment #19)
That example's a bit misleading, because 'int' really isn't a class,
namespace or enumeration, but the error's wrong because there could be a
specialization of A, and the same error is produced even if AT::type is
a class type.
You're right. This will reproduce the problem, too:
SNIP
struct C;
template typename T struct A {
typedef C type;
};
template typename T struct B : public AT {
using typename AT::type;
static const int block_size = type::block_size;
};
SNAP
[Bug target/59904] New: [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 Bug ID: 59904 Summary: [ARM] tls-reload-1.c fails Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 206897 (LRA fix PR rtl-optimization/59858) I have noticed that: gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fPIE execution test gcc.dg/torture/tls/tls-reload-1.c -Os -pie -fpie execution test the compiler used to ICE, but after the LRA fix the generated code is not functional. I have tested with qemu-arm, target arm-none-linux-gnueabi, --with-mode=thumb --with-cpu=cortex-a9, using RUNTESTFLAGS=-march=armv5t gcc.log contains: qemu: uncaught target signal 6 (Aborted) - core dumped
[Bug c++/14258] typename in a using declaration not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258 --- Comment #22 from Elias Pipping pipping at exherbo dot org --- I guess my test case is a reduction/duplicate of PR37140.
[Bug target/56315] ARM: Improve use of 64-bit constants in logical operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56315 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- This is now fixed on trunk, most probably with r199527.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- I wouldn't call the conditional SYSCALL_SUPPORTED, but SANITIZER_SUPPORTED or so. In the future, the configure could have various other reasons why it should give up on building any sanitizer libraries altogether. Also, supposedly __NR_gettid could be added to the test too.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #8 from ktkachov at gcc dot gnu.org ---
arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=softfp -O2 -mthumb:
sqrlen4D_16u8:
vmovd18, r0, r1 @ v16qi
vmovd19, r2, r3
vld1.64 {d16-d17}, [sp:64]
vabd.u8 q8, q9, q8
vmull.u8q9, d16, d16
vmull.u8q8, d17, d17
vuzp.32 q9, q8
vpaddl.u16 q9, q9
vmovq10, q9 @ v4si
vpadal.u16 q10, q8
vmovr0, r1, d20 @ v4si
vmovr2, r3, d21
bx lr
With current trunk I'm getting for the softfp case:
push{lr}@ 40*push_multi [length = 2]
vmovd16, r0, r1 @ v16qi@ 37*neon_movv16qi/6[length
= 8]
vmovd17, r2, r3
add lr, sp, #4 @ 36*arm_addsi3/5 [length = 4]
vldrd18, [sp, #4] @ 3 *neon_movv16qi/4[length = 8]
vldrd19, [sp, #12]
vabd.u8 q9, q8, q9 @ 7 neon_vabdv16qi [length = 4]
vmull.u8q8, d18, d18@ 14neon_vmullv8qi [length = 4]
vmull.u8q9, d19, d19@ 16neon_vmullv8qi [length = 4]
vuzp.32 q8, q9 @ 18*neon_vuzpv4si_insn [length = 4]
vpaddl.u16 q8, q8 @ 22neon_vpaddlv8hi [length = 4]
vpadal.u16 q8, q9 @ 28neon_vpadalv8hi [length = 4]
vmovr0, r1, d16 @ v4si @ 39*neon_movv4si/5 [length = 8]
vmovr2, r3, d17
ldr pc, [sp], #4@ 45*ldr_with_return[length = 4]
The move between the vpad*s is gone, but there's a couple of redundant loads
and some register spillage.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #9 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #10 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #11 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #12 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #13 from StaffLeavers at arm dot com --- greta.yorsh no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug c/59905] New: Unfriendly abort when calling a fucntion via a function pointer cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59905
Bug ID: 59905
Summary: Unfriendly abort when calling a fucntion via a
function pointer cast
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nisse at lysator dot liu.se
Created attachment 31918
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31918action=edit
Example program
Some background:
In GNU nettle, I use function casts between function types differing in
the type of some pointer arguments. E.g.,
struct s;
int foo(struct s *);
typedef int func_t(void *);
func_t *f = (func_t *) foo;
Later on, f will be called with an argument of type void *, which
actually is a pointer to a valid struct s, but cast to void *.
I'm aware this is not strictly valid C, but I expect it to work on
virtually all C implementations, because struct s may well be an
incomplete type, and hence the calling conventions cannot reasonably
depend on it's actual definition. If it matters, I could replace void
* above by struct anything *, where struct anything is a different
incomplete type, not defined in any compilation unit ever.
(If you know any examples of architectures, supported by gcc or
otherwise, where calling conventions make this break, I'd be curious
to know about it).
And I think this style is fairly common in object oriented C code. The
closest alternatives, if one wants to stick to the C specification, is
to either skip type checking altogether, always using void * for the
function arguments, and casting when used. Or have do-nothing wrapper
functions like
int foo(struct s *);
int foo_wrapper(void *p) { return foo(p); }
This would typically compile to a single jump instruction, but I don't
think the wrapper can be eliminated completely by an optimizing C
compiler, because it is required that pointer comparison foo ==
foo_wrapper gives a false result.
And the reason I care is that I have a library with fairly a large
number of functions, which I want to let applications call either
directly, *with* strong type checking of all arguments, or call via an
abstraction using function pointers and void * instead of the real
struct type pointer, for state/context arguments.
This style seems to work fine with gcc. The surprise is when you call
a function via a cast like this, *without* first storing it a
variable. Like
struct s;
((func_t *)foo)(s);
Here, the compiler issues a warning, and replaces the call by a call
to abort(). I'm attaching a complete example program. With gcc-4.7.2,
on Debian GNU/linux x86_64, this is what happens (and it's the same
with gcc-4.4 and gcc-4.6)
$ gcc func-cast.c
func-cast.c: In function ‘main’:
func-cast.c:33:41: warning: function called through a non-compatible type
[enabled by default]
func-cast.c:33:41: note: if this code is reached, the program will abort
$ ./a.out
foo x: 1
bar x (var): 2
Illegal instruction (core dumped)
I find this behaviour a bit obnoxious... I understand you might just
say that this is bad code and gcc could emit an exec(nethack) if it
wanted to. I think the current gcc behaviour is bad, in particular as
default behavior, because
1. Generating a call to abort is generally unfriendly.
2. I expect that
f = expr; f(...);
and
(expr)(...);
should behave in roughly the same way for all possible expr, at
least as long as f and expr have the same type, so the assignment
itself doesn't imply any type conversion.
3. I think the compiler should in general treat explicit casts in the
source code as meaning I think I know what I'm doing, please don't
complain about it.
[Bug bootstrap/56645] libgcc /configure identifies non-existing /lib/cpp as preprocessor on Mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56645 Lode Leroy lode.leroy at gmail dot com changed: What|Removed |Added CC||lode.leroy at gmail dot com --- Comment #3 from Lode Leroy lode.leroy at gmail dot com --- cpp is not found by configure: which cpp returns '/mingw/bin/cpp' /lib/cpp happens to be the last one tried in libgcc/configure:3859
[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 31919
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31919action=edit
gcc49-pr59594.patch
Untested patch for discussion. The reason why we (incorrectly) vectorize the
testcase is that we ignore the data dependency, on the testcase both the b[a]
read vs. b[a+1] store and b[a] store vs. b[a+1] store DDRs have dist 1 and
DDR_REVERSED_P set and we ignore those. Now on say:
int printf (const char *, ...);
int a;
static int b[1024];
int
main ()
{
for (a = 0; a = 512; a++)
{
b[a - 1] = b[a];
b[a] = 1;
}
printf (%d\n, b[1]);
return 0;
}
only the b[a] read vs. b[a-1] store is dist 1 DDR_REVERSED_P and b[a] store vs.
b[a-1] store is dist 1 !DDR_REVERSED_P, thus we don't vectorize it (correctly).
Unfortunately not ignoring dist 0 DDR_REVERSED_P ddrs for negative step
regresses the testcase I've attached, where there is a write after read ddr and
it works properly with the current check. While the attached patch keeps that
testcase (no-vfa-vect-depend*.c) working and fixes the test (pr59594.c), the
conditions are piled completely randomly, I'm afraid I don't know why it is so,
if for the DDR_REVERSED_P continue it matters whether step is positive or
negative, or if that is irrelevant and all the write after write DDR_REVERSED_P
ddrs need to be checked normally (abs (dist) = *max_vf), or if say only write
after read should be treated as the code treats it right now and even read
after write is problematic. The DDR_REVERSED_P stuff has been added in 2007
for PR32377, see e.g. http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01067.html
Richard, any ideas?
[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Created attachment 31920 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31920action=edit don't use _M_add_ref_lock() when exceptions are disabled Here's a patch which fixes Paul's testcase
[Bug fortran/59906] New: [4.7/4.8 Regression] error: size of variable 'anonymous' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906
Bug ID: 59906
Summary: [4.7/4.8 Regression] error: size of variable
'anonymous' is too large
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Hi,
a colleague just reported a regression for the code below.
It compiles fine with 4.3.4 and 4.5.0, but fails with 4.7.4 and 4.8.2.
Cannot check trunk right now.
% gfortran48 robin_gfortran_bug.f90
robin_gfortran_bug.f90: In function 'y':
robin_gfortran_bug.f90:17:0: error: size of variable 'anonymous' is too large
print*,str_cmp((/'aaa','bbb'/), str_aux)
^
% gfortran47 robin_gfortran_bug.f90
robin_gfortran_bug.f90: In function 'y':
robin_gfortran_bug.f90:17:0: error: size of variable 'anonymous' is too large
% cat robin_gfortran_bug.f90
program x
implicit none
call y('abcdef')
contains
subroutine y(str)
character(len=*), intent(in) :: str
character(len=len_trim(str)) :: str_aux
str_aux = str
! Compiles
! print*,str_cmp((/'aaa','bbb'/), str)
! Does not compile:
print*,str_cmp((/'aaa','bbb'/), str_aux)
end subroutine y
elemental logical function str_cmp(str1, str2)
character(len=*), intent(in) :: str1
character(len=*), intent(in) :: str2
str_cmp = (str1 == str2)
end function str_cmp
end program x
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added Attachment #31917|0 |1 is obsolete|| --- Comment #15 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31921 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31921action=edit Third try Makes sense, patch updated.
[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029 --- Comment #7 from Yury Gribov y.gribov at samsung dot com --- Volker, could you close this bug if gcc trunk works for you?
[Bug other/59384] Cilk Plus array notation with for loop after segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 --- Comment #2 from Nick Tomlinson nick.tomlinson at arm dot com --- I tried that patch against the latest CilkPlus branch, but could not apply it. I also tried building GCC 4.9 from trunk, but could not use cilk_for. Please could you let me know if there is a branch that supports both cilk_for and array notation? Thanks
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Sorry for not catching it earlier, I'm worried about -Wunused complaining about the vars. Can you instead use something like int x = syscall (__NR_gettid); syscall (__NR_futex, x, 1, 1); syscall (__NR_exit_group, 0); ? Please post to gcc-patches with the change (if it works). Thanks.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #17 from Yury Gribov y.gribov at samsung dot com --- Will do.
[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable 'anonymous' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added Known to work||4.1.2 Known to fail||4.4.5, 4.5.2, 4.6.3 --- Comment #1 from Harald Anlauf anlauf at gmx dot de --- It's not entirely clear when the regression occured. I see no failure with GNU Fortran (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] but the failure occurs with 4.4.5 and 4.5.2 on a Debian based system.
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r190594 which apparently made big changes in some of the GIMPLE passes, e.g. the optimized dump linecount went down from 65782 lines (r190593) to 52107 lines (r190594). But, for some reason that change results in uncomparably more log links and combiner opportunities. In -fdump-rtl-combine-details dump, 'Successfully match' matches went up from 9742 up to 3921927, and 'Failed to match' matches went up from 53193 to 22538586. So, the combiner success rate is approximately the same, around 17.5%, just on 400 times more opportunities. For GIMPLE passes, looking just at the sizes of the gimple dumps, until esra the sizes are the same, from fre1 the dump with r190594 is slightly to significantly larger than corresponding r190593 dump until crited, and then surprisingly the pre dump is on the other side half the size of r190593 dump and from sink till optimized the dump sizes roughly match the 65782 to 52107 lines.
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- With -O2 -fno-automatic -ffixed-line-length-none --param sccvn-max-alias-queries-per-access=1300 the combiner completely disappears out of the picture, supposedly because then FRE/PRE doesn't give up, with 1200 the combiner already takes 17% of compile time and 77% of memory, with the default 1000 it takes 58% of compile time and 96% of memory.
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|joao.eiras at gmail dot com| --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Fabien, any news on this - now that we are in Stage 3?
[Bug other/59384] Cilk Plus array notation with for loop after segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 Balaji V. Iyer bviyer at gmail dot com changed: What|Removed |Added CC||bviyer at gmail dot com --- Comment #3 from Balaji V. Iyer bviyer at gmail dot com --- Try this patch and the trunk revision mentioned in the thread: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01170.html
[Bug target/56315] ARM: Improve use of 64-bit constants in logical operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56315 --- Comment #4 from Joshua Conner josh.m.conner at gmail dot com --- Excellent - thanks!
[Bug ada/59907] New: Ada 2012 Indefinite_Holders Reference_Type is not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59907 Bug ID: 59907 Summary: Ada 2012 Indefinite_Holders Reference_Type is not implemented Product: gcc Version: unknown URL: http://ada-auth.org/standards/12rm/html/RM-A-18-18.htm l Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: christian_morgenr...@t-online.de The Ada 2012 Indefinite_Holders package declares the following types and functions which aren't implemented yet: type Constant_Reference_Type (Element : not null access constant Element_Type) is private with Implicit_Dereference = Element; type Reference_Type (Element : not null access Element_Type) is private with Implicit_Dereference = Element; function Constant_Reference (Container : aliased in Holder) return Constant_Reference_Type; function Reference (Container : aliased in out Holder) return Reference_Type;
[Bug target/43538] config/mt-gnu CXXFLAGS_FOR_TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43538 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-22 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- CXXFLAGS_FOR_TARGET is currently useless on platforms using mt-gnu...
[Bug tree-optimization/59908] New: Incorrect uninit warning with -fsanitize=address caused by LIM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59908
Bug ID: 59908
Summary: Incorrect uninit warning with -fsanitize=address
caused by LIM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
struct S
{
int s;
struct S *p;
};
extern void bar (void) __attribute__ ((__noreturn__));
extern void baz (struct S **);
void
foo (struct S *x, long c)
{
int s;
struct S *y;
if (c)
bar ();
lab:
s = x-s;
y = x;
switch (s)
{
case 0:
x = x-p;
goto lab;
case 1:
baz (y);
}
}
when compiled with -O2 -Wall -fsanitize=address incorrectly warns about maybe
uninitialized y, with just -O2 -Wall it doesn't (both 4.8 and trunk).
I couldn't find anything wrong in the -fdump-tree-asan1-all dump though, seems
like the problematic uninitialized load is inserted by lim pass, a single store
into y in the loop is replaced by load from uninitialized var before the loop
and 4 different stores after the loop (2 before the __asan_report* noreturn
calls, one before call to baz and one before exit.
[Bug tree-optimization/59908] Incorrect uninit warning with -fsanitize=address caused by LIM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59908 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug target/59691] cilk-plus run failures on non-sse processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 --- Comment #2 from Balaji V. Iyer bviyer at gmail dot com --- Hello Bernd, I don't have a pentium 2 machine readily available. Can you try this patch and see if it works for you? Thanks, Balaji V. Iyer. diff --git a/libcilkrts/runtime/config/x86/os-unix-sysdep.c b/libcilkrts/runtime /config/x86/os-unix-sysdep.c index 881bc3f..8d5642c 100644 --- a/libcilkrts/runtime/config/x86/os-unix-sysdep.c +++ b/libcilkrts/runtime/config/x86/os-unix-sysdep.c @@ -47,7 +47,7 @@ // save the FP state (rounding mode and the like) before calling setjmp. We // will need to restore that state when we resume. #ifndef __MIC__ -# if defined(__i386__) || defined(__x86_64) +# if (defined(__i386__) || defined(__x86_64)) defined (__SSE__) # define RESTORE_X86_FP_STATE # endif // defined(__i386__) || defined(__x86_64) #endif // __MIC__
[Bug target/59691] cilk-plus run failures on non-sse processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Balaji V. Iyer from comment #2) Hello Bernd, I don't have a pentium 2 machine readily available. Can you try this patch and see if it works for you? This is not correct, there should be a runtime check rather than a compile time one. Thanks, Balaji V. Iyer. diff --git a/libcilkrts/runtime/config/x86/os-unix-sysdep.c b/libcilkrts/runtime /config/x86/os-unix-sysdep.c index 881bc3f..8d5642c 100644 --- a/libcilkrts/runtime/config/x86/os-unix-sysdep.c +++ b/libcilkrts/runtime/config/x86/os-unix-sysdep.c @@ -47,7 +47,7 @@ // save the FP state (rounding mode and the like) before calling setjmp. We // will need to restore that state when we resume. #ifndef __MIC__ -# if defined(__i386__) || defined(__x86_64) +# if (defined(__i386__) || defined(__x86_64)) defined (__SSE__) # define RESTORE_X86_FP_STATE # endif // defined(__i386__) || defined(__x86_64) #endif // __MIC__
[Bug target/59691] cilk-plus run failures on non-sse processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- On 01/22/14 10:45, pinskia at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Balaji V. Iyer from comment #2) Hello Bernd, I don't have a pentium 2 machine readily available. Can you try this patch and see if it works for you? This is not correct, there should be a runtime check rather than a compile time one. Also note that you can usually change the underlying processor in VM environments. That's obviously useful for testing this kind of thing. VMs are, umm, goodness. jeff
[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable 'anonymous' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-22 Version|4.8.2 |4.7.3 Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r158683.
[Bug target/59909] Quad memory bootstrap issues on little endian powerpc64 power8 systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59909 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64le-linux Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-22 CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||matz at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-linux Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 Build||powerpc64le-linux
[Bug c++/59482] A friend class cannot inherit a private nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Jan 22 18:08:01 2014 New Revision: 206933 URL: http://gcc.gnu.org/viewcvs?rev=206933root=gccview=rev Log: /cp 2014-01-22 Ville Voutilainen ville.voutilai...@gmail.com PR c++/59482 * parser.c (cp_parser_class_head): Push the class before parsing the base-clause, pop after it. /testsuite 2014-01-22 Ville Voutilainen ville.voutilai...@gmail.com PR c++/59482 * g++.dg/pr59482.C: New. Added: trunk/gcc/testsuite/g++.dg/pr59482.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/59909] Quad memory bootstrap issues on little endian powerpc64 power8 systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59909 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 31922 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31922action=edit Proposed patch to fix the problem Split quad-memory support into two options, -mquad-memory for non-atomic load/stores, -mquad-memory-atomic for atomic load/stores. Don't allow non-atomic quad load/stores in little endian mode. Swap double words in little endian mode for atomic loads/stores.
[Bug target/59909] New: Quad memory bootstrap issues on little endian powerpc64 power8 systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59909 Bug ID: 59909 Summary: Quad memory bootstrap issues on little endian powerpc64 power8 systems Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Using the current sources, the GCC 4.9 compiler will not bootstrap if the default target is power8 on a little endian system. The cause is the new quad word load/store support does not deal with swapping words after doing the load, and before doing the store.
[Bug target/59909] Quad memory bootstrap issues on little endian powerpc64 power8 systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59909 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 31923 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31923action=edit Patch back ported to the ibm/gcc-4_8-branch Back ported patch to ibm/gcc-4_8-branch.
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #21 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jan 22 18:28:30 2014 New Revision: 206934 URL: http://gcc.gnu.org/viewcvs?rev=206934root=gccview=rev Log: Backport from mainline 2014-01-20 Uros Bizjak ubiz...@gmail.com * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false for SImode_address_operand operands, having only a REG argument. 2014-01-20 Jakub Jelinek ja...@redhat.com PR target/59880 * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false if operands[1] is a REG or ZERO_EXTEND of a REG. 2014-01-18 Uros Bizjak ubiz...@gmail.com H.J. Lu hongjiu...@intel.com PR target/59379 * config/i386/i386.md (*leamode): Zero-extend return register to DImode for zero-extended addresses. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/config/i386/i386.md
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #11 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jan 22 18:28:30 2014 New Revision: 206934 URL: http://gcc.gnu.org/viewcvs?rev=206934root=gccview=rev Log: Backport from mainline 2014-01-20 Uros Bizjak ubiz...@gmail.com * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false for SImode_address_operand operands, having only a REG argument. 2014-01-20 Jakub Jelinek ja...@redhat.com PR target/59880 * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false if operands[1] is a REG or ZERO_EXTEND of a REG. 2014-01-18 Uros Bizjak ubiz...@gmail.com H.J. Lu hongjiu...@intel.com PR target/59379 * config/i386/i386.md (*leamode): Zero-extend return register to DImode for zero-extended addresses. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/config/i386/i386.md
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal
[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.9.0 |4.8.3 --- Comment #22 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug c++/59482] A friend class cannot inherit a private nested class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59482 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 --- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com --- Created attachment 31924 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31924action=edit Alternate fix from Kyle Lippincott Alternate patch, courtesy Kyle Lippincott spect...@google.com. AFAIU, Kyle's patch uses roughly the same idea as Jonathan's, but no #ifdef's. Should we take these patches to gcc-patches list?
[Bug sanitizer/59029] ICE with builtin function and -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Volker Reichelt reichelt at gcc dot gnu.org --- Fixed on trunk by Yury's patch.
[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477 --- Comment #8 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Jan 22 19:38:47 2014 New Revision: 206938 URL: http://gcc.gnu.org/viewcvs?rev=206938root=gccview=rev Log: 2014-01-22 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/59477 * lra-constraints.c (inherit_in_ebb): Process call for living hard regs. Update reloads_num and potential_reload_hard_regs for all insns. 2014-01-22 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/59477 * g++.dg/pr59477.C: New. Added: trunk/gcc/testsuite/g++.dg/pr59477.C Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Jan 22 19:46:44 2014 New Revision: 206939 URL: http://gcc.gnu.org/viewcvs?rev=206939root=gccview=rev Log: PR libstdc++/58764 * include/bits/stl_deque.h (deque::deque(const allocator_type): Split into separate default constructor and constructor taking allocator. * include/bits/stl_list.h (list::list(const allocator_type): Likewise. * include/bits/stl_vector.h (vector::vector(const allocator_type): Likewise. * include/debug/deque (deque::deque(const allocator_type)): Likewise. * include/debug/list (list::list(const _Allocator)): Likewise. * include/debug/map.h (map::map(const _Compare, const _Allocator)): Likewise. * include/debug/multimap.h (multimap::multimap(const _Compare, const _Allocator)): Likewise. * include/debug/set.h (set::set(const _Compare, const _Allocator)): Likewise. * include/debug/multiset.h (multiset::multiset(const _Compare, const _Allocator)): Likewise. * include/debug/vector (vector::vector(const allocator_type)): Likewise. * include/profile/deque (deque::deque(const _Allocator)): Likewise. * include/profile/list (list::list(const _Allocator)): Likewise. * include/profile/map.h (map::map(const _Compare, const _Allocator)): Likewise. * include/profile/multimap.h (multimap::multimap(const _Compare, const _Allocator)): Likewise. * include/profile/set.h (set::set(const _Compare, const _Allocator)): Likewise. * include/profile/multiset.h (multiset::multiset(const _Compare, const _Allocator)): Likewise. * include/profile/vector (vector::vector(const _Allocator)): Likewise. * testsuite/23_containers/deque/58764.cc: New. * testsuite/23_containers/list/58764.cc: New. * testsuite/23_containers/map/58764.cc: New. * testsuite/23_containers/multimap/58764.cc: New. * testsuite/23_containers/set/58764.cc: New. * testsuite/23_containers/multiset/58764.cc: New. * testsuite/23_containers/vector/58764.cc: New. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Adjust dg-error line number. * testsuite/23_containers/deque/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/deque/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/map/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/set/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/58764.cc - copied, changed from r206938, trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/debug/deque trunk/libstdc++-v3/include/debug/list trunk/libstdc++-v3/include/debug/map.h trunk/libstdc++-v3/include/debug/multimap.h trunk/libstdc++-v3/include/debug/multiset.h trunk/libstdc++-v3/include/debug/set.h
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #30 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Denis Excoffier from comment #29) (In reply to Iain Sandoe from comment #28) Well, there is a fix - which is to update /usr/lib/libgcc_s.dylib to a non-buggy version. I had understood that it was desirable not to replace libgcc_s.dylib. so long as the system was maintained by the Vendor, then indeed it would be a bad thing but… see below (It's also somewhat like open-heart surgery - if you make a mistake doing the exchange then you need to boot from a different disk to recover. This makes it unsuitable, without an installer, for casual users) Personally, i use the sed command (shown in comment #17) to create my own libgcc_s.1.dylib, i install it with GCC in /usr/local (or equivalent) and try to always link with it (and usually succeed since i don't use any libraries that are already linked with /usr/lib/libgcc_s.dylib). For security matters, that's like replacing, however. I think replacing is the proper option in this case - the security issue is moot for an unsupported EOL system. In any case, that bug is not NEW any more. Well, I think we should close as WONTFIX - because we don't have resources to find a better solution - and replacing the library is an acceptable work-around for EOL systems (I've now done this on both my i686 and ppc darwin9 boxes). Note: that a replacement library MUST be built FAT if you want ppc64 to work and FAT including ppc on i686-darwin9 if you want rosetta to work.
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764
--- Comment #10 from Marc Glisse glisse at gcc dot gnu.org ---
vector() _GLIBCXX_NOEXCEPT : _Base() { }
list() _GLIBCXX_NOEXCEPT
I think that's wrong, the default construction of the allocator may throw,
hence the conditional noexcept I was suggesting in comment #3.
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #12 from uros at gcc dot gnu.org --- Author: uros Date: Wed Jan 22 19:57:30 2014 New Revision: 206940 URL: http://gcc.gnu.org/viewcvs?rev=206940root=gccview=rev Log: PR target/59880 * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false for SImode_address_operand operands. Return false if operands[1] is a REG. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/i386.c
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- Fixed.
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- OK, I'll make the noexcept conditional, which will mean losing it in C++03 mode.
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||ramana at gcc dot gnu.org,
||rearnsha at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
The #c1 to #c5 comments are completely unrelated to the #c0 issue, which is
clearly a bug in the ARM backend.
When creating prologue, the ARM backend decides to save some garbage registers
(just to avoid having to decrement stack pointer separately?):
if (optimize_size !frame_pointer_needed
saved_regs == offsets-saved_regs - offsets-saved_args)
{
/* If no coprocessor registers are being pushed and we don't have
to worry about a frame pointer then push extra registers to
create the stack frame. This is done is a way that does not
alter the frame layout, so is independent of the epilogue. */
int n;
int frame;
n = 0;
while (n 8 (live_regs_mask (1 n)) == 0)
n++;
frame = offsets-outgoing_args - (offsets-saved_args + saved_regs);
if (frame n * 4 = frame)
{
n = frame / 4;
live_regs_mask |= (1 n) - 1;
saved_regs += frame;
}
}
so without -g we get:
stmfd sp!, {r0, r1, r2, lr}
in the prologue (note, this is shrink wrapped) and
add sp, sp, #12
@ sp needed
ldr lr, [sp], #4
in the epilogue (note, r0-r2 not restored there).
This is all fine, except that the
emit_multi_reg_push/arm_emit_strd_push/thumb2_emit_strd_push all record all
those saved registers into
REG_FRAME_RELATED_EXPR, which is a very bad idea. Only call clobbered
registers that you actually save in prologue and restore in epilogue should be
declared as saved for CFI purposes, the dwarf2cfi.c code verifies this property
and that's the reason for this ICE.
Now, I'm afraid I'm not familiar enough with the multitude of ARM ABIs, so not
sure if the best fix is just to ignore for the REG_FRAME_RELATED_EXPR in those
3 above mentioned functions all non-fixed call_used registers, just ignore
r0..r3, or if the caller should call those functions with two masks, one for
what registers should be actually saved to the stack (as right now) and another
for which registers should be in REG_FRAME_RELATED_EXPR (equal to the first or
some subset thereof).
[Bug fortran/59910] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59910 Bug ID: 59910 Summary: ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327 Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: victorlei at gmail dot com Created attachment 31925 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31925action=edit input to reproduce the bug lei@dilbert ~/smop/smop $ gfortran bugrep.f90 bugrep.f90: In function ‘runcontest’: bugrep.f90:8:0: internal compiler error: in gfc_conv_array_initializer, at fortran/trans-array.c:5327 See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. lei@dilbert ~/smop/smop $ gfortran --version GNU Fortran (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
[Bug target/59672] Add -m16 support for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 --- Comment #5 from David Woodhouse dwmw2 at infradead dot org --- Note that LLVM/clang has a -m16 option now which does the same thing. Again, not needing dirty hacks to ensure that asm(.code16gcc) really *is* the first thing the assembler sees.
[Bug rtl-optimization/59477] [4.8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law law at redhat dot com --- Fixed by Vlad's commit on the trunk.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #5 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Wed Jan 22 21:27:38 2014 New Revision: 206941 URL: http://gcc.gnu.org/viewcvs?rev=206941root=gccview=rev Log: PR tree-optimization/59597 * tree-ssa-threadupdate.c (dump_jump_thread_path): Move to earlier in file. Accept new argument REGISTERING and use it to modify dump output appropriately. (register_jump_thread): Corresponding changes. (mark_threaded_blocks): Reinstate code to cancel unprofitable thread paths involving joiner blocks. Add code to dump cancelled jump threading paths. PR tree-optimization/59597 * gcc.dg/tree-ssa/pr59597.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr59597.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Fixed by recent commit on trunk.
[Bug libstdc++/59472] Many warnings type of 'X' does not match original declaration when linking with libstdc++ static library compiled with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59472 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-22 Component|lto |libstdc++ Ever confirmed|0 |1 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Same here (CXXFLAGS_FOR_TARGET=-O2 -g -flto -ffat-lto-objects after a trivial fix for PR 43538): /data/repos/gcc/trunk/libstdc++-v3/src/c++98/ios_init.cc:56:33: warning: type of 'buf_wcerr' does not match original declaration [enabled by default] extern stdio_filebufwchar_t buf_wcerr; ^ /data/repos/gcc/trunk/libstdc++-v3/src/c++98/globals_io.cc:105:17: note: previously declared here fake_wfilebuf buf_wcerr; ^ etc. Reassigning to libstdc++ because the warnings seem to say the truth.
[Bug rtl-optimization/53252] Missed shrink wrapping opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53252 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law law at redhat dot com --- This was fixed at some point, but I don't know precisely when.
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #14 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Wed Jan 22 22:01:00 2014 New Revision: 206942 URL: http://gcc.gnu.org/viewcvs?rev=206942root=gccview=rev Log: Backport gcc.target/i386/pr59880.c Backport from mainline 2014-01-20 Jakub Jelinek ja...@redhat.com PR target/59880 * gcc.target/i386/pr59880.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59880.c Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug other/59893] Use LTO for libgcc.a, libstdc++.a, etc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Marc Glisse from comment #0) It may be as easy as adding the flags to C(XX)FLAGS_FOR_TARGET With a trivial fix for PR 43538, this works. However, we then hit PR 59472. Also, if instead of gold 1.11 (which works fine) I use GNU ld 2.24, I get warnings: /usr/bin/ld: error in /tmp/cc5iP5Yf.ltrans2.ltrans.o(.eh_frame); no .eh_frame_hdr table will be created. because of crtend.o. The path is long... At least, I tried the result, and it does help for PR 59048 and does allow removing operator delete(0).
[Bug c/59891] [4.7/4.8/4.9 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Jan 22 22:15:12 2014 New Revision: 206944 URL: http://gcc.gnu.org/viewcvs?rev=206944root=gccview=rev Log: PR c/59891 c/ * c-typeck.c (build_conditional_expr): Call c_fully_fold instead of remove_c_maybe_const_expr on op1 and op2. testsuite/ * gcc.dg/torture/pr59891.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59891.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/59891] [4.7/4.8 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891 --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Wed Jan 22 22:20:14 2014 New Revision: 206945 URL: http://gcc.gnu.org/viewcvs?rev=206945root=gccview=rev Log: PR c/59891 c/ * c-typeck.c (build_conditional_expr): Call c_fully_fold instead of remove_c_maybe_const_expr on op1 and op2. testsuite/ * gcc.dg/torture/pr59891.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59891.c Modified: branches/gcc-4_8-branch/gcc/c/ChangeLog branches/gcc-4_8-branch/gcc/c/c-typeck.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c/59891] [4.7 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[4.7/4.8 Regression] ICE on |[4.7 Regression] ICE on |invalid code (with |invalid code (with |div-by-zero) at all |div-by-zero) at all |optimization levels on |optimization levels on |x86_64-linux-gnu|x86_64-linux-gnu --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug target/59672] Add -m16 support for x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 --- Comment #6 from H. Peter Anvin hpa at zytor dot com --- This could also be implemented in binutils as a --code16gcc option, in which case gcc users would have to use -m32 -Wa,--code16gcc. Ugly but would work.
[Bug c/59911] New: Improper warnings when expressing min int64_t as decimal literal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59911
Bug ID: 59911
Summary: Improper warnings when expressing min int64_t as
decimal literal.
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: johngro at google dot com
Created attachment 31926
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31926action=edit
Simple test case preproc output.
When attempting to express the minimum int64 value as a decimal literal, the
compiler generates two warning indicating that the literal is too large and is
being treated as unsigned. The assignment is permitted, and printf shows that
the proper bit pattern is being assigned to the variable, but it is expected
that no warning should be produced given a literal value which is in range for
its data type.
EXPECTED BEHAVIOR
Code compiles with no warnings or error.
ACTUAL BEHAVIOR
The following 2 warnings are produced.
warning: integer constant is so large that it is unsigned [enabled by default]
warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
BASE SOURCE CODE
#include stdio.h
#include stdint.h
int main(int argc, char** argv) {
int64_t min_int64 = -9223372036854775808ll;
int64_t not_quite_min_int64 = -9223372036854775807ll;
int32_t min_int32 = -2147483648;
printf(int32_t :: %20d 0x%x\n, min_int32, min_int32);
printf(int64_t :: %20ld 0x%lx\n, min_int64, min_int64);
printf(int64_t :: %20ld 0x%lx (not quite min)\n,
not_quite_min_int64, not_quite_min_int64);
}
(sorry about inlining the .c file into the description; I couldn't figure out
how to attach more than one file to the bug without using an archive)
COMPILER COMMAND LINE
gcc-4.8 /tmp/test_case.c ./a.out
COMPILER OUTPUT
/tmp/test_case.c: In function ‘main’:
/tmp/test_case.c:5:26: warning: integer constant is so large that it is
unsigned [enabled by default]
int64_t min_int64 = -9223372036854775808ll;
^
/tmp/test_case.c:5:5: warning: this decimal constant is unsigned only in ISO
C90 [enabled by default]
int64_t min_int64 = -9223372036854775808ll;
^
PROGRAM OUTPUT
int32_t :: -2147483648 0x8000
int64_t :: -9223372036854775808 0x8000
int64_t :: -9223372036854775807 0x8001 (not quite min)
SYSTEM/COMPILER INFO (produced with gcc-4.8 -v -save-temps=obj
/tmp/test_case.c)
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --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.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps=obj' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -E -quiet -v -imultilib . -imultiarch
x86_64-linux-gnu /tmp/test_case.c -mtune=generic -march=x86-64 -fpch-preprocess
-fstack-protector -o test_case.i
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps=obj' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -fpreprocessed test_case.i -quiet
-dumpbase test_case.c -mtune=generic -march=x86-64 -auxbase test_case -version
-fstack-protector -o test_case.s
GNU C (Ubuntu 4.8.1-2ubuntu1~12.04) version 4.8.1 (x86_64-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version
[Bug c/59911] Improper warnings when expressing min int64_t as decimal literal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59911 --- Comment #1 from John Grossman johngro at google dot com --- Created attachment 31927 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31927action=edit basic test case C source ah; found out I can add the .c file as another attachment once the bug has been created. Sorry again for the inline.
[Bug c/59911] Improper warnings when expressing min int64_t as decimal literal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59911 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- -9223372036854775808ll is two tokens unary - and 9223372036854775808ll and the second token does not fit into a signed long long. The second warning is saying C90 and C99 are different here.
[Bug c/59911] Improper warnings when expressing min int64_t as decimal literal.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59911 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- To get rid of that warning, write the value using hex, that is int64_t min_int64 = 0x8000;
[Bug c++/59912] New: [C++1y] ICE when deducing return type for specialized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59912
Bug ID: 59912
Summary: [C++1y] ICE when deducing return type for specialized
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: n.sakisaka at gmail dot com
// normal function, OK
// auto f(int)
// {
// return 0;
// }
// specialized function, NG
templateclass T, class ReturnType
ReturnType f(T);
template
auto f(int)
{
return 0;
}
ICE error output:
prog.cc:15:1: internal compiler error: Segmentation fault
}
^
0x95499f crash_signal
/home/gccbuilder/gcc/gcc/toplev.c:337
0xb2aa12 make_decl_rtl(tree_node*)
/home/gccbuilder/gcc/gcc/varasm.c:1274
0xb2b12a notice_global_symbol(tree_node*)
/home/gccbuilder/gcc/gcc/varasm.c:1548
0x6e0251 cgraph_finalize_function(tree_node*, bool)
/home/gccbuilder/gcc/gcc/cgraphunit.c:434
0x5fbd9f expand_or_defer_fn(tree_node*)
/home/gccbuilder/gcc/gcc/cp/semantics.c:3979
0x5c2c56 cp_parser_function_definition_after_declarator
/home/gccbuilder/gcc/gcc/cp/parser.c:22705
0x5c3b1c cp_parser_function_definition_from_specifiers_and_declarator
/home/gccbuilder/gcc/gcc/cp/parser.c:22609
0x5c3b1c cp_parser_init_declarator
/home/gccbuilder/gcc/gcc/cp/parser.c:16598
0x5c3e54 cp_parser_single_declaration
/home/gccbuilder/gcc/gcc/cp/parser.c:23018
0x5c467d cp_parser_explicit_specialization
/home/gccbuilder/gcc/gcc/cp/parser.c:14203
0x5cc553 cp_parser_declaration
/home/gccbuilder/gcc/gcc/cp/parser.c:10941
0x5cb168 cp_parser_declaration_seq_opt
/home/gccbuilder/gcc/gcc/cp/parser.c:10874
0x5cc9aa cp_parser_translation_unit
/home/gccbuilder/gcc/gcc/cp/parser.c:4021
0x5cc9aa c_parse_file()
/home/gccbuilder/gcc/gcc/cp/parser.c:31350
0x6758a3 c_common_parse_file()
/home/gccbuilder/gcc/gcc/c-family/c-opts.c:1060
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.
Working code:
http://melpon.org/wandbox/permlink/WWuXWgF9W7E6bywL
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Wed Jan 22 23:50:58 2014 New Revision: 206946 URL: http://gcc.gnu.org/viewcvs?rev=206946root=gccview=rev Log: PR libstdc++/58764 (again) * include/bits/stl_list.h (list): Make default constructor's exception specification conditional. * include/bits/stl_vector.h (vector): Likewise. * testsuite/util/testsuite_allocator.h (SimpleAllocator): Add noexcept to default constructor. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Adjust dg-error line number. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- On trunk now we have separate (non-explicit) default constructors for deque, list, vector, map, multimap, set and multiset. Debug and profile modes should be consistent with normal mode. We still have explicit default constructors for the C++11 containers, forward_list and unordered_xxx, which I suggest revisiting when LWG 2193 is resolved, but the regression is fixed.
[Bug other/59834] [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Balaji V. Iyer from comment #1) Hi H. J., I am not able to reproduce it in my SUSE machine. I tried both -m64 and -m32. Thanks, You should see it with -m32 after r206947.
[Bug c/16351] NULL dereference warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #16 from Jeffrey A. Law law at redhat dot com --- Created attachment 31928 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31928action=edit Work-In-Progress patch
[Bug tree-optimization/46639] [4.7/4.8/4.9 Regression] Missing optimization due to function splitting and redundant conditionals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46639 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #13 from Jeffrey A. Law law at redhat dot com --- Another approach would be to do some minimal redundancy elimination as part of the into-ssa pass. Having done it before, I know it's pretty easy.
[Bug target/46716] [4.7/4.8/4.9 Regression] wrong code generated with -mno-sse2 -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46716 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #13 from Jeffrey A. Law law at redhat dot com --- Fixed on the trunk some time ago.
[Bug middle-end/48087] [4.7/4.8/4.9 Regression] -Wall -Werror adds warnings over and above those generated by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #26 from Jeffrey A. Law law at redhat dot com --- Fixed long ago on the trunk.
