Re: RFD: selective linking of floating point support for *printf / *scanf
On 18 August 2014 11:35, Joey Ye joey.ye...@gmail.com wrote: Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html, which is already in newlib mainline. I think it solves the same issue in a slight different approach. Does it work for you? No, this is completely besides the point. avr-libc has had manual printf variant selection (requiring -u and -l options to the linker) for quite some time. But this requirement for manual selection means that lots of dejagnu tests fail; it also means that a lot of software fails to work properly out of the box. The point of my patch is to do an automatic selection inasmuch as this is possible with gcc noting where floating point is being used from looking at *printf* / *scanf* calls in isolation and passing the information gained to the linker to figure out which implementation to use.
Re: bug report - libsanitizer compilation fail
On 10/06/2014 03:09 PM, Daniel Doron wrote: Hi, I am sending this bug report here because I can't register an account in bugzilla... gcc version: gcc-linaro-4.9-2014.09 (I checked also the main repo git, the code is the same) kernel: 2.6.37 home/daniel/Downloads/.build/src/gcc-custom/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:675:43: error: 'EVIOCGPROP' was not declared in this scope This happens when compiling with kernel 2.6.37 headers. #if EV_VERSION (0x01) unsigned IOCTL_EVIOCGKEYCODE_V2 = EVIOCGKEYCODE_V2; unsigned IOCTL_EVIOCGPROP = EVIOCGPROP(0); unsigned IOCTL_EVIOCSKEYCODE_V2 = EVIOCSKEYCODE_V2; #else unsigned IOCTL_EVIOCGKEYCODE_V2 = IOCTL_NOT_PRESENT; unsigned IOCTL_EVIOCGPROP = IOCTL_NOT_PRESENT; unsigned IOCTL_EVIOCSKEYCODE_V2 = IOCTL_NOT_PRESENT; #endif although in kernel 2.6.37 the EV_VERSION is indeed (0x01) the EVIOCGPROP define is missing and only appears in 2.6.38 onwards. You'll probably want to report this to upstream project (which is compiler-rt). -Y
ping: MPX ABI extension
Hello All, We would like to ping this patch: https://sourceware.org/ml/libc-alpha/2013-08/msg00482.html We have some modifications on GDB side that depends on those changes. Thanks and regards, Walfred Tedeschi Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
Towards GNU11
Hi!
I'd like to kick off a discussion about moving the default standard
for C from gnu89 to gnu11.
This really shouldn't be much of a surprise: the docs mention that
gnu11 is intended future default for a year now. I would presume now
is a good time to make this move: together with the new naming scheme
this should make GCC more modern (C89 really is as old as the hills).
And we're still in stage1.
Prerequisites should be largely complete at this point:
- we have -Wc90-c99-compat option that warns about features not present
in ISO C90, but present in ISO C99,
- we have -Wc99-c11-compat option that warns about features not present
in ISO C99, but present in ISO C11,
- the testsuite has been adjusted so all the test that pass with gnu89
default should pass with gnu11 default as well (see my recent batch
of cleanup patches). This unfortunately isn't correct for all archs,
I just don't have enough resources to test everything. But generally
the fallout from moving to gnu11 is easy to fix: just add proper decls
and return types (to fix defaulting to int), or for inline stuff use
-fgnu89-inline/gnu_inline attribute. I'd appreciate testing on other
architectures than x86_64/ppc64.
The things I had to fix in the testsuite nicely reflect what we can expect
in the real life: mostly bunch of new warnings about missing declarations
and defaulting to int (this is probably going to be a pain with -Werror,
but I feel that people really should write proper declarations), different
inline semantics (in C99 semantics, the TU has to have the body of the inline
function etc.), new return with no value, in function returning non-void
warnings. Different rules for constant expressions, the fact that in C90
non-lvalue arrays do not decay to pointers, slightly different rules for
compatible types (?) might come in game as well.
In turn, you can use all C99 and C11 features even with -pedantic.
Comments?
Regtested/bootstrapped on powerpc64-linux and x86_64-linux.
2014-10-07 Marek Polacek pola...@redhat.com
* doc/invoke.texi: Update to reflect that GNU11 is the default
mode for C.
* c-common.h (c_language_kind): Update comment.
c-family/
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 1e3477f..a895084 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -445,7 +445,7 @@ struct GTY(()) sorted_fields_type {
typedef enum c_language_kind
{
- clk_c= 0,/* C90, C94 or C99 */
+ clk_c= 0,/* C90, C94, C99 or C11 */
clk_objc = 1,/* clk_c with ObjC features. */
clk_cxx = 2,/* ANSI/ISO C++ */
clk_objcxx = 3 /* clk_cxx with ObjC features. */
diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
index 3f295d8..eb078e3 100644
--- gcc/c-family/c-opts.c
+++ gcc/c-family/c-opts.c
@@ -250,6 +250,9 @@ c_common_init_options (unsigned int decoded_options_count,
if (c_language == clk_c)
{
+ /* The default for C is gnu11. */
+ set_std_c11 (false /* ISO */);
+
/* If preprocessing assembly language, accept any of the C-family
front end options since the driver may pass them through. */
for (i = 1; i decoded_options_count; i++)
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 5fe7e15..fa84ed4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -1692,8 +1692,7 @@ interfaces) and L (Analyzability). The name @samp{c1x}
is deprecated.
@item gnu90
@itemx gnu89
-GNU dialect of ISO C90 (including some C99 features). This
-is the default for C code.
+GNU dialect of ISO C90 (including some C99 features).
@item gnu99
@itemx gnu9x
@@ -1701,8 +1700,8 @@ GNU dialect of ISO C99. The name @samp{gnu9x} is
deprecated.
@item gnu11
@itemx gnu1x
-GNU dialect of ISO C11. This is intended to become the default in a
-future release of GCC. The name @samp{gnu1x} is deprecated.
+GNU dialect of ISO C11. This is the default for C code.
+The name @samp{gnu1x} is deprecated.
@item c++98
@itemx c++03
Marek
lm32 build problem.
version: 4.9.1 host compiler: gcc-4.8.2 host OS: Ubuntu 14.04 target: lm32-unknown-elf Here's the problem I see: tm@tm-VirtualBox:~/lm32-toolchain/lm32-gcc$ ../gcc-4.9.1/configure --prefix=/home/tm/bin --target=lm32-uclibc-elf --enable-languges=c ; make ... checking if /home/tm/lm32-toolchain/lm32-gcc/./gcc/xgcc -B/home/tm/lm32-toolchain/lm32-gcc/./gcc/ -B/home/tm/bin/lm32-uclibc-elf/bin/ -B/home/tm/bin/lm32-uclibc-elf/lib/ -isystem /home/tm/bin/lm32-uclibc-elf/include -isystem /home/tm/bin/lm32-uclibc-elf/sys-includesupports -c -o file.o... (cached) yes checking whether the /home/tm/lm32-toolchain/lm32-gcc/./gcc/xgcc -B/home/tm/lm32-toolchain/lm32-gcc/./gcc/ -B/home/tm/bin/lm32-uclibc-elf/bin/ -B/home/tm/bin/lm32-uclibc-elf/lib/ -isystem /home/tm/bin/lm32-uclibc-elf/include -isystem /home/tm/bin/lm32-uclibc-elf/sys-includelinker (/home/tm/lm32-toolchain/lm32-gcc/./gcc/collect-ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Martin Liška from comment #8) Created attachment 33653 [details] Fix patch2 Yes, this patch works for me.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #19 from rguenther at suse dot de rguenther at suse dot de --- On Mon, 6 Oct 2014, hubicka at ucw dot cz wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #11 from Jan Hubicka hubicka at ucw dot cz --- Hi, this patch implements the lowring. Each call with warn attribute triggers code in cgraphunit that inserts call to bulitin_warning/error that is output at expansion time. Do we have way to define bulitin that is not user accessible? Also we do not have way to define LOOPING_CONST bulitin, so I am simply forcing the flag in cgraphunit.c that is somewhat ugly. But this also means that when attaching the attribute to pure/const functions which result becomes unused and thus the call gets DCEd will still emit the warning/error. Similar if the function gets inlined (formerly no warning/error). I think you need an alternate lowering for the first case at least, like passing through the return value. Not sure how to deal with the 2nd case. That said, I don't think this is the way to go to implement the attribute.
[Bug tree-optimization/63467] should have asm statement that does not prevent vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Why not use a label?
#define N 100
int a[N], b[N], c[N];
main()
{
static void *x __attribute__((used)) = bar;
int i;
for (i = 0; i N; i++) {
bar:
a[i] = b[i] + c[i];
}
}
will get you
.L2:
movdqa b(%rax), %xmm0
addq$16, %rax
paddd c-16(%rax), %xmm0
movaps %xmm0, a-16(%rax)
cmpq$400, %rax
jne .L2
...
.type x.1751, @object
.size x.1751, 8
x.1751:
.quad .L2
(ok, the label isn't called 'bar' anymore for some dubious reason). Maybe
there is a more fancy way to mark the label used than taking its address
(a used attribute on the label itself is ignored).
The code_label (bar) survives until the very end but it seems that asmout
transforms local labels to the .Ld form unconditionally.
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 --- Comment #10 from Martin Liška mliska at suse dot cz --- Fixed in r215967.
[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 Ai Azuma ai.azuma at gmail dot com changed: What|Removed |Added CC||ai.azuma at gmail dot com --- Comment #4 from Ai Azuma ai.azuma at gmail dot com --- PR61643 shares the root cause with this PR. The behavior of the test case in PR61643 completely agrees with the analysis in Comment 2, and the proposed patch makes the test case in PR61643 work properly. I confirmed that this bug was reproduced with 4.8.4 20140925, 4.9.2 20140924 and 5.0.0 20140928.
[Bug libstdc++/61643] [C++11] std::uncaught_exception returns wrong values after std::rethrow_if_nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61643 Ai Azuma ai.azuma at gmail dot com changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Known to fail|4.10.0, 4.9.1 |4.9.2, 5.0 --- Comment #1 from Ai Azuma ai.azuma at gmail dot com --- See Comment 2 in PR62258. The proposed patch attached in that comment make the above test case work properly.
[Bug libstdc++/61643] [C++11] std::uncaught_exception returns wrong values after std::rethrow_if_nested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61643 Ai Azuma ai.azuma at gmail dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Ai Azuma ai.azuma at gmail dot com --- *** This bug has been marked as a duplicate of bug 62258 ***
[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 --- Comment #5 from Ai Azuma ai.azuma at gmail dot com --- *** Bug 61643 has been marked as a duplicate of this bug. ***
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #17 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
* Wouldn't the new patch re-introduce the bug that
func foo(n int) {
if (n == 0) { recover(); } else { foo(0); }
}
func main() {
defer foo(1)
panic(...)
}
would recover although it should not?
Hmmm, I hadn't fully internalized that issue. Your new
withoutRecoverRecursive test doesn't fail for me on x86_64.
I think you have implicitly fixed this issue by splitting functions that call
recover() into two parts (i.e. main.foo and main.foo$recover). So recursive
calls originate from the ...$recover function and never match the return
address check. Well, maybe it was only a problem with tail recursion, i.e.
func foo(n int) int {
if (n == 0) { recover(); return 0; }
return foo(0)
}
Would be optimized to a loop, removing the function call, and then the return
address check would trigger. That's not possible with two function approach.
But if there's another criterion to allow recover that simply depends on the
caller's name the problem might reappear.
* The code is even more expensive than the approach I had chosen because
now it needs to fetch a two level backtrace instead of just one level
(and probably each level is more expensive than the one
_Unwind_FindEnclosingFunc()).
Yes, but the expensive case only happens in the rare cases where
either recover should not work or when the existing code has a
false negative.
Hm, so the patch penalises platforms that cannot deal with the 16 byte window?
func main() { defer foo(); panic(...); }
func foo() { defer bar(); }
func bar() { recover(); }
In this case, the call to recover in bar is supposed to return nil;
it should not recover the panic. If you read the paragraph before
the one you quote, you will see that recover only returns non-nil
if it was called by a function that was deferred before the call to
panic.
I've read it but cannot see anything that would disallow recovery in this
situation. What exactly do you mean?
4) __go_can_recover assumes that any call through libffi is allowed
to recover.
Thanks for the example. Does your patch fix this problem?
No, I just became aware of the problem when reviewing the code last week.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- The builtin-types.def part is unnecessary, I don't see internal-fn.def part. Also, we might need to tune optimizations across the two internal calls (from aliasing POV at least), we certainly want them to act as they have unspecified other effects (i.e. we don't want DCE to delete them, or hoist them before condition guarding them, on the other side, it would be nice if alias would know they don't clobber nor read any memory, are leaf etc.).
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- The only duplicate decls are the C extern inline __attribute__((gnu_inline)) (or -std=c89/gnu89 extern inline) or C++ inline __attribute__((gnu_inline)). We do have a middle-end representation of those, don't we? Do you have a problem that they have the same asm names, or DECL_NAME, something else? If you wanted different asm names (e.g. normal asm name plus space at the end), we'd need some code to change calls to the functions with space after it back into ones without it if inlining failed.
[Bug libstdc++/63466] sstream is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- You're comparing apples and oranges. This function forces you to do additional allocations for the arguments, which has nothing to do with iostream performance: void __attribute__((noinline, noclone)) func(string , string ) This allocates even more memory: istringstream iss(line); The expression (iss index s) is far more flexible than your C version, handling adjacent whitespace and being able to extract arbitrary types from the stream. If you don't need those extra allocations and flexibility then don't use them; your C code is a valid C++ program too. But rewriting your C++ code to be equivalent to the C code (e.g. by using std::string::find_first_of) would remove any use of stringstream, leaving only the performance of std::getline as a limiting factor, which is not the topic of this bug report. So if your point is simply iostreams are slower than stdio then yes, we know, welcome to 1998 ;-)
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 --- Comment #5 from Venkataramanan venkataramanan.kumar at amd dot com --- Not able to reproduce with latest trunk r215964. Bisecting to find a revision from which bug disappears.
[Bug libstdc++/63466] sstream is very slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
The calls you see to getc are nothing to do with sstream, they're from the
std::getline call reading from stdin, and are required because you didn't tell
the C++ runtime that you don't need it to be synchronised with C stdio. If you
don't need to mix C and C++ I/O then you forgot the most important thing for
iostream performance on standard I/O streams:
std::ios::sync_with_stdio(false);
If you don't need that synchronisation, don't use it.
Something like this is a more accurate equivalent of the C program, and much
closer in performance:
#include iostream
#include string
#include sstream
using namespace std;
void __attribute__((noinline, noclone)) func(char*, char*)
{
}
int main()
{
std::ios::sync_with_stdio(false);
string line;
while (getline(cin, line)) {
char* a = line[0];
char* b = nullptr;
auto pos1 = line.find_first_of( \t\n);
if (pos1 != std::string::npos) {
line[pos1] = '\0';
b = a + pos1 + 1;
auto pos2 = line.find_first_of( \t\n, pos1+1);
if (pos2 != std::string::npos) {
line[pos2] = '\0';
}
}
func(a, b);
}
}
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #13 from Richard PALO richard at netbsd dot org --- Since this regresses on the same omnios (illumos) platform between gcc 4.7.3 and 4.8.1 are there some pointers on how to identify the issue in illumos? (the fact the 4.8.1 tested is native omnios (R151012) eliminates any eventual pkgsrc issue, for me at least). that is, 'git diff local-4.7.3 local-4.8.1` seems like quite a bit of work. otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc 4.9.1 may be awhile before I have the time... cheers
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 33658
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33658action=edit
gcc5-pr63464.patch
Updated patch for the switchconv, this time checking rtx costs.
As for reassoc, the problem I see is that this kind of optimization needs to
split basic blocks, as left shift by negative or = word bit size is undefined
behavior, so the expected generated code is probably jump around the left
shift.
I think reassoc pass is not prepared to see splitting of basic blocks, nor
adding new PHI nodes etc. In the:
int
foo (int x)
{
return x == 1 || x == 2 || x == 4 || x == 6 || x == 15 || x == 17;
}
case we actually have 2 basic blocks and there is no other test ored in in
either of the basic blocks, so we could perform it even without creating a new
bb, but I'd say that very often we will not be that lucky.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 7 Oct 2014, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 33658
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33658action=edit
gcc5-pr63464.patch
Updated patch for the switchconv, this time checking rtx costs.
As for reassoc, the problem I see is that this kind of optimization needs to
split basic blocks, as left shift by negative or = word bit size is undefined
behavior, so the expected generated code is probably jump around the left
shift.
I think reassoc pass is not prepared to see splitting of basic blocks, nor
adding new PHI nodes etc. In the:
int
foo (int x)
{
return x == 1 || x == 2 || x == 4 || x == 6 || x == 15 || x == 17;
}
case we actually have 2 basic blocks and there is no other test ored in in
either of the basic blocks, so we could perform it even without creating a new
bb, but I'd say that very often we will not be that lucky.
But you could do preparations and do the actual transform splitting blocks
as a 2nd phase?
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
CC||ebotcazou at gcc dot gnu.org,
||law at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Component|middle-end |tree-optimization
Known to work||4.8.3, 4.9.2
Target Milestone|--- |5.0
Summary|request: make |[5 Regression] request:
|-Wstrict-overflow avoid a |make -Wstrict-overflow
|class of false positives|avoid a class of false
||positives
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
The warning is senseless for equality compares. We are trying to transform
(T) x CMP CST to x CMP (typeof x) CST - for equality compares it only matters
whether CST fits in typeof x. CCing Jeff who added the warning code last year
(making this a regression). 4.9 doesn't warn even if the warning code is
the same, 4.8 doesn't have the warning code.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 215917)
+++ gcc/tree-vrp.c (working copy)
@@ -9189,8 +9189,9 @@ simplify_cond_using_ranges (gimple stmt)
/* If the range overflowed and the user has asked for warnings
when strict overflow semantics were used to optimize code,
issue an appropriate warning. */
- if ((is_negative_overflow_infinity (vr-min)
- || is_positive_overflow_infinity (vr-max))
+ if (cond_code != EQ_EXPR cond_code != NE_EXPR
+ (is_negative_overflow_infinity (vr-min)
+ || is_positive_overflow_infinity (vr-max))
issue_strict_overflow_warning
(WARN_STRICT_OVERFLOW_CONDITIONAL))
{
location_t location;
_6 has [1, +INF(OVF)] beause of Erics new code handling symbolic ranges better
(CCing Eric):
Found new range for j_9: [i_15 + 1, +INF]
Visiting statement:
_6 = j_9 - i_15;
Found new range for _6: [1, +INF(OVF)]
i_15 could be negative and thus j_9 - i_15 could well overflow the input
range at the +INF side. (i_15 is [-INF, j_5(D) + -1])
I believe we are just better in propagating the ranges here and 4.9
computed _6 as VARYING (and thus not applying the optimization).
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Agustín Bergé from comment #15) (In reply to Jonathan Wakely from comment #14) Agustin, do you have a copyright assignment? I do not have one. The attached tuple is derived from libstdc++'s tuple and I have left the license in place, wouldn't that be enough? No. You are free to release your derived work under the terms of the GPL, but that is not sufficient for the code to be accepted into the FSF repository. I did not intend for the attachment to be a patch (it is not a patch, I did not consider coding styles, I did not run tests, etc), but merely a proof of concept implementation so that others could measure the compile-time performance win of a flat implementation. And that's fine. But to respond to Manu in comment 11 and comment 13, we need more than just a review, since the proof of concept attached here cannot be used without the usual legal prerequisites being met. Another option would be for someone else to provide a flat implementation, but again that is more than just a review.
[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-07 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #13 from Richard PALO richard at netbsd dot org --- [...] otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc 4.9.1 may be awhile before I have the time... What porting is there to do? For me, configure; make; make install just works on Solaris. Rainer
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |--- --- Comment #2 from John David Anglin danglin at gcc dot gnu.org --- Introduced by r215449: Author: rsandifo Date: Mon Sep 22 07:38:12 2014 New Revision: 215449 URL: https://gcc.gnu.org/viewcvs?rev=215449root=gccview=rev Log: gcc/ * hard-reg-set.h: Include hash-table.h. (target_hard_regs): Add a finalize method and a x_simplifiable_subregs field. * target-globals.c (target_globals::~target_globals): Call hard_regs-finalize. * rtl.h (subreg_shape): New structure. (shape_of_subreg): New function. (simplifiable_subregs): Declare. * reginfo.c (simplifiable_subreg): New structure. (simplifiable_subregs_hasher): Likewise. (simplifiable_subregs): New function. (invalid_mode_changes): Delete. (alid_mode_changes, valid_mode_changes_obstack): New variables. (record_subregs_of_mode): Remove subregs_of_mode parameter. Record valid mode changes in valid_mode_changes. (find_subregs_of_mode): Remove subregs_of_mode parameter. Update calls to record_subregs_of_mode. (init_subregs_of_mode): Remove invalid_mode_changes and bitmap handling. Initialize new variables. Update call to find_subregs_of_mode. (invalid_mode_change_p): Check new variables instead of invalid_mode_changes. (finish_subregs_of_mode): Finalize new variables instead of invalid_mode_changes. (target_hard_regs::finalize): New function. * ira-costs.c (print_allocno_costs): Call invalid_mode_change_p even when CLASS_CANNOT_CHANGE_MODE is undefined.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #13 from Ville Voutilainen ville.voutilainen at gmail dot com --- Hmm. The first of the two ICE tests still ICEs. It no longer stops my build, though - and I don't quite understand why, because previously the build ICEd when building the library pre-compiled headers.
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- i_15 could be negative and thus j_9 - i_15 could well overflow the input range at the +INF side. (i_15 is [-INF, j_5(D) + -1]) Actually, this is a very good point. There is indeed a potential integer overflow in the original code. Thus, the warning seems valid. Perhaps the warning message could say that the problem is that j - i can overflow if i is negative. A major problem with the Wstrict-overflow warning is that it is too cryptic. Even looking at the dump files it is not clear immediately when and why the warning is given. Another issue is that the location is off, it should point to j - i.
[Bug lto/59441] ICE in bitmap_element_allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59441 --- Comment #5 from Ilya Palachev i.palachev at samsung dot com --- Suggested a patch that fixes this. https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00546.html
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #18 from Ian Lance Taylor ian at airs dot com ---
Well, maybe it was only a problem with tail recursion,
Note that because Go programs expect predictable results from runtime.Callers
and other stack backtracing functions, the Go frontend disables tail recursion
(go_langhook_post_options in gcc/go/go-lang.c).
Hm, so the patch penalises platforms that cannot deal with the 16 byte window?
Yes, but, recall that on your system almost all tests pass using the code that
is in the tree today, before your patch. The only tests that fail are the very
challenging ones in recover.go, that stress test the panic/recover mechanism
but are in no way representative of real code. The normal tests all works
fine. So while there is a penalty, it is one that only occurs in rare cases.
func main() { defer foo(); panic(...); }
func foo() { defer bar(); }
func bar() { recover(); }
In this case, the call to recover in bar is supposed to return nil;
it should not recover the panic. If you read the paragraph before
the one you quote, you will see that recover only returns non-nil
if it was called by a function that was deferred before the call to
panic.
I've read it but cannot see anything that would disallow recovery in this
situation. What exactly do you mean?
The spec says Suppose a function G defers a function D that calls recover and
a panic occurs in a function on the same goroutine in which G is executing.
The order is 1) G defers D; 2) a panic occurs. In your example above, this
applies to main defers foo and then a panic occurs. It does not apply to foo
defers bar, because there is no panic after foo defers bar (the panic has
already occurred--that is why we are executing foo). Since there is no panic,
the recover in bar returns nil.
The recover.go file tests this pattern in, e.g., test1WithClosures.
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 7 Oct 2014, manu at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- i_15 could be negative and thus j_9 - i_15 could well overflow the input range at the +INF side. (i_15 is [-INF, j_5(D) + -1]) Actually, this is a very good point. There is indeed a potential integer overflow in the original code. Thus, the warning seems valid. Perhaps the warning message could say that the problem is that j - i can overflow if i is negative. Sure - but we warn about the comparison against zero which doesn't behave differently if overflow wraps or is undefined.
[Bug ipa/63470] New: [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 Bug ID: 63470 Summary: [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: mliska at suse dot cz CC: hubicka at ucw dot cz Starting from r215794 Firefox produces following error in WPA with -flto and --enable-checking=all: lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308 0x7d7fc1 estimate_edge_growth ../../gcc/ipa-inline.h:307 0x7d7fc1 estimate_size_after_inlining(cgraph_node*, cgraph_edge*) ../../gcc/ipa-inline-analysis.c:3817 0xf388d1 caller_growth_limits ../../gcc/ipa-inline.c:186 0xf388d1 can_inline_edge_p ../../gcc/ipa-inline.c:363 0xf3acdd update_callee_keys ../../gcc/ipa-inline.c:1236 0xf3c9a6 inline_small_functions ../../gcc/ipa-inline.c:1818 0xf3c9a6 ipa_inline ../../gcc/ipa-inline.c:2182 0xf3c9a6 execute ../../gcc/ipa-inline.c:2542 Edge: caller: _ZNK12SkRefCntBase16internal_disposeEv/14636955 (internal_dispose) @0x7f9c1a33d178 Type: function definition analyzed Visibility: virtual next sharing asm name: 14636951 References: Referring: Read from file: /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/toolkit/library/build/../../../gfx/2d/Unified_cpp_gfx_2d0.o Function internal_dispose/14636955 is inline copy in __base_dtor /13594851 Clone of _ZNK12SkRefCntBase16internal_disposeEv/14636951 Availability: local First run: 0 Function flags: local Called by: _ZNK12SkRefCntBase5unrefEv.part.40/14636954 (inlined) (indirect_inlining) (0.02 per call) Calls: _ZN13SkGPipeCanvasD0Ev/13594853 (indirect_inlining) (0.01 per call) callee: _ZN13SkGPipeCanvasD0Ev/13594853 (__deleting_dtor ) @0x7f9c1575d8d0 Type: function definition analyzed Visibility: prevailing_def_ironly virtual Address is taken. References: Referring: _ZTV13SkGPipeCanvas/13595722 (addr)_ZNK12SkRefCntBase16internal_disposeEv/14605659 (addr) (speculative)_ZNK12SkRefCntBase16internal_disposeEv/14614102 (addr) (speculative)_ZNK12SkRefCntBase16internal_disposeEv/14636951 (addr) (speculative) Read from file: /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/toolkit/library/build/../../../gfx/skia/Unified_cpp_gfx_skia20.o Availability: available First run: 0 Function flags: Called by: _ZNK12SkRefCntBase16internal_disposeEv/14636955 (indirect_inlining) (0.01 per call) _ZNK12SkRefCntBase16internal_disposeEv/14636951 (speculative) (indirect_inlining) (0.03 per call) _ZNK12SkRefCntBase16internal_disposeEv/14614102 (speculative) (indirect_inlining) (0.08 per call) _ZNK12SkRefCntBase16internal_disposeEv/14605659 (speculative) (indirect_inlining) (0.08 per call) Calls: moz_free/1431 (1.00 per call) _ZN13SkGPipeCanvasD1Ev/13594852 (1.00 per call) Thanks, Martin
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org ---
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.
When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), but that didn't make a
difference.
It converts the local variable to be a value-expr.
It's still not exactly clear who deletes the variable declaration though.
There are two possibilities:
- nrv shouldn't convert the variable in the first place
- someone who messes with the variables forgets to check for value-exprs.
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
NRV Replaced: l_55 with: retval
func_52 (uint32_t p_53)
{
extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4} [value-expr:
retval];
bb 2:
return retval;
}
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Andi Kleen from comment #6)
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.
When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), but that didn't make a
difference.
It converts the local variable to be a value-expr.
It's still not exactly clear who deletes the variable declaration though.
There are two possibilities:
- nrv shouldn't convert the variable in the first place
- someone who messes with the variables forgets to check for value-exprs.
;; Function func_52 (func_52, funcdef_no=86, decl_uid=2858, cgraph_uid=54,
symbol_order=1152)
NRV Replaced: l_55 with: retval
func_52 (uint32_t p_53)
{
extern const struct S0 l_55 = {.f0=4, .f1=40290, .f2=10, .f3=4}
[value-expr: retval];
only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
What does func_52 look like before the NRV pass? It must be sth like
retval = l_55;
?
Looks like a bug in nrv to me:
/* The returned value must be a local automatic variable of the
same type and alignment as the function's result. */
if (TREE_CODE (found) != VAR_DECL
|| TREE_THIS_VOLATILE (found)
|| DECL_CONTEXT (found) != current_function_decl
|| TREE_STATIC (found)
|| TREE_ADDRESSABLE (found)
|| DECL_ALIGN (found) DECL_ALIGN (result)
|| !useless_type_conversion_p (result_type,
TREE_TYPE (found)))
return 0;
should probably use auto_var_in_fn_p which checks for !DECL_EXTERNAL as well.
Index: gcc/tree-nrv.c
===
--- gcc/tree-nrv.c (revision 215917)
+++ gcc/tree-nrv.c (working copy)
@@ -216,8 +216,7 @@ pass_nrv::execute (function *fun)
same type and alignment as the function's result. */
if (TREE_CODE (found) != VAR_DECL
|| TREE_THIS_VOLATILE (found)
- || DECL_CONTEXT (found) != current_function_decl
- || TREE_STATIC (found)
+ || !auto_var_in_fn_p (found, current_function_decl)
|| TREE_ADDRESSABLE (found)
|| DECL_ALIGN (found) DECL_ALIGN (result)
|| !useless_type_conversion_p (result_type,
bb 2:
return retval;
}
[Bug ipa/63470] [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #18 from Teresa Johnson tejohnson at google dot com ---
On Mon, Oct 6, 2014 at 10:15 PM, Teresa Johnson tejohn...@google.com wrote:
I'm going to finish testing my patch, which passes regular
x86_64-unknown-linux-gnu bootstrap + regression tests. I am still
trying to get the lto profiledbootstrap to work. I found some
workarounds for the undefined reference issue on Honza's blog, and I
Nevermind, that was for something else, the issue was that I needed to
upgrade my binutils from 2.22 to 2.24. Now the LTO profiledbootstrap
is humming along.
Once I get a round of testing in I will send for review.
Thanks,
Teresa
am trying to get that working. Then I will send to gcc-patches for
review.
In the meantime, H.J. do you want to try the patch? It is below.
Thanks,
Teresa
2014-10-06 Teresa Johnson tejohn...@google.com
* tree-ssa-threadupdate.c (estimated_freqs_path): New function.
(ssa_fix_duplicate_block_edges): Invoke it.
(mark_threaded_blocks): Make two passes to avoid ordering dependences.
Index: tree-ssa-threadupdate.c
===
--- tree-ssa-threadupdate.c (revision 215830)
+++ tree-ssa-threadupdate.c (working copy)
@@ -959,6 +959,43 @@ update_joiner_offpath_counts (edge epath, basic_bl
}
+/* Check if the paths through RD all have estimated frequencies but zero
+ profile counts. This is more accurate than checking the entry block
+ for a zero profile count, since profile insanities sometimes creep in. */
+
+static bool
+estimated_freqs_path (struct redirection_data *rd)
+{
+ edge e = rd-incoming_edges-e;
+ vecjump_thread_edge * *path = THREAD_PATH (e);
+ edge ein;
+ edge_iterator ei;
+ bool non_zero_freq = false;
+ FOR_EACH_EDGE (ein, ei, e-dest-preds)
+{
+ if (ein-count)
+return false;
+ non_zero_freq |= ein-src-frequency != 0;
+}
+
+ for (unsigned int i = 1; i path-length (); i++)
+{
+ edge epath = (*path)[i]-e;
+ if (epath-src-count)
+return false;
+ non_zero_freq |= epath-src-frequency != 0;
+ edge esucc;
+ FOR_EACH_EDGE (esucc, ei, epath-src-succs)
+{
+ if (esucc-count)
+return false;
+ non_zero_freq |= esucc-src-frequency != 0;
+}
+}
+ return non_zero_freq;
+}
+
+
/* Invoked for routines that have guessed frequencies and no profile
counts to record the block and edge frequencies for paths through RD
in the profile count fields of those blocks and edges. This is because
@@ -1058,9 +1095,11 @@ ssa_fix_duplicate_block_edges (struct redirection_
data we first take a snapshot of the existing block and edge frequencies
by copying them into the empty profile count fields. These counts are
then used to do the incremental updates, and cleared at the end of this
- routine. */
+ routine. If the function is marked as having a profile, we still check
+ to see if the paths through RD are using estimated frequencies because
+ the routine had zero profile counts. */
bool do_freqs_to_counts = (profile_status_for_fn (cfun) != PROFILE_READ
- || !ENTRY_BLOCK_PTR_FOR_FN (cfun)-count);
+ || estimated_freqs_path (rd));
if (do_freqs_to_counts)
freqs_to_counts_path (rd);
@@ -2077,35 +2116,48 @@ mark_threaded_blocks (bitmap threaded_blocks)
/* Now iterate again, converting cases where we want to thread
through a joiner block, but only if no other edge on the path
- already has a jump thread attached to it. */
+ already has a jump thread attached to it. We do this in two passes,
+ to avoid situations where the order in the paths vec can hide
overlapping
+ threads (the path is recorded on the incoming edge, so we would miss
+ cases where the second path starts at a downstream edge on the same
+ path). First record all joiner paths, deleting any in the unexpected
+ case where there is already a path for that incoming edge. */
for (i = 0; i paths.length (); i++)
{
vecjump_thread_edge * *path = paths[i];
if ((*path)[1]-type == EDGE_COPY_SRC_JOINER_BLOCK)
+{
+ /* Attach the path to the starting edge if none is yet recorded. */
+ if ((*path)[0]-e-aux == NULL)
+(*path)[0]-e-aux = path;
+ else if (dump_file (dump_flags TDF_DETAILS))
+ dump_jump_thread_path (dump_file, *path, false);
+}
+}
+ /* Second, look for paths that have any other jump thread attached to
+ them, and either finish converting them or cancel them. */
+ for (i = 0; i paths.length (); i++)
+{
+ vecjump_thread_edge * *path = paths[i];
+ edge e = (*path)[0]-e;
+
+ if ((*path)[1]-type ==
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Tue Oct 7 16:13:22 2014 New Revision: 215974 URL: https://gcc.gnu.org/viewcvs?rev=215974root=gccview=rev Log: gcc/fortran/ChangeLog: 2014-10-06 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 PR fortran/54687 * gfortran.h (gfc_warning_cmdline): Add overload that takes an option. (gfc_error_cmdline): Declare. * error.c (gfc_warning_cmdline): New overload that takes an option. (gfc_error_cmdline): New. * lang.opt (Wmissing-include-dirs): New. * scanner.c (add_path_to_list): Use the new functions. (load_file): Likewise. * options.c (gfc_init_options): Wmissing-include-dirs is enabled by default in Fortran. (gfc_handle_option): Accept automatically handled options. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Tue Oct 7 16:13:22 2014 New Revision: 215974 URL: https://gcc.gnu.org/viewcvs?rev=215974root=gccview=rev Log: gcc/fortran/ChangeLog: 2014-10-06 Manuel López-Ibáñez m...@gcc.gnu.org PR fortran/44054 PR fortran/54687 * gfortran.h (gfc_warning_cmdline): Add overload that takes an option. (gfc_error_cmdline): Declare. * error.c (gfc_warning_cmdline): New overload that takes an option. (gfc_error_cmdline): New. * lang.opt (Wmissing-include-dirs): New. * scanner.c (add_path_to_list): Use the new functions. (load_file): Likewise. * options.c (gfc_init_options): Wmissing-include-dirs is enabled by default in Fortran. (gfc_handle_option): Accept automatically handled options. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/scanner.c
[Bug bootstrap/61565] [4.10 Regression] ICE building libjava/interpret.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61565 --- Comment #6 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Tue Oct 7 16:17:57 2014 New Revision: 215975 URL: https://gcc.gnu.org/viewcvs?rev=215975root=gccview=rev Log: 2014-10-07 Venkataramanan Kumar venkataramanan.ku...@linaro.org Backport from trunk r209643, r211881. 2014-06-22 Richard Henderson r...@redhat.com PR target/61565 * compare-elim.c (struct comparison): Add eh_note. (find_comparison_dom_walker::before_dom_children): Don't eliminate a redundant comparison in a different EH region. Purge EH edges if necessary. 2014-04-22 Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/aarch64/aarch64.c (TARGET_FLAGS_REGNUM): Define. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/compare-elim.c branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.c
[Bug target/61981] PowerPC Linux Split-Stack Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981 Daisuke Oka daisuke_oka at nanosoftware dot biz changed: What|Removed |Added CC||daisuke_oka at nanosoftware dot bi ||z --- Comment #2 from Daisuke Oka daisuke_oka at nanosoftware dot biz --- Hello David Edelsohn san My name is Daisuke Oka from Japan is PowerPC Linux Linux installed in Mac? for example Devian Linux in Mac. I will try to solve this problem.
[Bug libfortran/63471] New: [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Bug ID: 63471 Summary: [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-5.0/hppa 64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-5.0/hppa64-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -iquote../../../gcc/libgfortran/io -I../../../gc c/libgfortran/../gcc -I../../../gcc/libgfortran/../gcc/config -I../../../gcc/lib gfortran/../libquadmath -I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT unix.lo -MD -MP -MF .deps/unix.Tpo -c ../../../gcc/libgfortran/io/unix.c -DPIC -o .libs/unix.o ../../../gcc/libgfortran/io/unix.c: In function 'stream_ttyname': ../../../gcc/libgfortran/io/unix.c:1906:10: error: implicit declaration of function 'ttyname_r' [-Werror=implicit-function-declaration] return ttyname_r (((unix_stream *) s)-fd, buf, buflen); ^ cc1: some warnings being treated as errors make[3]: *** [unix.lo] Error 1 Probably _REENTRANT is not defined.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Ville Voutilainen from comment #13) Hmm. The first of the two ICE tests still ICEs. Which test? None of the tests are ICEing for me.
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Found new range for j_9: [i_15 + 1, +INF]
Visiting statement:
_6 = j_9 - i_15;
Found new range for _6: [1, +INF(OVF)]
i_15 could be negative and thus j_9 - i_15 could well overflow the input
range at the +INF side. (i_15 is [-INF, j_5(D) + -1])
Yes, the range is as expected here but...
I believe we are just better in propagating the ranges here and 4.9
computed _6 as VARYING (and thus not applying the optimization).
...we actually don't apply any optimization to the code:
Value ranges after VRP:
n_1: [1, +INF] EQUIVALENCES: { n_7 c_8 n_16 } (3 elements)
_2: [1, +INF] EQUIVALENCES: { n_7 n_16 } (2 elements)
pretmp_3: ~[0, 0]
i_4(D): VARYING
j_5(D): VARYING
_6: [1, +INF(OVF)]
n_7: [0, +INF]
[...]
bb 2:
if (i_4(D) j_5(D))
goto bb 3;
else
goto bb 7;
bb 3:
_6 = j_5(D) - i_4(D);
n_7 = (unsigned int) _6;
if (_6 != 0)
goto bb 4;
else
goto bb 7;
The range of n_7 is suboptimal and the test on _6 can be eliminated.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #15 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #14)
(In reply to Ville Voutilainen from comment #13)
Hmm. The first of the two ICE tests still ICEs.
Which test? None of the tests are ICEing for me.
This one:
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
}
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #16 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Ville Voutilainen from comment #15)
(In reply to Jason Merrill from comment #14)
(In reply to Ville Voutilainen from comment #13)
Hmm. The first of the two ICE tests still ICEs.
Which test? None of the tests are ICEing for me.
This one:
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
}
And the trace is
[ville@localhost ~]$ g++ --std=c++14 -c trivial_trait.cpp
trivial_trait.cpp:5:43: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in comptypes, at cp/typeck.c:1391
__is_trivially_constructible(T, Args...)::type
^
0xe07427 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9226
0x6b4f50 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:2856
0x6b4f50 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1391
0x5c2934 template_args_equal
../../gcc/cp/pt.c:7223
0x5c2fbe comp_template_args_with_info
../../gcc/cp/pt.c:7250
0x5c30ec comp_template_args(tree_node*, tree_node*)
../../gcc/cp/pt.c:7268
0x5c30ec eq_specializations
../../gcc/cp/pt.c:1512
0x123c2c4 htab_find_with_hash
../../libiberty/hashtab.c:598
0x5e9b31 lookup_template_class_1
../../gcc/cp/pt.c:7688
0x5e9b31 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:7979
0x700da2 finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:2981
0x6936e9 cp_parser_template_id
../../gcc/cp/parser.c:13658
0x6939f8 cp_parser_class_name
../../gcc/cp/parser.c:19487
0x687b4a cp_parser_qualifying_entity
../../gcc/cp/parser.c:5570
0x687b4a cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:5295
0x69fec0 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:14864
0x67b725 cp_parser_type_specifier
../../gcc/cp/parser.c:14610
0x67c97b cp_parser_type_specifier_seq
../../gcc/cp/parser.c:18355
0x691e52 cp_parser_type_id_1
../../gcc/cp/parser.c:18227
0x691f4e cp_parser_template_type_arg
../../gcc/cp/parser.c:18277
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #17 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Ville Voutilainen from comment #16)
This one:
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
}
Yeah, that works fine for me. Perhaps the ICE is related to changes you've
made to type_traits?
[Bug c++/63472] New: transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472
Bug ID: 63472
Summary: transaction_atomic within while loop causes ICE
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: spear at cse dot lehigh.edu
Summary:
The following code produces an ICE when compiled with g++ -fgnu-tm bug.cc -c
int val;
void test() {
while (true) {
__transaction_atomic {
if (val == 42)
return;
}
}
}
Error Message:
bug.cc: In function ‘void test()’:
bug.cc:12:1: internal compiler error: in duplicate_block, at cfghooks.c:1032
}
^
0x84c987 duplicate_block(basic_block_def*, edge_def*, basic_block_def*)
../../source_git/gcc/cfghooks.c:1032
0x84cca5 copy_bbs(basic_block_def**, unsigned int, basic_block_def**,
edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool)
../../source_git/gcc/cfghooks.c:1312
0xbd6139 ipa_uninstrument_transaction
../../source_git/gcc/trans-mem.c:4093
0xbd6139 ipa_tm_scan_calls_transaction
../../source_git/gcc/trans-mem.c:4167
0xbd6139 ipa_tm_execute
../../source_git/gcc/trans-mem.c:5340
0xbd6139 execute
../../source_git/gcc/trans-mem.c:5578
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.
GCC Information:
gcc (GCC) 5.0.0 20141007 (experimental)
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215970
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug other/56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 52278, which changed state. Bug 52278 Summary: [4.8/4.9/5 Regression] [avr] inefficient register allocation for SUBREGs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME
[Bug other/52278] [4.8/4.9/5 Regression] [avr] inefficient register allocation for SUBREGs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52278 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.2 Resolution|--- |WORKSFORME Known to fail|4.8.0 | --- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org --- Works for me in 4.8 and 4.9.
[Bug objc++/61759] [ICE] [objc] reaching gcc_unreachable in objc_eh_runtime_type at objc/objc-next-runtime-abi-01.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61759 --- Comment #5 from Douglas Mencken dougmencken at gmail dot com --- Now I know it's question about non-well-supported NeXT Objective C ABIs. Will try -fgnu-runtime
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #18 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #17)
(In reply to Ville Voutilainen from comment #16)
This one:
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
}
Yeah, that works fine for me. Perhaps the ICE is related to changes you've
made to type_traits?
Fishy. Taking integral_constant and __and_ (and conditional) from type_traits
and faking is_constructible works fine. My modifications to type_traits work
fine when used in a test program, so compiling the actual trait itself seems
to work just fine. Yet this particular test will not work with my
modifications,
but works without them (I just tested that).
Well, this test is an ill-formed program, it's using names reserved to
the implementation. :)
[Bug c/59717] better warning when using functions without including appropriate header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Oct 7 17:49:46 2014 New Revision: 215979 URL: https://gcc.gnu.org/viewcvs?rev=215979root=gccview=rev Log: PR c/59717 * c-decl.c (header_for_builtin_fn): New function. (implicitly_declare): Suggest which header to include. * gcc.dg/pr59717.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr59717.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/59717] better warning when using functions without including appropriate header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59717 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #19 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Ville Voutilainen from comment #18) to work just fine. Yet this particular test will not work with my modifications, but works without them (I just tested that). Attach a preprocessed file that ICEs?
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #8 from andi at firstfloor dot org ---
only automatic vars may have a VALUE_EXPR, certainly not 'extern const' stuff.
It's an initializer for an automatic var in the source
func_52() {
struct S0 foo = { ... }
...
}
What does func_52 look like before the NRV pass? It must be sth like
retval = l_55;
?
Yes it looks like that.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #20 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #19)
(In reply to Ville Voutilainen from comment #18)
to work just fine. Yet this particular test will not work with my
modifications, but works without them (I just tested that).
Attach a preprocessed file that ICEs?
The presence of a libiberty hash operation
and comptypes would suggest that it's something to do with the lookup of
templates,
when there's already a template that is more or less similar, and then
a definition of another one quite like it with a different name...
This test fails even without my changes in type_traits:
#include type_traits
template typename T, class... Args
struct mytrait : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
};
template typename T, class... Args
struct mytrait2 : public std::__and_std::is_constructibleT, Args...,
std::integral_constantbool,
__is_trivially_constructible(T, Args...)::type
{
};
Ok, I can even reduce it, again:
template bool b struct bool_
{
};
template typename T, class... Args
struct mytrait : bool___is_trivially_constructible(T, Args...)
{
};
template typename T, class... Args
struct mytrait2 : bool___is_trivially_constructible(T, Args...)
{
};
[ville@localhost ~]$ g++ --std=c++14 -c trivial_trait3.cpp
trivial_trait3.cpp:11:65: internal compiler error: tree check: expected class
‘type’, have ‘exceptional’ (tree_list) in comptypes, at cp/typeck.c:1391
struct mytrait2 : bool___is_trivially_constructible(T, Args...)
^
0xe07427 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.c:9226
0x6b4f50 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:2856
0x6b4f50 comptypes(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:1391
0x5c2934 template_args_equal
../../gcc/cp/pt.c:7223
0x5c2fbe comp_template_args_with_info
../../gcc/cp/pt.c:7250
0x5c30ec comp_template_args(tree_node*, tree_node*)
../../gcc/cp/pt.c:7268
0x5c30ec eq_specializations
../../gcc/cp/pt.c:1512
0x123c2c4 htab_find_with_hash
../../libiberty/hashtab.c:598
0x5e9b31 lookup_template_class_1
../../gcc/cp/pt.c:7688
0x5e9b31 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:7979
0x700da2 finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:2981
0x6936e9 cp_parser_template_id
../../gcc/cp/parser.c:13658
0x6939f8 cp_parser_class_name
../../gcc/cp/parser.c:19487
0x687b4a cp_parser_qualifying_entity
../../gcc/cp/parser.c:5570
0x687b4a cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:5295
0x67aae9 cp_parser_base_specifier
../../gcc/cp/parser.c:21231
0x67aae9 cp_parser_base_clause
../../gcc/cp/parser.c:21080
0x67aae9 cp_parser_class_head
../../gcc/cp/parser.c:20293
0x67aae9 cp_parser_class_specifier_1
../../gcc/cp/parser.c:19567
0x67b990 cp_parser_class_specifier
../../gcc/cp/parser.c:19859
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #19 from Jeffrey A. Law law at redhat dot com --- On 10/04/14 09:34, Teresa Johnson wrote: Looking at the code, I think it attempts to check for this case and prevent it but that code does not work in this case because of the order the paths are identified and subsequently iterated in the paths vec. In mark_threaded_blocks it looks at paths with joiners and if there are any edges along the path already part of another path it will skip that path. But in this case, we registered the paths in this order: Registering jump thread: (119, 150) incoming edge; (150, 13) joiner; (13, 15) normal; ... Registering jump thread: (150, 13) incoming edge; (13, 15) joiner; (15, 17) normal; For the first path, the path is attached to incoming edge 119-150. So when we walk edges in the 2nd path we don't see the first path. If we looked at the paths in the reverse order we would have seen the path attached to incoming edge 150-13 and skipped the 119-150 path. Note that we end up doing the actual threading in the reverse order - first we do the threading through 13 (the second path), then later the threading through 150 (the first path), leading to the issue I am seeing. Jeff, what is intended here - should we not be threading both of these paths? The code in mark_threaded_jumps looks for cases where there is a jump threading path with a joiner block is subsumed by a jump threading path without a joiner block and it will suppress the jump threading path with the joiner. We had more suppressed paths in the past, but they mostly got ripped out as the implementation solidified. In the case shown above, we have two paths with joiner blocks so the suppression code in mark_threaded_blocks does not fire and we attempt to realize both jump threading paths. From a correctness standpoint the code should handle this case; however, there may be strong reasons to suppress one path or the other from a code bloat and/or performance standpoint. I typically have to draw out the CFG and the intermediate steps to gain clarity into the desired result and there's not enough info here to do that. My gut tells me suppression of one jump thread path is desirable, we aren't going to have anything good to guide which path to suppress, the vast majority of the time it won't matter which path is suppressed. So I'm comfortable with suppressing either path. jeff
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #20 from Jeffrey A. Law law at redhat dot com --- On 10/04/14 13:29, Teresa Johnson wrote: Jeff, what is intended here - should we not be threading both of these paths? I have a patch to make the mark_threaded_blocks checking of paths work regardless of the ordering of paths in the vec. This fixes the failure. This seems like a better solution. It'll decrease unnecessary block copying. The other approach is whenever we finish threading a path, go through the vec of remaining paths and update the edges for any that have been affected by the threading and that should instead include the duplicated edges. That'd probably work too, but I suspect there's not much, if any, benefit to keeping both paths. Jeff
[Bug c/63474] New: Optimizer bug causes crash on unaligned integer writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474 Bug ID: 63474 Summary: Optimizer bug causes crash on unaligned integer writes Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jaf at meyersound dot com Created attachment 33660 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33660action=edit trivial example program to reproduce the fault I think this is an optimizer bug, since Intel machines should be able to perform non-word-aligned integer writes without crashing. Also, the crash only occurs if optimization is enabled. To reproduce: 1) On an Intel machine, compile and run the attached trivial example program using gcc 4.7.2, like this: root@debian7:/home/jaf/cs6/software# gcc --version gcc (Debian 4.7.2-5) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. root@debian7:/home/jaf/cs6/software# gcc -O3 ./bug_in_gcc_4.7.2.c root@debian7:/home/jaf/cs6/software# ./a.out Testing for g++ unaligned-word-writes optimizer bug... (sizeof(int)==4) Begin unaligned writes to 8 words... Segmentation fault Note the segmentation fault above, which is unexpected. Compiling with -O2 optimization or lower gives the expected (non-crashing) behavior: root@debian7:/home/jaf/cs6/software# gcc -O2 ./bug_in_gcc_4.7.2.c root@debian7:/home/jaf/cs6/software# ./a.out Testing for g++ unaligned-word-writes optimizer bug... (sizeof(int)==4) Begin unaligned writes to 8 words... End unaligned writes. Resulting buffer is: 4a 4a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a
[Bug c/63474] Optimizer bug causes crash on unaligned integer writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- 4.7 is not supported anymore, could you try more recent gcc?
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Attachment #33644|0 |1 is obsolete|| --- Comment #19 from Ian Lance Taylor ian at airs dot com --- Created attachment 33661 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33661action=edit possible patch 2 Here is a new possible patch. This time I tested it on a PPC GNU/Linux machine. The problem was a mishandling of the stack walk when using MakeFunc with FFI closures. This passes on both x86_64 and PPC. It also address Dominik's case in which there is a spurious recover when one MakeFunc function calls another. Please review this patch and let me know if this fails on your system. Thanks.
[Bug fortran/63473] New: Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 Bug ID: 63473 Summary: Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: paul.vandelst at noaa dot gov Created attachment 33659 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33659action=edit Test program that exhibits the memory leak issue. I'm seeing the following valgrind output from the attached test program using gfortran 4.8.2 and 4.9.2: $ gfortran -g test_allocarg.f90 $ valgrind --leak-check=full ./a.out ==13675== Memcheck, a memory error detector ==13675== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==13675== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==13675== Command: ./a.out ==13675== F T T ==13675== ==13675== HEAP SUMMARY: ==13675== in use at exit: 2,160 bytes in 61 blocks ==13675== total heap usage: 80 allocs, 19 frees, 7,774 bytes allocated ==13675== ==13675== 800 bytes in 40 blocks are definitely lost in loss record 2 of 3 ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==13675==by 0x400CF0: __testmodule_MOD_create_mytype (test_allocarg.f90:15) ==13675==by 0x400B74: __testmodule_MOD_allocate_mytype (test_allocarg.f90:24) ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40) ==13675==by 0x400E94: main (test_allocarg.f90:33) ==13675== ==13675== 1,360 (960 direct, 400 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==13675==at 0x4A069EE: malloc (vg_replace_malloc.c:270) ==13675==by 0x4009DA: __testmodule_MOD_allocate_mytype (test_allocarg.f90:22) ==13675==by 0x400E47: MAIN__ (test_allocarg.f90:40) ==13675==by 0x400E94: main (test_allocarg.f90:33) ==13675== ==13675== LEAK SUMMARY: ==13675==definitely lost: 1,760 bytes in 41 blocks ==13675==indirectly lost: 400 bytes in 20 blocks ==13675== possibly lost: 0 bytes in 0 blocks ==13675==still reachable: 0 bytes in 0 blocks ==13675== suppressed: 0 bytes in 0 blocks ==13675== ==13675== For counts of detected and suppressed errors, rerun with: -v ==13675== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6) Note in the test program the loop around the allocation subroutine call. Memory leaks do NOT occur on the first call, only on subsequent calls when the array is already allocated. It appears the INTENT(OUT) attribute of the dummy argument with the allocatable attribute is not being honoured. cheers, paulv p.s. Below are the outputs of gcc -v on my linux box: * For v4.8.2 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr1/wd20pd/local/gcc-4.8/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-source/gcc-4.8-20130801/configure --enable-languages=c,c++,fortran --enable-checking=release --disable-libmudflap --disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold --with-plugin-ld=/usr/bin/gold --with-cloog-include=/usr/include-cloog --with-cloog-lib=/usr/lib64 --prefix=/usr/local/gcc-4.8 Thread model: posix gcc version 4.8.2 20130801 (prerelease) (GCC) * For v4.9.2 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr1/wd20pd/local/gcc-4.9/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9-source/gcc-4.9-20141001/configure --enable-languages=c,c++,fortran --enable-checking=release --disable-libmudflap --disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold --with-plugin-ld=gold --with-cloog-include=/usr/include-cloog --with-cloog-lib=/usr/lib64 --prefix=/usr/local/gcc-4.9 Thread model: posix gcc version 4.9.2 20141001 (prerelease) (GCC)
[Bug c/63474] Optimizer bug causes crash on unaligned integer writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63474 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Even though Intel machines can perform GPRs loads and stores unaligned but some SSE load/stores can't do unaligned. Also in C, it is undefined to access an unaligned pointer.
[Bug rtl-optimization/63475] New: Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475
Bug ID: 63475
Summary: Postreload CSE propagates aliased memory operand
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Following testcase:
--cut here--
extern void foo (void);
static char aaa = 0;
static char bbb = 0;
void bar (void)
{
char aaa_sav = aaa, bbb_sav = bbb;
aaa = 1;
bbb = 1;
foo ();
aaa = aaa_sav;
bbb = bbb_sav;
}
--cut here--
exposes the problem where posteload CSE eliminates a memory load by propagating
memory load with alignment AND over memory store (also with alignment and).
These two locations alias in the above case, the second store overwrites the
value of the first location.
This problem can be analyzed with a crosscompiler to alpha-linux-gnu and -O2
-mexplicit-relocs.
This is expanded RTL sequence up to the call:
5: r72:DI=high(`aaa')
6: r76:DI=[r72:DI+low(`aaa')0xfff8]
7: r77:DI=r72:DI+low(`aaa')
8: r75:QI#0=zero_extract(r76:DI,0x8,r77:DI0x3)
9: r73:DI=r75:QI#0
10: r74:DI=r73:DI0x38
11: r70:DI=r74:DI0x38
12: r78:DI=high(`bbb')
13: r82:DI=[r78:DI+low(`bbb')0xfff8]
14: r83:DI=r78:DI+low(`bbb')
15: r81:QI#0=zero_extract(r82:DI,0x8,r83:DI0x3)
16: r79:DI=r81:QI#0
17: r80:DI=r79:DI0x38
18: r71:DI=r80:DI0x38
19: r84:DI=high(`aaa')
20: r85:QI=0x1
21: r87:DI=[r84:DI+low(`aaa')0xfff8]
22: r86:DI=r84:DI+low(`aaa')
23: r87:DI=!0xffr86:DI0x3r87:DI
24: r88:DI=zero_extend(r85:QI)r86:DI0x3
25: r88:DI=r88:DI|r87:DI
26: [r84:DI+low(`aaa')0xfff8]=r88:DI
27: r89:DI=high(`bbb')
28: r90:QI=0x1
29: r92:DI=[r89:DI+low(`bbb')0xfff8]
30: r91:DI=r89:DI+low(`bbb')
31: r92:DI=!0xffr91:DI0x3r92:DI
32: r93:DI=zero_extend(r90:QI)r91:DI0x3
33: r93:DI=r93:DI|r92:DI
34: [r89:DI+low(`bbb')0xfff8]=r93:DI
35: call [`foo'] argc:0
REG_CALL_DECL `foo'
Just before postreload CSE, we have:
5: $13:DI=high(`aaa')
REG_EQUIV high(`aaa')
12: $11:DI=high(`bbb')
REG_EQUIV high(`bbb')
7: $14:DI=$13:DI+low(`aaa')
REG_EQUIV `aaa'
6: $1:DI=[$13:DI+low(`aaa')0xfff8]
20: $3:QI=0x1
REG_EQUIV 0x1
13: $2:DI=[$11:DI+low(`bbb')0xfff8]
24: $4:DI=zero_extend($3:QI)$14:DI0x3
REG_EQUAL 0x1`aaa'0x3
23: $5:DI=!0xff$14:DI0x3$1:DI
14: $12:DI=$11:DI+low(`bbb')
REG_EQUIV `bbb'
25: $4:DI=$4:DI|$5:DI
26: [$13:DI+low(`aaa')0xfff8]=$4:DI
9: $1:DI=zero_extract($1:DI,0x8,$14:DI0x3)
29: $4:DI=[$11:DI+low(`bbb')0xfff8]
16: $2:DI=zero_extract($2:DI,0x8,$12:DI0x3)
10: $1:DI=$1:DI0x38
17: $2:DI=$2:DI0x38
31: $4:DI=!0xff$12:DI0x3$4:DI
32: $3:DI=zero_extend($3:QI)$12:DI0x3
REG_EQUAL 0x1`bbb'0x3
11: $9:DI=$1:DI0x38
18: $10:DI=$2:DI0x38
33: $3:DI=$3:DI|$4:DI
34: [$11:DI+low(`bbb')0xfff8]=$3:DI
35: call [`foo'] argc:0
REG_CALL_DECL `foo'
Please note (insn 29). The new value of aaa (+ neighborhood) was stored in
(insn 26) and value of bbb (+ aliased neighborhood including value of aaa) is
read. (insn 34) stores both: aliased value of aaa and updated value of bbb.
Here comes postreload CSE:
5: $13:DI=high(`aaa')
REG_EQUIV high(`aaa')
12: $11:DI=high(`bbb')
REG_EQUIV high(`bbb')
7: $14:DI=$13:DI+low(`aaa')
REG_EQUIV `aaa'
6: $1:DI=[$13:DI+low(`aaa')0xfff8]
20: $3:QI=0x1
REG_EQUIV 0x1
13: $2:DI=[$11:DI+low(`bbb')0xfff8]
24: $4:DI=zero_extend($3:QI)$14:DI0x3
REG_EQUAL 0x1`aaa'0x3
23: $5:DI=!0xff$14:DI0x3$1:DI
14: $12:DI=$11:DI+low(`bbb')
REG_EQUIV `bbb'
25: $4:DI=$4:DI|$5:DI
26: [$13:DI+low(`aaa')0xfff8]=$4:DI
9: $1:DI=zero_extract($1:DI,0x8,$14:DI0x3)
29: $4:DI=$2:DI
16: $2:DI=zero_extract($2:DI,0x8,$12:DI0x3)
10: $1:DI=$1:DI0x38
17: $2:DI=$2:DI0x38
31: $4:DI=!0xff$12:DI0x3$4:DI
32: $3:DI=zero_extend($3:QI)$12:DI0x3
REG_EQUAL 0x1`bbb'0x3
11: $9:DI=$1:DI0x38
18: $10:DI=$2:DI0x38
33: $3:DI=$3:DI|$4:DI
34: [$11:DI+low(`bbb')0xfff8]=$3:DI
35: call [`foo'] argc:0
REG_CALL_DECL `foo'
Please again note (insn 29). The propagated value of bbb doesn't include
updated value in the memory location of aaa, as the propagation doesn't mind
aliased store to aaa in (insn 26). As a consequence, the final store in (insn
34) overwrites aliased location of aaa with its original value!
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #15 from Richard PALO richard at netbsd dot org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #14) --- Comment #13 from Richard PALO richard at netbsd dot org --- [...] otherwise, I'll have to port a more recent gdb because 7.6.1 balks under gcc 4.9.1 may be awhile before I have the time... What porting is there to do? For me, configure; make; make install just works on Solaris. Rainer Well, I get this, for example: In file included from opncls.c:26:0: opncls.c: In function 'bfd_fopen': bfd.h:529:65: error: right-hand operand of comma expression has no effect [-Werror=unused-value] #define bfd_set_cacheable(abfd,bool) (((abfd)-cacheable = bool), TRUE) ^ opncls.c:263:5: note: in expansion of macro 'bfd_set_cacheable' bfd_set_cacheable (nbfd, TRUE); ^
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Can you try the patches I posted here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02637.html ? They're conceptually a single change, I just split them up for review. Thanks, Richard
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 --- Comment #4 from dave.anglin at bell dot net --- On 10/7/2014 2:48 PM, rsandifo at gcc dot gnu.org wrote: Can you try the patches I posted here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02637.html Will do when I get home. Thanks, Dave
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #21 from Teresa Johnson tejohnson at google dot com --- On Tue, Oct 7, 2014 at 11:08 AM, Jeff Law l...@redhat.com wrote: On 10/04/14 13:29, Teresa Johnson wrote: Jeff, what is intended here - should we not be threading both of these paths? I have a patch to make the mark_threaded_blocks checking of paths work regardless of the ordering of paths in the vec. This fixes the failure. This seems like a better solution. It'll decrease unnecessary block copying. Ok, great. The patch I posted had a bug I introduced when cleaning it up that was caught by my LTO profiledbootstrap in that I wasn't resetting the e-aux pointer back to NULL when canceling the jump thread. I am kicking off the testing again and should hopefully have a final patch to send to gcc-patches later today. The other approach is whenever we finish threading a path, go through the vec of remaining paths and update the edges for any that have been affected by the threading and that should instead include the duplicated edges. That'd probably work too, but I suspect there's not much, if any, benefit to keeping both paths. Yeah, in this case the extra threading worked from a correctness standpoint but doesn't make sense from a logical or performance standpoint. I typically have to draw out the CFG and the intermediate steps to gain clarity into the desired result and there's not enough info here to do that. I'm glad I'm not the only one who has to draw it out every time! Thanks, Teresa Jeff
[Bug target/61387] [5 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 --- Comment #15 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Author: mrs Date: Tue Oct 7 18:59:24 2014 New Revision: 215983 URL: https://gcc.gnu.org/viewcvs?rev=215983root=gccview=rev Log: 2014-10-07 Iain Sandoe i...@codesourcery.com PR target/61387 * config/i386/i386.c (x86_output_mi_thunk): Fix darwin fallout. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/61387] [5 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Fixed.
[Bug target/61387] [5 Regression] ~900 test failures on on x86_64-apple-darwin13 for g++ with -m64 after r211089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61387 --- Comment #17 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fixed. Thanks Mike!
[Bug middle-end/63434] builtins.c has incorrect parameters for GEN_CALL_VALUE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63434 --- Comment #2 from steve at hearnden dot org.uk --- (In reply to Richard Biener from comment #1) Patches should be sent to gcc-patches@ I was trying to be sure that my understanding was correct before posting my fix. I have since found in the mmix config, a work around for what appears to be this bug, so I am fairly sure I am on the right lines. If someone could validate what the 4th and 5th parameters are meant to be, then I can post my fix.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #22 from Jan Hubicka hubicka at ucw dot cz --- Concerning Richard's comment, it is true that we will produce more warings then before in case function is optimized out. But we always did produce extra warnings when the function call is optimized out (as dead or pure/const unused) during RTL optimization. Of course this was more common before we got tree-ssa, but the feature AFAIK predates that. This is ugly area, because it exposes too much of internals. The only duplicate decls are the C extern inline __attribute__((gnu_inline)) (or -std=c89/gnu89 extern inline) or C++ inline __attribute__((gnu_inline)). We do have a middle-end representation of those, don't we? We don't. We really replace inline version by offline and mark it noinline. With Winline you get warning redefined extern inline functions are not considered for inlining Here I think a way around would be to make C/C++ FEs to produce a static inline function and record in its cgraph node that it should be used for inlining of some other symbol. Unreachable code removal would need to be extended to deal with this (i.e. not remove it until references to the real symbol disappears) and inliner can handle it easily redirecting to the inline version prior inlining. I never got past implementing the frontend part though. Do you have a problem that they have the same asm names, or DECL_NAME, something else? Asm name, since Zack's one declaration changes, we are supposed to have only one decl for an ASM name. It is not always true - the warning attribute is one offender and in some cases FEs still break the rule. If you wanted different asm names (e.g. normal asm name plus space at the end), we'd need some code to change calls to the functions with space after it back into ones without it if inlining failed. This still does break one declaration rule because we would end up with two declarations and two symbols for one real symbol. This cause problems, because we need to consider this i.e. in testing symbols for equality etc. We do have a precedent here - the weakrefs are the same evil. I could generalize weakref code to also handle warnings(), pattern match this sepcific use (where we have two symbols for one asm name that differs by warnings), keep the non-warning global, turn the warning decl static weakref translating into the global decl. Making it static is needed to support different warning messsages across multiple LTO units - we must not merge the warning annotated symbols. Now of course this will need a lot of extra special casing of weakref because currently we belive the visibility properties of the duplicated decl that does not match the visibility properties of the real node. For weakref I just redirect all refernces to the prevailing declaration if it exists that solves the problem. This would disable the warnings. So while I can implement this, it is not bacportable to 4.8/4.9 and it will likely trigger interesting side cases for a while, like weakref did. We can also put warning attribute into gimple call. Honza
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
We have this optimization implemented for switches,
Thanks, that's indeed the most natural place for it, although I hadn't thought
of testing that...
Glibc's strspn has:
__STRING_INLINE size_t
__strspn_c3 (const char *__s, int __accept1, int __accept2, int __accept3)
{
size_t __result = 0;
/* Please note that __accept1 to __accept3 never can be '\0'. */
while (__s[__result] == __accept1 || __s[__result] == __accept2
|| __s[__result] == __accept3)
++__result;
return __result;
}
This is only called when optimizing and with a second argument that is a string
literal, but it is still inconvenient to turn that into a switch, so it seems
useful to optimize this form as well (well, maybe we could expand
__builtin_strspn in gcc instead so it also works for larger constant second
arguments, but creating a loop is not so nice and there are plenty of other
similar functions).
(By the way, those optimizations are protected by a test __builtin_constant_p
(s) which only seems to be true if passing _directly_ a string literal, maybe
__builtin_constant_p could be made to return true a bit more often, or glibc
could test instead __builtin_constant_p (s[0]) etc)
(For completeness, I also compared with a repne scasb; je version I found
somewhere in glibc, which was more than 20 times slower, and quite difficult to
generate since we don't allow clobbers on asm goto...)
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #7 from Marc Glisse glisse at gcc dot gnu.org ---
The SLP version is slightly slower than the bit test in this case (at least on
my old desktop), but it can more easily handle testing for characters that are
not within 64 of each other.
__m128i b=_mm_set1_epi8(*s);
__m128i m=_mm_set_epi8('\n','\r',',',' ',' ',' ',' ',' ',' ',' ',' ',' ','
',' ',' ',' ');
__m128i e=_mm_cmpeq_epi8(b,m);
bool found=_mm_movemask_epi8(e)!=0;
Though we are missing REDUC_TRUTH_OR_EXPR to model the last line.
[Bug tree-optimization/63476] New: [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476
Bug ID: 63476
Summary: [5 Regression] ICE: tree check: expected ssa_name,
have var_decl in walk_aliased_vdefs_1, at
tree-ssa-alias.c:2689
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
On ppc64 I get:
trippels@gcc1-power7: % cat nsCacheService.ii
enum class nsresult;
class A;
class B
{
public:
B (int);
A *operator-();
};
class C
{
};
class A
{
public:
virtual nsresult AddObserver (const char *, C *, bool) = 0;
};
class D : A
{
nsresult
AddObserver (const char *p1, C *p2, bool p3)
{
AddObserver (p1, p2, p3);
}
};
char *prefList[]{};
class F : C
{
nsresult Install ();
};
nsresult
F::Install ()
{
B branch = 0;
for (int i;;)
branch-AddObserver (prefList[i], this, false);
}
trippels@gcc1-power7: % c++ -c -std=gnu++0x -O3 nsCacheService.ii
nsCacheService.ii: In function ‘virtual nsresult D::AddObserver(const char*,
C*, bool)’:
nsCacheService.ii:20:3: internal compiler error: tree check: expected ssa_name,
have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
AddObserver (const char *p1, C *p2, bool p3)
^
0x10c40f8f tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9175
0x10a88313 tree_check
../../gcc/gcc/tree.h:2733
0x10a88313 walk_aliased_vdefs_1
../../gcc/gcc/tree-ssa-alias.c:2689
0x10a883d7 walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*,
tree_node*, void*), void*, bitmap_head**, bool*)
../../gcc/gcc/tree-ssa-alias.c:2741
0x1074de9f ipa_polymorphic_call_context::get_dynamic_type(tree_node*,
tree_node*, tree_node*, gimple_statement_base*)
../../gcc/gcc/ipa-polymorphic-call.c:1584
0x10b30543 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-pre.c:4285
0x10f1925b dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:177
0x10b2e1c3 eliminate
../../gcc/gcc/tree-ssa-pre.c:4431
0x10b3839b execute
../../gcc/gcc/tree-ssa-pre.c:4762
0x10b3839b execute
../../gcc/gcc/tree-ssa-pre.c:4721
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #20 from boger at us dot ibm.com --- The latest patch worked on ppc64 for LE BE. That is, the testcase recover.go now works and no new regressions were introduced.
[Bug c/63477] New: Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
Bug ID: 63477
Summary: Bogus warning with -O3 -Warray-bounds: array subscript
is above array bounds
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lennox at cs dot columbia.edu
When compiled with -O3, the following code produces an array subscript is
above array bounds warning, which is bogus as far as I can tell:
#define MAX_VAL 16
typedef struct
{
int itemList[MAX_VAL+1];
unsigned int numItems;
} ItemList;
void FrobList(ItemList *l)
{
unsigned int i;
for (i=0; i l-numItems-1; i++) {
int minVal = l-itemList[i];
unsigned int minIdx = i;
unsigned int idx;
for (idx=i+1; idx l-numItems; ++idx) {
if (l-itemList[idx] minVal) {
minVal = l-itemList[idx];
minIdx = idx;
}
}
l-itemList[i] = l-itemList[minIdx];
}
}
$ gcc -O3 -Warray-bounds -c LmiH264RefPictures-Reduced.c
LmiH264RefPictures-Reduced.c: In function ‘FrobList’:
LmiH264RefPictures-Reduced.c:18:19: warning: array subscript is above array
bounds [-Warray-bounds]
if (l-itemList[idx] minVal) {
^
The warning occurs on compilers targeted to x86_64 and armhf, but not i686. It
does not occur with -O2 or lower. Tested on both Linux and Cygwin.
This is a regression from GCC 4.6.3, at least. Have not tested 4.7.x.
Clearly it would be an out-of-bounds access if l-numItems were = MAX_VAL+1,
but (in the actual application this testcase is reduced from), it's an
invariant that it won't be, and the compiler shouldn't be making range
assumptions to the contrary.
Verbose compiler output:
$ gcc -v -O3 -Warray-bounds -c LmiH264RefPictures-Reduced.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--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 --disable-libmudflap
--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,mx32 --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.2 (Ubuntu 4.8.2-19ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-O3' '-Warray-bounds' '-c' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/4.8/cc1 -quiet -v -imultiarch x86_64-linux-gnu
LmiH264RefPictures-Reduced.c -quiet -dumpbase LmiH264RefPictures-Reduced.c
-mtune=generic -march=x86-64 -auxbase LmiH264RefPictures-Reduced -O3
-Warray-bounds -version -fstack-protector -Wformat -Wformat-security -o
/tmp/ccXMNHkF.s
GNU C (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
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.
GNU C (Ubuntu 4.8.2-19ubuntu1) version 4.8.2 (x86_64-linux-gnu)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dc75e0628c9356affcec059d0c81cc01
LmiH264RefPictures-Reduced.c: In function ‘FrobList’:
LmiH264RefPictures-Reduced.c:18:19: warning: array subscript is above array
bounds [-Warray-bounds]
if (l-itemList[idx] minVal) {
^
COLLECT_GCC_OPTIONS='-v' '-O3' '-Warray-bounds' '-c' '-mtune=generic'
'-march=x86-64'
as -v --64 -o LmiH264RefPictures-Reduced.o /tmp/ccXMNHkF.s
GNU assembler version 2.24 (x86_64-linux-gnu) using
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #21 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Ville Voutilainen from comment #20)
template bool b struct bool_
{
};
template typename T, class... Args
struct mytrait : bool___is_trivially_constructible(T, Args...)
{
};
template typename T, class... Args
struct mytrait2 : bool___is_trivially_constructible(T, Args...)
{
};
Fixed.
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 --- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org --- Patch fixes the test case.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #3 from russelldub at gmail dot com --- Any hope for movement on this? I've made some attempts at diagnosing the issue, but not sure why equivalences behave differently than other statements in the modules.
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #4 from russelldub at gmail dot com --- Any hope for movement on this? I've made some attempts at diagnosing the issue, but not sure why equivalences behave differently than other statements in the modules.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Attachment #33657|0 |1 is obsolete|| --- Comment #55 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 33662 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33662action=edit revised patch The last patch should check if base rtx and index rtx of the address are registers.
[Bug c/63478] New: internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478
Bug ID: 63478
Summary: internal compiler error: in sparc_emit_set_const64, at
config/sparc/sparc.c:2061
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dev at cor0 dot com
Given the simplest possible test code :
$ cat -n hello.c
1 #include stdio.h
2
3 int
4 main(int argc, char *argv[])
5 {
6 printf ( Hello World!\n );
7 return (0);
8 }
We see ICE thus :
$ /opt/intermediate/gcc4/bin/gcc -v -save-temps -mcpu=v8 -mno-app-regs -m32
-mptr64 -g -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -S -o
hello_sparcv8_gcc-4.7.4.s hello.c
Using built-in specs.
COLLECT_GCC=/opt/intermediate/gcc4/bin/gcc
Target: sparc64-sun-solaris2.10
Configured with: ../gcc-4.7.4/configure --build=sparc64-sun-solaris2.10
--prefix=/opt/intermediate/gcc4 --libdir=/opt/intermediate/gcc4/lib
--libexecdir=/opt/intermediate/gcc4/lib --without-gnu-as --without-gnu-ld
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local
--disable-nls --enable-threads=posix --enable-shared --with-cpu=v9
--enable-bootstrap --enable-languages=ada,c,c++ --enable-stage1-languages=c
--with-pkgversion='genunix Tue Oct 7 02:05:39 GMT 2014'
Thread model: posix
gcc version 4.7.4 (genunix Tue Oct 7 02:05:39 GMT 2014)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mcpu=v8' '-mno-app-regs' '-m32'
'-mptr64' '-g' '-D' '_POSIX_PTHREAD_SEMANTICS' '-D' '_LARGEFILE64_SOURCE' '-D'
'_TS_ERRNO' '-S' '-o' 'hello_sparcv8_gcc-4.7.4.s'
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/cc1 -E -quiet -v
-imultilib sparcv8plus -D__sparcv8 -D _POSIX_PTHREAD_SEMANTICS -D
_LARGEFILE64_SOURCE -D _TS_ERRNO hello.c -mptr32 -mno-stack-bias -mcpu=v8
-mno-app-regs -m32 -mptr64 -g -fworking-directory -fpch-preprocess -o hello.i
ignoring nonexistent directory
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/../../../../sparc64-sun-solaris2.10/include
#include ... search starts here:
#include ... search starts here:
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include
/usr/local/include
/opt/intermediate/gcc4/include
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mcpu=v8' '-mno-app-regs' '-m32'
'-mptr64' '-g' '-D' '_POSIX_PTHREAD_SEMANTICS' '-D' '_LARGEFILE64_SOURCE' '-D'
'_TS_ERRNO' '-S' '-o' 'hello_sparcv8_gcc-4.7.4.s'
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/cc1
-fpreprocessed hello.i -mptr32 -mno-stack-bias -quiet -dumpbase hello.c
-mcpu=v8 -mno-app-regs -m32 -mptr64 -auxbase-strip hello_sparcv8_gcc-4.7.4.s -g
-version -o hello_sparcv8_gcc-4.7.4.s
GNU C (genunix Tue Oct 7 02:05:39 GMT 2014) version 4.7.4
(sparc64-sun-solaris2.10)
compiled by GNU C version 4.7.4, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (genunix Tue Oct 7 02:05:39 GMT 2014) version 4.7.4
(sparc64-sun-solaris2.10)
compiled by GNU C version 4.7.4, GMP version 6.0.0, MPFR version 3.1.2,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6c00354b9ef0a393ae7d72f614661fa3
hello.c: In function 'main':
hello.c:6:12: internal compiler error: in sparc_emit_set_const64, at
config/sparc/sparc.c:2061
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$
Full pre-processed source :
$ cat hello.i
# 1 hello.c
# 1 /export/home/dclarke/pgm/hello//
# 1 command-line
# 1 hello.c
# 1 /usr/include/stdio.h 1 3 4
# 19 /usr/include/stdio.h 3 4
#pragma ident @(#)stdio.h 1.8613/09/11 SMI
# 1
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed/sys/feature_tests.h
1 3 4
# 17
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed/sys/feature_tests.h
3 4
#pragma ident @(#)feature_tests.h 1.2611/04/12 SMI
# 1 /usr/include/sys/ccompile.h 1 3 4
# 9 /usr/include/sys/ccompile.h 3 4
#pragma ident @(#)ccompile.h 1.2 04/11/08 SMI
# 20
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed/sys/feature_tests.h
2 3 4
# 1 /usr/include/sys/isa_defs.h 1 3 4
#pragma ident @(#)isa_defs.h 1.3011/03/31 SMI
# 21
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed/sys/feature_tests.h
2 3 4
# 22 /usr/include/stdio.h 2 3 4
# 66 /usr/include/stdio.h 3 4
# 1
/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed/iso/stdio_iso.h
1 3 4
# 41
[Bug c/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #1 from Dennis Clarke dev at cor0 dot com --- The option -mptr64 seems to be the issue here because : $ /opt/intermediate/gcc4/bin/gcc -v -save-temps -mcpu=v8 -mno-app-regs -m32 -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -S -o hello_sparcv8_gcc-4.7.4.s hello.c Using built-in specs. COLLECT_GCC=/opt/intermediate/gcc4/bin/gcc Target: sparc64-sun-solaris2.10 Configured with: ../gcc-4.7.4/configure --build=sparc64-sun-solaris2.10 --prefix=/opt/intermediate/gcc4 --libdir=/opt/intermediate/gcc4/lib --libexecdir=/opt/intermediate/gcc4/lib --without-gnu-as --without-gnu-ld --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/sparcv9/ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --disable-nls --enable-threads=posix --enable-shared --with-cpu=v9 --enable-bootstrap --enable-languages=ada,c,c++ --enable-stage1-languages=c --with-pkgversion='genunix Tue Oct 7 02:05:39 GMT 2014' Thread model: posix gcc version 4.7.4 (genunix Tue Oct 7 02:05:39 GMT 2014) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mcpu=v8' '-mno-app-regs' '-m32' '-D' '_POSIX_PTHREAD_SEMANTICS' '-D' '_LARGEFILE64_SOURCE' '-D' '_TS_ERRNO' '-S' '-o' 'hello_sparcv8_gcc-4.7.4.s' /opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/cc1 -E -quiet -v -imultilib sparcv8plus -D__sparcv8 -D _POSIX_PTHREAD_SEMANTICS -D _LARGEFILE64_SOURCE -D _TS_ERRNO hello.c -mptr32 -mno-stack-bias -mcpu=v8 -mno-app-regs -m32 -fpch-preprocess -o hello.i ignoring nonexistent directory /opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/../../../../sparc64-sun-solaris2.10/include #include ... search starts here: #include ... search starts here: /opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include /usr/local/include /opt/intermediate/gcc4/include /opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mcpu=v8' '-mno-app-regs' '-m32' '-D' '_POSIX_PTHREAD_SEMANTICS' '-D' '_LARGEFILE64_SOURCE' '-D' '_TS_ERRNO' '-S' '-o' 'hello_sparcv8_gcc-4.7.4.s' /opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/cc1 -fpreprocessed hello.i -mptr32 -mno-stack-bias -quiet -dumpbase hello.c -mcpu=v8 -mno-app-regs -m32 -auxbase-strip hello_sparcv8_gcc-4.7.4.s -version -o hello_sparcv8_gcc-4.7.4.s GNU C (genunix Tue Oct 7 02:05:39 GMT 2014) version 4.7.4 (sparc64-sun-solaris2.10) compiled by GNU C version 4.7.4, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (genunix Tue Oct 7 02:05:39 GMT 2014) version 4.7.4 (sparc64-sun-solaris2.10) compiled by GNU C version 4.7.4, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6c00354b9ef0a393ae7d72f614661fa3 COMPILER_PATH=/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/:/usr/ccs/bin/ LIBRARY_PATH=/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/sparcv8plus/:/usr/ccs/lib/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/../../../:/lib/:/usr/lib/:/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mcpu=v8' '-mno-app-regs' '-m32' '-D' '_POSIX_PTHREAD_SEMANTICS' '-D' '_LARGEFILE64_SOURCE' '-D' '_TS_ERRNO' '-S' '-o' 'hello_sparcv8_gcc-4.7.4.s' $ $ $ cat hello_sparcv8_gcc-4.7.4.s .file hello.c .section.rodata .align 8 .LLC0: .asciz Hello World! .section.text .align 4 .global main .type main, #function .proc 04 main: save%sp, -96, %sp st %i0, [%fp+68] st %i1, [%fp+72] sethi %hi(.LLC0), %g1 or %g1, %lo(.LLC0), %o0 callputs, 0 nop mov 0, %g1 mov %g1, %i0 restore jmp %o7+8 nop .size main, .-main .ident GCC: (genunix Tue Oct 7 02:05:39 GMT 2014) 4.7.4 $ $ /usr/ccs/bin/as -V -Qy -s -xarch=v8 -o hello_sparcv8_gcc-4.7.4.o hello_sparcv8_gcc-4.7.4.s /usr/ccs/bin/as: SunOS 5.10 118683-13 Patch 08/06/2014 $ $ /opt/intermediate/gcc4/bin/gcc -v -save-temps -mcpu=v8 -mno-app-regs -m32 -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO -o hello_sparcv8_gcc-4.7.4 hello_sparcv8_gcc-4.7.4.o Using built-in specs. COLLECT_GCC=/opt/intermediate/gcc4/bin/gcc COLLECT_LTO_WRAPPER=/opt/intermediate/gcc4/lib/gcc/sparc64-sun-solaris2.10/4.7.4/lto-wrapper Target: sparc64-sun-solaris2.10 Configured with: ../gcc-4.7.4/configure --build=sparc64-sun-solaris2.10
[Bug c/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #2 from Dennis Clarke dev at cor0 dot com --- Also, this may be a simple RESOLVED WONT FIX because : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191 Sorry, the option -mptr64 looks to be undocumented and therefore a no no. Dennis
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||Sparc Component|c |target --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Why are you trying to use -mptr64 anyways? Especially without -m64 ?
[Bug tree-optimization/56580] Internal compiler error when trying to compile a sequence of NOPs inside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56580 ak at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ak at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from ak at gcc dot gnu.org --- Fixed since some time in trunk with 2013-09-08 Andi Kleen a...@linux.intel.com * tree-inline.c (estimate_num_insns): Limit asm cost to 1000.
[Bug c/63479] New: Compiler flag to zero structure padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479
Bug ID: 63479
Summary: Compiler flag to zero structure padding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: josh at joshtriplett dot org
Many memory disclosure vulnerabilities occur due to uninitialized structure
padding. For instance, if the kernel declares a structure, initializes its
fields, and copies the entire structure to userspace, it discloses the contents
of the padding to userspace.
To eliminate that source of memory disclosure vulnerabilities, GCC could have a
compiler option to always zero structure padding, either when initializing all
fields of the structure, or when doing structure assignment. In many cases,
this could be done very inexpensively, or even with no additional instructions
at all. For instance, given a struct like this:
struct foo {
char c;
uint64_t i;
};
On 64-bit x86, GCC typically generates four 64-bit mov instructions, into and
out of registers. GCC could instead generate a movzx and three mov
instructions.
[Bug c/63480] New: -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
Bug ID: 63480
Summary: -Wmissing-field-initializers should not warn about
intentionally empty initializers (or that should be a
separate option)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: josh at joshtriplett dot org
-Wmissing-field-initializers warns if a positional initializer does not
initialize all fields. However, it does so even if the initializer is {},
which is a common idiom to initialize the entire structure to zero. Please
consider not warning in that specific case. If anyone actually *wants* GCC to
warn in that case, perhaps that could go in a separate -Wempty-initializer.
Alternatively, if people *really* want -Wmissing-field-initializers to warn
about {}, could we have some other warning option that only warns about missing
field initializers with non-empty initializers?
[Bug c/63481] New: Improve prepare_shrink_wrap to sink more instructions causes linux kernel failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63481 Bug ID: 63481 Summary: Improve prepare_shrink_wrap to sink more instructions causes linux kernel failure Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sasha.levin at oracle dot com Created attachment 33663 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33663action=edit good/bad kernel disasm I've updated gcc (since two weeks ago) and now my kernel fails to boot with: [ 38.896180] kernel BUG at block/blk-flush.c:212! [ 38.897035] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 38.898179] Dumping ftrace buffer: [ 38.898666](ftrace buffer empty) [ 38.899186] Modules linked in: [ 38.899562] CPU: 6 PID: 0 Comm: swapper/6 Not tainted 3.17.0-rc7-next-20141003-sasha-00051-g8905629 #1329 [ 38.900882] task: 8800366f ti: 8800366e4000 task.ti: 8800366e4000 [ 38.901745] RIP: blk_flush_complete_seq (block/blk-flush.c:212) [ 38.903026] RSP: :8801c3a03e08 EFLAGS: 00010002 [ 38.903717] RAX: 0008 RBX: 88003353 RCX: 0003 [ 38.904619] RDX: dfffe900 RSI: 8800334f4000 RDI: 8800335300a0 [ 38.905102] RBP: 8801c3a03e58 R08: R09: [ 38.905102] R10: 1100b1888030 R11: R12: 8800334f4000 [ 38.905102] R13: R14: 8800335300a0 R15: [ 38.905102] FS: () GS:8801c3a0() knlGS: [ 38.905102] CS: 0010 DS: ES: CR0: 8005003b [ 38.905102] CR2: a022d0c0 CR3: 21a22000 CR4: 06a0 [ 38.905102] Stack: [ 38.905102] 8800366e4000 880033530030 8802e3bd1f70 0007 [ 38.905102] 9bfc6c23 8800335300a8 8800334f4000 [ 38.905102] 8800334f3f78 8800334f4020 8801c3a03ec8 9bfc6d4d [ 38.905102] Call Trace: [ 38.905102] IRQ [ 38.905102] ? flush_end_io (block/blk-flush.c:230) [ 38.905102] flush_end_io (block/blk-flush.c:243 (discriminator 2)) [ 38.905102] blk_mq_end_request (block/blk-mq.c:303) [ 38.905102] virtblk_request_done (drivers/block/virtio_blk.c:139) [ 38.905102] __blk_mq_complete_request_remote (block/blk-mq.c:311) [ 38.905102] ? blkdev_issue_zeroout (block/blk-mq.c:307) [ 38.905102] flush_smp_call_function_queue (kernel/smp.c:129 (discriminator 3) kernel/smp.c:254 (discriminator 3)) [ 38.905102] ? preempt_count_add (kernel/sched/core.c:2631) [ 38.905102] generic_smp_call_function_single_interrupt (kernel/smp.c:208) [ 38.905102] smp_call_function_single_interrupt (arch/x86/kernel/smp.c:317 arch/x86/kernel/smp.c:323) [ 38.905102] call_function_single_interrupt (arch/x86/kernel/entry_64.S:1020) [ 38.905102] EOI [ 38.905102] ? native_safe_halt (./arch/x86/include/asm/irqflags.h:50) [ 38.905102] ? trace_hardirqs_on (kernel/locking/lockdep.c:2609) [ 38.905102] default_idle (./arch/x86/include/asm/paravirt.h:111 arch/x86/kernel/process.c:313) [ 38.905102] arch_cpu_idle (arch/x86/kernel/process.c:305) [ 38.905102] cpu_idle_loop (kernel/sched/idle.c:120 kernel/sched/idle.c:226) [ 38.905102] cpu_startup_entry (??:?) [ 38.905102] start_secondary (arch/x86/kernel/smpboot.c:240) [ 38.905102] Code: 00 0f 84 ec 00 00 00 31 f6 48 89 df e8 aa 90 00 00 4c 89 e7 e8 92 91 00 00 44 89 e8 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 66 0f 1f 44 00 00 4c 8d ab a8 00 00 00 4d 8d 7c 24 30 4c All code 0:00 0fadd%cl,(%rdi) 2:84 ectest %ch,%ah 4:00 00add%al,(%rax) 6:00 31add%dh,(%rcx) 8:f6 (bad) 9:48 89 df mov%rbx,%rdi c:e8 aa 90 00 00 callq 0x90bb 11:4c 89 e7 mov%r12,%rdi 14:e8 92 91 00 00 callq 0x91ab 19:44 89 e8 mov%r13d,%eax 1c:48 83 c4 28 add$0x28,%rsp 20:5b pop%rbx 21:41 5cpop%r12 23:41 5dpop%r13 25:41 5epop%r14 27:41 5fpop%r15 29:5d pop%rbp 2a:c3 retq 2b:*0f 0bud2-- trapping instruction 2d:66 0f 1f 44 00 00nopw 0x0(%rax,%rax,1) 33:4c 8d ab a8 00 00 00 lea0xa8(%rbx),%r13 3a:4d 8d 7c 24 30 lea0x30(%r12),%r15 3f:4c rex.WR ... Code starting with the faulting instruction === 0:0f 0b
[Bug c/63481] Improve prepare_shrink_wrap to sink more instructions causes linux kernel failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63481 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 63404 *** This bug has been marked as a duplicate of bug 63404 ***
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||sasha.levin at oracle dot com --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63481 has been marked as a duplicate of this bug. ***
[Bug c++/63472] transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472 ak at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 CC||ak at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ak at gcc dot gnu.org --- Confirmed with trunk. Program received signal SIGSEGV, Segmentation fault. 0x008805b1 in copy_bbs (bbs=0x1e8ecc8, n=9, new_bbs=0x1e8e810, edges=0x0, num_edges=0, new_edges=0x0, base=0x0, after=0x76c3aa90, update_dominance=true) at ../../gcc/gcc/cfghooks.c:1335 1335 if (dom_bb-flags BB_DUPLICATED) (gdb) p dom_bb-flags Cannot access memory at address 0x50 (gdb)
[Bug c++/63472] transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472 --- Comment #2 from ak at gcc dot gnu.org --- Looks like there are more problems with -fgnu-tm I hacked csmith to generate random __transaction_atomic blocks and I got a lot of crashes immediately. All I looked at were variants of these two: 0x8e23b7 crash_signal ../../gcc/gcc/toplev.c:340 0x92df5c copy_loops ../../gcc/gcc/tree-inline.c:2379 0x93225c copy_cfg_body ../../gcc/gcc/tree-inline.c:2583 0x93225c copy_body ../../gcc/gcc/tree-inline.c:2777 0x935ab3 tree_function_versioning(tree_node*, tree_node*, vecipa_replace_map*, va_gc, vl_embed*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*) and 0x6d7465 expand_expr_addr_expr_1 ../../gcc/gcc/expr.c:7737 0x6cd9a6 expand_expr_addr_expr ../../gcc/gcc/expr.c:7779 0x6cd9a6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10604 0x6084f1 expand_normal ../../gcc/gcc/expr.h:457 0x6084f1 precompute_register_parameters ../../gcc/gcc/calls.c:832 0x6084f1 expand_call(tree_node*, rtx_def*, int) ../../gcc/gcc/calls.c:3002 0x5fbeb0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/gcc/builtins.c:6825 0x6cdd95 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10369 0x6d751a store_expr(tree_node*, rtx_def*, int, bool) ../../gcc/gcc/expr.c:5337 0x6dc2d9 expand_assignment(tree_node*, tree_node*, bool)
[Bug c++/63472] transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472 --- Comment #3 from ak at gcc dot gnu.org --- Another one: 0x8e23b7 crash_signal ../../gcc/gcc/toplev.c:340 0x61be46 copy_bbs(basic_block_def**, unsigned int, basic_block_def**, edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool) ../../gcc/gcc/cfghooks.c:1335 0x8eaecf ipa_uninstrument_transaction ../../gcc/gcc/trans-mem.c:4093 0x8eaecf ipa_tm_scan_calls_transaction ../../gcc/gcc/trans-mem.c:4167 0x8eaecf ipa_tm_execute ../../gcc/gcc/trans-mem.c:5340 0x8eaecf execute ../../gcc/gcc/trans-mem.c:5578
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #21 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to boger from comment #20) The latest patch worked on ppc64 for LE BE. That is, the testcase recover.go now works and no new regressions were introduced. Also works on alpha [1] without new regressions. [1] https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg00840.html
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362 --- Comment #22 from Ville Voutilainen ville.voutilainen at gmail dot com --- Created attachment 33664 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33664action=edit Preprocessed source for is_trivially_copy_constructible tests This test fails the static_assert for TType (which is a trivial type), PODType and DelDef, and it would be expected that all those static_asserts succeed. Then, the compiler segfaults, trace: [ville@localhost is_trivially_copy_constructible]$ g++ -v -save-temps --std=c++11 -I ../../util/ -c value.cc Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local --enable-languages=c,c++ Thread model: posix gcc version 5.0.0 20141008 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-I' '../../util/' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -E -quiet -v -I ../../util/ -D_GNU_SOURCE value.cc -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o value.ii ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: ../../util/ /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/../../../../include/c++/5.0.0/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-I' '../../util/' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/cc1plus -fpreprocessed value.ii -quiet -dumpbase value.cc -mtune=generic -march=x86-64 -auxbase value -std=c++11 -version -o value.s GNU C++ (GCC) version 5.0.0 20141008 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 5.0.0 20141008 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 5.0.0 20141008 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 5.0.0 20141008 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7d1439b3948ab95e7d138f746bcfda79 value.cc: In function ‘void test01()’: value.cc:40:3: error: static assertion failed: static_assert(test_categoryis_trivially_copy_constructible, ^ value.cc:42:3: error: static assertion failed: static_assert(test_categoryis_trivially_copy_constructible, ^ value.cc:48:3: error: static assertion failed: static_assert(test_categoryis_trivially_copy_constructible, ^ g++: internal compiler error: Segmentation fault (program cc1plus) 0x40c49c execute ../../gcc/gcc.c:2908 0x40c789 do_spec_1 ../../gcc/gcc.c:4724 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 0x40d2e7 do_spec_1 ../../gcc/gcc.c:5378 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 0x40d2e7 do_spec_1 ../../gcc/gcc.c:5378 0x40cc13 do_spec_1 ../../gcc/gcc.c:5493 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 0x40d2e7 do_spec_1 ../../gcc/gcc.c:5378 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 0x40d2e7 do_spec_1 ../../gcc/gcc.c:5378 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 0x40d2e7 do_spec_1 ../../gcc/gcc.c:5378 0x40f189 process_brace_body ../../gcc/gcc.c:6007 0x40f189 handle_braces ../../gcc/gcc.c:5921 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.
