[Bug c/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #12 from Chen Gang --- I am just comparing the issue code demo and the other 3 correct code demo (the demostrations which del one param, or add one param, or add two params are all correct). I find the issue code contents additonal one 'code_label' insn in its rtx tree, before create trace. I will continue analyzing, it seems, by comparing the issue demo and the other 3 correct demo, and dumping related information step by step, can find the root cause.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #14 from Joshua Cogliati --- Manuel López-Ibáñez, thank you for the patch review. I will make the changes you requested, and rebase it against svn trunk, and run bootstrap and testsuite. It may be a few weeks before I get this all done (depending on available time). UNSAFE_SIGN is unused, but when I was doing the patch, I noticed that unsafe_conversion_p basically does not report sign conversion errors, instead it does the warning directly inside the function. So there definitely is a distinct unsafe conversion type, but I am not sure if I should remove the constant entirely or not. Either way I will try and document the behavior better.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 Oleg Smolsky changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Oleg Smolsky --- A TSan variant also works when the setrlimit() call is omitted.
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #5 from John David Anglin --- Author: danglin Date: Sat Sep 21 00:00:38 2013 New Revision: 202808 URL: http://gcc.gnu.org/viewcvs?rev=202808&root=gcc&view=rev Log: PR middle-end/56791 * config/pa/pa.c (pa_option_override): Disable auto increment and decrement instructions until reload is completed. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/pa/pa.c
[Bug middle-end/56791] [4.8/4.9 Regression] Segmentation fault in stage2 gengenrtl -- Incorrect instruction sequence generated by reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791 --- Comment #4 from John David Anglin --- Author: danglin Date: Fri Sep 20 23:58:43 2013 New Revision: 202807 URL: http://gcc.gnu.org/viewcvs?rev=202807&root=gcc&view=rev Log: PR middle-end/56791 * config/pa/pa.c (pa_option_override): Disable auto increment and decrement instructions until reload is completed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug c/58488] New: -Wuninitialized is useless for a variable whose address is later taken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58488
Bug ID: 58488
Summary: -Wuninitialized is useless for a variable whose
address is later taken
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eblake at redhat dot com
Here's a simple example of where -Wuninitialized is rather useless at default
optimization:
$ cat foo.c
#include
int main(void) {
char *oops;
free(oops);
void *other =
#ifdef RELIABLE
NULL
#else
&oops
#endif
;
return !other;
}
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -DRELIABLE
foo.c: In function ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
free(oops);
^
cc1: all warnings being treated as errors
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -O2
foo.c: In function ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
free(oops);
^
cc1: all warnings being treated as errors
$ gcc -Werror -Wall -Wuninitialized -o foo -c foo.c -DRELIABLE -O2
foo.c: In function ‘main’:
foo.c:5:9: error: ‘oops’ is used uninitialized in this function
[-Werror=uninitialized]
free(oops);
^
cc1: all warnings being treated as errors
I understand that -O2 enables better uninitialization checks, but I find it
quite awkward that even without -O2, the mere taking an address of a variable
hides it from the uninit checker. My end goal is to have a macro that does a
one-shot evaluation of its argument:
#define FREE(x) { typeof(x) *_x = &(x); free(*_x); *_x = NULL; }
for safety, but that macro kills -Wuninit checking by virtue of the fact that
it takes the address of the pointer. Even if I limit myself to a macro that
evaluates its argument more than once (and forcing me to audit code to avoid
FREE(side-effects) - if only there were a way to make the compiler
automatically barf if it encounters side effects in a macro argument), I am
unable to come up with a way to get the uninit checking that gcc provides
regardless of optimization without also having the safety of ensuring the
pointer isn't abused after the fact.
[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #43 from Juha Kallioinen --- (In reply to Jakub Jelinek from comment #42) > (In reply to Juha Kallioinen from comment #41) > > Maybe this failure with a newly built gcc 4.8 is related to this bug. > > No, that is just a buggy testcase. Redefining a prototype, especially if > you have no idea how the system function prototype looks like, is a bug. > In the testcaseif you redefine the prototype to something different and > obviously it then fails to inline it. Don't do that. This was just a reduction of a piece of code that started to fail with gcc 4.8, but compiles with earlier versions. I'll try to understand what is different in the prototype redefinition.
[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 --- Comment #42 from Jakub Jelinek --- (In reply to Juha Kallioinen from comment #41) > Maybe this failure with a newly built gcc 4.8 is related to this bug. No, that is just a buggy testcase. Redefining a prototype, especially if you have no idea how the system function prototype looks like, is a bug. In the testcaseif you redefine the prototype to something different and obviously it then fails to inline it. Don't do that.
[Bug libstdc++/16371] libstdc++ fails for crosses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371 roger pack changed: What|Removed |Added CC||rogerdpack at gmail dot com --- Comment #27 from roger pack --- (sorry to comment on something so ancient). Anyway ran into something similar today, a couple of hints/clues: mine was caused by having an empty environment variable CFLAGS (like bash's export CFLAGS=). So unsetting that and I was good to go. Also (as others have noted) this error message basically means "your cross compiler is unable to link at all" or something like that (the config.log that may describe it is called something like i686-w64-mingw32/libstdc++-v3/config.log)
[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
Juha Kallioinen changed:
What|Removed |Added
CC||kaltsi+gnu at gmail dot com
--- Comment #41 from Juha Kallioinen ---
Maybe this failure with a newly built gcc 4.8 is related to this bug.
Built gcc today from
commit a846b696b9f3e9b9caab7e43ef8450cbded2715c
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@202762
138bc75d-0d04-0410-961f-82ee72b
~/gcc48/bin$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/kaltsi/gcc48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/kaltsi/gcc48
--disable-bootstrap --with-tune=generic --disable-multilib
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object --enable-lto
--enable-linker-build-id --enable-languages=c,c++ --enable-threads=posix
--enable-shared --disable-libgcj
Thread model: posix
gcc version 4.8.2 20130920 (prerelease) (GCC)
Compiling the following simple program with these options on an Ubuntu 12.04
causes a failure:
$ gcc -Wp,-D_FORTIFY_SOURCE=2 -O2 -D_GNU_SOURCE=1
-- foo.c --
#include
extern ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct
sockaddr *from, socklen_t *fromlen);
int main()
{
int s, flags; void *buf; size_t len; struct sockaddr *from; socklen_t*
fromlen;
return(recvfrom(s, buf, len, flags, from, fromlen));
}
-- foo.c --
~/gcc48/bin$ ./gcc -Wp,-D_FORTIFY_SOURCE=2 -O2 -D_GNU_SOURCE=1 foo.c
In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:251:0,
from foo.c:5:
foo.c: In function ‘main’:
/usr/include/x86_64-linux-gnu/bits/socket2.h:65:1: error: inlining failed in
call to always_inline ‘recvfrom’: mismatched arguments
recvfrom (int __fd, void *__restrict __buf, size_t __n, int __flags,
^
foo.c:12:18: error: called from here
return(recvfrom(s, buf, len, flags, from, fromlen));
^
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #13 from Manuel López-Ibáñez --- Another potential issue is that your patch is against 4.8.1, but this is not a regression, so it is very likely that maintainers will ask you to submit a patch with respect to current trunk: http://www.gnu.org/software/gcc/svn.html
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini --- Fixed for 4.9.0.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #14 from Oleg Smolsky --- The ASan issue was due to the memory limit applied via setrlimit(). The virtual size (in this -fPIC -pie build) is really huge and so memory allocations were failing. I'll confirm the TSan case in a bit. Thank you Kostya!
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 --- Comment #7 from Damian Kaczmarek --- Cheers guys, much appreciated. Keep up the good work.
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Sep 20 21:04:09 2013 New Revision: 202797 URL: http://gcc.gnu.org/viewcvs?rev=202797&root=gcc&view=rev Log: /cp 2013-09-20 Paolo Carlini PR c++/58481 * pt.c (tsubst_copy): Use current_nonlambda_class_type to call tsubst_baselink. /testsuite 2013-09-20 Paolo Carlini PR c++/58481 * g++.dg/cpp0x/lambda/lambda-this17.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58487] Missed return value optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487 Marc Glisse changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Marc Glisse --- PR53637 or one of the other RVO PRs (see the meta PR 58055).
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001
--- Comment #12 from Manuel López-Ibáñez ---
The patch looks mostly correct to me, but you will need a few extra details
before a maintainer (not me!) can accept it.
* You need to bootstrap + run the testsuite. You don't really need to add
testcases, because there are quite a few already in the testsuite for
Wconversion, but perhaps to be sure that your patch is correct, you could check
those and change -Wconversion for -Wfloat-conversion where it should trigger.
* You need to write a Changelog and submit to gcc-patc...@gcc.gnu.org. When
submitting CC do...@redhat.com who is the diagnostics maintainer.
* There are some potential issues in the patch that maintainers may complain
diff -ur gcc-4.8.1_orig/gcc/c-family/c-common.c
gcc-4.8.1/gcc/c-family/c-common.c
--- gcc-4.8.1_orig/gcc/c-family/c-common.c2013-05-14 14:52:27.0
-0600
+++ gcc-4.8.1/gcc/c-family/c-common.c2013-09-02 13:14:01.0 -0600
@@ -294,6 +294,8 @@
{NULL, 0, 0},
};
+enum conversion_safety
{SAFE_CONVERSION=0,UNSAFE_OTHER,UNSAFE_SIGN,UNSAFE_REAL};
+
Perhaps you should add a bit of documentation of what each value means? Also,
you don't seem to use UNSAFE_SIGN.
Also, some extra whitespace around =, after ',' and {, and before }.
-extern bool unsafe_conversion_p (tree, tree, bool);
This function is used in the C++ FE, you cannot make it static. Did you
bootstrap the compiler with the patch?
+ if ((conversion_kind = unsafe_conversion_p (type, expr, true)))
I don't think this is going to be accepted. You should split the assignment and
the test.
+Wfloat-conversion
+C ObjC C++ ObjC++ Var(warn_float_conversion) LangEnabledBy(C ObjC
C++,Wconversion) EnabledBy(Wextra)
This looks ok to me, but you could add ObjC++ in the LangEnabledBy part.
+This includes conversions from real to integer, and from higher precision
+real to lower precision real values. This option is also enabled by
+@option{-Wconversion}.
and by @option{-Wextra}! You should also add it to the list of things enabled
by -Wextra (look where -Wextra is defined).
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #13 from Oleg Smolsky --- Created attachment 30875 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30875&action=edit another stack ASAN_OPTIONS=malloc_context_size=1 gets me passed the initial issue, but the code gets stuck here: __asan::asan_malloc strerror __sanitizer::MmapFixedOrDie
[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) > Can be fixed with this patch: ... which regtests cleanly.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #11 from Joshua Cogliati --- Created attachment 30873 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30873&action=edit Patch to add -Wfloat-conversion option This version also is enabled with -Wextra. $ gcc -o float_test float_test.c $ gcc -Wfloat-conversion -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ $ gcc -Wconversion -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ $ gcc -Wextra -o float_test float_test.c float_test.c: In function ‘main’: float_test.c:2:3: warning: conversion to ‘int’ alters ‘double’ constant value [-Wfloat-conversion] int i = 3.14; ^ float_test.c: In function ‘foo’: float_test.c:8:3: warning: conversion to ‘int’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^ float_test.c: In function ‘foo2’: float_test.c:12:3: warning: conversion to ‘float’ from ‘double’ may alter its value [-Wfloat-conversion] return x; ^
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #8 from Kostya Serebryany --- ouch! free calling malloc. this is not going to work :) This code has changed since our last merge to gcc -- the trunk version does not have strerror call any more. I really hope to make another merge before end of month (~ ish) Note that the code deadlocks while trying to report an error (out of mem) and die. It is likely that if you give the process more ram it will work.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #7 from Oleg Smolsky --- Created attachment 30874 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30874&action=edit full stack Here is the full stack. It comes from the very same spot in my app. As for the minimal repro - that's problematic. I extracted the same regex into a minimal program and it works correctly. I am guessing there is something about conditional re-entrancy: __asan::asan_malloc ... strerror ... asan_free ... std::__debug::vector boost::re_detail::basic_char_set
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #6 from jbglaw at gcc dot gnu.org --- Author: jbglaw Date: Fri Sep 20 19:00:02 2013 New Revision: 202796 URL: http://gcc.gnu.org/viewcvs?rev=202796&root=gcc&view=rev Log: Work around buggy gas not properly sign-extending a 64bit value on a 32bit host PR target/56875 2013-09-20 Martin Husemann Jan-Benedict Glaw gcc/ * config/vax/vax.c (vax_output_int_move): Use D format specifier. * config/vax/vax.md (ashldi3, ): Ditto. gcc/testsuite/ * gcc.target/vax/vax.exp: New. * gcc.target/vax/pr56875.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/vax/ trunk/gcc/testsuite/gcc.target/vax/pr56875.c trunk/gcc/testsuite/gcc.target/vax/vax.exp Modified: trunk/gcc/ChangeLog trunk/gcc/config/vax/vax.c trunk/gcc/config/vax/vax.md trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #12 from Kostya Serebryany --- You can also try ASAN_OPTIONS=malloc_context_size=1 (or 0) this will eliminate this particular call to mmap (but will reduce the usefulness of asan report)
[Bug c++/58487] New: Missed return value optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
Bug ID: 58487
Summary: Missed return value optimization
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jm at bourguet dot org
$ cat rva.cpp
#include
class rva
{
public:
rva() { std::cout << "Default construction\n"; }
rva(rva const&) { std::cout << "Copy construction\n"; }
rva& operator=(rva const&) { std::cout << "Assignation\n"; }
~rva() { std::cout << "Destruction\n"; }
};
rva f(int i) {
if (i == 0) {
rva result;
return result;
} else {
return rva();
}
}
int main()
{
{ std::cout << "f(0)\n"; f(0); }
{ std::cout << "\nf(1)\n"; f(1); }
{ std::cout << "\ng(0)\n"; g(0); }
{ std::cout << "\ng(1)\n"; g(1); }
return 0;
}
$ g++-4.8.1 --version
g++-4.8.1 (GCC) 4.8.1
Copyright (C) 2013 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.
$ g++-4.8.1 rva.cpp
$ ./a.out
f(0)
Default construction
Copy construction
Destruction
Destruction
f(1)
Default construction
Destruction
It seems to me that for f(0) the copy construction could be avoided.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #11 from Oleg Smolsky --- Sure. The verbose thing does not yield much: ==1236== Parsed ASAN_OPTIONS: verbosity=1 ==1236== AddressSanitizer: libc interceptors initialized || `[0x10007fff8000, 0x7fff]` || HighMem|| || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || || `[0x8fff7000, 0x02008fff6fff]` || ShadowGap || || `[0x7fff8000, 0x8fff6fff]` || LowShadow || || `[0x, 0x7fff7fff]` || LowMem || MemToShadow(shadow): 0x8fff7000 0x91ff6dff 0x004091ff6e00 0x02008fff6fff red_zone=16 malloc_context_size=30 SHADOW_SCALE: 3 SHADOW_GRANULARITY: 8 SHADOW_OFFSET: 7fff8000 ==1236== Installed the sigaction for signal 11 ==1236== T0: stack [0x7fff22a4,0x7fff2344) size 0xa0; local=0x7fff2343e3bc ==1236== AddressSanitizer Init done
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #10 from Kostya Serebryany --- Your stack traces tells me this: __sanitizer::MmapOrDie calls strerror, which means that mmap call failed. This may happen if the process OOM-ed (unlikely in your case), or may have some kind of limit (also unlikely, because the process managed to allocate the asan shadow). Let's try two things: 1. run with ASAN_OPTIONS=verbosity=1 and send us the log file 2. run under strace and figure out why did the last mmap fail
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #11 from Dima --- (In reply to Jason Merrill from comment #9) > Created attachment 30818 [details] > patch > > Can you verify that this patch fixes the issue? Yes, it works for me and makes abi-compliance-checker function once again. Regards, Dmitrijs.
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #9 from Oleg Smolsky --- Hold on, I don't get the "more memory" bit. This happens very early, before anything else of merit. Also, it turns out that this isn't a deadlock, the main thread is spinning inside asan code. USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND osmolsky 54012 69.9 0.1 18253895480 223896 pts/82 R+ 11:35 3:37 dc/dc So, what do you suggest I try?
[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 Bug 58417 depends on bug 58484, which changed state. Bug 58484 Summary: [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug sanitizer/58465] ASan/TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #6 from Kostya Serebryany --- Is that the full stack trace? (As usual, a reproducer will help us much)
[Bug testsuite/57605] colors break note pruning in the testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57605 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Sep 20 17:52:29 2013 New Revision: 202791 URL: http://gcc.gnu.org/viewcvs?rev=202791&root=gcc&view=rev Log: PR testsuite/57605 libstdc++-v3/ * testsuite/lib/libstdc++.exp (libstdc++_init): Prepend -fdiagnostics-color=never to cxxflags. libmudflap/ * testsuite/lib/libmudflap.exp (libmudflap-init): Append -fdiagnostics-color=never to cxxflags. libgomp/ * testsuite/lib/libgomp.exp: Add -fdiagnostics-color=never to ALWAYS_CFLAGS. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/lib/libgomp.exp trunk/libmudflap/ChangeLog trunk/libmudflap/testsuite/lib/libmudflap.exp trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/libstdc++.exp
[Bug middle-end/58484] [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug middle-end/58484] [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Sep 20 17:49:45 2013 New Revision: 202790 URL: http://gcc.gnu.org/viewcvs?rev=202790&root=gcc&view=rev Log: 2013-09-20 Richard Biener PR middle-end/58484 * tree-scalar-evolution.c (struct scev_info_str): Shrink by remembering SSA name version and block index. (new_scev_info_str): Adjust. (hash_scev_info): Likewise. Also hash the block index. (eq_scev_info): Adjust. (find_var_scev_info): Likewise. (struct instantiate_cache_entry): Remove. (struct instantiate_cache_type): Use a htab to map name, block to chrec. (instantiate_cache_type::~instantiate_cache_type): Adjust. (get_instantiated_value_entry): Likewise. (hash_idx_scev_info, eq_idx_scev_info): New functions. (instantiate_scev_name): Adjust. * gfortran.dg/pr58484.f: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr58484.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #9 from Joshua Cogliati --- Created attachment 30871 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30871&action=edit some floating conversion issues This tests three of the floating conversion reduction in precision issues. P.S. Copyright assignment paperwork from both myself and my employer for GCC has been sent to copyright-clerk
[Bug tree-optimization/55860] Turn segmented iteration into nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860 --- Comment #4 from Jeffrey A. Law --- BTW, I did look at walking up the CFG to discover edge equivalences we could add to our tables. We don't have access to the path through the dominator tree that we've followed, so I had to use a fairly conservative "if we have a single pred, record equivalences implied by traversing that incoming edge" and recurse. While it does clearly enter more stuff into the tables, it's not useful in practice. With my bucket of testfiles, there were only a dozen or so cases where the additional table entries made any difference in what edges we could thread and in fact we were missing jump threads. The cause was replacing a constant equivalence in the table with an equivalence to another SSA_NAME. That's an artifact of walking up the CFG recording as we go. Instead we need to record in reverse order. Fixing that results in no differences before/after adding the new equivalences. I'm going to leave this open because it is a good example of what we'd like to do with a revamp to use Bodik's work. But I'm not planning to work on it in the immediate future.
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-20 Ever confirmed|0 |1
[Bug bootstrap/58476] In top-level configure --disable-static should change default for --with-boot-ldflags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 Ian Lance Taylor changed: What|Removed |Added Summary|bootstrap failure with Go |In top-level configure |enabled |--disable-static should ||change default for ||--with-boot-ldflags --- Comment #3 from Ian Lance Taylor --- The default value for --with-boot-ldflags is "-static-libstdc++ -static-libgcc" (set in the top level configure.ac file). When the g++ driver sees -static-libstdc++, it puts -Bstatic before -lstdc++ and puts -Bdynamic after it. So when you build with --disable-static, the effect is that go1 is linked against some other libstdc++ that it finds on the system, not the one that was just built. So it is not surprising that something went wrong. I would say that if someone configures with --disable-static, we need to change the default value of --with-boot-ldflags.
[Bug target/58486] New: insufficient CFI generated for call-saved VFP registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58486
Bug ID: 58486
Summary: insufficient CFI generated for call-saved VFP
registers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabi
I think this bug exists in trunk and in all past versions (seen in 4.6, at
least), but I did the detailed testing on today's gcc-4_8-branch.
The DWARF CFI generated to describe the save/restore of the call-saved VFP
registers (d8-d15) is insufficient: it covers only half of each register.
Consider this test case:
__attribute__((noinline)) void foo(void) {
struct { unsigned i[2]; } x = { 0x, 0x };
asm("vldr d8, %0; bkpt" :: "m" (x) : "d8");
}
__attribute__((noinline)) void bar(void) {
struct { unsigned i[2]; } x = { 0x, 0x };
asm("vldr d8, %0" :: "m" (x) : "d8");
foo();
}
int main(void) {
bar();
return 0;
}
Compiled with: gcc -O2 -g -marm -mfpu=neon -mhard-float
This gdb session demonstrates the failure:
$ cat > foo.x
r
i reg s17
up
i reg s17
k
q
$ gdb -x foo.x foo
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
For bug reporting instructions, please see:
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini --- On it.
[Bug sanitizer/58465] TSan deadlock in a single-threaded program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58465 --- Comment #5 from Oleg Smolsky --- BTW, I get an identical deadlock with ASan: #0 0x7fe631504ae9 in syscall () from /lib64/libc.so.6 #1 0x7fe63363ddc0 in __sanitizer::internal_sched_yield () at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_linux.cc:138 #2 0x7fe63362d521 in __sanitizer::StaticSpinMutex::LockSlow (this=this@entry=0x7fe635bb29c0 <__sanitizer::depot>) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:49 #3 0x7fe63363fef4 in Lock (this=0x7fe635bb29c0 <__sanitizer::depot>) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:30 #4 GenericScopedLock (mu=0x7fe635bb29c0 <__sanitizer::depot>, this=) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_mutex.h:83 #5 allocDesc (size=2) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:90 #6 __sanitizer::StackDepotPut (stack=stack@entry=0x7fff79d77100, size=2) at ../../../../gcc48-google/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:169 #7 0x7fe63362c3c0 in __asan::Allocate (size=size@entry=49, alignment=, alignment@entry=8, stack=stack@entry=0x7fff79d770f0, alloc_type=alloc_type@entry=__asan::FROM_MALLOC) at ../../../../gcc48-google/libsanitizer/asan/asan_allocator2.cc:386 #8 0x7fe63362cf02 in __asan::asan_malloc (size=size@entry=49, stack=stack@entry=0x7fff79d770f0) at ../../../../gcc48-google/libsanitizer/asan/asan_allocator2.cc:599 #9 0x7fe633638fa3 in __interceptor_malloc (size=49) at ../../../../gcc48-google/libsanitizer/asan/asan_malloc_linux.cc:72 #10 0x7fe63144fdb9 in _nl_make_l10nflist () from /lib64/libc.so.6 #11 0x7fe63144e0c5 in _nl_find_domain () from /lib64/libc.so.6 #12 0x7fe63144d9b0 in __dcigettext () from /lib64/libc.so.6 #13 0x7fe6314a0a38 in strerror_r () from /lib64/libc.so.6 #14 0x7fe6314a093e in strerror () from /lib64/libc.so.6 #15 0x7fe63362ef42 in __interceptor_strerror (errnum=)
[Bug rtl-optimization/57915] [4.8/4.9 Regression] ICE in set_address_disp, at rtlanal.c:5537
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57915 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #4 from Vladimir Makarov --- The address in question is (plus (symbol_ref ...) (const_int 4)) LRA finds two displacements (symbol_ref and const_int) although only one displacement is allowed. The correct canonical address should be: (const (plus (symbol_ref ...) (const_int 4))) Non-canonical address is created from (reg ...) by 1st constant propagation pass (cprop1). I believe the problem should be fixed there. As for reload pass, it has code transforming address (plus some const some const) into (const (plus some const some const)). It was probably a problem fix in a wrong place. There is no need to complicate LRA more and implement analogous code in LRA. As I wrote I believe it should be fixed in cprop1 by generating the correct canonical address.
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 Joshua Cogliati changed: What|Removed |Added CC||jjcogliati-r1 at yahoo dot com --- Comment #8 from Joshua Cogliati --- Created attachment 30870 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30870&action=edit Patch to add -Wfloat-conversion option This patch add a -Wfloat-conversion option. It adds an enumeration type called conversion_safety, with a SAFE_CONVERSION being 0, and unsafe ones being non-zero. It changes the unsafe_conversion_p to return this enumeration. This allows the floating point conversions to be handled separately. Someone who understands the c.opt file better than I should check that I did it correctly. -Wconversion implies -Wfloat-conversion. -Wall does not, but it might possibly be worth considering.
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #5 from Jan-Benedict Glaw --- Created attachment 30872 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30872&action=edit Updated patch including testcase.
[Bug bootstrap/58476] bootstrap failure with Go enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 --- Comment #2 from Tom Tromey --- The problem occurs because I use --disable-static. If I remove this, the bootstrap completes. I am not sure whether or not this is a supported configuration.
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481
--- Comment #3 from Paolo Carlini ---
Indeed, let's avoid the big , this is enough:
struct Test {
template inline void triggerTest (Args&&... fargs) { }
};
struct TestPickled : Test {
template void triggerTest (Args&&... fargs) {
[=](Args... as) {
Test::triggerTest(as...);
// this->_Test::triggerTest(as...);
// ^^^ THIS WORKAROUNDS THE PROBLEM
} ();
}
};
int main()
{
TestPickled test;
test.triggerTest();
return 0;
}
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jason Merrill --- (In reply to H.J. Lu from comment #9) > Does mingw provide its own SSE/MMX intrinsic implementations? > Can mingw just include where SSE/MMX instrincis > is needed? Right. Why does mingw need to declare these functions itself?
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #5 from Paul Smith --- Thank you!
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #10 from Richard Neill --- Thank you for adding this - I will certainly find it useful! May I suggest that this warning be implicitly enabled by -Wextra, (even if it's not enabled by -Wall) ?
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 --- Comment #9 from H.J. Lu --- Does mingw provide its own SSE/MMX intrinsic implementations? Can mingw just include where SSE/MMX instrincis is needed?
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #10 from Marc Glisse --- Author: glisse Date: Fri Sep 20 15:50:09 2013 New Revision: 202781 URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev Log: 2013-09-20 Marc Glisse PR libstdc++/58338 * include/bits/allocator.h (__alloc_swap::_S_do_it, __shrink_to_fit_aux::_S_do_it): Mark as noexcept. * include/bits/basic_string.h (basic_string::_Rep) [_S_empty_rep, _M_is_leaked, _M_is_shared, _M_set_leaked, _M_set_sharable, _M_set_length_and_sharable, _M_dispose]: Likewise. (basic_string::_Alloc_hider::_Alloc_hider): Likewise. (basic_string) [_M_data, _M_rep, _M_ibegin, _M_iend, _M_limit, _M_disjunct, _M_copy, _M_move, _M_assign, _S_copy_chars, _S_compare, _S_empty_rep, shrink_to_fit, operator[] const, front const, back const]: Likewise. [clear]: Link to PR 56166. [swap]: Link to PR 58265. * include/bits/stl_deque.h (_Deque_iterator) [_S_buffer_size, _Deque_iterator, _M_const_cast, operator*, operator->, operator++, operator--, operator+=, operator+, operator-=, operator-, operator[], _M_set_node]: Mark as noexcept. (operator==(const _Deque_iterator&, const _Deque_iterator&), operator!=(const _Deque_iterator&, const _Deque_iterator&), operator<(const _Deque_iterator&, const _Deque_iterator&), operator>(const _Deque_iterator&, const _Deque_iterator&), operator<=(const _Deque_iterator&, const _Deque_iterator&), operator>=(const _Deque_iterator&, const _Deque_iterator&), operator-(const _Deque_iterator&, const _Deque_iterator&), operator+(ptrdiff_t, const _Deque_iterator&)): Likewise. (_Deque_base) [_Deque_base(const allocator_type&)]: Add missing call to _M_initialize_map. [~_Deque_base, _M_deallocate_node, _M_deallocate_map, _M_destroy_nodes]: Mark as noexcept. (_Deque_base::_Deque_impl) [_Deque_impl(const _Tp_alloc_type&), _Deque_impl(_Tp_alloc_type&&)]: Likewise. (deque) [_S_buffer_size, operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Likewise. [deque(), deque(const allocator_type&)]: Merge. * include/debug/deque (deque) [operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Mark as noexcept. * include/profile/deque (deque) [operator=(deque&&), operator[], front, back, pop_front, pop_back, swap]: Likewise. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Adjust line number. * testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/allocator.h trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/debug/deque trunk/libstdc++-v3/include/profile/deque trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc
[Bug libstdc++/58265] [lwg/2063] std::string move assignment should be noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58265 --- Comment #5 from Marc Glisse --- Author: glisse Date: Fri Sep 20 15:50:09 2013 New Revision: 202781 URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev Log: 2013-09-20 Marc Glisse PR libstdc++/58338 * include/bits/allocator.h (__alloc_swap::_S_do_it, __shrink_to_fit_aux::_S_do_it): Mark as noexcept. * include/bits/basic_string.h (basic_string::_Rep) [_S_empty_rep, _M_is_leaked, _M_is_shared, _M_set_leaked, _M_set_sharable, _M_set_length_and_sharable, _M_dispose]: Likewise. (basic_string::_Alloc_hider::_Alloc_hider): Likewise. (basic_string) [_M_data, _M_rep, _M_ibegin, _M_iend, _M_limit, _M_disjunct, _M_copy, _M_move, _M_assign, _S_copy_chars, _S_compare, _S_empty_rep, shrink_to_fit, operator[] const, front const, back const]: Likewise. [clear]: Link to PR 56166. [swap]: Link to PR 58265. * include/bits/stl_deque.h (_Deque_iterator) [_S_buffer_size, _Deque_iterator, _M_const_cast, operator*, operator->, operator++, operator--, operator+=, operator+, operator-=, operator-, operator[], _M_set_node]: Mark as noexcept. (operator==(const _Deque_iterator&, const _Deque_iterator&), operator!=(const _Deque_iterator&, const _Deque_iterator&), operator<(const _Deque_iterator&, const _Deque_iterator&), operator>(const _Deque_iterator&, const _Deque_iterator&), operator<=(const _Deque_iterator&, const _Deque_iterator&), operator>=(const _Deque_iterator&, const _Deque_iterator&), operator-(const _Deque_iterator&, const _Deque_iterator&), operator+(ptrdiff_t, const _Deque_iterator&)): Likewise. (_Deque_base) [_Deque_base(const allocator_type&)]: Add missing call to _M_initialize_map. [~_Deque_base, _M_deallocate_node, _M_deallocate_map, _M_destroy_nodes]: Mark as noexcept. (_Deque_base::_Deque_impl) [_Deque_impl(const _Tp_alloc_type&), _Deque_impl(_Tp_alloc_type&&)]: Likewise. (deque) [_S_buffer_size, operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Likewise. [deque(), deque(const allocator_type&)]: Merge. * include/debug/deque (deque) [operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Mark as noexcept. * include/profile/deque (deque) [operator=(deque&&), operator[], front, back, pop_front, pop_back, swap]: Likewise. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Adjust line number. * testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/allocator.h trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/debug/deque trunk/libstdc++-v3/include/profile/deque trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #7 from Marc Glisse --- Author: glisse Date: Fri Sep 20 15:50:09 2013 New Revision: 202781 URL: http://gcc.gnu.org/viewcvs?rev=202781&root=gcc&view=rev Log: 2013-09-20 Marc Glisse PR libstdc++/58338 * include/bits/allocator.h (__alloc_swap::_S_do_it, __shrink_to_fit_aux::_S_do_it): Mark as noexcept. * include/bits/basic_string.h (basic_string::_Rep) [_S_empty_rep, _M_is_leaked, _M_is_shared, _M_set_leaked, _M_set_sharable, _M_set_length_and_sharable, _M_dispose]: Likewise. (basic_string::_Alloc_hider::_Alloc_hider): Likewise. (basic_string) [_M_data, _M_rep, _M_ibegin, _M_iend, _M_limit, _M_disjunct, _M_copy, _M_move, _M_assign, _S_copy_chars, _S_compare, _S_empty_rep, shrink_to_fit, operator[] const, front const, back const]: Likewise. [clear]: Link to PR 56166. [swap]: Link to PR 58265. * include/bits/stl_deque.h (_Deque_iterator) [_S_buffer_size, _Deque_iterator, _M_const_cast, operator*, operator->, operator++, operator--, operator+=, operator+, operator-=, operator-, operator[], _M_set_node]: Mark as noexcept. (operator==(const _Deque_iterator&, const _Deque_iterator&), operator!=(const _Deque_iterator&, const _Deque_iterator&), operator<(const _Deque_iterator&, const _Deque_iterator&), operator>(const _Deque_iterator&, const _Deque_iterator&), operator<=(const _Deque_iterator&, const _Deque_iterator&), operator>=(const _Deque_iterator&, const _Deque_iterator&), operator-(const _Deque_iterator&, const _Deque_iterator&), operator+(ptrdiff_t, const _Deque_iterator&)): Likewise. (_Deque_base) [_Deque_base(const allocator_type&)]: Add missing call to _M_initialize_map. [~_Deque_base, _M_deallocate_node, _M_deallocate_map, _M_destroy_nodes]: Mark as noexcept. (_Deque_base::_Deque_impl) [_Deque_impl(const _Tp_alloc_type&), _Deque_impl(_Tp_alloc_type&&)]: Likewise. (deque) [_S_buffer_size, operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Likewise. [deque(), deque(const allocator_type&)]: Merge. * include/debug/deque (deque) [operator=(deque&&), shrink_to_fit, operator[], front, back, pop_front, pop_back, swap]: Mark as noexcept. * include/profile/deque (deque) [operator=(deque&&), operator[], front, back, pop_front, pop_back, swap]: Likewise. * testsuite/23_containers/deque/requirements/dr438/assign_neg.cc: Adjust line number. * testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/deque/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/allocator.h trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/debug/deque trunk/libstdc++-v3/include/profile/deque trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/deque/requirements/dr438/insert_neg.cc
[Bug other/58467] Documentation of the "used" variable attribute needs additional information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58467 --- Comment #6 from Paul Smith --- A minor typo: - attached to a variable with the static storage, + attached to a variable with static storage, Also, I wonder if it might be helpful to be clear that it can ONLY be applied to variables with static storage, or else you get a warning/error. That would require more substantial changes to the text though. Cheers!
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #3 from dennis luehring --- according to the feedback from the clang mailing list by Benjamin Kramer http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-September/032111.html llvm seems to not have any problem in removing new/delete in this situation but got still a bug in not understanding that there is no need for the values to be on the heap - if i get it correct :)
[Bug c++/56038] declarations in xmmintrin.h conflict with mingw-w64 intrin.h in c++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56038 Jacek Caban changed: What|Removed |Added CC||jacek at codeweavers dot com --- Comment #8 from Jacek Caban --- It would be great if this could be fixed in GCC so that we wouldn't need to work around linkage differences in headers, but this should not be a problem for mingw-w64 since rev 6303, which added a work around to intrin.h.
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 Anatoly Sinyavin changed: What|Removed |Added CC||a.sinyavin at samsung dot com --- Comment #3 from Anatoly Sinyavin --- __builtin_unreachable is processed by "fab" optimization pass (fold all builtins / tree-ssa-ccp.c) in optimize_unreachable function. This pass is executed after vectorization so vectorizer gets __builtin_unreachable. Moreover __builtin_unreachable processing is one of the last pass on gimple. It leads that __builtin_unreachable can prevent not only vectorization but also many others optimization. So I suggest processing __builtin_unreachable immediately after "cfg" pass (cfg buiding). If we don't have any objections I can make patch for this problem.
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #42 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Fri Sep 20 14:10:14 2013 New Revision: 202778 URL: http://gcc.gnu.org/viewcvs?rev=202778&root=gcc&view=rev Log: 2013-09-20 Bernd Edlinger PR middle-end/57748 * expr.c (expand_assignment): Remove misalignp code path. testsuite/ PR middle-end/57748 * gcc.dg/torture/pr57748-1.c: New test. * gcc.dg/torture/pr57748-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57748-1.c trunk/gcc/testsuite/gcc.dg/torture/pr57748-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58355] [4.7/4.8/4.9 Regression] [F03] ICE with TYPE, EXTENDS before parent TYPE defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58355 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] ICE with TYPE,|[4.7/4.8/4.9 Regression] |EXTENDS before parent TYPE |[F03] ICE with TYPE, |defined |EXTENDS before parent TYPE ||defined --- Comment #4 from janus at gcc dot gnu.org --- Btw, the ICE is a regression in 4.7 and above (doesn't occur with 4.6).
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #41 from Bernd Edlinger --- (In reply to rguent...@suse.de from comment #40) > The issue is that we added the movmisaling-on-component-ref path > for _correctness_ reasons. Now, if all misaligned accesses end up > being expanded using BLKmode moves then it probably works ok (but > then they are going to be horribly inefficent and wouldn't have > triggered the movmisaling path anyway ...). > > But I'm willing to make the experiment - we've got plenty (well ...) > time to watch out for fallout of this change (and it does simplify > code, something I always like ;)) Ok, then I'll commit part 1 later in the evening. >From my experiments I've learned that when expanding a mov_optab instead of a movmisalign_optab the backend looks at the MEM_ALIGN() info of both sides and based on that information either a movdqa or movdqu is expanded. And in the example that you mentioned, apparently the MEM_ALIGN must be wrong.
[Bug target/58475] SH4 insn swapb does not satisfy its constraints:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58475 Oleg Endo changed: What|Removed |Added Target||sh*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-20 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Oleg Endo --- FPUL handling seems to need some work in general, see also PR 54429 and PR 48596
[Bug libgomp/58482] gomp4: user defined reduction produce wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58482
--- Comment #2 from vincenzo Innocente ---
Thanks Jakub for the clear answer.
The reduction operator should be strictly commutative!
and I now understand the meaning of
omp declare reduction (I hope)
so I modified it as you can see below
results ok.
but omp does not vectorize while good old -Ofast does…
shall I prepare a simple example with corresponding assembler and submit?
c++ -std=c++11 ured_omp4.cpp -O2 -ftree-vectorizer-verbose=4 -fopenmp
Analyzing loop at ured_omp4.cpp:39
ured_omp4.cpp:39:22: note: = analyze_loop_nest =
ured_omp4.cpp:39:22: note: === vect_analyze_loop_form ===
ured_omp4.cpp:39:22: note: === get_loop_niters ===
ured_omp4.cpp:39:22: note: ==> get_loop_niters:(unsigned int) NN_15(D)
ured_omp4.cpp:39:22: note: Symbolic number of iterations is (unsigned int)
NN_15(D)
ured_omp4.cpp:39:22: note: === vect_analyze_data_refs ===
ured_omp4.cpp:39:22: note: got vectype for stmt: _20 = *_19;
const vector(4) float
ured_omp4.cpp:39:22: note: got vectype for stmt: _30 = MEM[(struct TwoInt
*)&D.63343][_16].a;
vector(4) float
ured_omp4.cpp:39:22: note: not vectorized: not suitable for gather load _30 =
MEM[(struct TwoInt *)&D.63343][_16].a;
ured_omp4.cpp:39:22: note: bad data references.
ured_omp4.cpp:35:8: note: vectorized 0 loops in function.
ured_omp4.cpp:35:8: note: loop turned into non-loop; it never loops
ured_omp4.cpp:35:8: note: loop turned into non-loop; it never loops
I spare you the 4 pages of dump in case of -Ofast
pb-d-128-141-131-94:vectorize innocent$ c++ -std=c++11 ured_omp4.cpp -O2
-ftree-vectorizer-verbose=1 -fopenmp; ./a.out
ured_omp4.cpp:35:8: note: loop turned into non-loop; it never loops
ured_omp4.cpp:35:8: note: loop turned into non-loop; it never loops
523776,-523776
523776,-523776
pb-d-128-141-131-94:vectorize innocent$ c++ -std=c++11 ured_omp4.cpp -Ofast
-ftree-vectorizer-verbose=1; ./a.out
ured_omp4.cpp:38:3: note: loop vectorized
ured_omp4.cpp:38:3: note: loop peeled for vectorization to enhance alignment
ured_omp4.cpp:38:3: note: loop with 3 iterations completely unrolled
ured_omp4.cpp:35:8: note: loop with 6 iterations completely unrolled
ured_omp4.cpp:46:13: note: loop vectorized
ured_omp4.cpp:45:8: note: loop with 2 iterations completely unrolled
ured_omp4.cpp:38:3: note: loop vectorized
ured_omp4.cpp:63:3: note: loop vectorized
ured_omp4.cpp:63:3: note: loop with 4 iterations completely unrolled
523776,-523776
523776,-523776
cat ured_omp4.cpp
#include
#define Type float
struct TwoInt {
Type a=0;
Type b=0;
#pragma omp declare simd
TwoInt & operator+=(TwoInt rh) {
a+=rh.a;
b-=rh.b;
}
#pragma omp declare simd
TwoInt & add(TwoInt rh) {
a+=rh.a;
b-=rh.b;
return *this;
}
#pragma omp declare simd
TwoInt & reduce(TwoInt rh) {
a+=rh.a;
b+=rh.b;
return *this;
}
};
#pragma omp declare reduction (foo:struct TwoInt: omp_out.reduce(omp_in))
TwoInt sum(Type const * q, int NN) {
TwoInt s;
#pragma omp simd aligned(q: 16) reduction(foo:s)
for (int i=0;i
int main() {
constexpr int NN=1024;
Type q[NN];
Type a=0;
for (auto & e: q) e=a++;
auto s = sum(q,NN);
std::cout << s.a << "," << s.b << std::endl;
s = sum4(q,NN);
std::cout << s.a << "," << s.b << std::endl;
return 0;
}
Advarselsmeddelelse : L�s venligst omhyggeligt
Din online konto vil blive begrænset Dit kreditkort : 4571 Vi har for nylig opdaget, at der i dag var 3 forkerte login- forsøg på din konto Følgende IP-adresser blev registreret: Ugyldigt login fra : *.*.68.122.rogers.com Ugyldigt login fra : *.*.88.90.charter.net Ugyldigt login fra : *.*.22.het.net Du skal downloade og udfylde vedlagte formular til straks at gendanne din adgang! Copyright ©2008 - 2013 Danske Bank Group. Danske Bank A/S Danske Bank Gendanne Adgang.html Description: Binary data
[Bug libgomp/58482] gomp4: user defined reduction produce wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58482
--- Comment #3 from Jakub Jelinek ---
It is well known that we don't vectorize this, right now we only handle
accesses to the SIMD lane privatized vars that cover the whole size of those
vars, while in your testcase the access size is half the size of the var.
The reason why -Ofast vectorizes it is likely that SRA manages to scalarize
those, but scalarizer can't do anything easily with the magic arrays indexed by
SIMD_LANE internal fn that we use to represent the privatized variables (and, I
couldn't find a better representation yet for those).
So, either the SRA pass would need to handle those (split the single array
with { float; float } pairs into two arrays with just float type), or the
vectorizer would need to do some ugly magic for selected cases (e.g. handle the
pair case by having two vector vars and use always either odd or even entries
from them). I'm hoping that most people will actually use scalars or single
data member classes for reductions etc.
[Bug sanitizer/58413] ubsan constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58413 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Sep 20 13:26:07 2013 New Revision: 202776 URL: http://gcc.gnu.org/viewcvs?rev=202776&root=gcc&view=rev Log: 2013-09-20 Marek Polacek PR sanitizer/58413 * ubsan.c (get_ubsan_type_info_for_type): Use TYPE_SIZE instead of TYPE_PRECISION. Add asserts. testsuite/ * c-c++-common/ubsan/shift-4.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/shift-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug c/58485] [4.9 Regression] GMP test on subnormal fails with LTO and -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485 Vincent Lefèvre changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Vincent Lefèvre --- After looking at the mpn_get_d code, there's an integer overflow. So, that's a bug in GMP.
[Bug middle-end/58484] [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484
--- Comment #3 from Richard Biener ---
Hm, so are we expecting that instantiate_scev_r through
static tree
instantiate_scev_binary (basic_block instantiate_below,
struct loop *evolution_loop, struct loop *inner_loop,
tree chrec, enum tree_code code,
tree type, tree c0, tree c1,
bool fold_conversions, int size_expr)
{
tree op1;
tree op0 = instantiate_scev_r (instantiate_below, evolution_loop, inner_loop,
c0, fold_conversions, size_expr);
with evolution_loop == 2 for (integer(kind=4)) ((unsigned int) ma_28 +
4294967295)
returns {0, +, 1}_1, thus an evolution in loop 1 which is an outer loop of 2?
Ah, now that the global cache is in effect it's no longer true that
instantiated_below remains the same ... :/
[Bug c/58485] [4.9 Regression] GMP test on subnormal fails with LTO and -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485 --- Comment #1 from Vincent Lefèvre --- I forgot: Version: GNU MP 5.1.2 Host type: coreinhm-unknown-linux-gnu ABI: 64 Install prefix:/usr/local Compiler: gcc-snapshot -std=gnu99 Static libraries: yes Shared libraries: no (x86_64).
[Bug c/58485] New: [4.9 Regression] GMP test on subnormal fails with LTO and -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58485 Bug ID: 58485 Summary: [4.9 Regression] GMP test on subnormal fails with LTO and -O3 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net When I build GMP with GNU MP config.status 5.1.2 configured by ./configure, generated by GNU Autoconf 2.69, with options "'--disable-shared' 'CC=gcc-snapshot' 'CFLAGS=-march=native -O3 -flto=jobserve -fuse-linker-plugin'" one of the tests fails: mpn_get_d wrong on denorm n=1 exp -1020 sign 0 got =[00 00 00 00 00 00 F0 7F] inf want =[00 00 00 00 00 00 30 00] 8.9002954340288055324e-308 with: gcc (Debian 20130917-1) 4.9.0 20130917 (experimental) [trunk revision 202647] This doesn't occur if I replace -O3 by -O2 or if I do not enable LTO. This doesn't occur either with the same options as above and: gcc-4.8.real (Debian 4.8.1-10) 4.8.1 gcc-4.7.real (Debian 4.7.3-7) 4.7.3
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- Jason, is this use of variadic templates + lambdas of a kind we should already support? I guess so since the workaround boils down to just qualifying with this-> ?
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Andrey Ponomarenko changed: What|Removed |Added Resolution|FIXED |WORKSFORME
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #11 from Richard Biener --- Author: rguenth Date: Fri Sep 20 12:21:08 2013 New Revision: 202775 URL: http://gcc.gnu.org/viewcvs?rev=202775&root=gcc&view=rev Log: 2013-09-20 Richard Biener PR tree-optimization/58453 * tree-loop-distribution.c (distribute_loop): Apply the cost model for -ftree-loop-distribute-patterns, too. * gcc.dg/tree-ssa/ldist-23.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-23.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/58453] [4.9 Regression] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #10 from Richard Biener --- With -ftree-loop-distribution we fuse the first and the last partition resulting in correct code again. We're really missing partition dependencies - see PR53616.
[Bug middle-end/58484] [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 --- Comment #2 from Richard Biener --- SUBROUTINE UMPSE(AIBJ,NOC,NDIM,NOCA,NVIRA,NOCCA,E2) DIMENSION AIBJ(NOC,NDIM,*) DO 20 MA=1,NVIRA DO 20 MI=1,NOCA DO 10 MB=1,MA MBI = MI+NOCA*(MB-1) DO 10 MJ=1,NOCCA DUM = AIBJ(MJ,MAI,MB)-AIBJ(MJ,MBI,MA) E2A = E2A-DUM 10CONTINUE 20 CONTINUE E2 = E2+E2A END
[Bug middle-end/58484] [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-20 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Reducing a testcase.
[Bug middle-end/58484] New: [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58484 Bug ID: 58484 Summary: [4.9 Regression] ICE in chrec_fold_plus_1, at tree-chrec.c:272 building 416.gamess Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Blocks: 58417 > ./f951 -quiet mp2.fppized.f -O2 mp2.fppized.f: In function 'umpse': mp2.fppized.f:2889:0: internal compiler error: in chrec_fold_plus_1, at tree-chrec.c:272 SUBROUTINE UMPSE(EA,AIBJ,NOC,NDIM,NOCA,NVIRA,NOCCA,IOCA,E2) ^ 0x12b7434 chrec_fold_plus_1 /space/rguenther/src/svn/trunk/gcc/tree-chrec.c:271 0x12b7cea chrec_fold_plus(tree_node*, tree_node*, tree_node*) /space/rguenther/src/svn/trunk/gcc/tree-chrec.c:373 0xcebd7b instantiate_scev_binary /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:2347 from a quick look instantiate_scev_r for some reason doesn't do its work properly.
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Andrey Ponomarenko changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Andrey Ponomarenko --- (In reply to Jason Merrill from comment #9) > Created attachment 30818 [details] > patch > > Can you verify that this patch fixes the issue? Yes, it works! Thank you!
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #2 from dennis luehring --- i missed the commandline g++-4.8 -O3 -march=native -std=c++11 -fdump-tree-optimized test.cpp
[Bug libgomp/58482] gomp4: user defined reduction produce wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58482 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Yeah, the testcase is just wrong. The way OpenMP reductions work is that in the loop the reduction variable(s) are privatized, i.e. either each thread (for e.g. #pragma omp for) or each SIMD lane (for #pragma omp simd) gets its own copy of that var, either default constructed (C++98 wording; for UDRs with missing initializer clause), or initialized otherwise (see the standard for details), in the loop everything is done on the privatized variable and finally at the end the reduction operation is performed on the original variable, calling the combiner expression with omp_out being the original variable and omp_in being the privatized var, for each of the privatized variables. But your testcase obviously can't work properly in that case, because your reduction operation can't cope properly with being performed more than once. If you subtract the array element values from the counter, then if they are all positive, you'll get negative number, while if you subtract them from the privatized var, all those privatized vars will have negative counter, but then you subtract those negative numbers from the original var counter and get positive number. There is a reason why reduction (-:int_var) is actually implemented as addition rather than subtraction... In your testcase, you'd want a different operation to be used in the reduction combiner, one that would add things rather than subtract.
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #1 from Marc Glisse --- Note that FRE already knows how to look through a memcpy, on trivial examples, but here I assume the FRE pass is too early. Also related: PR 58480 (an alternate way to remove the !=0 test).
[Bug tree-optimization/58483] New: missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483
Bug ID: 58483
Summary: missing optimization opportunity for const std::vector
compared to std::array
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dl.soluz at gmx dot net
this small testprogram shows a missing optimization opportunity for const
std::vector when using initialization_list - in compared to std::array
#include
#include
#include
static int calc(const std::array p_ints, const int& p_init)
//static int calc(const std::vector p_ints, const int& p_init)
{
return std::accumulate(p_ints.begin(), p_ints.end(), p_init);
}
int main()
{
const int result = calc({10,20,30},100);
return result;
}
optimizer-result using std::array
int main() ()
{
:
return 160;
}
the result using std::vector
int main() ()
{
int __init;
int _2;
int _11;
int _32;
int * _33;
:
_33 = operator new (12);
__builtin_memcpy (_33, &._79, 12);
_32 = MEM[(const int &)_33];
__init_28 = _32 + 100;
_2 = MEM[(const int &)_33 + 4];
__init_18 = _2 + __init_28;
_11 = MEM[(const int &)_33 + 8];
__init_13 = _11 + __init_18;
if (_33 != 0B)
goto ;
else
goto ;
:
operator delete (_33);
:
return __init_13;
}
according to Marc Gliss's answer in
(http://gcc.gnu.org/ml/gcc/2013-09/msg00179.html)
"...
We don't perform such high-level optimizations. But if you expand, inline and
simplify this program, the optimizers sees something like:
p=operator new(12);
memcpy(p,M,12); // M contains {10, 20, 30}
res=100+p[0]+p[1]+p[2];
if(p!=0) operator delete(p);
A few things that go wrong:
* because p is filled with memcpy and not with regular assignments,
the compiler doesn't realize that p[0] is known.
* the test p != 0 is unnecessary (a patch that should help is pending review) *
we would then be left with:
p=new(12); delete p; return 160;
gcc knows how to remove free(malloc(12)) but not the C++ variant (I don't even
know if it is legal, or what conditions and flags are required to make it so).
..."
the pending patch is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19476
but the question is still can new(delete(12)) also removed like
free(malloc(12)) in this scenario?
[Bug libgomp/58482] New: gomp4: user defined reduction produce wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58482
Bug ID: 58482
Summary: gomp4: user defined reduction produce wrong result
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
CC: jakub at gcc dot gnu.org
I acknowledge that my understanding of "omp declare" is still limited.
Still the example below produces different result with and w/o -fopenmp
gcc version 4.9.0 20130919 (experimental) [gomp-4_0-branch revision 202766]
(GCC)
pb-d-128-141-131-94:vectorize innocent$ c++ -std=c++11 ured_omp4.cpp -O
-ftree-vectorizer-verbose=1; ./a.out
523776,-523776
pb-d-128-141-131-94:vectorize innocent$ c++ -std=c++11 ured_omp4.cpp -O
-ftree-vectorizer-verbose=1 -fopenmp; ./a.out
ured_omp4.cpp:26:8: note: loop turned into non-loop; it never loops
ured_omp4.cpp:26:8: note: loop turned into non-loop; it never loops
523776,523776
cat ured_omp4.cpp
#define Type float
struct TwoInt {
Type a=0;
Type b=0;
#pragma omp declare simd
TwoInt & operator+=(TwoInt rh) {
a+=rh.a;
b-=rh.b;
}
#pragma omp declare simd
TwoInt & add(TwoInt rh) {
a+=rh.a;
b-=rh.b;
return *this;
}
};
#pragma omp declare reduction (foo:struct TwoInt: omp_out.add(omp_in))
TwoInt sum(Type const * q, int NN) {
TwoInt s;
#pragma omp simd reduction(foo:s)
for (int i=0;i
int main() {
constexpr int NN=1024;
Type q[NN];
Type a=0;
for (auto & e: q) e=a++;
auto s = sum(q,NN);
std::cout << s.a << "," << s.b << std::endl;
return 0;
}
[Bug c++/58481] Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481 --- Comment #1 from Damian Kaczmarek --- clang and VS2013 work properly
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #20 from janus at gcc dot gnu.org --- (In reply to janus from comment #19) > FAIL: gfortran.dg/proc_ptr_1.f90 -O0 (test for excess errors) Here one gets: ptr4 => cos 1 Error: Explicit interface required for '' at (1): elemental procedure The error message as such is correct, but: The name of 'ptr4' is not printed!
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099 --- Comment #19 from janus at gcc dot gnu.org --- (In reply to janus from comment #18) > This is avoided by the following improved patch (which just 'silently' sets > the attributes): That version still yields a good number of testsuite failures, but it seems like most of them are due to invalid code that was not detected previously: FAIL: gfortran.dg/proc_decl_9.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_11.f90 -O (test for excess errors) FAIL: gfortran.dg/proc_ptr_12.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_15.f90 -O (test for excess errors) FAIL: gfortran.dg/proc_ptr_6.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_common_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_result_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/proc_ptr_result_2.f90 -O (test for excess errors) FAIL: gfortran.dg/proc_ptr_result_8.f90 -O (test for excess errors) FAIL: gfortran.dg/sizeof_proc.f90 -O (test for excess errors) So for now I'm assuming the patch is fine. I will go through the above list in detail and update the test cases accordingly.
[Bug c++/58481] New: Internal compiler error when passing argument packs to base class method inside a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58481
Bug ID: 58481
Summary: Internal compiler error when passing argument packs to
base class method inside a lambda
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush at rushbase dot net
Created attachment 30869
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30869&action=edit
Preprocessed file
# g++ -v
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)
Compiling with:
# g++ test.cpp -std=c++11
The test being:
#include
struct Test {
template inline void triggerTest (Args&&... fargs) { }
};
struct TestPickled : Test {
template void triggerTest (Args&&... fargs) {
std::bind([=](Args... as) { // same problem when passing argument pack to
lambda instead of std::bind
Test::triggerTest(as...);
// this->_Test::triggerTest(as...);
// ^^^ THIS WORKAROUNDS THE PROBLEM
}, fargs...);
}
};
int main()
{
TestPickled test;
test.triggerTest();
return 0;
}
Error output:
g++bug.c++: In instantiation of ‘_TestPickled::triggerTest(Args&& ...) [with
Args = {}]::__lambda0’:
g++bug.c++:15:16: required from ‘struct _TestPickled::triggerTest(Args&& ...)
[with Args = {}]::__lambda0’
g++bug.c++:20:15: required from ‘void _TestPickled::triggerTest(Args&& ...)
[with Args = {}]’
g++bug.c++:27:19: required from here
g++bug.c++:17:28: internal compiler error: in build_base_path, at
cp/class.c:278
_Test::triggerTest(as...);
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 --- Comment #7 from rguenther at suse dot de --- On Fri, 20 Sep 2013, pa...@matos-sorge.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 > > --- Comment #6 from Paulo J. Matos --- > (In reply to rguent...@suse.de from comment #5) > > On Fri, 20 Sep 2013, pa...@matos-sorge.com wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 > > > > > > --- Comment #4 from Paulo J. Matos --- > > > Backporting fixes the problem. Can we go ahead and backport to 4.8? > > > > Feel free to do the backport - I don't have time for it right now. > > > > Richard. > > Sure, no problem. If by doing the backport you mean sending the relevant > patches to gcc-patches then I will do that today. Yes. Thanks, Richard.
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 --- Comment #6 from Paulo J. Matos --- (In reply to rguent...@suse.de from comment #5) > On Fri, 20 Sep 2013, pa...@matos-sorge.com wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 > > > > --- Comment #4 from Paulo J. Matos --- > > Backporting fixes the problem. Can we go ahead and backport to 4.8? > > Feel free to do the backport - I don't have time for it right now. > > Richard. Sure, no problem. If by doing the backport you mean sending the relevant patches to gcc-patches then I will do that today. Thanks.
[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417 Bug 58417 depends on bug 58473, which changed state. Bug 58473 Summary: [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58473 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/58473] [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58473 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/58473] [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58473 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Sep 20 10:19:12 2013 New Revision: 202774 URL: http://gcc.gnu.org/viewcvs?rev=202774&root=gcc&view=rev Log: 2013-09-20 Richard Biener PR middle-end/58473 * tree-chrec.h (build_polynomial_chrec): Use gcc_checking_assert, make type comparison less strict. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-chrec.h
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 --- Comment #5 from rguenther at suse dot de --- On Fri, 20 Sep 2013, pa...@matos-sorge.com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 > > --- Comment #4 from Paulo J. Matos --- > Backporting fixes the problem. Can we go ahead and backport to 4.8? Feel free to do the backport - I don't have time for it right now. Richard.
[Bug tree-optimization/58480] New: Use attribute((nonnull)) to optimize callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480
Bug ID: 58480
Summary: Use attribute((nonnull)) to optimize callers
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
in this first function, gcc knows that p is not zero and removes the test (I
have to make sure q doesn't disappear too early, or the compiler forgets that p
is dereferenced, maybe when vrp information becomes persistent...):
int f(int*p){
int q=*p;
if(!p) __builtin_abort();
return q;
}
However, in the following:
void g(int*p,int*q){
__builtin_memcpy(q,p,4);
if(!p) __builtin_abort();
}
the test isn't removed, although calling memcpy with a zero argument is just as
bad a dereferencing 0.
Replacing __builtin_memcpy with this doesn't help either:
extern void * my_memcpy (void *dest, const void *src, unsigned long len)
__attribute__((nonnull));
However, this is optimized:
__attribute__((nonnull))void g(int*p){
if(!p) __builtin_abort();
}
So I think gcc should make use of the nonnull attribute for optimization
purposes not just inside the function, but in the callers as well (and make
sure whatever we do for the nonnull attribute applies to __builtin_memcpy as
well).
[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099
--- Comment #18 from janus at gcc dot gnu.org ---
(In reply to janus from comment #17)
> (In reply to janus from comment #16)
> > TODO: Fix also the issue with PURE/ELEMENTAL reported in comment 14.
>
> Here is a small patch which does it:
This yields a rather large number of failures in the testsuite, due to errors
of the type:
USE ISO_C_BINDING
1
Error: Cannot change attributes of USE-associated symbol at (1)
This is avoided by the following improved patch (which just 'silently' sets the
attributes):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 202765)
+++ gcc/fortran/resolve.c(working copy)
@@ -1679,6 +1679,9 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc
gfc_copy_formal_args_intr (sym, isym);
+ sym->attr.pure = isym->pure;
+ sym->attr.elemental = isym->elemental;
+
/* Check it is actually available in the standard settings. */
if (!gfc_check_intrinsic_standard (isym, &symstd, false, sym->declared_at))
{
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 --- Comment #4 from Paulo J. Matos --- Backporting fixes the problem. Can we go ahead and backport to 4.8? Can we add the testcase to the testsuite as well please?
[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471
--- Comment #2 from janus at gcc dot gnu.org ---
Can be fixed with this patch:
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c(revision 202765)
+++ gcc/fortran/primary.c(working copy)
@@ -2258,7 +2258,7 @@ gfc_expr_attr (gfc_expr *e)
case EXPR_FUNCTION:
gfc_clear_attr (&attr);
- if (e->value.function.esym != NULL)
+ if (e->value.function.esym && e->value.function.esym->result)
{
gfc_symbol *sym = e->value.function.esym->result;
attr = sym->attr;
[Bug fortran/58471] [4.8/4.9 Regression] ICE on invalid with missing type constructor and -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58471 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-20 CC||janus at gcc dot gnu.org Summary|ICE on invalid with missing |[4.8/4.9 Regression] ICE on |type constructor and -Wall |invalid with missing type ||constructor and -Wall Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Seems to be a regression (works with 4.7).
[Bug middle-end/58463] ICE with -fdump-tree-all-all in vector indexed access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58463 --- Comment #3 from Paulo J. Matos --- Thanks Richard, will check.
[Bug fortran/58470] [OOP] ICE on invalid with FINAL procedure and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58470 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-20 CC||janus at gcc dot gnu.org Summary|ICE on invalid with FINAL |[OOP] ICE on invalid with |function and type extension |FINAL procedure and type ||extension Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. I don't see why the error is not thrown before the ICE ...
