https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70884
Eric Botcazou changed:
What|Removed |Added
Attachment #38382|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70886
Bug ID: 70886
Summary: -frename-registers causes boostrap comparison failures
on ia64
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: build
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70886
Andreas Schwab changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70886
--- Comment #2 from Andreas Schwab ---
No, the crash isn't related to -frename-registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70887
Bug ID: 70887
Summary: internal compiler error in trunc_int_for_mode, at
explow.c:78
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70887
--- Comment #1 from zoidbergx at tlen dot pl ---
Created attachment 38384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38384&action=edit
source file
Preprocessed file, obtained with "-save-temps" option is too big (size =
1331314 bytes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70887
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67485
--- Comment #1 from Vittorio Zecca ---
Still in 6.1.0 at line 3162 of expmed.c
"val_so_far -= (HOST_WIDE_INT) 1 << log;"
../../gcc-6.1.0/gcc/expmed.c:3162:42: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represente
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69412
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70848
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70886
Eric Botcazou changed:
What|Removed |Added
Keywords|wrong-code |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69412
--- Comment #4 from Vittorio Zecca ---
A reproducer for the parser.c runtime error
/* gcc-6.1.0-undefined/bin/g++ -I../../gcc-6.1.0/gcc/.
-I../../gcc-6.1.0/gcc/../include -I../../gcc-6.1.0/gcc/../libcpp/include p.c
-S -I. */
/* ../../gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
--- Comment #15 from Oleg Endo ---
Maybe the standard name patterns sdot_prod for 16 bit and 32 bit int vectors
could be implemented using the mac.w and mac.l insns, if the input vectors are
somehow put in memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70886
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70887
--- Comment #3 from zoidbergx at tlen dot pl ---
Created attachment 38385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38385&action=edit
preprocessed source file (compressed)
#x27;
--enable-languages=c,c++,fortran --no-create --no-recursion
Thread model: posix
gcc version 7.0.0 20160430 (experimental) [trunk revision 235678p25] (GCC)
where gcc7a is
Using built-in specs.
COLLECT_GCC=gfca
COLLECT_LTO_WRAPPER=/opt/gcc/gcc7a/libexec/gcc/x86_64-apple-darwin15.4.0/7.0.0/lto-wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70887
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #7 from Vittorio Zecca ---
I understand that you are still seeing a message like this
../../gcc-6.1.0/gcc/fortran/trans-array.c:2233:27: runtime error: load
of value 176, which is not a valid value for type 'bool'
right?
If yes, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #8 from Dominique d'Humieres ---
> If yes, the problem might well be in ubsan, unless it has been fixed
> in 7.0.0. I'll look into this.
I have instrumented the trunk (7.0) and indeed the bug has not been fixed.
Although my understan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #12 from Dominique d'Humieres ---
The ICE is gone with the patch in comment 2, however I get at run time
../../../work/libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of
1 by 31 places cannot be represented in type 'in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70346
--- Comment #4 from milicic at math dot utah.edu ---
I see the same bug compiling released version of gcc-6.1.0 on Sun Ultra
27 running Solaris 11.3 x86 with Oracle supplied GNU make 3.82 and
gcc-4.8.2.
Dragan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70346
Andrew Paprocki changed:
What|Removed |Added
Version|6.0 |6.1.0
Summary|[libvtv] 6.0-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #9 from Vittorio Zecca ---
My C is not better than yours, but length_from_typespec might have
been incorrectly
initialized elsewhere, otherwise it is a false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #13 from Vittorio Zecca ---
I think that 1 << 31 is undefined because "1" is assumed (signed) int.
Maybe it should be 1u << 31 ?
Anyway on 6.1.0 I have no runtime error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14435
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #14 from Dominique d'Humieres ---
> I think that 1 << 31 is undefined because "1" is assumed (signed) int.
> Maybe it should be 1u << 31 ?
I have tried it, but it does not work.
> Anyway on 6.1.0 I have no runtime error message.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67496
--- Comment #10 from Dominique d'Humieres ---
> My C is not better than yours, but length_from_typespec might have
> been incorrectly initialized elsewhere, otherwise it is a false positive.
I see
(lldb) p expr->ts.u.cl->length_from_typespec
(b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #67 from Sven C. Dack ---
(In reply to Richard Biener from comment #66)
> The issue re-appears with GCC 6, the workaround doing
> --enable-stage1-checking=release still works.
>
> Note that the comparison we do with LTO bootstrap is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70888
Bug ID: 70888
Summary: #pragma diagnostic ignored -Wlong-long ineffective
with __LONG_LONG_MAX__ in c++98 mode
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70889
Bug ID: 70889
Summary: memory reordering across loads tagged as
memory_order_seq_cst
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70700
vries at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70700
--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 38386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38386&action=edit
proposed patch
Patch with testcase included. I'll put this through testing.
32 matches
Mail list logo
