[Bug testsuite/59897] FAIL: c-c++-common/asan/use-after-return-1.c -O* output pattern test, is 1: 0x2285020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897 --- Comment #6 from Yury Gribov --- Dominique, please check and close if it works for you.
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 Jakub Jelinek changed: What|Removed |Added Attachment #31934|0 |1 is obsolete|| --- Comment #15 from Jakub Jelinek --- Created attachment 31943 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31943&action=edit gcc49-pr59575.patch Updated patch, which should now handle the dummy pushes also in arm_unwind_emit_sequence. Untested as before, just it doesn't ICE on the source you've attached anymore.
[Bug sanitizer/57884] False positive in libgfortran finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57884 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #3 from Yury Gribov --- Can't repro with 4.9.
[Bug bootstrap/59913] [4.9 Regresion] bootstrap failure on arm-linux-gnueabihf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #4) > I'm still bisecting, but I suspect two recent commits to lra-constraints: > > r206938 > > 2014-01-22 Vladimir Makarov > > PR rtl-optimization/59477 > * lra-constraints.c (inherit_in_ebb): Process call for living hard > regs. Update reloads_num and potential_reload_hard_regs for all > insns. > Bisection shows it's r206938
[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594
--- Comment #6 from Jakub Jelinek ---
On:
#define N 1024
int ia[N + 1];
int ib[N + 1];
void
f1 (void)
{
int i;
for (i = 0; i < N; i++)
{
ia[i + 1] = 1;
ib[i] = ia[i];
}
}
void
f2 (void)
{
int i;
for (i = 0; i < N; i++)
{
ia[i] = 1;
ib[i] = ia[i + 1];
}
}
void
f3 (void)
{
int i;
for (i = N - 1; i >= 0; i--)
{
ia[i + 1] = 1;
ib[i] = ia[i];
}
}
void
f4 (void)
{
int i;
for (i = N - 1; i >= 0; i--)
{
ia[i] = 1;
ib[i] = ia[i + 1];
}
}
we properly vectorize f2 and f3 where the write/read DDR is DDR_REVERSED_P and
not f1/f4.
On
#define N 1024
int ia[N + 1];
int ib[N + 1];
void
f1 (void)
{
int i;
for (i = 0; i < N; i++)
{
ia[i + 1] = 1;
ia[i] = 2;
}
}
void
f2 (void)
{
int i;
for (i = 0; i < N; i++)
{
ia[i] = 1;
ia[i + 1] = 2;
}
}
void
f3 (void)
{
int i;
for (i = N - 1; i >= 0; i--)
{
ia[i + 1] = 1;
ia[i] = 2;
}
}
void
f4 (void)
{
int i;
for (i = N - 1; i >= 0; i--)
{
ia[i] = 1;
ia[i + 1] = 2;
}
}
we don't vectorize f1 and f2, in both cases for the write/write DDR
DDR_REVERSED_P is false, and vectorize f3/f4, where DDR_REVERSED_P is true in
both cases. f2 and f3 shouldn't be vectorizable (at least not as is, when we'd
be trying to vectorize the two stores just by putting a vector store at that
position), f1 and f4 can. So, this leads me to believe that for write/write we
don't have a way to differentiate between the bad and good cases using dist > 0
&& DDR_REVERSED_P test. In that case, I'd think best would be to not ignore
dist > 0 && DDR_REVERSED_P (ddr)
ddrs if (!DR_IS_READ (dra) && !DR_IS_READ (drb)).
[Bug c++/59318] ICE on invalid C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59318 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-24 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Looking into it.
[Bug c++/59352] Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59352 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-24 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- The reduced testcase is simply rejected: 59352.C: In member function ‘const Derived& Interfaces::get_interface() const’: 59352.C:57:13: error: ‘derived’ was not declared in this scope if (derived == 0) ^ 59352.C:59:17: error: ‘derived’ was not declared in this scope return *derived; ^ maybe you meant to provide something else?
[Bug c++/59404] declaration shadowing template parameter wrongly accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59404 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini --- Yes, this is fixed for 4.9.0.
[Bug c++/59463] Illegal Instruction: min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59463 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Paolo Carlini --- Closing then.
[Bug c++/59540] ICE while building libcilkrt library with --disable-bootstrap and --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-24 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Please provide all the required information per the bug reporting instructions (http://gcc.gnu.org/bugs/#report), in particular the preprocessed reproducer.
[Bug libstdc++/59548] Abort after copying std::unordered_map in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548 Paolo Carlini changed: What|Removed |Added CC||fdumont at gcc dot gnu.org, ||jwakely.gcc at gmail dot com Component|c++ |libstdc++ --- Comment #4 from Paolo Carlini --- Can you please have a look?
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 Paolo Carlini changed: What|Removed |Added CC||adam at jessamine dot co.uk --- Comment #2 from Paolo Carlini --- Maybe Adam can have a look.
[Bug c++/59681] SVN 197248 adding N3582 support broke Boost.Regex with -std=c++1y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Paolo Carlini --- Let's add Jason in CC.
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini --- Sorry.
[Bug libstdc++/59548] Abort after copying std::unordered_map in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #9 from Kostya Serebryany --- > It still fails for me. It has nothing to do with "make -jN". When I I tried running this on the fresh gcc trunk. During the 3-rd stage I get this: checking how to run the C preprocessor... ../libiberty/libiberty.a(regex.o): In function `byte_compile_range': ... gcc-boot/libiberty/../../gcc/libiberty/regex.c:4495: undefined reference to `__asan_report_load1' Before that the builds works fine, but compilation of insn-recog.c with asan-ified gcc is indeed expensive: takes ~8 minutes and 4+Gb RAM This excessive memory usage may be the reason of your OOM in case you have some sort of limit (Are you by any chance building in x32 mode?) non-asanified build of insn-recog.c takes ~3.5 minutes and 700M RAM. The asan slowdown here is reasonable, but the memory overhead is surprisingly large...
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #10 from Kostya Serebryany ---
H.J., can you send the contents of /proc/PID/{maps,smaps,status}
of the failing process before it dies?
(you can use ASAN_OPTIONS=sleep_before_dying=1000)
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #11 from H.J. Lu --- (In reply to Kostya Serebryany from comment #9) > > It still fails for me. It has nothing to do with "make -jN". When I > > I tried running this on the fresh gcc trunk. > > During the 3-rd stage I get this: > checking how to run the C preprocessor... ../libiberty/libiberty.a(regex.o): > In function `byte_compile_range': > ... gcc-boot/libiberty/../../gcc/libiberty/regex.c:4495: undefined reference > to `__asan_report_load1' Please try hjl/asan branch at http://gcc.gnu.org/git/?p=gcc.git;a=summary It fixes this problem among others.
[Bug other/59384] Cilk Plus array notation with for loop after segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 --- Comment #4 from Nick Tomlinson --- Created attachment 31944 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31944&action=edit Example that is broken when the suggested patch is used.
[Bug other/59384] Cilk Plus array notation with for loop after segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 --- Comment #5 from Nick Tomlinson --- Hello I tried the new patch against the suggested revision (patch and revision from http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01170.html). While I was able to patch and build GCC, I get an incorrect warning from GCC when using _Cilk_for, and the resulting program segfaults. See the attached reproducer. Thanks
[Bug c/59933] New: for loop goes wild with assert() enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933
Bug ID: 59933
Summary: for loop goes wild with assert() enabled
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: warnerme at ptd dot net
I have this odd case where a for loop goes wild.
But it only fails when assert() is enabled.
gcc -Iinc -g -O2 -DDEBUG -fstack-protector-all -W -Wstrict-prototypes -Wall
-Wextra -Wcast-align -Wnested-externs -Wshadow -c -o build/NSQ_del_dec.o
c/NSQ_del_dec.c
If -DNDEBUG is used, the code works fine, although there is a slight difference
between CYGWIN32 (4.8.2-2) and CYGWIN64 (4.8.2-1). This was not a problem with
gcc 4.7.
if (RDmin_Q10 < RDmax_Q10)
{
#if 1
/* THIS IS THE CODE THAT FAILS */
for (k = i; k < (int)(sizeof(NSQ_del_dec_struct) /
sizeof(opus_int32)); ++k)
{
psDelDec[RDmax_ind].sLPC_Q14[k] =
psDelDec[RDmin_ind].sLPC_Q14[k];
}
#else
/* THIS IS THE WORK-AROUND */
int n = (sizeof(NSQ_del_dec_struct) / sizeof(opus_int32)) - i;
opus_int32 *src = &psDelDec[RDmin_ind].sLPC_Q14[i];
opus_int32 *dst = &psDelDec[RDmax_ind].sLPC_Q14[i];
while (n-- > 0)
*dst++ = *src++;
#endif
psSampleState[RDmax_ind][0] = psSampleState[RDmin_ind][1];
}
I've tried lots of combinations of code to get the work around, and this even
fails when I insert printf-s, but the most common with this exact code is that
it does sizeof(NSQ_del_dec_struct) number of loops leaving out the /
sizeof(opus_int32). I have had some test test where the loop didn't stop till
it destroyed enough stack to crash it.
Sorry, that the file is a bit big but trying to whittle it down usually made
the problem go away.
[Bug c/59933] for loop goes wild with assert() enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59933 --- Comment #1 from Mark Warner --- Created attachment 31945 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31945&action=edit C source of subroutines which contain problem for loop This is a file from OPUS. As sent it can't be run, but the problem was bad enough that I thought looking at the generated code might be enough. All, except system, include files are inlined.
[Bug bootstrap/59934] New: Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 Bug ID: 59934 Summary: Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Bootstrap on s390x started failing with r206941: Author: law Date: Wed Jan 22 21:27:38 2014 New Revision: 206941 URL: http://gcc.gnu.org/viewcvs?rev=206941&root=gcc&view=rev Log: PR tree-optimization/59597 * tree-ssa-threadupdate.c (dump_jump_thread_path): Move to earlier in file. Accept new argument REGISTERING and use it to modify dump output appropriately. (register_jump_thread): Corresponding changes. (mark_threaded_blocks): Reinstate code to cancel unprofitable thread paths involving joiner blocks. Add code to dump cancelled jump threading paths. PR tree-optimization/59597 * gcc.dg/tree-ssa/pr59597.c: New test. Stage 2: In file included from /home/andreas/clean/gcc-head/gcc/expmed.c:39:0: /home/andreas/clean/gcc-head/gcc/expmed.h: In function ‘void init_expmed()’: /home/andreas/clean/gcc-head/gcc/expmed.h:252:33: error: array subscript is above array bounds [-Werror=array-bounds] return &costs->cost[speed][idx]; ^ /home/andreas/clean/gcc-head/gcc/expmed.h:252:33: error: array subscript is above array bounds [-Werror=array-bounds]
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 Andreas Krebbel changed: What|Removed |Added Target||s390x-ibm-linux Priority|P3 |P2 CC||law at gcc dot gnu.org Host||s390x-ibm-linux Build||s390x-ibm-linux Severity|critical|major
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #12 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #10)
> H.J., can you send the contents of /proc/PID/{maps,smaps,status}
> of the failing process before it dies?
> (you can use ASAN_OPTIONS=sleep_before_dying=1000)
If you run cc1plus under GDB, you will get
Breakpoint 6, __sanitizer::Report (
format=format@entry=0x284f6f0 "ERROR: %s failed to allocate 0x%zx (%zd)
bytes of %s: %d\n")
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #13 from Kostya Serebryany --- > If you run cc1plus under GDB, you will get > > Breakpoint 6, __sanitizer::Report ( > format=format@entry=0x284f6f0 "ERROR: %s failed to allocate 0x%zx (%zd) > bytes of %s: %d\n") This happens due to OOM, we need to understand why OOM happens.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #14 from H.J. Lu ---
Created attachment 31946
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31946&action=edit
/proc/cc1plus/{maps,smaps,status}
This is the output of "cat /proc/cc1plus/{maps,smaps,status}".
[Bug c++/57524] [4.7/4.8/4.9 Regression] ICE: in timevar_start, at timevar.c:343
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #12 from Paolo Carlini --- As far as I can see, it's just matter of using timevar_cond_start instead of timevar_start.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #15 from Kostya Serebryany --- This looks very weird: 60200120-60200121 rw-p 00:00 0 60200121-60200122 rw-p 00:00 0 We have two adjacent mappings with the same perms which are not merged by the kernel into one. This is not what I typically see on my linux. Is this some kind of modified kernel config or something? If your kernel behaves this way no winder that mmap eventually fails.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #16 from H.J. Lu --- (In reply to Kostya Serebryany from comment #15) > This looks very weird: > 60200120-60200121 rw-p 00:00 0 > 60200121-60200122 rw-p 00:00 0 > > We have two adjacent mappings with the same perms > which are not merged by the kernel into one. > This is not what I typically see on my linux. > Is this some kind of modified kernel config or something? > > If your kernel behaves this way no winder that mmap eventually fails. I am running 3.12.8-200.fc19.x86_64 from Fedora 19.
[Bug middle-end/59917] [4.9 Regression] ICE in calc_dfs_tree, at dominance.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59917 --- Comment #2 from Jakub Jelinek --- Created attachment 31947 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31947&action=edit gcc49-pr59917.patch Untested partial fix, which fixes the first testcase, but still ICEs with the second testcase. The problem is that omp expansion relies on dominance to find the regions, but because of the incorrect EDGE_ABNORMAL edges inserted just in case by tree-cfg.c (note, all OpenMP regions are SESE by definition, and this single entry single exit property must not be violated through setjmp/longjmp, computed goto or similar in valid programs, so setjmp/longjmp is fine, as long as it doesn't leave an OpenMP region or enter OpenMP region) the dominance relationship is broken. I'd say much better would be not to create the incorrect edges at all. Say instead of making make_abnormal_goto_edges right away when walking the bbs we could just push the bbs for which we call make_abnormal_goto_edges right now into some vector, and, if cur_region in make_edges is ever non-NULL, create a vector indexed by bb numbers with corresponding cur_region values at the start of a bb, and then if the vector of bbs that might need EDGE_ABNORMAL edges is non-empty, just do make_abnormal_goto_edges once (and process all the bbs there, might be cheaper than for every bb needing EDGE_ABNORMAL walking all bbs after all) and only make edges if the source and destination bbs for the EDGE_ABNORMAL have the same omp region.
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Is it valid to longjmp to a setjmp where the containing function hasn't
terminated yet, but the scope in which the setjmp has been declared has been
left already?
I mean:
{ if (setjmp (jmp_buf) == 0) bar (); }
baz ();
and only baz () doing the longjmp? I see the standard talks about leaving the
caller, or about VLAs, and for C++ about destructors (but e.g. doesn't talk
about crossing constructors).
What about:
{ volatile int a; if (setjmp (jmp_buf) == 0) bar (&a, 0); else bar (&a, 1); }
{ volatile int b; baz (&b); }
and baz doing longjmp? This is effectively entering a scope that has been left
already, we could very well share the stack slot between a and b etc.
And for C++, say
struct A { A (); ~A (); };
...
{ volatile A a; if (setjmp (jmp_buf) == 0) bar (&a, 0); else bar (&a, 1); }
baz (&b);
? Supposedly there are no destructors that would make this invalid, on the
other side I think the C++ wording is as if setjmp was catch and longjmp throw,
and you really can't do that with throw/catch.
Anyway, the idea was that if longjmp to setjmp that has already left it's scope
was invalid, we could do some hacks and add the EDGE_ABNORMAL edges only from
calls within the scope of the setjmp. As the testcase has all the setjmp
surrounded by small scopes that have only one _setjmp together with at most a
couple of calls, this would dramatically reduce the number of EH edges,
SSA_NAMEs etc.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can you please attach expmed.i and gcc options used to compile it, so that it can be hopefully debugged using a cross-compiler? As it is stage2, I'd think that it shouldn't be a miscompilation of cc1plus itself.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #2 from Andreas Krebbel --- Created attachment 31948 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31948&action=edit Preprocessed file compile with: -O2 -Warray-bounds
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #17 from Kostya Serebryany ---
When I look at my /proc/PID/maps of cc1plus, I see this:
...
6100-6103 rw-p 00:00 0
6103-6110 ---p 00:00 0
6110-61100098 rw-p 00:00 0
61100098-6120 ---p 00:00 0
6120-6120001b rw-p 00:00 0
6120001b-6130 ---p 00:00 0
6130-61300037 rw-p 00:00 0
61300037-6140 ---p 00:00 0
6140-6140001a rw-p 00:00 0
6140001a-6150 ---p 00:00 0
6150-61500046 rw-p 00:00 0
...
As you can see, there are no adjacent mappings with same perms.
Here is a tiny test:
#include
#include
#include
int main() {
static volatile void *x;
for (int i = 0; i < 100; i++)
x = malloc(1000);
printf("PID %d\n", getpid());
sleep(100);
}
% clang -fsanitize=address nmalloc.c ; ./a.out
The mapping at the end looks like this:
...
2008fff7000-10007fff8000 rw-p 00:00 0
6000-6190 ---p 00:00 0
6190-61904c4c rw-p 00:00 0
61904c4c-6400 ---p 00:00 0
6400-64003000 rw-p 00:00 0
7f434fff7000-7f434fffb000 rw-p 00:00 0
...
Note: only 4 mappings that start with 6.
I bet that on your OS this test will fail under asan; please check.
I don't know what makes Linux behave this way, we haven't seen it before.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 Kostya Serebryany changed: What|Removed |Added CC||eugeni.stepanov at gmail dot com --- Comment #18 from Kostya Serebryany --- eugenis@ says he sees something similar on Ubuntu 13.10.
[Bug preprocessor/59935] New: [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 Bug ID: 59935 Summary: [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org markus@x4 src % gcc -P --save-temps -O3 -o cairo-ft-font.o -c -I../../../../dist/system_wrappers -include /var/tmp/mozilla-central/config/gcc_hidden.h -DPACKAGE_VERSION='"moz"' -DPACKAGE_BUGREPORT='"http://bugzilla.mozilla.org/";' -DCAIRO_HAS_PTHREAD -D_GNU_SOURCE -DMOZ_TREE_CAIRO -DMOZ_TREE_PIXMAN -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I/var/tmp/mozilla-central/gfx/cairo/cairo/src -I. -I../../../../dist/include -I/var/tmp/moz-build-dir/dist/include/nspr -I/var/tmp/moz-build-dir/dist/include/nss -I/usr/include/freetype2 -I/usr/include/freetype2 -fPIC -include ../../../../mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/cairo-ft-font.o.pp -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Werror=int-to-pointer-cast -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -Wcast-align -march=native -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe -DNDEBUG -DTRIMMED -O3 -fomit-frame-pointer -Wno-missing-field-initializers -Wno-conversion /var/tmp/mozilla-central/gfx/cairo/cairo/src/cairo-ft-font.c gcc: warning: -pipe ignored because -save-temps specified /var/tmp/mozilla-central/gfx/cairo/cairo/src/cairo-ft-font.c:64:0: warning: "_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE /* for RTLD_DEFAULT */ ^ :0:0: note: this is the location of the previous definition : internal compiler error: Segmentation fault 0x99c78f crash_signal ../../gcc/gcc/toplev.c:337 0xf0d0a7 add_file_to_cache_tab ../../gcc/gcc/input.c:296 0xf0d0a7 lookup_or_add_file_to_cache_tab ../../gcc/gcc/input.c:330 0xf0d0a7 location_get_source_line(expanded_location, int*) ../../gcc/gcc/input.c:704 0xf07feb diagnostic_show_locus(diagnostic_context*, diagnostic_info const*) ../../gcc/gcc/diagnostic.c:304 0xf0902b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/gcc/diagnostic.c:800 0x5cde84 c_cpp_error(cpp_reader*, int, int, unsigned int, unsigned int, char const*, __va_list_tag (*) [1]) ../../gcc/gcc/c-family/c-common.c:9638 0xf17856 cpp_error_with_line(cpp_reader*, int, unsigned int, unsigned int, char const*, ...) ../../gcc/libcpp/errors.c:163 0xf278ff _cpp_create_definition ../../gcc/libcpp/macro.c:3124 0xf14051 do_define ../../gcc/libcpp/directives.c:584 0xf15887 _cpp_handle_directive ../../gcc/libcpp/directives.c:492 0xf223dc _cpp_lex_token ../../gcc/libcpp/lex.c:2067 0xf26fcf cpp_get_token_1 ../../gcc/libcpp/macro.c:2362 0x5e9d5f scan_translation_unit ../../gcc/gcc/c-family/c-ppoutput.c:176 0x5e9d5f preprocess_file(cpp_reader*) ../../gcc/gcc/c-family/c-ppoutput.c:101 0x5e8778 c_common_init() ../../gcc/gcc/c-family/c-opts.c:1040 0x57ad4d c_objc_common_init() ../../gcc/gcc/c/c-objc-common.c:65 0x99e7e6 lang_dependent_init ../../gcc/gcc/toplev.c:1712 0x99e7e6 do_compile ../../gcc/gcc/toplev.c:1900 Perhaps not surprisingly compiling the preprocessed file works fine. Started with r206957.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #19 from Kostya Serebryany --- (In reply to Kostya Serebryany from comment #18) > eugenis@ says he sees something similar on Ubuntu 13.10. Actually, only on Ubuntu 14.04 candidate. Looks like a fresh regression in Kernel.
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 Markus Trippelsdorf changed: What|Removed |Added Last reconfirmed||2014-1-24 CC||dodji at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #3 from Carlos O'Donell --- (In reply to Jakub Jelinek from comment #2) > Is it valid to longjmp to a setjmp where the containing function hasn't > terminated yet, but the scope in which the setjmp has been declared has been > left already? IMO this is undefined behaviour. I can't convince myself that can be anything but that. However, as written ISO C allows this, but it's allowance would require that the entire state of the scope should be kept around for the duration of the function just to satisfy the wording of setjmp/longjmp in the standard. I can't justify that to myself. An implementation might detect a setjmp in the scope, along with volatile or non-automatic variables and then making sure the state of the scope is never reused so a longjmp can return to it.
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #20 from Evgeniy Stepanov --- I can confirm that the issue can be reproduced on 3.13.0-5-generic (ubuntu 14.04 candidate), and can not be reproduced on 3.11.0-15-generic (ubuntu 13.10).
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733
--- Comment #21 from Evgeniy Stepanov ---
A reproducer without ASan:
#include
#include
#include
#include
int main() {
char * p = (char*)0x61904c1e;
for (int i = 0; i < 100; ++i)
mmap(p + i * 4096, 4096, PROT_WRITE | PROT_READ, MAP_PRIVATE |
MAP_ANONYMOUS, 0, 0);
printf("PID %d\n", getpid());
sleep(100);
}
[Bug other/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
typedef unsigned int (__attribute__ ((ms_abi)) *F) (long);
void
foo (F f)
{
f (0);
}
or even:
extern void bar (int) __attribute__ ((ms_abi));
void
foo (void)
{
bar (0);
}
Why do you need ACCUMULATE_OUTGOING_ARGS in the non-ms_abi caller of a ms_abi
function though? There is no SEH involved there... I see the subsequent ICE is
about the stack pointer delta not being sufficiently aligned, but it is unclear
if it is because of i386.c bug in the ms_abi support, or calls.c bug.
Changing ACCUMULATE_OUTGOING_ARGS on the fly if we notice that the current
function calls or might call a ms_abi function would be both weird and not sure
where the target would have a chance to see the calls to decide that prior to
expansion (and, changing that while already in expansion is too late).
[Bug sanitizer/59733] [4.9 Regression] bootstrap-asan failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59733 --- Comment #22 from Kostya Serebryany --- A quick workaround would be to change static const uptr kUserMapSize = 1 << 16; in sanitizer_common/sanitizer_allocator.h to something like 17 or 18. We can also try using mremap. However I'd like to hear from kernel experts whether this is considered a kernel bug or a feature.
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 --- Comment #1 from Markus Trippelsdorf --- markus@x4 /tmp % cat foo.c #define _GNU_SOURCE markus@x4 /tmp % gcc -D_GNU_SOURCE -c foo.c foo.c:1:0: warning: "_GNU_SOURCE" redefined [enabled by default] #define _GNU_SOURCE ^ :0:0: note: this is the location of the previous definition foo.c:1:0: internal compiler error: Segmentation fault
[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59935 Dodji Seketeli changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dodji at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dodji Seketeli --- I am looking into that.
[Bug c++/57524] [4.7/4.8/4.9 Regression] ICE: in timevar_start, at timevar.c:343
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 --- Comment #13 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 24 15:45:14 2014 New Revision: 207047 URL: http://gcc.gnu.org/viewcvs?rev=207047&root=gcc&view=rev Log: /cp 2014-01-24 Paolo Carlini PR c++/57524 * name-lookup.c (push_using_directive): Use timevar_cond_start. /testsuite 2014-01-24 Paolo Carlini PR c++/57524 * g++.dg/ext/timevar2.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/timevar2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/57524] [4.7/4.8/4.9 Regression] ICE: in timevar_start, at timevar.c:343
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 --- Comment #14 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 24 15:53:07 2014 New Revision: 207048 URL: http://gcc.gnu.org/viewcvs?rev=207048&root=gcc&view=rev Log: /cp 2014-01-24 Paolo Carlini PR c++/57524 * name-lookup.c (push_using_directive): Use timevar_cond_start. /testsuite 2014-01-24 Paolo Carlini PR c++/57524 * g++.dg/ext/timevar2.C: New. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/ext/timevar2.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/name-lookup.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/57524] [4.7 Regression] ICE: in timevar_start, at timevar.c:343
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|4.7.4 |4.8.3 Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] ICE: in |ICE: in timevar_start, at |timevar_start, at |timevar.c:343 |timevar.c:343 --- Comment #15 from Paolo Carlini --- Fixed mainline and 4.8.3.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #3 from Jeffrey A. Law --- I'll take a look. It's a couple deep in the queue, but obviously high priority.
[Bug libstdc++/59548] [4.7/4.8/4.9 Regression] Abort after copying std::unordered_map in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548 Jonathan Wakely changed: What|Removed |Added Known to work||4.6.4 Summary|Abort after copying |[4.7/4.8/4.9 Regression] |std::unordered_map in debug |Abort after copying |mode|std::unordered_map in debug ||mode --- Comment #5 from Jonathan Wakely --- (In reply to Max Kellermann from comment #3) > This is a regression by svn r195253. Are you sure? I see this fail on the 4.7 branch, which doesn't have that change. I'm about to fix it anyway ...
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920 --- Comment #4 from joseph at codesourcery dot com --- For C I believe it's valid to jump back into a scope like that. I don't think it affects reuse of stack space, because the variables in the scope that was left have no defined values at longjmp time and so have no defined values on the second return from setjmp.
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed by reverting the RANGE_EXPR change.
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Jan 24 16:47:54 2014 New Revision: 207051 URL: http://gcc.gnu.org/viewcvs?rev=207051&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * typeck2.c (process_init_constructor_array): Don't create RANGE_EXPR yet. Added: trunk/gcc/testsuite/g++.dg/init/aggr10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
[Bug c++/59659] large zero-initialized std::array compile time excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659 --- Comment #11 from Jason Merrill --- Author: jason Date: Fri Jan 24 16:47:54 2014 New Revision: 207051 URL: http://gcc.gnu.org/viewcvs?rev=207051&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * typeck2.c (process_init_constructor_array): Don't create RANGE_EXPR yet. Added: trunk/gcc/testsuite/g++.dg/init/aggr10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
[Bug libgcc/59936] New: undefined reference to gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59936 Bug ID: 59936 Summary: undefined reference to gfortran Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: benyahia-nezha at hotmail dot fr Hello, I'am using quantum espresso in my searches, but i'am still a beginner in this domain. I have faced a problem in which it prevent me to compile my program, i have looked all around the internet for the hope of finding a solution to this issue but unfortunately nothing was found. If you have some solution to this problem, please don't hesitate for helping me, and i you will be so gratefull. Here is the message that i have received when writing the command "gcc band-3c.for" root@b-HP-Pavilion-Sleekbook-15-PC:/home/band# gcc band-3c.for /tmp/ccxmgVZP.o: dans la fonction « MAIN__ »: band-3c.for : (.text+0x63): référence indéfinie vers « _gfortran_st_open » band-3c.for : (.text+0xaf): référence indéfinie vers « _gfortran_st_read » band-3c.for : (.text+0xcc): référence indéfinie vers « _gfortran_transfer_real » band-3c.for : (. text+0xe9): référence indéfinie vers « _gfortran_transfer_real » band-3c.for : ( .text+0x106): référence indéfinie vers « _gfortran_transfer_real » band-3c.for: (.text+0x114): référence indéfinie vers « _gfortran_st_read_done » band-3c.for: (.text+0x14a): référence indéfinie vers « _gfortran_st_read » band-3c.for: (.text+0x167): référence indéfinie vers « _gfortran_transfer_real » band-3c.for: (.text+0x184): référence indéfinie vers « _gfortran_transfer_real » band-3c.for: (.text+0x1a1): référence indéfinie vers « _gfortran_transfer_real » band-3c.for: (.text+0x1be): référence indéfinie vers « _gfortran_transfer_real » band-3c.for: (.text+0x1db): référence indéfinie vers « _gfortran_transfer_real » /tmp/ccxmgVZP.o:band-3c.for . text+0x1f8): encore plus de références indéfinies suivent vers « _gfortran_transfer_real » /tmp/ccxmgVZP.o: dans la fonction « MAIN__ »: band-3c.for: (.text+0x240): référence indéfinie vers « _gfortran_st_read_done » band-3c.for: (.text+0x28a): référence indéfinie vers « _gfortran_st_write » band-3c.for: (.text+0x2a7): référence indéfinie vers « _gfortran_transfer_integer_write » band-3c.for: (.text+0x2c4): référence indéfinie vers « _gfortran_transfer_real_write » band-3c.for: (.text+0x2e1): référence indéfinie vers « _gfortran_transfer_real_write » band-3c.for: (.text+0x2fe): référence indéfinie vers « _gfortran_transfer_real_write » band-3c.for: (.text+0x31b): référence indéfinie vers « _gfortran_transfer_real_write » band-3c.for: (.text+0x338): référence indéfinie vers « _gfortran_transfer_real_write » /tmp/ccxmgVZP.o:band-3c.for . text+0x355): encore plus de références indéfinies suivent vers « _gfortran_transfer_real_write » /tmp/ccxmgVZP.o: dans la fonction « MAIN__ »: band-3c.for: (.text+0x39d): référence indéfinie vers « _gfortran_st_write_done » /tmp/ccxmgVZP.o: dans la fonction « main »: band-3c.for:(.text+0x3d7): référence indéfinie vers « _gfortran_set_args » band-3c.for: (.text+0x3eb): référence indéfinie vers « _gfortran_set_options » collect2: erreur: ld a retourné 1 code d'état d'exécution The file "band-3c.for": c plot structure de bande c point du klist a,b,c c les energies d,e,f,g,h,p,q,r,s,t(nombre de bande) real*8 a,b,c,d,e,f,g,h,i,j,k real*8 l,m,n,o,p,q,r,s real*8 t,u,v,w,x,y,z,aa real*8 bb,cc integer iii c Lire les energies apartir du fichier out ZnSbands.dat open(unit=2,status='unknown', file='GaAs-band') c i est le nonbre de point dans le klist do iii=1,91 read(2,*) a,b,c read(2,*) d,e,f,g,h,i,j,k write(3,10) iii,d,e,f,g,h,i,j,k 10 format(3x,I3,3x,120(f12.4,4x)) end do end root@b-HP-Pavilion-Sleekbook-15-PC:/home/band# gfortran -v Utilisation des specs internes. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper Target: i686-linux-gnu Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --enable-targets=all --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --disable-werror --with-arch-
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Matthew Krafczyk changed: What|Removed |Added CC||krafczyk.matthew at gmail dot com --- Comment #13 from Matthew Krafczyk --- Hi, this is still broken in the latest git version of gcc. What are the hurdles which need to be accomplished to get this bug fixed?
[Bug c++/59659] large zero-initialized std::array compile time excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659 --- Comment #12 from Jason Merrill --- Author: jason Date: Fri Jan 24 17:09:07 2014 New Revision: 207052 URL: http://gcc.gnu.org/viewcvs?rev=207052&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * g++.dg/opt/value-init2.C: Remove. Removed: trunk/gcc/testsuite/g++.dg/opt/value-init2.C
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 --- Comment #10 from Jason Merrill --- Author: jason Date: Fri Jan 24 17:09:07 2014 New Revision: 207052 URL: http://gcc.gnu.org/viewcvs?rev=207052&root=gcc&view=rev Log: PR c++/59886 PR c++/59659 * g++.dg/opt/value-init2.C: Remove. Removed: trunk/gcc/testsuite/g++.dg/opt/value-init2.C
[Bug c++/58550] [4.9 Regression] ][c++11] ICE with auto in function return type and lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934
--- Comment #4 from Jakub Jelinek ---
I think it is just warning on dead code, but GCC doesn't know it is dead code.
s390 doesn't have any partial or vector modes, so expmed_mode_index
because MIN_MODE_PARTIAL_INT and MIN_MODE_VECTOR_INT are 0 becomes:
switch (((enum mode_class) mode_class[mode]))
{
case MODE_INT:
return mode - 22;
case MODE_PARTIAL_INT:
return mode + 6;
case MODE_VECTOR_INT:
return mode + 6;
default:
gcc_unreachable ();
}
}
Now, when we use the result of this in a loop with mode going from 22 to 27 or
so, for MODE_INT (which those modes are) we get correct values 0 to 5, but for
for the other cases the range of mode + 6 will be 28 to 33 which obviously
doesn't fit as a valid index into array of 6. Now, when jump threading or what
duplicates the array accesses for the different cases, it is obvious why VRP2
complains. But, I'd guestion the desirability to warn about it during VRP2 at
all, at least unless we have some way to mark statements that were jump
threaded and just not warn about those. I remember various other issues like
this in the past.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #5 from Jeffrey A. Law --- I'd kindof suspected something along those lines and I've had to fix problems like this in the past. I'll have to look at how we dealt with this in the past.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #6 from Jakub Jelinek --- Now, if we want to "fix" this on the expmed.h side, either: --- gcc/expmed.h2014-01-03 11:40:57.228320531 +0100 +++ gcc/expmed.h2014-01-24 18:30:12.513908749 +0100 @@ -221,9 +221,11 @@ expmed_mode_index (enum machine_mode mod case MODE_INT: return mode - MIN_MODE_INT; case MODE_PARTIAL_INT: - return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT; + return (MIN_MODE_PARTIAL_INT == VOIDmode + ? 0 : mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT); case MODE_VECTOR_INT: - return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT; + return (MIN_MODE_VECTOR_INT == VOIDmode + ? mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT); default: gcc_unreachable (); } or --- gcc/expmed.h2014-01-03 11:40:57.228320531 +0100 +++ gcc/expmed.h2014-01-24 18:34:01.806725352 +0100 @@ -221,8 +221,10 @@ expmed_mode_index (enum machine_mode mod case MODE_INT: return mode - MIN_MODE_INT; case MODE_PARTIAL_INT: + gcc_assert (MIN_MODE_PARTIAL_INT != VOIDmode); return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT; case MODE_VECTOR_INT: + gcc_assert (MIN_MODE_VECTOR_INT != VOIDmode); return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT; default: gcc_unreachable (); should be enough to explain to the compiler that those cases really can't happen and let gcc not emit the warnings.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #7 from Jakub Jelinek --- Perhaps we could set gimple_set_no_warning on the jump threaded stmts and honor that in VRP array checking. Or TREE_NO_WARNING on the handled_component_p operands of the threaded stmts.
[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Jonathan Wakely --- Thanks, yes the general idea is identical. I prefer some parts of Kyle's fix but I don't want the new constructor to be public, so I'll combine the two patches and post it to gcc-patches next week.
[Bug c++/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #34 from Jason Merrill --- Created attachment 31949 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31949&action=edit mark_needed patch I don't see the function being declared 'inline' anywhere, so there's no ODR violation. I tried adding a mark_needed call to mark_decl_instantiated, as in this patch. But setting forced_by_abi on the cgraph node for the instantiation doesn't seem to help; the LTO output still has a private symbol.
[Bug target/59820] alpha: incorrect optimisation with -mcpu=ev4 and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820 --- Comment #4 from Richard Henderson --- Should be fixed in glibc mainline, by commit 4ab6acaebd0047dc37c6493946484be9f1b4920b
[Bug target/59820] alpha: incorrect optimisation with -mcpu=ev4 and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Richard Henderson --- glibc asm bug, not a compiler bug
[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com Depends on||11856 --- Comment #5 from Jason Merrill --- In retrospect, I think that change (which I suggested) was wrong. We don't want to suppress all warnings just because we're in a template; c_inhibit_evaluation_warnings should only be used when we aren't actually generating code for an expression. A better solution for 11856 would be to disable just -Wtype-limits in template instantiations, or even just across the build_x_binary_op if the expression before substitution is type-dependent.
[Bug c++/58561] [4.8/4.9 Regression] [c++11] ICE using declaration of function with auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58561 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- > -g isn't needed to reproduce this. Started with r198096, the huge function > with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so > starting with the r198096 commit we create probably about 1000 or so more > basic blocks, hundreds of thousands abnormal edges (but still *.cfg dump is > emitted quickly), I think all the memory is eaten by huge PHI argument lists. It's precisely for this kind of situation that the "weirdo" (your word IIRC :-) lowering of __builtin_setjmp was added. Maybe something similar could be done.
[Bug c++/59540] ICE while building libcilkrt library with --disable-bootstrap and --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540 --- Comment #2 from Nenad Vukicevic --- I just rechecked the latest trunk. Still the same problem. I am running the build on x86 VM with 4Gb of memory and I suspect that gcc ran out of memory as it took a long time to come back with an error. I am attaching the preprocessed file. I didn't think that it is useful as you have to build the g++ with the specified configure options in order to duplicate the problem Here is the current output. /eng/upc/dev/nenad/gcc-trunk/bld/./gcc/xg++ -B/eng/upc/dev/nenad/gcc-trunk/bld/./gcc/ -nostdinc++ -nostdinc++ -I/eng/upc/dev/nenad/gcc-trunk/bld/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/eng/upc/dev/nenad/gcc-trunk/bld/i686-pc-linux-gnu/libstdc++-v3/include -I/eng/upc/dev/nenad/gcc-trunk/src/libstdc++-v3/libsupc++ -I/eng/upc/dev/nenad/gcc-trunk/src/libstdc++-v3/include/backward -I/eng/upc/dev/nenad/gcc-trunk/src/libstdc++-v3/testsuite/util -L/eng/upc/dev/nenad/gcc-trunk/bld/i686-pc-linux-gnu/libstdc++-v3/src -L/eng/upc/dev/nenad/gcc-trunk/bld/i686-pc-linux-gnu/libstdc++-v3/src/.libs -L/eng/upc/dev/nenad/gcc-trunk/bld/i686-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include "-DPACKAGE_NAME=\"Cilk Runtime Library\"" -DPACKAGE_TARNAME=\"cilk-runtime-library\" -DPACKAGE_VERSION=\"2.0\" "-DPACKAGE_STRING=\"Cilk Runtime Library 2.0\"" -DPACKAGE_BUGREPORT=\"c...@intel.com\" -DPACKAGE_URL=\"\" -DPACKAGE=\"cilk-runtime-library\" -DVERSION=\"2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_ATTRIBUTE_VISIBILITY=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -I. -I../../../src/libcilkrts -I../../../src/libcilkrts/include -I../../../src/libcilkrts/runtime -I../../../src/libcilkrts/runtime/config/x86 -DIN_CILK_RUNTIME=1 -fcilkplus -g -O2 -D_GNU_SOURCE -MT cilk-abi-cilk-for.lo -MD -MP -MF .deps/cilk-abi-cilk-for.Tpo -c ../../../src/libcilkrts/runtime/cilk-abi-cilk-for.cpp -fPIC -DPIC -o .libs/cilk-abi-cilk-for.o xg++: internal compiler error: Segmentation fault (program cc1plus) 0x8050470 execute ../../src/gcc/gcc.c:2841 0x8050764 do_spec_1 ../../src/gcc/gcc.c:4641 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 0x8050d3c do_spec_1 ../../src/gcc/gcc.c:5295 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 0x8050d3c do_spec_1 ../../src/gcc/gcc.c:5295 0x8050bb7 do_spec_1 ../../src/gcc/gcc.c:5410 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 0x8050d3c do_spec_1 ../../src/gcc/gcc.c:5295 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 0x8050d3c do_spec_1 ../../src/gcc/gcc.c:5295 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 0x8050d3c do_spec_1 ../../src/gcc/gcc.c:5295 0x8052dca process_brace_body ../../src/gcc/gcc.c:5924 0x8052dca handle_braces ../../src/gcc/gcc.c:5838 Please submit a full bug report,
[Bug c++/59540] ICE while building libcilkrt library with --disable-bootstrap and --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59540 --- Comment #3 from Nenad Vukicevic --- Created attachment 31950 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31950&action=edit Preprocessed file that causes ICE
[Bug c++/58550] [4.9 Regression] ][c++11] ICE with auto in function return type and lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/58550] [4.9 Regression] ][c++11] ICE with auto in function return type and lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58550 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Jan 24 19:05:39 2014 New Revision: 207055 URL: http://gcc.gnu.org/viewcvs?rev=207055&root=gcc&view=rev Log: PR c++/58550 * decl.c (grokdeclarator): Turn pedwarn about auto return type in c++11 into error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto41.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/59224] [4.7/4.8/4.9 Regression] std::uncaught_exception returns true while constructing exception.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59224 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/59898] alignment problems in std::map with avx/avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898 --- Comment #5 from ignat at gmx dot net --- 16 overloadable memory allocation functions??? brave new world! Nothing against the possibility to have explicit alignment (when you need to align to a cache line, page or disk-block), but why not just do the right thing and let new return properly aligned pointers by default as it's supposed to do? Isn't that the idea of using a typed language in the first place? Unless I have missed something, I thought the whole point of introducing the alignof operator is exactly to make this possible for user defined allocators. And of course nothing has ever prevented the builtin new to return properly aligned pointers as the compiler internally always has this info. Just because a standard allows to return misaligned pointers to users doesn't mean the implementation has to. ignatius
[Bug c++/59231] [4.8/4.9 Regression] gcc misses [-Werror=sign-compare] when inside a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59231 --- Comment #6 from Paolo Carlini --- However, what Jason suggested at the time was "ANOTHER job for c_inhibit_evaluation_warning" (emphasis mine). In my mind that was important because I saw a clear consistency rationale in the fix. Before changing / reverting anything here, we should therefore audit all those uses and figure out which ones we want to remove and finally decide which replacement. Frankly, I'm not sure this is 4.9 material (whoever does the job ;)
[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920 --- Comment #6 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #5) > > -g isn't needed to reproduce this. Started with r198096, the huge function > > with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so > > starting with the r198096 commit we create probably about 1000 or so more > > basic blocks, hundreds of thousands abnormal edges (but still *.cfg dump is > > emitted quickly), I think all the memory is eaten by huge PHI argument > > lists. > > It's precisely for this kind of situation that the "weirdo" (your word IIRC > :-) lowering of __builtin_setjmp was added. Maybe something similar could > be done. So perhaps a dummy internal call inserted right before the setjmp/returns_twice call and a dummy setjmp/returns_twice dispatcher and just add the AB edges? The internal call before the setjmp/returns_twice calls would have FALLTHRU edge to the setjmp/returns_twice call and AB edge to the dummy dispatcher and the dummy dispatcher would have AB edge to all the setjmp/returns_twice calls. Guess that would be enough for GIMPLE purposes, the question is what we want at RTL level. I've tried the #c0 testcase with _setjmp calls replaced with __builtin_setjmp, and while it also isn't really small IL, e.g. the __builtin_setjmp_dispatcher bb has 294 PHIs, each with 1852 args, and then each of the __builtin_setjmp_receiver blocks has those 294 PHIs with 2 args, it is far better than if we have over 200 basic blocks for _setjmp calls, each with 294 PHIs and each with 1852 arguments. That is still 100mil. PHI arguments right now vs. 60 PHI arguments after the change.
[Bug libstdc++/59548] [4.7/4.8/4.9 Regression] Abort after copying std::unordered_map in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Jan 24 20:08:20 2014 New Revision: 207059 URL: http://gcc.gnu.org/viewcvs?rev=207059&root=gcc&view=rev Log: PR libstdc++/59548 * include/debug/safe_base.h (_Safe_sequence_base): Define copy constructor to prevent it being implicitly defined as deleted, but do not copy anything. * include/debug/safe_unordered_base.h (_Safe_unordered_container_base): Define copy and move constructors similar to _Safe_sequence_base's. * testsuite/23_containers/unordered_map/59548.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_map/59548.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/safe_base.h trunk/libstdc++-v3/include/debug/safe_unordered_base.h
[Bug libstdc++/59548] [4.7/4.8 Regression] Abort after copying std::unordered_map in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59548 Jonathan Wakely changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Abort |Abort after copying |after copying |std::unordered_map in debug |std::unordered_map in debug |mode|mode --- Comment #7 from Jonathan Wakely --- Fixed on the trunk so far.
[Bug libstdc++/59529] fix experimental/string_view end-of-string edge cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529 --- Comment #1 from emsr at gcc dot gnu.org --- Author: emsr Date: Fri Jan 24 20:15:00 2014 New Revision: 207060 URL: http://gcc.gnu.org/viewcvs?rev=207060&root=gcc&view=rev Log: 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> PR libstdc++/59531 * testsuite/experimental/string_view/operations/copy/char/1.cc: New. * testsuite/experimental/string_view/operations/copy/wchar_t/1.cc: New. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59531 * include/experimental/string_view (copy(_CharT*, size_type, size_type) const): Correct throw string. Correct copy start location. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59530 * include/experimental/string_view (operator[](size_type) const): Fix one-off index error in debug check. * testsuite/experimental/string_view/element_access/char/1.cc: Don't test basic_string_view at size(). * testsuite/experimental/string_view/element_access/wchar_t/1.cc: Ditto. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59529 * include/experimental/string_view (basic_string_view(const _CharT*, size_type)): Don't care if len == 0. * testsuite/experimental/string_view/operations/substr/char/1.cc: Comment out catch of out_of_range; No terminating null in basic_string_view. Check begin == end. * testsuite/experimental/string_view/operations/substr/wchar_t/1.cc: Ditto. Added: trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/string_view trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/wchar_t/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/wchar_t/1.cc
[Bug libstdc++/59531] string_view overrun in copy operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531 --- Comment #2 from emsr at gcc dot gnu.org --- Author: emsr Date: Fri Jan 24 20:15:00 2014 New Revision: 207060 URL: http://gcc.gnu.org/viewcvs?rev=207060&root=gcc&view=rev Log: 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> PR libstdc++/59531 * testsuite/experimental/string_view/operations/copy/char/1.cc: New. * testsuite/experimental/string_view/operations/copy/wchar_t/1.cc: New. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59531 * include/experimental/string_view (copy(_CharT*, size_type, size_type) const): Correct throw string. Correct copy start location. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59530 * include/experimental/string_view (operator[](size_type) const): Fix one-off index error in debug check. * testsuite/experimental/string_view/element_access/char/1.cc: Don't test basic_string_view at size(). * testsuite/experimental/string_view/element_access/wchar_t/1.cc: Ditto. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59529 * include/experimental/string_view (basic_string_view(const _CharT*, size_type)): Don't care if len == 0. * testsuite/experimental/string_view/operations/substr/char/1.cc: Comment out catch of out_of_range; No terminating null in basic_string_view. Check begin == end. * testsuite/experimental/string_view/operations/substr/wchar_t/1.cc: Ditto. Added: trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/string_view trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/wchar_t/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/wchar_t/1.cc
[Bug libstdc++/59530] Incorrect check on string_view operator[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530 --- Comment #2 from emsr at gcc dot gnu.org --- Author: emsr Date: Fri Jan 24 20:15:00 2014 New Revision: 207060 URL: http://gcc.gnu.org/viewcvs?rev=207060&root=gcc&view=rev Log: 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> PR libstdc++/59531 * testsuite/experimental/string_view/operations/copy/char/1.cc: New. * testsuite/experimental/string_view/operations/copy/wchar_t/1.cc: New. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59531 * include/experimental/string_view (copy(_CharT*, size_type, size_type) const): Correct throw string. Correct copy start location. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59530 * include/experimental/string_view (operator[](size_type) const): Fix one-off index error in debug check. * testsuite/experimental/string_view/element_access/char/1.cc: Don't test basic_string_view at size(). * testsuite/experimental/string_view/element_access/wchar_t/1.cc: Ditto. 2014-01-24 Ed Smith-Rowland <3dw...@verizon.net> Peter A. Bigot PR libstdc++/59529 * include/experimental/string_view (basic_string_view(const _CharT*, size_type)): Don't care if len == 0. * testsuite/experimental/string_view/operations/substr/char/1.cc: Comment out catch of out_of_range; No terminating null in basic_string_view. Check begin == end. * testsuite/experimental/string_view/operations/substr/wchar_t/1.cc: Ditto. Added: trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/ trunk/libstdc++-v3/testsuite/experimental/string_view/operations/copy/wchar_t/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/string_view trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/element_access/wchar_t/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/char/1.cc trunk/libstdc++-v3/testsuite/experimental/string_view/operations/substr/wchar_t/1.cc
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #8 from Jeffrey A. Law --- Setting TREE_NO_WARNING seems wrong to me. That would really seem better suited for cases where we have already warned on that expression and don't want to warn on it again. This case is pretty different. In effect threading isolates paths. Path isolation can/will expose out-of-bounds array indexing that is missed by the insanely lame code in tree-vrp.c.
[Bug tree-optimization/59932] spurious undefined behavior warning on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59932
--- Comment #4 from Zhendong Su ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Zhendong Su from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I don't see why you think this is not undefined behavior.
> > > If p1 starts at 1, it cannot turn into 0 as p1++ overflows during the
> > > 2147483646th iteration.
> >
> > Andrew, because "d.f1 > l" is false, so the code simply returns ("return
> > b;").
> >
> > I also always double-check with CompCert's reference interpreter and Frama-C
> > if possible.
>
> I see what is happening. It is a true warning that happens due to
> optimizing order differences. The place we warn does not know that f is
> zero the first time through the loop. Since -Os disables copy headers, we
> don't get a different copy of the header. So the code does not optimize
> away the header.
>
> This is where I am going to say there is a false positive due to optimizing.
> I want to close it as won't fix because if we change the value of l to be
> 0xfe, then we always warn.
Andrew, sorry, I'm baffled by your comments above.
Please note:
1) The issue isn't only triggered at -Os, but also at -O2 and -O3.
2) It doesn't affect GCC 4.8.
3) I don't see how changing l to 0xfe has changed anything.
4) Also optimizations shouldn't really change the warnings issued.
Perhaps I have some misunderstandings, so could you clarify? Thanks.
[Bug tree-optimization/59919] [4.9 Regression] ICE in process_assert_insertions_for, at tree-vrp.c:6096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919 --- Comment #6 from Jeffrey A. Law --- Author: law Date: Fri Jan 24 20:51:22 2014 New Revision: 207061 URL: http://gcc.gnu.org/viewcvs?rev=207061&root=gcc&view=rev Log: PR tree-optimization/59919 * tree-vrp.c (find_assert_locations_1): Do not register asserts for non-returning calls. PR tree-optimization/59919 * gcc.c-torture/compile/pr59919.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr59919.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/59919] [4.9 Regression] ICE in process_assert_insertions_for, at tree-vrp.c:6096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59919 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Fixed by my commit on the trunk.
[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Blocks||59224 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Known to fail||
[Bug c/59825] Many cilkplus test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jeffrey A. Law --- Should be resolved by Balaji's trunk commit.
[Bug target/59674] On m68k and vax variables stack variables with > MAX_STACK_ALIGNMENT make ssp fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674 --- Comment #9 from Andreas Schwab --- x86 works around its weird ABI by dynamic stack realignment. That's what needs to be implemented for your ABI as well.
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #9 from Jeffrey A. Law --- Jakub, I think your second approach is the better solution. It'll abort rather than silently returning a value which may or may not be appropriate in the caller's context. ie, returning 0 when we don't (for example) have partial modes may avoid this particular problem, but may cause issues elsewhere. Granted this code only has one user, but I'd rather play things like this defensively and just abort if we get into a situation that's not supposed to happen. I'll start an s390x build and see where the 2nd approach takes us...
[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59934 --- Comment #10 from Jakub Jelinek --- But with the second patch we'll generate bigger code (because we pass arguments to fancy_abort) and it really is a will never happen case, if you don't have any partial (or vector) modes, then no mode will have MODE_PARTIAL_INT (or MODE_VECTOR_INT) class. Plus, with --disable-checking we'll trigger the warning again.
[Bug middle-end/59561] [4.9 Regression] warning: iteration 4 invokes undefined behavior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59561 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Jan 24 23:17:25 2014 New Revision: 207065 URL: http://gcc.gnu.org/viewcvs?rev=207065&root=gcc&view=rev Log: PR middle-end/59561 * cfgloopmanip.c (copy_loop_info): If loop->warned_aggressive_loop_optimizations, make sure the flag is set in target loop too. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c
[Bug sanitizer/57316] [4.8 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 --- Comment #21 from Paul H. Hargrove --- A build from svn trunk (r207062) completed w/o problems. I see: Configuring in i686-pc-linux-gnu/libsanitizer followed later by checking for necessary platform features... no So the added configure check appears to have functioned as intended. Do I need to test other branches too? -Paul
[Bug c++/59937] New: [constexpr] bogus diagnostic "used in its own initializer"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59937 Bug ID: 59937 Summary: [constexpr] bogus diagnostic "used in its own initializer" Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk GCC rejects this: constexpr const char * const &r = ""; constexpr const char * const &s = r; with this bogus diagnostic: test.cpp:2:35: error: the value of ‘r’ is not usable in a constant expression constexpr const char * const &s = r; ^ test.cpp:1:31: note: ‘r’ used in its own initializer constexpr const char * const &r = ""; ^
[Bug c++/59938] New: [C++11] Bogus "... is not a constant expression"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938
Bug ID: 59938
Summary: [C++11] Bogus "... is not a constant expression"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test:
struct Data { const char* const& name; };
constexpr Data d = { "" };
Using g++ (GCC) 4.9.0 20140122 (experimental):
g++ -c -std=c++11 t.cc
t.cc:2:25: error: 'const Data{(* & _ZGRL1d0)}' is not a constant expression
constexpr Data d = { "" };
^
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 --- Comment #10 from Andrew Pinski --- I noticed this also when I was helping out an uboot developer here at Cavium for Octeon. Really I think someone should get LTO working for uboot.
[Bug c/59939] New: No warning on signedness changes caused by implicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939
Bug ID: 59939
Summary: No warning on signedness changes caused by implicit
conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
There is no warning on signedness changes by implicit conversion, which occur
in dead code due to short-circuit of "or". See the following. If I change "1 ||
fn1(a, b)" to "0 || fn1(a, b)", then Gcc warns.
--
$: cat s.c.v6.c
int a, b;
int fn1(unsigned, unsigned);
unsigned int fn2() {
return 1 || fn1(a, b);
}
$: gcc-trunk -c -Wconversion s.c.v6.c
$: clang-trunk -c -Wconversion s.c.v6.c
s.c.v6.c:5:19: warning: implicit conversion changes signedness: 'int' to
'unsigned int' [-Wsign-conversion]
return 1 || fn1(a, b);
~~~ ^
s.c.v6.c:5:22: warning: implicit conversion changes signedness: 'int' to
'unsigned int' [-Wsign-conversion]
return 1 || fn1(a, b);
~~~^
2 warnings generated.
-
Is it a better way to report that the "fn1(a,b)" is not reachable and there are
signedness changes in this function call, just like the way Clang does, or at
least one of them?
[Bug c/59939] No warning on signedness changes caused by implicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59939 --- Comment #1 from Andrew Pinski --- IIRC this was done so that code which uses macros and have conditional code like: MACRO1 || fn1(a, b)
