https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79482
Bug ID: 79482
Summary: _Static_assert(__builtin_constant_p(x)):
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79481
Bug ID: 79481
Summary: AVX512PF: unmasked gather prefetch intrinsics missing
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79480
--- Comment #4 from PeteVine ---
Whereas `-fsanitize=address` aborts all the same:
==28821==ERROR: AddressSanitizer: alloc-dealloc-mismatch (operator new [] vs
operator delete) on 0xaf012100
#0 0xb6af76fb in operator delete(void*, unsigned i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79480
--- Comment #3 from PeteVine ---
That's the same command line that leads to an immediate crash (uninstrumented).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79480
--- Comment #2 from PeteVine ---
OK, having been built with:
-mcpu=cortex-a5 -O3 -ffast-math -marm -fomit-frame-pointer -fipa-pta
-mfpu=neon-vfpv4 -ftree-vectorize -flto -fsanitize=undefined
doesn't crash but prints many errors, e.g.:
3ds.cpp
rch=haswell
Thread model: posix
gcc version 7.0.1 20170212 (experimental) [trunk revision 245376] (GCC)
Since no one can reproduce it, maybe it is Haswell-specific? I'll check if
removing "--with-arch=haswell" helps ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #7 from Andrew Pinski ---
(In reply to janus from comment #6)
> The error goes away when using --enable-checking=release.
Well that is kinda of expected as the error is only enabled with checking
enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> I'm configuring with:
>
> --program-suffix=-7 --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu --with-arch=haswell --prefix=/usr
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79480
--- Comment #1 from Andrew Pinski ---
Have you tried -fsanitize=undefined or -fsanitize=address to see if there is
undefined behavior in there?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79480
Bug ID: 79480
Summary: -O3 and -mfpu=neon produces crashing code on ARM
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854
--- Comment #8 from Jerry DeLisle ---
Sorry for the delay here. The unit number passed to the users dtio procedure is
0, so thats clearly wrong. I will see if I can fix that and see what happens.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364
--- Comment #4 from Guillaume Knispel ---
The dup seems to be 69846
This might also be vaguely related to 52154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
Bug ID: 79479
Summary: -Woverflow false alarm in unreachable expression
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #4)
> The preprocessed source doesn't ICE for me neither.
Huh, I guess then the problem is with me not doing a full bootstrap. I'm
configuring with:
--progr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79478
Bug ID: 79478
Summary: possible gimple error with gcc.dg/gimplefe-16.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79477
Bug ID: 79477
Summary: Please write code more translator-friendly
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: transl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79476
Bug ID: 79476
Summary: C++ frontend ignores diagnostic pragma in macro
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79475
Bug ID: 79475
Summary: Missing space in error message: SINK addend not a
constant integer
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65542
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Sun Feb 12 16:10:22 2017
New Revision: 245376
URL: https://gcc.gnu.org/viewcvs?rev=245376&root=gcc&view=rev
Log:
2017-02-12 Thomas Koenig
PR fortran/65542
* intrinsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49974
--- Comment #9 from Marc Glisse ---
gcc is unable to look through dynamic static initializers, even with -flto or
-fwhole-program. If you use constexpr, you can make the program fail to
compile.
(adding your warning would be good, I just wanted t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79473
Bug ID: 79473
Summary: -mload-store-pairs option is not documented in
invoke.texi
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433
--- Comment #19 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #16)
> Even if we moved our headers to separate directories, it wouldn't make
> __has_include sufficient..
Could you explain why? It would be a pain for other compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79448
--- Comment #3 from Mark Wielaard ---
A "workaround" for the example given in the description is to just pick some
arbitrary number you know wouldn't get exceeded. e.g:
/* To help -Wformat-truncation=2 pretend the "count"
translation will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79357
--- Comment #3 from Marc Glisse ---
Note that we do not generate better code for
typedef float vec __attribute__((vector_size(8)));
vec g(vec x){return 2*x;}
(we don't consider larger vector modes when lowering/expanding vector
operations, there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462
--- Comment #5 from Jakub Jelinek ---
What kind of comment would you like to have? Normally we document what the
code is supposed to do, but here I can imagine just something like:
/* We used to clear operands[4] here, which used to be a scrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
--- Comment #1 from Raphael C ---
After some experimentation (also carried out by Hagen von Eitzen), it seems
that any limit of at least 72 which is also a multiple of 4 causes the same
optimisation problem. That is the loop is *not* optimised ou
27 matches
Mail list logo
