[Bug c++/66270] [6 Regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66270
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-24
Target Milestone|--- |6.0
Summary|ICE: canonical types differ |[6 Regression] ICE:
|for identical types |canonical types differ for
||identical types
Ever confirmed|0 |1
--- Comment #1 from Marc Glisse ---
typedef float __m256 __attribute__ (( __vector_size__(32), __may_alias__ ));
struct A {
__m256 ymm;
const float &f() const {
return ymm[1];
}
};
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #24 from Tomasz Gajewski --- Well, they certainly did not at that time, so I think the bug can be closed.
[Bug ipa/66271] New: -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 Bug ID: 66271 Summary: -Os generates incorrect code on ARM possibly due to IPA Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: gccbugs at rooted dot tk Target Milestone: --- Created attachment 35609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35609&action=edit code snippet and generated assembly GCC generates incorrect code when cross compiling for ARM on x86_64 on version 5.1.0 snapshot 5-20150519. The code is correct when -fno-ipa-sra is added as a switch, making me believe that this is an issue with IPA. This bug breaks compiling Linux, particularly lib/vsprintf.c. The problematic part of that file is attached as a code snippet along with the generated assembly. It was compiled with the following command line: arm-none-eabi-gcc bug.c -S -o bug.s -Os -Wall -Wextra -fverbose-asm -frecord-gcc-switches The issue occurs if spec.field_width is passed in as -1. LDRSH at line 96 correctly sign extends this 16-bit value to the 32-bit value -1. If !(spec.flags & LEFT), then the branch at line 100 is not taken. The loop does not run due to the comparison at line 104 (r0 is the result of strnlen(s, ...)). However, lines 103 and 105 effectively zero out the top 16 bits of r3, which is later written back to r5 at line 114. At line 132, r5 should be -2 or 0xFFFE but is instead 0xFFFE. Thus, the branch at line 136 is not taken even though it should not be taken ((len < spec.field_width--) should always be true if spec.field_width is negative and no wrapping occurs). The end result is that lines 49-51 in the C file run once even when they should not run. The code would work correctly if LSR were replaced with ASR on lines 105 and 135. This is done correctly at lines 110 and 140, which makes it odd that the other two lines would be different.
[Bug c/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #1 from gccbugs at rooted dot tk --- Oddly enough, the code is correct with -O2 instead of -Os.
[Bug c/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #2 from gccbugs at rooted dot tk --- Created attachment 35610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35610&action=edit correct code with -O2
[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #3 from gccbugs at rooted dot tk --- Created attachment 35611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35611&action=edit gcc -v output
[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #5 from gccbugs at rooted dot tk --- Created attachment 35613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35613&action=edit C source code
[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66271 --- Comment #4 from gccbugs at rooted dot tk --- Created attachment 35612 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35612&action=edit incorrect output wiith -Os
[Bug tree-optimization/46032] openmp inhibits loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032 --- Comment #10 from vries at gcc dot gnu.org --- An observation. A patch like this allows vectorization without alias check: ... diff --git a/gcc/omp-low.c b/gcc/omp-low.c index 8290a65..501d631 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -1241,7 +1241,12 @@ install_var_field (tree var, bool by_ref, int mask, omp_context *ctx) type = build_pointer_type (build_pointer_type (type)); } else if (by_ref) +#if 0 type = build_pointer_type (type); +#else +type = build_qualified_type (build_reference_type (type), +TYPE_QUAL_RESTRICT); +#endif else if ((mask & 3) == 1 && is_reference (var)) type = TREE_TYPE (type); ... The problem is that we don't have information at this point to decide between pointer and restrict reference. If var would be a scalar, we could use addr_taken to ensure that the var is not aliased. For arrays that doesn't work. If the c frontend would distinguish between: - element read: result[x], and - alias created: result, &result, &result[x] and store that in an alias_created property, we could use that property to decide between pointer and restrict reference. That would not fix the problem in general though, since that solution would already no longer work if the example was rewritten using pointers. I wonder if postponing omp_expand till after ealias would give us enough information to update the field reference types with a restrict tag (or not) at that point. [ Though I'm not sure if doing that update there would actually have the desired effect. ]
[Bug fortran/44054] Handle -Werror, -Werror=, -fdiagnostics-show-option, !GCC$ diagnostic (pragmas) and color
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054 --- Comment #27 from Manuel López-Ibáñez --- From my POV, this is FIXED. The only thing missing is the diagnostic pragmas: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html#Diagnostic-Pragmas I'm not sure how pragmas work in the Fortran FE, but it should be a matter of following more or less what the C/C++ FE do to interface with diagnostic.c. I'm not going to work on that. I leave to the Fortran maintainers whether to track that on a different PR and close this one or leave this one open.
[Bug tree-optimization/66272] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66272
Bug ID: 66272
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk miscompiles the following code on x86_64-linux at -O3 in
both 32-bit and 64-bit modes.
It also affects gcc 5.1.x and 4.9.2 (but not 4.9.0 and I didn't check 4.9.1).
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150524 (experimental) [trunk revision 223630] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-4.9.0 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ gcc-4.9.2 -O3 small.c
$ ./a.out
Aborted (core dumped)
$ gcc-5.1.0 -O3 small.c
$ ./a.out
Aborted (core dumped)
$
struct S
{
int f0;
int f1;
} a[2], c;
int b;
int
main ()
{
struct S d = { 0, 1 };
for (b = 0; b < 2; b++)
{
a[b] = d;
c = d = a[0];
}
if (c.f1 != 1)
__builtin_abort ();
return 0;
}
[Bug c/66263] Performance regression from gcc-4.8 and up (trivial sudoku program)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66263 --- Comment #2 from EyalBD --- Created attachment 35614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35614&action=edit Preprocessed source file
[Bug lto/66273] New: [6 Regression] FAIL: gcc.dg/guality/pr43177.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66273 Bug ID: 66273 Summary: [6 Regression] FAIL: gcc.dg/guality/pr43177.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- On Linux/x86, r223608 caused: FAIL: gcc.dg/guality/pr43177.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 24 l == 10 FAIL: gcc.dg/guality/pr43177.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 24 x == 7 On Linux/x86-32, it also caused: FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects line 32 a[0] == 4
[Bug libstdc++/65392] Bad mangled names in Debug Mode assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65392 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED CC||fdumont at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #1 from François Dumont --- Symbols are now automatically demangle, the issue doesn't appear anymore.
[Bug tree-optimization/46032] openmp inhibits loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032 --- Comment #11 from vries at gcc dot gnu.org --- The ipa-pta solution no longer works. In 4.6, we had: ... # USE = anything # CLB = anything GOMP_parallel_startD.1048 (main._omp_fn.0D.1472, &.omp_data_o.1D.1484, 0); # USE = anything # CLB = anything main._omp_fn.0D.1472 (&.omp_data_o.1D.1484); # USE = anything # CLB = anything GOMP_parallel_endD.1049 (); ... On trunk, we have now: ... # USE = anything # CLB = anything GOMP_parallelD.1345 (main._omp_fn.0D.1844, &.omp_data_o.1D.1856, 0, 0); ... So there's no longer a path in the call graph from main to main._omp_fn. Perhaps a dummy body for GOMP_parallel could fix that.
[Bug inline-asm/66274] New: gcc6: x86 -m32 emits 64bit register in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66274
Bug ID: 66274
Summary: gcc6: x86 -m32 emits 64bit register in inline asm
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at os dot inf.tu-dresden.de
Target Milestone: ---
The following reduced test-case:
void f()
{
asm ("push %0" : : "r" ((unsigned long long)456 >> 32));
}
produces:
$ gcc -c -m32 t.i
t.i: Assembler messages:
t.i:3: Error: bad register name `%rax'
$ gcc --version
gcc (GCC) 6.0.0 20150524 (experimental)
Works with gcc-5 and previous versions.
[Bug fortran/66257] [5/6 Regression] ELEMENTAL procedure pointer component XX is not allowed as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66257 --- Comment #4 from Mikael Morin --- Author: mikael Date: Sun May 24 14:55:50 2015 New Revision: 223631 URL: https://gcc.gnu.org/viewcvs?rev=223631&root=gcc&view=rev Log: PR fortran/66257 gcc/fortran/ * resolve.c (resolve_actual_arglist): Don't throw an error if the argument with procedure pointer component is not a variable. gcc/testsuite/ * typebound_call_27.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/66275] New: __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66275
Bug ID: 66275
Summary: __attribute__((sysv_abi)) with x86_64-w64-mingw32-gcc
generates incorrect code
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Created attachment 35615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35615&action=edit
main.c, asm-test.h, and less-stripped-down intrin-pinsrw.c
gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
w64 mingw gcc is mis-compiling functions declared with
__attribute__((sysv_abi)). Registers holding args are getting clobbered with
temp values, but then used as if they still held function args.
This code is mis-compiled by
x86_64-w64-mingw32-gcc -g -Wall -funroll-loops -O3 -std=gnu11 intrin-pinsrw.c
... main.c
cat > intrin-pinsrw.c <<"EOF"
#include
#include
#define SYSV_ABI __attribute__((sysv_abi))
union wordbytes { uint16_t w; uint8_t b[2]; };
void SYSV_ABI rs_process_pinsrw_intrin(void* dstvoid, const void* srcvoid,
size_t size, const uint32_t* LH)
{
const uint64_t *src = srcvoid;
__m128i d, l, h;
__m128i *dst = dstvoid;
for (size_t i = 0; i < size/sizeof(d) ; i+=1) {
uint64_t s0 = src[i*2 + 0];
#define LO(x) ((uint8_t)x)
#define HI(x) (( (union wordbytes) ((uint16_t)x) ).b[1])
l = _mm_cvtsi32_si128( LH[ LO(s0)] );
h = _mm_cvtsi32_si128( LH[256 + HI(s0)] );
s0 >>= 16;
// commented-out code that wasn't needed to trigger the bug
d = _mm_xor_si128(l, h);
d = _mm_xor_si128(d, dst[i]);
_mm_store_si128(&dst[i], d);
}
}
EOF
x86_64-w64-mingw32-gcc -Wall -funroll-loops -O3 -std=gnu11 intrin-pinsrw.c -S
search for "si" in the output, and notice how %rsi is used as a pointer to load
src data, but also used as a tmp.
.L5:
movq(%rsi,%r10), %rdx
movzbl %dl, %esi ## clobbered here
movzbl %dh, %eax
movd(%rcx,%rsi,4), %xmm8
movd1024(%rcx,%rax,4), %xmm9
pxor%xmm8, %xmm9
pxor(%rdi,%r10), %xmm9
movaps %xmm9, (%rdi,%r10)
movq16(%rsi,%r10), %rdx## not restored after use as a tmp
...
%rdi is also clobbered and then used as a pointer again, later in the loop.
In the AMD64 sysv ABI, %rdi holds the 1st arg, %rsi holds the 2nd, %rdx holds
the 3rd, and %rcx holds the 4th.
(and see attached for a less-stripped-down and a main.c to call it)
-funroll-loops is needed to trigger the problem on this reduced test-case. It
might not be needed with a bigger function that would run out of registers
without unrolling. Even the less-stripped-down version in the attachment runs
fine under WINE when compiled without -funroll-loops.
If testing by actually running the code with WINE, note that wine and wine64
seem to have incompatible requirements for the contents of ~/.wine. I
eventually made a wrapper like:
#!/bin/sh
WINEPREFIX=~/.wine64 /usr/bin/wine64 "$@"
For anyone curious why I had this code in the first place:
This code is from par2 (the reed-solomon inner-loop that multiplies a buffer of
GF16 values by a constant factor, using a pre-computed lookup table). See
https://github.com/pcordes/par2-asm-experiments
I have some functions written directly in asm. They're written for the Linux
SysV ABI. I could make an alternate entry point for win ABI, with extra mov
instructions, and push/pop the extra regs that are callee-save in MS-ABI but
not SYSV. Or I could just declare their prototypes with
__attribute__((sysv_abi)), and gcc will call them properly.
I tried making a version of the function using intrinsics, so of course my test
harness needs to call it, too. Since I call via function pointer, I had to
declare it the same way.
It was working fine until a recent change to the code of the function. Old
version that didn't tickle this bug (partial diff):
- uint64_t s0, s1;
- for (size_t i = 0; i < size ; i+=16) {
- s0 = *((uint64_t*) ((char*)srcvoid + i)); // byte address
math, 64bit load
- s1 = *((uint64_t*) ((char*)srcvoid+8 + i)); // byte address
math, 64bit load
- d = _mm_xor_si128(d, *(dst+i/16));
- _mm_store_si128(dst+i/16, d);
I wrote it in that ugly way initially because I was basically porting my ASM
code to intrinsics. BTW, the results were terrible. gcc generates
ridiculously bad code for getting the src bytes into zero-extended 64bit regs,
for use as scaled-offsets in an address, compared to
movzx %dl, %eax
movxz %dh, %ebx
shr $16, %rdx
use rax/rbx
movzx %dl, %eax
movxz %dh, %ebx
shr $16, %rdx
use rax/rbx
...
gcc never just shifts the reg holding src data. Instead if copies,
[Bug lto/66273] [6 Regression] FAIL: gcc.dg/guality/pr43177.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66273 --- Comment #1 from Jan Hubicka --- > On Linux/x86, r223608 caused: > > FAIL: gcc.dg/guality/pr43177.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects line 24 l == 10 > FAIL: gcc.dg/guality/pr43177.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects line 24 x == 7 > > On Linux/x86-32, it also caused: > > FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects line 32 a[0] == 4 Interesting, only codegen changes I saw with this patch are related to ipa-icf no longer merging functions returning void because it makes bogues alias_set querries I am about to fix incrementally (and I even got no code changes on tramp3d with -fno-icf). I will check if these two testcases depends on ICF to pass with LTO. Anyway hope early debug to get us out of trouble here ;) Honza
[Bug c++/66267] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267 --- Comment #2 from cjedic at gmail dot com --- Created attachment 35616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35616&action=edit calcGrades.cpp
[Bug c++/66267] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267 --- Comment #3 from cjedic at gmail dot com --- Created attachment 35617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35617&action=edit gradeBook.txt
[Bug c++/66267] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #4 from Daniel Krügler --- The code seems to compile successfully on gcc 4.7.3, 4.8.1, 4.8.2, 4.9.0, 4.9.1, 4.9.2, 5.1.0, and gcc HEAD 6.0.0 20150523 (experimental)
[Bug middle-end/66276] New: [5 regression] internal compiler error: in get_loop_body, at cfgloop.c:856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66276 Bug ID: 66276 Summary: [5 regression] internal compiler error: in get_loop_body, at cfgloop.c:856 Product: gcc Version: 5.1.0 URL: https://github.com/OpenModelica/OMCompiler Status: UNCONFIRMED Severity: critical Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: martin.sjolund at liu dot se CC: martin.sjolund at liu dot se Target Milestone: --- Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu Created attachment 35618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35618&action=edit File triggering the bug (pre-processed and slightly trimmed down from the original) Configured with: ./configure --prefix=/opt/gcc-5.1.0 gcc version 5.1.0 (GCC) $ /opt/gcc-5.1.0/bin/gcc -O2 Matching.c Matching.c: In function ‘omc_Matching_PR__FIFO__FAIRrelabel’: Matching.c:3319:1: internal compiler error: in get_loop_body, at cfgloop.c:856 } ^ 0x6ba046 get_loop_body(loop const*) ../.././gcc/cfgloop.c:856 0x9358b0 predict_loops ../.././gcc/predict.c:1580 0x9358b0 tree_estimate_probability() ../.././gcc/predict.c:2371 0x936542 execute ../.././gcc/predict.c:3066 The original code compiles fine in gcc 4.4-4.9 and clang. It crashes in 5.1.0, the svn 5 branch and svn trunk. Does not seem to be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517
[Bug c++/66268] struct { volatile int x; } should not be trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66268 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler --- It is correct that the rule change in regard to trivial copy/move constructors had been introduced via CWG 496, http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#496 But recently another new issue had been opened regarding this particular rule. CWG 2094 (becomes visible in the next issue list publication). The essence of the new issue are two items, quoted below: a) "This change breaks the IA-64 ABI, so it has been requested that CWG reconsider this aspect of the resolution." b) "the resolution of issue 496 also changed 3.9 [basic.types] paragraph 9, which makes volatile-qualified scalar types “trivial” but not “trivially copyable.” It is not clear why there is a distinction made here; the only actual use of “trivial type” in the Standard appears to be in the description of qsort, which should probably use “trivially copyable.” (See also issue 1746.)" This issue has not yet been discussed during the Lenexa meeting
[Bug c++/66267] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #5 from Markus Trippelsdorf --- (In reply to Daniel Krügler from comment #4) > The code seems to compile successfully on gcc 4.7.3, 4.8.1, 4.8.2, 4.9.0, > 4.9.1, 4.9.2, 5.1.0, and gcc HEAD 6.0.0 20150523 (experimental) Thanks. Closing.
[Bug c++/66267] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66267 Markus Trippelsdorf changed: What|Removed |Added Resolution|WONTFIX |FIXED
[Bug middle-end/66276] [5 regression] internal compiler error: in get_loop_body, at cfgloop.c:856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66276
Markus Trippelsdorf changed:
What|Removed |Added
Target|x86_64-unknown-linux-gnu|
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-05-24
CC||trippels at gcc dot gnu.org
Host|x86_64-unknown-linux-gnu|
Ever confirmed|0 |1
Build|x86_64-unknown-linux-gnu|
Severity|critical|normal
--- Comment #1 from Markus Trippelsdorf ---
typedef void *modelica_metatype;
struct mmc_struct
{
void *data[0];
};
int a, c, d;
extern int _setjmp ();
extern void longjmp ();
modelica_metatype
nobox_arrayGet ()
{
int b = *(int *) 0 >> 1;
if (a || 0 > b)
longjmp ();
return ((struct mmc_struct *) 0)->data[a - 1];
}
modelica_metatype
omc_Matching_PR__FIFO__FAIRrelabel ()
{
if (_setjmp ())
tmp2_top:;
for (; c; c++)
switch (c)
case 0:
{
int e = (long) nobox_arrayGet ();
if (e)
goto goto_1;
d = (long) nobox_arrayGet ();
if (d)
goto goto_1;
}
goto_1:
if (0)
goto tmp2_top;
return 0;
}
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180 --- Comment #10 from Jan Hubicka --- Author: hubicka Date: Sun May 24 19:38:14 2015 New Revision: 223633 URL: https://gcc.gnu.org/viewcvs?rev=223633&root=gcc&view=rev Log: PR lto/66180 * ipa-devirt.c (type_with_linkage): Check that TYPE_STUB_DECL is set; check for assembler name at LTO time. (type_in_anonymous_namespace): Remove hacks, check that all anonymous types are called "" (odr_type_p): Simplify; add check for "" (odr_subtypes_equivalent): Add odr_type_p check. * tree.c (need_assembler_name_p): Even anonymous namespace needs assembler name. * mangle.c (mangle_decl): Mangle anonymous namespace types as "". * g++.dg/lto/pr66180_0.C: New testcase. * g++.dg/lto/pr66180_1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr66180_0.C trunk/gcc/testsuite/g++.dg/lto/pr66180_1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug other/66259] Combined gcc and binutils build from git-master fails, with gas/as-new not existing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66259
--- Comment #5 from Michael Darling ---
The commit that broke combined builds is:
binutils # 35eafcc71b8a54330704656fb6df0b5d6665ed15 Fri Jul 4 12:59:42 2014
+0930 | Rename
configure.in to configure.ac (HEAD)
If I run binutils # 35eafcc combined with gcc # 09853ca {Jul 4 15:56:27 2014},
I get the same error regarding "gas/as-new not existing".
If I move binutils to its parent, # 82b57a9, combined with the same gcc, it
builds just fine. (I was using "configure --disable-multilib" and CFLAGS &
CXXFLAGS being "-Wno-error=unused-value -Wno-error=strict-overflow
-Wno-error=maybe-uninitialized". Not sure if these 3 were all needed for gcc
4.9.2 to "backwards compile" gcc between 4.8.3 and 4.8.4, but I picked these 3
up along the way binary searching for the problem.)
I can move gcc a few ways in either direction with no effect. It all depends
on which side if this binutils commit it's on.
Binutils # 35eafcc renamed 6 configure.in files to configure.ac (in bfd,
binutils, gas, gprof, ld, and opcodes). It updated binutils calls to these
files with the new extension. But, there was never a corresponding change to
gcc to use the new extension. And, it left 3 configure.in files with th eold
extension (in etc, readline, and readline/examples/rlfe).
Fixing the gcc calls to binutils configure files is much easier with all of
binutils configure.in files renamed to configure.ac. So, I submitted a patch
to binutils to rename the 3 remaining configure.in files, and update all
references to them within binutils. And, I submitted a patch to gcc to fix all
references to binutils configure.in files to the new extension.
I also noticed gcc renamed its configure.in files to configure.ac some time
ago. But, a few references to configure.in remained in error messages and
documentation. The gcc patch I submitted fixes these references.
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #22 from Douglas Mencken --- Created attachment 35619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35619&action=edit pre-processed source of genmatch
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 --- Comment #25 from Jonathan Wakely --- Pawel, since you say you still see problems could you please provide a testcase that actually links?
[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66243 --- Comment #2 from Nathan Sidwell --- Author: nathan Date: Sun May 24 23:17:58 2015 New Revision: 223636 URL: https://gcc.gnu.org/viewcvs?rev=223636&root=gcc&view=rev Log: cp/ PR c++/66243 * decl.c (build_enumerator): Don't silently convert scoped enums. testsuite/ PR c++/66243 * g++.dg/cpp0x/pr66243.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr66243.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66243] enum class value is allowed to be initialized by value from other enum class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66243 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- committed obvious patch
[Bug tree-optimization/66272] [4.9.2/5/6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66272
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.8.4
Keywords||wrong-code
Last reconfirmed||2015-05-24
CC||miyuki at gcc dot gnu.org
Ever confirmed|0 |1
Summary|wrong code at -O3 on|[4.9.2/5/6 Regression]
|x86_64-linux-gnu|wrong code at -O3 on
||x86_64-linux-gnu
Known to fail||4.9.2, 5.1.0, 6.0
--- Comment #1 from Mikhail Maltsev ---
The testcase can be simplified a bit (I eliminated variable c and moved array a
inside main, so it's now local).
struct S
{
int f0;
int f1;
};
int b;
int main ()
{
struct S a[2] = { 0 };
struct S d = { 0, 1 };
for (b = 0; b < 2; b++) {
a[b] = d;
d = a[0];
}
if (d.f1 != 1)
__builtin_abort ();
}
Wrong transformation is made in predictive commoning pass (the program compiled
with -O3 -fno-predictive-commoning does not abort). The store d.f1 = a[0].f1;
is assumed to be independent of the previous store to a[b] (which is obviously
wrong) and it is hoisted out of the loop.
I think the reason is that find_data_references_in_stmt or some related
function misenterprets MEM[(struct S[2] *)&a + 4B] as some object that does not
alias with MEM[(struct S *)&a]'s SCEV.
By the way, the expression itself looks strange: struct S * should be "a", not
"&a".
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: MEM[(struct S *)_4 + 4B] = d$f1_7;
# ref: MEM[(struct S *)_4 + 4B];
# base_object: MEM[(struct S *)&a];
# Access function 0: {4B, +, 8}_1
#)
#(Data Ref:
# bb: 3
# stmt: d$f1_16 = MEM[(struct S[2] *)&a + 4B];
# ref: MEM[(struct S[2] *)&a + 4B];
# base_object: MEM[(struct S[2] *)&a + 4B];
#)
(no dependence)
)
If I scalarize the assignment d = a[0] (I mean, in the source), the bug
disappears.
[Bug target/60925] [4.9/5 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925 Carlos O'Donell changed: What|Removed |Added CC||carlos at redhat dot com --- Comment #13 from Carlos O'Donell --- For the record I made glibc use %r5 and saved/restored %r1 as required around the syscall. I also added more clobbers in the event of future changes to the kernel interface. This works around the "can't find a register in class FOO while reloading 'asm'" error from the compiler. The real culprit here is atomic.h in glibc and the asm in question is the atomic compare and exchange that is being done via the light-weight kernel syscall.
[Bug lto/66180] [6 Regression] many -Wodr false positives when building LLVM with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66180 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #11 from Markus Trippelsdorf --- Fixed. LLVM now builds without any warnings. Thanks.
