https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83293
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
Bug ID: 83294
Summary: int32_t & related definitions wrong with
-funsigned-bitfields
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79228
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 5 21:00:15 2017
New Revision: 255434
URL: https://gcc.gnu.org/viewcvs?rev=255434&root=gcc&view=rev
Log:
PR c++/79228
* expr.c (interpret_float_suffix): Avoid memc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83295
Bug ID: 83295
Summary: libgomp complains about trying to map data that is
already mapped
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #1 from joseph at codesourcery dot com ---
I'm not aware of a standard requirement not to use plain int for int32_t
(even with unsigned bit-fields), though it may well be useful to make the
signedness explicit. After all, int is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #2 from Rich Felker ---
I agree it's not clear if there's a conformance distinction or just a QoI
issue, but it seems really unfortunate for int32_t not to be usable in
bitfields if -funsigned-bitfields might be passed to GCC, since t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83294
--- Comment #3 from joseph at codesourcery dot com ---
FWIW, current glibc already uses signed int for int32_t (via using it for
__int32_t which is used to define int32_t), entirely as an accident
following a header refactoring, but not for oth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83296
Bug ID: 83296
Summary: missing -Wstringop-overflow due to missing range info
for MAX_EXPR
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82646
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83120
--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
In my regen of the testcases, I clobbered some dg-extra-options or something.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83297
Bug ID: 83297
Summary: Internal Compiler Error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83297
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094
--- Comment #2 from Scott Constable ---
This is still an issue in 7.2.0.
/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171205 (experimental) [trunk revision 255434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83299
Bug ID: 83299
Summary: result of pointer addition can be assumed to be less
than or equal to PTRDIFF_MAX
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549
--- Comment #30 from Jerry DeLisle ---
Not quite fixed yet. I have found:
==17070== 88 bytes in 1 blocks are definitely lost in loss record 3 of 9
==17070==at 0x4C31B25: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
--- Comment #3 from Andrew Church ---
I use __builtin_return(__builtin_apply(...)) in library function wrappers for
failure injection in tests, so that I don't need to explicitly write out all
the arguments multiple times for each wrapped functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79119
--- Comment #2 from Marc Glisse ---
With POINTER_DIFF_EXPR, things may be easier. One of the things I suggested
when introducing it was that VRP could always use a range of [ -PTRDIFF_MAX,
PTRDIFF_MAX ] for them. If you had written
__PTRDIFF_T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83296
--- Comment #1 from Marc Glisse ---
Note that -fdump-tree-optimized-all includes the range information in the dump.
Normally, we know how to derive a range for MAX_EXPR, but in this case the
MAX_EXPR only appears in phiopt3, later than VRP2. On t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83300
Bug ID: 83300
Summary: Segmentation fault with template and
__attribute__((vector_size (sizeof(int) * N)));
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83299
--- Comment #1 from Marc Glisse ---
As an implementation detail, the argument to POINTER_PLUS is always unsigned...
(maintainers are in favor of changing that, but someone needs to do the work)
Also, we now quickly simplify p-q to -i, which lose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657
Tom de Vries changed:
What|Removed |Added
Keywords||ra, wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83292
--- Comment #4 from Uroš Bizjak ---
(In reply to Andrew Church from comment #3)
> I use __builtin_return(__builtin_apply(...)) in library function wrappers
> for failure injection in tests, so that I don't need to explicitly write out
> all the a
101 - 127 of 127 matches
Mail list logo
