[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80775 David Binderman changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from David Binderman --- (In reply to Peter Bergner from comment #15) > Doesn't fail for me on x86_64 either, so I'll need target/configure options > as well as full compile options. Seems fixed somewhere between revision 249638 and 249861.
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Jul 1 08:16:27 2017 New Revision: 249865 URL: https://gcc.gnu.org/viewcvs?rev=249865&root=gcc&view=rev Log: PR sanitizer/81262 * bb-reorder.c (fix_up_fall_thru_edges): Move variable declarations to the right scopes, make sure cond_jump isn't preserved between multiple iterations. Search for fallthru edge whenever there are 3+ edges and use find_fallthru_edge for it. * gcc.c-torture/compile/pr81262.c: New test. * g++.dg/ubsan/pr81262.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/pr81262.C trunk/gcc/testsuite/gcc.c-torture/compile/pr81262.c Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/80330] OpenACC: Unexpected data mapping instead of implicit firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80330 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 6.3.0 up to trunk (8.0).
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Sat Jul 1 10:11:16 2017 New Revision: 249866 URL: https://gcc.gnu.org/viewcvs?rev=249866&root=gcc&view=rev Log: PR sanitizer/81262 * bb-reorder.c (fix_up_fall_thru_edges): Move variable declarations to the right scopes, make sure cond_jump isn't preserved between multiple iterations. Search for fallthru edge whenever there are 3+ edges and use find_fallthru_edge for it. Modified: trunk/gcc/bb-reorder.c
[Bug ipa/81214] GCC target_clone support does not work for global functions with no references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81214 --- Comment #6 from Dominique d'Humieres --- At revision r249851 I see the following regression on darwin FAIL: gcc.target/i386/mvc6.c (test for excess errors) UNRESOLVED: gcc.target/i386/mvc6.c scan-assembler punpcklbw UNRESOLVED: gcc.target/i386/mvc6.c scan-assembler vpshufb % gcc8 -c -O3 /opt/gcc/_clean/gcc/testsuite/gcc.target/i386/mvc6.c /opt/gcc/_clean/gcc/testsuite/gcc.target/i386/mvc6.c:8:1: error: the call requires ifunc, which is not supported by this target foo(char *in, char *out, int size) ^~~ I suspect this to be caused by revision r249840.
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/81271] New: gcc/cp/lex.c:116: wrong condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81271 Bug ID: 81271 Summary: gcc/cp/lex.c:116: wrong condition ? Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/gcc/cp/lex.c:116]: (style) Boolean result is used in bitwise operation. Clarify expression with parentheses. Source code is gcc_checking_assert (!IDENTIFIER_KIND_BIT_2 (id) & !IDENTIFIER_KIND_BIT_1 (id) & !IDENTIFIER_KIND_BIT_0 (id)); Maybe better code gcc_checking_assert (!IDENTIFIER_KIND_BIT_2 (id) && !IDENTIFIER_KIND_BIT_1 (id) && !IDENTIFIER_KIND_BIT_0 (id));
[Bug c/81272] New: libdecnumber/decNumber.c:6032: wrong condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81272
Bug ID: 81272
Summary: libdecnumber/decNumber.c:6032: wrong condition ?
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
trunk/libdecnumber/decNumber.c:6032]: (style) Boolean result is used in bitwise
operation. Clarify expression with parentheses.
Source code is
if (decNumberIsNegative(lhs) & !decNumberIsNegative(rhs)) {
Maybe better code
if (decNumberIsNegative(lhs) && !decNumberIsNegative(rhs)) {
trunk/libdecnumber/decNumber.c:6036]: (style) Boolean result is used in bitwise
operation. Clarify expression with parentheses.
Duplicate.
[Bug tree-optimization/41244] "&data[i] - data" isn't converted to "i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41244 --- Comment #5 from Marc Glisse --- If we write &data[i] - &data[0] instead of &data[i] - data, we hit the special case in fold_binary_loc /* Fold &a[i] - &a[j] to i-j. */ which leads to fold_addr_of_array_ref_difference.
[Bug testsuite/57301] bit rotation is optimized in c but not c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57301 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Marc Glisse --- Seems to work as expected on currently supported branches.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751 --- Comment #3 from Vittorio Zecca --- (In reply to Dominique d'Humieres from comment #1) > > This issue is exposed by adding a gcc_assert at trans-stmt.c:455 > > Could you please be more explicit about what you changed in trans-stmt.c and > why you are doing that? I believe I answered your question. The NULL pointer dereferencing is still in trunk 249961
[Bug fortran/80751] NULL pointer dereferencing in gfc_trans_call on compiling call to an elemental procedure (trunk 247930)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80751 --- Comment #4 from Vittorio Zecca --- I believe I answered your question. The NULL pointer dereferencing is still in trunk 249961
[Bug c/81273] New: Wrong code generated for ARM setting volatile struct field with a literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81273
Bug ID: 81273
Summary: Wrong code generated for ARM setting volatile struct
field with a literal
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ldeboer at gateway dot net.au
Target Milestone: ---
struct __attribute__((__packed__)) TimerRegisters {
volatile uint32_t Load; //0x00
volatile uint32_t Value; //0x04
};
uint32_t base_addr = 0x3F00;
#define TIMER ((struct TimerRegisters*)(base_addr + 0xB400))
void ShowBug (void){
TIMER->Load = 0x400; // -02 compile and look at code
}
void ShowFix1 (void){
*(volatile uint32_t*)ARMTIMER->Load = 0x400;
}
void ShowFix2 (void){
volatile uint32_t temp = 0x400;
ARMTIMER->Load = temp;
}
Code generated you can see the two fixes produce markedly different and correct
code. Fun trying to write to hardware registers with this bug.
383 .section.text.ShowBug,"ax",%progbits
384.align 2
385.global ShowBug
386.syntax unified
387.arm
388.fpu neon-vfpv4
389.type ShowBug, %function
390ShowBug:
391@ args = 0, pretend = 0, frame = 0
392@ frame_needed = 0, uses_anonymous_args = 0
393@ link register save eliminated.
394 003000E3 movwr3, #:lower16:.LANCHOR0
395 0004 003040E3 movtr3, #:upper16:.LANCHOR0
396 0008 0020A0E3 mov r2, #0
397 000c 0410A0E3 mov r1, #4
398 0010 003093E5 ldr r3, [r3]
399 0014 2D3B83E2 add r3, r3, #46080
400 0018 D3E5 ldrbr0, [r3]@ zero_extendqisi2
401 001c 0020C3E5 strbr2, [r3]
402 0020 0100D3E5 ldrbr0, [r3, #1]@ zero_extendqisi2
403 0024 0110C3E5 strbr1, [r3, #1]
404 0028 0210D3E5 ldrbr1, [r3, #2]@ zero_extendqisi2
405 002c 0220C3E5 strbr2, [r3, #2]
406 0030 0310D3E5 ldrbr1, [r3, #3]@ zero_extendqisi2
407 0034 0320C3E5 strbr2, [r3, #3]
408 0038 1EFF2FE1 bx lr
409.size ShowBug, .-ShowBug
410.section.text.ShowFix1,"ax",%progbits
411.align 2
412.global ShowFix1
413.syntax unified
414.arm
415.fpu neon-vfpv4
416.type ShowFix1, %function
417ShowFix1:
418@ args = 0, pretend = 0, frame = 0
419@ frame_needed = 0, uses_anonymous_args = 0
420@ link register save eliminated.
421 003000E3 movwr3, #:lower16:RPi_IO_Base_Addr
422 0004 003040E3 movtr3, #:upper16:RPi_IO_Base_Addr
423 0008 012BA0E3 mov r2, #1024
424 000c 003093E5 ldr r3, [r3]
425 0010 2D3B83E2 add r3, r3, #46080
426 0014 003093E5 ldr r3, [r3]@ unaligned
427 0018 002083E5 str r2, [r3]
428 001c 1EFF2FE1 bx lr
429.size ShowFix1, .-ShowFix1
430.section.text.ShowFix2,"ax",%progbits
431.align 2
432.global ShowFix2
433.syntax unified
434.arm
435.fpu neon-vfpv4
436.type ShowFix2, %function
437ShowFix2:
438@ args = 0, pretend = 0, frame = 8
439@ frame_needed = 0, uses_anonymous_args = 0
440@ link register save eliminated.
441 003000E3 movwr3, #:lower16:RPi_IO_Base_Addr
442 0004 003040E3 movtr3, #:upper16:RPi_IO_Base_Addr
443 0008 08D04DE2 sub sp, sp, #8
444 000c 012BA0E3 mov r2, #1024
445 0010 003093E5 ldr r3, [r3]
446 0014 04208DE5 str r2, [sp, #4]
447 0018 2D3B83E2 add r3, r3, #46080
448 001c 04209DE5 ldr r2, [sp, #4]
449 0020 002083E5 str r2, [r3]@ unaligned
450 0024 08D08DE2 add sp, sp, #8
451@ sp needed
452 0028 1EFF2FE1
[Bug target/81273] Wrong code generated for ARM setting volatile struct field with a literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81273 --- Comment #1 from LdB --- In above code the ARMTIMER cases should be TIMER not related to bug just cut and paste typo.
[Bug target/81274] New: x86 optimizer emits unnecessary LEA instruction when using AVX intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81274
Bug ID: 81274
Summary: x86 optimizer emits unnecessary LEA instruction when
using AVX intrinsics
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cody at codygray dot com
Target Milestone: ---
Target: i?86-*-*
When AVX intrinsics are used in a function, the x86-32 optimizer emits
unnecessary LEA instructions that clobber a register, forcing it to be
preserved at additional expense.
Test Code:
--
#include
__m256 foo(const float *x)
{
__m256 ymmX = _mm256_load_ps(&x[0]);
return _mm256_addsub_ps(ymmX, ymmX);
}
Compile with: "-m32 -mtune=generic -mavx -O2"
This is also reproduced at -O1 and -O3, and when tuning for any architecture
that supports AVX (not specific to the "generic" target).
It also does not matter whether the code is compiled in C or C++ mode.
This behavior is exhibited by *all* versions of GCC that support AVX targeting,
from at least 4.9.0 through the 8.0.0 (20170701).
The code compiles warning-free, of course.
See it live on Godbolt: https://godbolt.org/g/NDDgsA
Actual Disassembly:
---
foo:# -O2 or -O3
pushl %ecx
movl 8(%esp), %eax
leal 8(%esp), %ecx
vmovaps(%eax), %ymm0
popl %ecx
vaddsubps %ymm0, %ymm0, %ymm0
ret
The LEA instruction performs a redundant load of the parameter from the stack
into ECX, and then promptly discards that value. The load of ECX also has
spill-over effects, requiring that additional code be emitted to preserve the
original value of this register (PUSH+POP).
The same bug is observed at -O1, but the ordering of the instructions is
slightly different and the load of ECX is actually used to load EAX, further
lengthening the dependency chain for no benefit whatsoever.
foo:# -O1
pushl %ecx
leal 8(%esp), %ecx
movl (%ecx), %eax
vmovaps(%eax), %ymm0
vaddsubps %ymm0, %ymm0, %ymm0
popl %ecx
ret
Expected Disassembly:
-
foo:
movl 8(%esp), %eax
vmovaps(%eax), %ymm0
vaddsubps %ymm0, %ymm0, %ymm0
ret
Or better yet:
foo:
vmovaps8(%esp), %ymm0
vaddsubps %ymm0, %ymm0, %ymm0
ret
The correct code shown above is already generated for x86-64 builds (-m64), so
this optimization deficiency affects only x86-32 builds (-m32).
