[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #14 from Richard Biener ---
(In reply to sandra from comment #13)
> Well, no. The problem is that the scheduler is moving
>
> ldw r2, 0(r4)
>
> ahead of
>
> stw zero, 0(r5)
>
> which is incorrect because the pointers in r4 and r5 are aliases.
Ah, so the scheduler needs to call anti_dependence (WAR).
> So at the point of call to true_dependence, I see:
>
> (gdb) frame 1
> #1 0x01d1a108 in sched_analyze_2 (deps=0x7fffdd50,
> x=0x7742cac8, insn=0x77315600)
> at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/sched-deps.c:2663
> 2663if (true_dependence (pending_mem->element (),
> VOIDmode, t)
> (gdb) print debug_rtx(insn)
> (insn 17 10 18 2 (set (reg/i:SI 2 r2)
> (mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0
> S4 A32]))
> "/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/
> pr93946-1.c":18:1 5 {movsi_internal}
> (expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:47 bv ] [47])
> (nil)))
> $3 = void
> (gdb) print debug_rtx(pending->insn())
> (insn 9 8 10 2 (set (mem/j:SI (reg/v/f:SI 5 r5 [orig:48 ptr ] [48]) [1
> MEM[(struct aa *)ptr_1(D)].a.u.i+0 S4 A32])
> (const_int 0 [0]))
> "/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.dg/torture/
> pr93946-1.c":15:12 5 {movsi_internal}
> (nil))
> $4 = void
[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 --- Comment #2 from Martin Liška --- If I remember correctly kernel implements its own "runtime library" libgcov, so I would expect a crash somewhere in it. Anyway, a reasonable reproducer would be needed.
[Bug c++/93597] [9 Regression] ICE in get_fns since r10-6219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597 Richard Biener changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Summary|[10 Regression] ICE in |[9 Regression] ICE in |get_fns since r10-6219 |get_fns since r10-6219 Target Milestone|10.0|9.4 --- Comment #4 from Richard Biener --- r10-6219-g8b91e848130e45b427599ad30e99f96e447ea9aa was backported and now this fails on the branch as well. (in future make sure to add appropriate Blocks)
[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373 --- Comment #3 from Hongtao.liu --- (In reply to Hongtao.liu from comment #2) > I think > Change lea_cost from 2 --> 1 in skylake can fix this regressions. > > Since it's stage4 now, i hold my patch. Classify: it's for -O2 -mtune=skylake-avx512 not sure the what cause the regression for -O2 -mtune=generic.
[Bug gcov-profile/94394] [GCOV]It will cause random kernel panic during collecting kernel code coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-03-30 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- There is not information here to say if this is a kernel issue or a compiler issue. See https://gcc.gnu.org/bugs.html on what information we need. Also I don't think the gcov code is used directly inside the kernel.
[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #4 from Petro Karashchenko --- Andrew Pinski could you please share with me requirements needed for strict alignment? Actually I do not understand why read-write cycle is needed if no "read" or "modify" operation is requested (I mean no operations like |=, &=, +=, etc. are issued), but a "pure" write a constant value is requested. In other words: what is the reason of reading value that is discarded? If I remove 'volatile' from a struct typedef I'm getting pretty optimised code without excessive reads, to it seems to be a 'volatile'+'packed' combo.
[Bug target/94395] New: Powerpc suboptimal 64-bit constant generation near large values with few bits set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94395 Bug ID: 94395 Summary: Powerpc suboptimal 64-bit constant generation near large values with few bits set Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: npiggin at gmail dot com Target Milestone: --- 0xc000UL is generated with li 9,-1 rldicr 9,9,0,1 0xbfffUL (0xc000UL - 1) is lis 9,0xbfff ori 9,9,0x sldi 9,9,32 oris 9,9,0x ori 9,9,0x Could be li 9,-1 rldicr 9,9,0,1 subi 9,9,1
[Bug tree-optimization/94375] 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94375 --- Comment #1 from Hongtao.liu --- Try -mprefer-vector-width=128,256-bit vectorization is not helpful for 548 according to our experience.
[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94373 --- Comment #2 from Hongtao.liu --- I think Change lea_cost from 2 --> 1 in skylake can fix this regressions. Since it's stage4 now, i hold my patch.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #10 from Fangrui Song ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }
This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereference that address
mov-0xfc3(%rip),%rax# 44 <_binary_a_c_size>
> NO LLD is not implemented the ABI as PIE COPYRELOC is required by the ABI
> these days.
My objdump -d output in Comment #5 demonstrates that GNU ld linked code will be
incorrect at runtime.
It can be argued that either the user code or GCC does the wrong thing, but a
linker is not responsible for the mistake.
(I have argued lld does the right thing by erroring at link time.)
The compiler can ask the assembler to produce an indirect (GOT) reference.
The code (`unsigned long foo() { return (unsigned long)_binary_a_c_size; })
will work perfectly.
> Also it is wrong for a person to assume a normal C variable could be SHN_ABS;
> that is the bug here.
> It is a bug in the user code.
> I showed up to fix it by using an top level inline-asm.
-fno-pic and -fpic work fine. -fpie before commit
77ad54d911dd7cb88caf697ac213929f6132fdcf worked fine.
commit 77ad54d911dd7cb88caf697ac213929f6132fdcf ("x86-64: Optimize access to
globals in PIE with copy reloc")
is responsible for the -fpie change.
In 2015, H.J. invented R_X86_64_{REX,}GOTPCRELX. The linker relaxation is a
perfect solution.
We can retire HAVE_LD_PIE_COPYREL now.
// The code will still be faulty but we can argue that it is an user error.
__attribute__((visibility("hidden"))) extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
The relaxed R_X86_64_{REX,}GOTPCRELX will be a bit longer than R_X86_64_PC32.
The difference is small enough and should not matter for practical use cases.
For those who care about the tiny regression, we can invent an option
-fdirect-access-extern (clang currently calls it -mpie-copy-relocations but we
can design a better name).
It is more useful on non-x86 architectures for a mostly statically linked
program.
extern int var; int foo(void) { return var; }
// clang -target aarch64 -fPIE -O3
adrpx8, :got:var
ldr x8, [x8, :got_lo12:var]
ldr w0, [x8]
ret
// clang -target aarch64 -fPIE -O3 -mpie-copy-relocations
adrpx8, var
ldr w0, [x8, :lo12:var]
ret
// x86-64
// clang -O3 -fPIE a.c -Wa,--mrelax-relocations=yes
0: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7
3: R_X86_64_REX_GOTPCRELX var-0x4
7: 8b 00 mov(%rax),%eax
9: c3 retq
// clang -O3 -fPIE a.c -mpie-copy-relocations
0: 8b 05 00 00 00 00 mov0x0(%rip),%eax# 6
2: R_X86_64_PC32var-0x4
6: c3 retq
[Bug gcov-profile/94394] New: [GCOV]It will cause random kernel panic during collecting kernel code coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94394 Bug ID: 94394 Summary: [GCOV]It will cause random kernel panic during collecting kernel code coverage Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ammy.yi at intel dot com CC: marxin at gcc dot gnu.org Target Milestone: --- It will cause random kernel panic during collecting kernel code coverage . gcc version 9.3.1 20200319 releases [ 222.538244] #PF: supervisor instruction fetch in kernel mode [ 222.543945] #PF: error_code(0x0010) - not-present page [ 222.549133] PGD 0 P4D 0 [ 222.551719] Oops: 0010 [#1] SMP NOPTI [ 222.577223] RIP: 0010:0x0 [ 222.579901] Code: Bad RIP value. [ 222.583184] RSP: 0018:ae3140f13f58 EFLAGS: 00010082 [ 222.588448] RAX: 94217940 RBX: RCX: [ 222.595618] RDX: 80004000 RSI: 89203c624440 RDI: 94217940 [ 222.602781] RBP: R08: 94203da0 R09: [ 222.609942] R10: R11: 0002c502 R12: [ 222.617114] R13: R14: R15: [ 222.624283] FS: 7fc8e2c1a740() GS:89205fc0() knlGS: [ 222.632404] CS: 0010 DS: ES: CR0: 80050033 [ 222.638190] CR2: ffd6 CR3: 000497278005 CR4: 00fe0ef0 [ 222.645354] DR0: DR1: DR2: [ 222.652523] DR3: DR6: fffe0ff0 DR7: 0400 [ 222.659697] PKRU: 5554 [ 222.662441] Call Trace: [ 222.664924] WARNING: kernel stack frame pointer at fc81ab36 in load_unload_mod:4080 has bad value 8657b9bc [ 222.664926] unwind stack type:0 next_sp:8657b9bc mask:0x2 graph_idx:0 [ 222.664927] fc81ab36: ...
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #9 from H.J. Lu ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
>
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 referencing an external symbol in
> -fpie mode.
>
> % gcc -fuse-ld=lld -nostdlib -fpie -pie a.c
> % objdump -dr a.o
> ...
> :
>0: 55 push %rbp
>1: 48 89 e5mov%rsp,%rbp
>4: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# b
> 7: R_X86_64_PC32_binary_a_c_size-0x4
>b: 5d pop%rbp
>c: c3 retq
>
> % gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a
> /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to
> 1000
> % objdump -dr a
> ...
> 1000 :
> 1000: 55 push %rbp
> 1001: 48 89 e5mov%rsp,%rbp
> 1004: 48 8d 05 39 f0 ff fflea-0xfc7(%rip),%rax# 44
> <_binary_a_c_size>
> 100b: 5d pop%rbp
> 100c: c3 retq
>
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
>
> lea-0xfc7(%rip),%rax # loads 44 to %rax only if the load base is 0. Due
> to ASLR (-pie), this is simply not true.
Your are using the incorrect user code. Please use
---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---
GCC and ld handle it correctly.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #8 from Andrew Pinski --- Also it is wrong for a person to assume a normal C variable could be SHN_ABS; that is the bug here. It is a bug in the user code. I showed up to fix it by using an top level inline-asm.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #7 from Andrew Pinski --- (In reply to Fangrui Song from comment #5) > This bug exposes several problems: > > * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS > symbol > * GCC should not produce R_X86_64_PC32 referencing an external symbol in > -fpie mode. NO LLD is not implemented the ABI as PIE COPYRELOC is required by the ABI these days.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 --- Comment #6 from Fangrui Song --- > It is incorrect to reference a non-preemptible symbol with a PC relative > relocation in a -pie link. GNU ld allows it but the code can be incorrect at > runtime. Correction: It is incorrect to reference a non-preemptible SHN_ABS symbol with a PC relative relocation in a PIC (-shared or -pie) link. This is non-representable due to ASLR (load base not fixed at link time)
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #5 from Fangrui Song --- This bug exposes several problems: * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS symbol * GCC should not produce R_X86_64_PC32 referencing an external symbol in -fpie mode. % gcc -fuse-ld=lld -nostdlib -fpie -pie a.c % objdump -dr a.o ... : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 48 8d 05 00 00 00 00lea0x0(%rip),%rax# b 7: R_X86_64_PC32_binary_a_c_size-0x4 b: 5d pop%rbp c: c3 retq % gcc -fuse-ld=bfd -nostdlib -fpie -pie a.c b.o -o a /usr/bin/ld.bfd: warning: cannot find entry symbol _start; defaulting to 1000 % objdump -dr a ... 1000 : 1000: 55 push %rbp 1001: 48 89 e5mov%rsp,%rbp 1004: 48 8d 05 39 f0 ff fflea-0xfc7(%rip),%rax# 44 <_binary_a_c_size> 100b: 5d pop%rbp 100c: c3 retq It is incorrect to reference a non-preemptible symbol with a PC relative relocation in a -pie link. GNU ld allows it but the code can be incorrect at runtime. lea-0xfc7(%rip),%rax # loads 44 to %rax only if the load base is 0. Due to ASLR (-pie), this is simply not true. lld correctly rejects the relocation. To fix this, I had a write-up last year: https://gcc.gnu.org/legacy-ml/gcc/2019-05/msg00215.html We should change the configure-time HAVE_LD_PIE_COPYRELOC to an option, probably -f(no-)direct-access-extern In clang, HAVE_LD_PIE_COPYRELOC is a compile-time option: -mpie-copy-relocations. But I think we should improve the option name. At the very least, we can also let -fno-pic code reference an external symbol with GOT to avoid copy relocations. -f(no-)direct-access-extern may be a candidate.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
H.J. Lu changed:
What|Removed |Added
Resolution|WONTFIX |WORKSFORME
--- Comment #4 from H.J. Lu ---
(In reply to Yuxuan Shui from comment #0)
> Test case:
>
> Source file (a.c):
> extern char _binary_a_c_size[];
> unsigned long foo() { return (unsigned long)_binary_a_c_size; }
Try
---
extern unsigned long _binary_a_c_size;
unsigned long foo() { return _binary_a_c_size; }
---
> Run:
> objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
> gcc -fuse-ld=lld -fpie -pie a.c b.o
>
> lld complains about:
>
> ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
> _binary_a_c_size
This is an lld bug.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- As I mentioned these symbols are special. You cant use them as normal symbols. Instead you need to like I did.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Yuxuan Shui changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Yuxuan Shui --- If you read the reply, you will find out that is not the same bug as this: > This is an over reduction. The real problem is that we are not tracking > absoluteness correctly. In the original case vvar_vsyscall_gtod_data > should not be absolute > > --- ELF/Relocations.cpp > > +++ ELF/Relocations.cpp > > @@ -356,6 +356,10 @@ > >return true; > > if (&Body == ElfSym::MipsGpDisp) > >return true; > > +// Sometimes code has relocations to absolute symbol defined in linker > > script. > > +// Example is linux kernel. Hence we allow it. > > +if (!Body.File) > > + return true; > We should not do this. It would accept broken cases too.
[Bug target/94393] New: Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393
Bug ID: 94393
Summary: Powerpc suboptimal 64-bit constant comparison
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: npiggin at gmail dot com
Target Milestone: ---
--- test case
void test1(unsigned long a)
{
if (a > 0xc000ULL)
printf("yes\n");
}
void test2(unsigned long a)
{
if (a >= 0xc000ULL)
printf("yes\n");
}
--
The first (important part) compiles to
li 9,-1
rldicr 9,9,0,1
cmpld 0,3,9
blelr 0
The second to
lis 9,0xbfff
ori 9,9,0x
sldi 9,9,32
oris 9,9,0x
ori 9,9,0x
cmpld 0,3,9
blelr 0
The second could use the same 2-insn constant as the first, but with bltlr.
[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed for GCC 10.
[Bug driver/94381] -falign-function/-falign-labels/-falign-loops documentation is inaccurate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381 --- Comment #3 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:dacc7effeead9ad3e63673f6957661c55e351eb9 commit r10-7454-gdacc7effeead9ad3e63673f6957661c55e351eb9 Author: H.J. Lu Date: Sun Mar 29 15:54:42 2020 -0700 doc: Update -falign-functions/-falign-loops/-falign-jumps Change -falign-functions=N to Align the start of functions to the next power-of-two greater than or equal to N. Add If '-falign-labels' is greater than this value, then its value is used instead. to -falign-loops=N and -falign-jumps=N. PR driver/94381 * doc/invoke.texi: Update -falign-functions, -falign-loops and -falign-jumps documentation.
[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #3 from Andrew Pinski --- so I think this is fine as it is doing a read-write cycle as needed for strict alignment requirements
[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #2 from Andrew Pinski --- volatile and packed on strict alignment targets are interesting to say the least. packed makes the alignment to 1 too.
[Bug fortran/92775] [8 Regression] Incorrect expression in DW_AT_byte_stride on an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug fortran/92775] [8 Regression] Incorrect expression in DW_AT_byte_stride on an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775 --- Comment #11 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e50319ad2437e7b3a7691aa1351d522437d5b95 commit r8-10150-g2e50319ad2437e7b3a7691aa1351d522437d5b95 Author: Jakub Jelinek Date: Fri Dec 20 18:36:48 2019 +0100 backport: re PR fortran/92775 (Incorrect expression in DW_AT_byte_stride on an array) Backported from mainline 2019-12-06 Jakub Jelinek PR fortran/92775 * trans.h (struct lang_type, struct lang_decl): Remove span member. (GFC_DECL_SPAN, GFC_TYPE_ARRAY_SPAN): Remove macros. * trans-array.h (gfc_get_descriptor_offsets_for_info): Add another argument. * trans-array.c (gfc_get_descriptor_offsets_for_info): Add SPAN_OFF argument and initialize *SPAN_OFF to the offset of span field. * trans-types.c (gfc_get_array_descr_info): Adjust gfc_get_descriptor_offsets_for_info caller. Compute elem_size as base->span instead of TYPE_SIZE_UNIT (etype) constant.
[Bug c/94392] Infinite loops are optimized away for C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 --- Comment #1 from Andrew Pinski --- I was looking at the patch email thread and the issue of finiteness not being discussed.
[Bug target/94391] gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- I think this is a bug in LLVM's lld. http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170116/420892.html 2: 0 NOTYPE GLOBAL DEFAULT1 _binary_t85_c_start 3: 02c8 0 NOTYPE GLOBAL DEFAULT1 _binary_t85_c_end 4: 02c8 0 NOTYPE GLOBAL DEFAULT ABS _binary_t85_c_size You cannot refer to this symbol directly from C code. What I do in my code is the following top level inline-asm: #define SIZE_SECTION(section) \ asm(\ ".pushsection .rodata\n"\ ".align 8\n"\ ".global __size_" section "\n" \ "__size_" section ":\n" \ ".xword .sizeof.." section "\n" \ ".popsection\n" \ )
[Bug c/94392] New: Infinite loops are optimized away for C99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94392 Bug ID: 94392 Summary: Infinite loops are optimized away for C99 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: krister.walfridsson at gmail dot com Target Milestone: --- Created attachment 48141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48141&action=edit Source code reproducing the issue John Regehr noticed on twitter (https://twitter.com/johnregehr/status/1244335355509129216) that trunk GCC removes infinite loops for C99, as can be seen by gcc -O3 -std=c99 fermat.c This behavior was introduced by the introduction of -ffinite-loops being enabled at -O2. This is fine for C11, but infinite loops do not invoke undefined behavior in C99, so the optimization should not be enabled per default for -std=c99.
[Bug other/94391] New: gcc refers to absolute symbols with R_X86_64_PC32 relocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Bug ID: 94391
Summary: gcc refers to absolute symbols with R_X86_64_PC32
relocation
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: yshuiv7 at gmail dot com
Target Milestone: ---
Test case:
Source file (a.c):
extern char _binary_a_c_size[];
unsigned long foo() { return (unsigned long)_binary_a_c_size; }
Run:
objcopy -B i386:x86-64 -I binary -O elf64-x86-64 a.c b.o
gcc -fuse-ld=lld -fpie -pie a.c b.o
lld complains about:
ld.lld: error: relocation R_X86_64_PC32 cannot refer to absolute symbol:
_binary_a_c_size
>>> defined in b.o
>>> referenced by a.c
>>> /tmp/cc3iReeC.o:(foo)
Also, this seems to be more than just a problem in gcc. Doing the same test
with clang+lld yields the expected results. However, with clang+gold/bfd, the
absolute symbol is relocated.
[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added Status|WAITING |NEW Summary|[9/10 Regression] ICE in|[9/10 Regression] ICE in |final_scan_insn_1, at |final_scan_insn_1, at |final.c:3074(error: could |final.c:3074(error: could |not split insn) on |not split insn) on |aarch64-linux-gnu |aarch64-linux-gnu since ||r9-3744 Target Milestone|--- |9.4 --- Comment #3 from Jakub Jelinek --- Actually, I can, -O2 -fpie is needed. Started with r9-3744-gd400fda3a8c3330f77eb9d51874f5482d3819a9f
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #13 from Segher Boessenkool --- If both compilers default to ibmlongdouble, both should use TFmode, no?
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965
--- Comment #19 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #16)
> (In reply to Marc Glisse from comment #5)
> > (The split into push_heap and __push_heap is just so the first part can be
> > inlined without the second, right?)
> >
> > A more direct adaptation of the old code to rvalue references would be:
> >
> > std::__push_heap(__first, _DistanceType((__last - __first) - 1),
> >_DistanceType(0), _ValueType(_GLIBCXX_MOVE(*(__last -
> > 1;
>
> I tried doing this and it didn't seem to help the testcase attached here.
push_heap(): default_ctors=0, copy_ctors=0, copy_assignments=0, swaps=0,
[-cheap_dtors=1998,-] {+cheap_dtors=999,+} expensive_dtors=0,
[-move_ctors=1998,-] {+move_ctors=999,+} cheap_move_assignments=2201,
expensive_move_assignments=0, comparisons=2196
It doesn't help the other operations, but it has some effect on this one.
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 --- Comment #4 from Bill Seurer --- The problem is definitely caused by g:7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65, r10-7444 I built it before and no problems, errors after.
[Bug libstdc++/63706] stl_heap.h:make_heap()'s worst time complexity doesn't conform with C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63706
Marc Glisse changed:
What|Removed |Added
Last reconfirmed||2020-03-29
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
--- Comment #1 from Marc Glisse ---
Trying exactly the construction described here with g++-4.9:
#include
#include
#include
int count=0;
bool cmp(int a, int b){++count;return a v;
const int n=1;
for(int i=0;i
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 --- Comment #3 from Paul Thomas --- (In reply to H.J. Lu from comment #0) > commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 > Author: Paul Thomas > Date: Sat Mar 28 19:11:35 2020 + > > Patch for PR94246 Since the ICE occurs in primary.c, I was highly skeptical that the patch for PR94246 caused it. To be sure though, I reverted the patch and found that the ICE remains. That said, I will take a look tomorrow to understand and try to fix this - unless Thomas beats me to it. Paul
[Bug c++/94126] [concepts] suboptimal diagnostic when type after substitution is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94126 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- With current trunk and -fconcepts-diagnostics-depth=2, we now get: disj.cc:13:15: error: static assertion failed 13 | static_assert(E); | ^~ disj.cc:13:15: note: constraints not satisfied disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:8:20: note: no operand of the disjunction is satisfied 8 | concept D = C || C; | ~^ disj.cc:8:15: note: the operand ‘C’ is unsatisfied because 8 | concept D = C || C; | ^~ disj.cc:5:11: required for the satisfaction of ‘C’ [with T = typename T::type] disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:13:15: error: ‘int’ is not a class, struct, or union type 13 | static_assert(E); | ^~ disj.cc:8:23: note: the operand ‘C’ is unsatisfied because 8 | concept D = C || C; | ^~ disj.cc:5:11: required for the satisfaction of ‘C’ [with T = typename T::type] disj.cc:8:11: required for the satisfaction of ‘D’ [with T = int] disj.cc:13:15: error: ‘int’ is not a class, struct, or union type 13 | static_assert(E); | ^~ So I'm considering this fixed.
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Martin Liška changed: What|Removed |Added CC||seurer at linux dot vnet.ibm.com --- Comment #2 from Martin Liška --- *** Bug 94390 has been marked as a duplicate of this bug. ***
[Bug fortran/94390] [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94390 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 94386 ***
[Bug fortran/94390] New: [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94390 Bug ID: 94390 Summary: [10 regression] After r10-xxx ICEs in gfortran.dg/pr93600_1.f90 and gfortran.dg/gfortran.dg/pr93365.f90 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- FAIL: gfortran.dg/pr93365.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O1 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O2 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -Os (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 6) FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 7) FAIL: gfortran.dg/pr93600_1.f90 -O (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O1 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O2 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -Os (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -Os (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr93600_1.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O -pedantic-errors -S -o pr93600_1.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/pr93600_1.f90:6:9: Error: The RE or IM part_ref at (1) must be applied to a COMPLEX expression compiler exited with status 1 FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 6) FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 7)
[Bug ipa/94363] possible typo: attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:85f6f317ec8c02beea0a8dcb9c9274ebcffc1da7 commit r10-7451-g85f6f317ec8c02beea0a8dcb9c9274ebcffc1da7 Author: Martin Liska Date: Sun Mar 29 19:24:33 2020 +0200 Fix typo in a warning related to flatten. PR ipa/94363 * cgraphunit.c (process_function_and_variable_attributes): Remove double 'attribute' words.
[Bug ipa/94363] possible typo: attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail|8.4.0 | Known to work||8.4.1 --- Comment #16 from Martin Liška --- Fixed on GCC 8 branch.
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 --- Comment #15 from CVS Commits --- The releases/gcc-8 branch has been updated by Martin Liska : https://gcc.gnu.org/g:40aa944391dfec4529fb6970b9e78d5805f88fc5 commit r8-10149-g40aa944391dfec4529fb6970b9e78d5805f88fc5 Author: Martin Liska Date: Sun Mar 29 19:19:09 2020 +0200 Backport 9297e013293e4d332fc7c40859ea4dd9616e0d88 Backport from mainline 2019-09-02 Martin Liska PR gcov-profile/91601 * gcov.c (path_contains_zero_cycle_arc): Rename to ... (path_contains_zero_or_negative_cycle_arc): ... this and handle also negative edges. (circuit): Handle also negative edges as they can happen in some situations.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #12 from Bill Seurer --- confgures are identical. Default compiler options are also identical, from -Q --help=target: The following options are target specific: -G0 -m32 [disabled] -m64 [enabled] -mabi=altivec [disabled] -mabi=d32 [enabled] -mabi=d64 [disabled] -mabi=elfv1 [disabled] -mabi=elfv2 [disabled] -mabi=ibmlongdouble [enabled] -mabi=ieeelongdouble [disabled] -mabi=no-altivec [enabled] -mads [disabled] -maix-struct-return [disabled] -malign- power -malign-branch-targets[enabled] -mallow-movmisalign [enabled] -maltivec [enabled] -malways-hint [enabled] -mavoid-indexed-addresses [enabled] -mbig [disabled] -mbig-endian [disabled] -mbionic [disabled] -mbit-align [disabled] -mbit-word[disabled] -mblock-compare-inline-limit= 63 -mblock-compare-inline-loop-limit=-1 -mblock-move-inline-limit=0 -mbss-plt [enabled] -mcall-ABI -mcmodel= small -mcmpb[enabled] -mcompat-align-parm [disabled] -mcpu=[default] -mcrypto [enabled] -mdebug= -mdirect-move [enabled] -mdlmzb [disabled] -meabi[disabled] -mefficient-unaligned-vsx [enabled] -memb [disabled] -mfloat128[disabled] -mfloat128-convert[disabled] -mfloat128-hardware [disabled] -mfold-gimple [enabled] -mfp-in-toc [enabled] -mfprnd [enabled] -mfriz[enabled] -mfull-toc[disabled] -mfused-madd -ffp-contract=fast -mfuture [disabled] -mgen-cell-microcode [ignored] -mglibc [enabled] -mgnu-attribute [enabled] -mhard-dfp[enabled] -mhard-float [enabled] -mhtm [enabled] -minsert-sched-nops= -misel[disabled] -mlittle [enabled] -mlittle-endian [enabled] -mlong-double-0 -mlongcall[disabled] -mlra [ignored] -mmfcrf [enabled] -mmfpgpr [disabled] -mminimal-toc [disabled] -mmodulo [disabled] -mmulhw [disabled] -mmultiple[disabled] -mmusl[disabled] -mmvme[disabled] -mnewlib [disabled] -mno-fp-in-toc[disabled] -mno-mfpgpr [ignored] -mno-string [ignored] -mno-sum-in-toc [disabled] -mno-toc [disabled] -mno-traceback[disabled] -mno-update [disabled] -moptimize-swaps [enabled] -mpcrel [disabled] -mpltseq [enabled] -mpointers-to-nested-functions[enabled] -mpopcntb [enabled] -mpopcntd [enabled] -mpower8-fusion [disabled] -mpower8-fusion-sign [disabled] -mpower8-vector [enabled] -mpower9-minmax [disabled] -mpower9-misc [disabled] -mpower9-vector [disabled] -mpowerpc [ignored] -mpowerpc-gfxopt [enabled] -mpowerpc-gpopt [enabled] -mpowerpc64 [enabled] -mprefixed[disabled]
[Bug c/94389] New: __attribute__((warn_unused_result)) will warn if the result is discarded as an optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94389
Bug ID: 94389
Summary: __attribute__((warn_unused_result)) will warn if the
result is discarded as an optimisation
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.von.s at posteo dot de
Target Milestone: ---
With the code below, the compiler warns about an unused result, even though the
result is used:
#define O_TEXT 0 /* defined on Windows and DOS, but not needed on Unix */
__attribute__((warn_unused_result))
extern int text_mode(void);
int get_flags(void) {
return text_mode() ? O_TEXT : 0;
}
Similarly, there is a warning if the result of a function marked with
__attribute__((warn_unused_result)) is multiplied by 0, and probably with other
expressions that are easily constant-folded. If the function also has
__attribute__((const)), there is no warning.
I think this issue could be resolved as a by-product of fixing bug 66425.
[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Can't reproduce it either. Any specific -march= etc. options?
[Bug rtl-optimization/94368] [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-29 Status|UNCONFIRMED |WAITING CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I can't reproduce that with x86-64 cross compiler.
[Bug analyzer/94378] -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94378 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-29 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c/94370] double negation in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94370 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to work||9.3.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-29 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Known to fail||10.0 --- Comment #1 from Martin Liška --- The wording was added by Martin, leaving to him.
[Bug fortran/94380] Nested associate+select type blocks cause compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94380 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-03-29 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, it's a very old issue.
[Bug fortran/94388] New: FAIL: gfortran.dg/unlimited_polymorphic_30.f03 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94388 Bug ID: 94388 Summary: FAIL: gfortran.dg/unlimited_polymorphic_30.f03 execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc /objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/unlimited_polymorphi c_30.f03 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagno stics-color=never -fdiagnostics-urls=never -O0 -pedantic-errors -B/test/gnu/gcc/ objdir/hppa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp- hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgf ortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs -B/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/ hppa64-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11. 11/./libquadmath/.libs -lm -o ./unlimited_polymorphic_30.exe PASS: gfortran.dg/unlimited_polymorphic_30.f03 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu /gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs:/test/gnu/gcc/objdir/hppa64-hp -hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libqua dmath/.libs:/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../..:.:/test/gnu/gcc/ob jdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux 11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/. libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/ objdir/hppa64-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc/testsuit e/gfortran/../.. spawn [open ...] Program received signal SIGBUS: Access to an undefined portion of a memory objec t. (gdb) r Starting program: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/unlimited_polymorphic_30.exe Program received signal SIGBUS, Bus error. 0x4000330c in MAIN__ () at /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/unlimited_polymorphic_30.f03:13 13x%v = ['foo','bar'] (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0x400032fc to 0x4000331c: 0x400032fc :fstd fr22,68(r3) 0x40003300 :ldd 68(r3),r19 0x40003304 :add,l ret0,r19,ret0 0x40003308 :add,l r6,ret0,ret0 => 0x4000330c :ldd 0(ret0),r31 0x40003310 :ldi 0,ret0 0x40003314 :cmpb,*<>,n ret0,r31,0x40003578 0x40003318 :addil L%0,dp,r1 End of assembler dump. (gdb) p/x $ret0 $1 = 0x8001b80b (gdb) p x%v $2 = ( _data = (0x666f6f01b820, 0x80010570), _vptr = 0x800101a0 <__vtab_CHARACTER_1_.10>, _len = 3 ) (gdb) p *((char *)0x8001b80b) Overflow on numeric constant.
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-03-29 --- Comment #1 from Thomas Koenig --- The error is here: Program received signal SIGSEGV, Segmentation fault. match_data_constant (result=0x7fffd628) at ../../gcc/gcc/fortran/decl.c:426 426 if ((*result)->symtree->n.sym->attr.save (gdb) l 421 attribute. ... If data-stmt-constant is initial-data-target 422 the corresponding data statement object shall be 423 data-pointer-initialization compatible (7.5.4.6) with the initial 424 data target; the data statement object is initially associated 425 with the target. */ 426 if ((*result)->symtree->n.sym->attr.save 427 && (*result)->symtree->n.sym->attr.target) 428 return m; 429 gfc_free_expr (*result); 430 } (gdb) p (*result)->symtree $1 = (gfc_symtree *) 0x0 (gdb) call debug(*result) (/ /) (INTEGER 4)
[Bug middle-end/94387] Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387 --- Comment #1 from Petro Karashchenko --- Also the ambiguity of the issue is that excess read instructions generation depends on type of the field. Excess reads are not generated when 8 bit types are accessed and generated when data types greater that 8 bits are accessed.
[Bug middle-end/94387] New: Excess read instructions are generated in case of writing to fields of volatile + packed type (structure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94387
Bug ID: 94387
Summary: Excess read instructions are generated in case of
writing to fields of volatile + packed type
(structure)
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: petro.karashchenko at gmail dot com
Target Milestone: ---
Created attachment 48140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48140&action=edit
preprocessed file
Excess read instructions are generated when access members of volatile + packed
types (structures):
test.c:
--
#include
typedef volatile struct type1_s {
uint32_t a1;
uint8_t a2;
uint8_t a3;
uint8_t a4;
uint8_t a5;
} __attribute__((packed)) type1_t;
typedef volatile struct {
uint32_t b1;
uint32_t b2;
} __attribute__((packed)) type2_t;
typedef volatile struct type3_s {
type1_t h1;
volatile union {
uint8_t b[24];
type2_t c1;
} __attribute__((packed)) h2;
} __attribute__((packed)) type3_t;
typedef volatile struct type4_s {
uint32_t x1;
uint8_t x2;
uint16_t x3;
uint8_t x4;
uint8_t x5;
uint8_t x6;
} __attribute__((packed)) type4_t;
static void my_func2(type3_t *p0, type4_t *p1) ;
int my_func1(uint8_t *p0, uint8_t *p1)
{
type3_t *i = (type3_t *)p0;
type4_t *o = (type4_t *)p1;
my_func2(i, o);
return 0;
}
static void my_func2(type3_t *p0, type4_t *p1)
{
p1->x1 = 0xFF01;
p1->x6 = 1;
p1->x2 = 2;
p1->x4 = p0->h1.a3;
p1->x5 = p0->h1.a4;
p1->x3 = 0;
}
--
arceb-elf32-gcc -save-temps -Wall -Wextra -c -mcpu=arc600 -mtune=arc600
-mbig-endian -mmul64 test.c -Os
--
Disassembly:
.global my_func1
.type my_func1, @function
my_func1:
ldb_s r2,[r1]
mov r2,-1 ;6
stb_s r2,[r1]
ldb_s r3,[r1,1]
stb_s r2,[r1,1]
ldb_s r3,[r1,2]
stb_s r2,[r1,2]
ldb_s r2,[r1,3]
mov_s r3,1;0
stb_s r3,[r1,3]
stb_s r3,[r1,9]
mov_s r3,2
stb_s r3,[r1,4]
ldb_s r3,[r0,5]
mov_s r2,0;0
stb_s r3,[r1,7]
ldb_s r0,[r0,6]
stb_s r0,[r1,8]
ldb_s r0,[r1,5]
stb_s r2,[r1,5]
ldb_s r0,[r1,6]
stb_s r2,[r1,6]
mov_s r0,0;0
j_s [blink]
.size my_func1, .-my_func1
--
Expected disassembly:
.global my_func1
.type my_func1, @function
my_func1:
mov r2,-1 ;6
stb_s r2,[r1]
stb_s r2,[r1,1]
stb_s r2,[r1,2]
mov_s r3,1;0
stb_s r3,[r1,3]
stb_s r3,[r1,9]
mov_s r3,2
stb_s r3,[r1,4]
ldb_s r3,[r0,5]
mov_s r2,0;0
stb_s r3,[r1,7]
ldb_s r0,[r0,6]
stb_s r0,[r1,8]
stb_s r2,[r1,5]
stb_s r2,[r1,6]
mov_s r0,0;0
j_s [blink]
.size my_func1, .-my_func1
--
I have checked same code compilation with:
arm-none-eabi-gcc -save-temps -Wall -Wextra -c -mcpu=arm7tdmi -mthumb test.c
-Os
The result is pretty much the same, so it is not architecture dependent bug.
[Bug gcov-profile/94369] 505.mcf_r is 6-7% slower at -Ofast -march=native with PGO+LTO than with just LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94369 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-03-29 --- Comment #1 from Martin Liška --- Confirmed, can be nicely seen on LNT periodic benchmarks: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=295.347.0&plot.1=293.347.0&plot.2=287.347.0&plot.3=286.347.0
[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91601 Martin Liška changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|NEW Known to fail||8.4.0 --- Comment #14 from Martin Liška --- Ah, sorry, I probably wrongly identified which versions are affected. Yes, I'm gonna backport that.
[Bug ipa/94363] possible typo: attribute attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94363 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||10.0 Known to work||9.3.0 Target Milestone|--- |10.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-29 --- Comment #1 from Martin Liška --- Thank you for the report. I'm working on the patch.
[Bug c++/94385] [10 Regression] Internal compiler error for __builtin_convertvector + statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug fortran/94386] New: [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Bug ID: 94386 Summary: [10 Regression] FAIL: gfortran.dg/pr93365.f90 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: pault at gcc dot gnu.org Target Milestone: --- commit 7d57570b0658b8c1b8a97dafa53dfd4ab4bd3f65 Author: Paul Thomas Date: Sat Mar 28 19:11:35 2020 + Patch for PR94246 caused: FAIL: gfortran.dg/pr93365.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O1 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O2 (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr93365.f90 -Os (internal compiler error) FAIL: gfortran.dg/pr93365.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr93600_1.f90 -O (internal compiler error) FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 6) FAIL: gfortran.dg/pr93600_1.f90 -O (test for errors, line 7) FAIL: gfortran.dg/pr93600_1.f90 -O (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O1 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O2 (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr93600_2.f90 -Os (internal compiler error) FAIL: gfortran.dg/pr93600_2.f90 -Os (test for excess errors)
[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #6 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Iain Sandoe from comment #4)
> I'm going to discuss this with the coroutines paper authors - as to whether
> any constraints had been considered. Note, once again, that failure to
> implement this does not make us non-conforming.
coro paper author hadn't tested this configuration.
==
basically, the intent is that one can continue an arbitrary number
of coroutines, without overflowing the stack. Maybe there's an alternate
pattern that we could construct that would allow this; modulo the caller-
save of the TOC. Coroutine actor functions are marked with a flag, so we
do have a mechanism for handling them differently.
In the meantime, I guess this isn't going to work for PPC (AIX/powerpc64)
:( and we have to XFAIL or switch it off.
/* A C equivalent of what's being done. */
extern void actor (void *p);
/* This is how the public part of the coroutine frame ABI looks. */
typedef struct __frame {
void (*a) (void *);
void (*d) (void *);
float _other_things;
} generic_frame_t;
/* This is what a coroutine handle looks like. */
typedef struct __handle {
generic_frame_t *fp;
} generic_handle_t;
/* A fake call to get a handle... */
__attribute__((__noinline__))
generic_handle_t get_handle (void)
{
generic_frame_t *f = (generic_frame_t *)__builtin_malloc (sizeof
(generic_frame_t));
f->a = actor;
f->d = actor;
f->_other_things = 0.0F;
generic_handle_t h = {f};
return h;
}
/* .. and part of coroutine state machine that wants to continue
by executing another coroutine.
X86 tail-calls this for O2+ (even for PIC) m32/m64
PPC tail-calls for m32 (even for PIC), but not for ELFv2 m64.
with the TOC reg caller-saved, perhaps there's no sequence that can
work.
*/
void actor2 (void *p2)
{
generic_handle_t h = get_handle ();
generic_frame_t *t = h.fp;
/* Use the TOC. */
t->other_things = 1.1F;
(*t->a) ((void *)t);
}
[Bug fortran/83705] [8/9/10 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Martin Diehl changed:
What|Removed |Added
CC||m.diehl at mpie dot de
--- Comment #15 from Martin Diehl ---
Just as an addon: Compiling the following code
program integer_conversion
implicit none
integer :: i
i = 5
print*, 'b'//repeat('a',i)
end program integer_conversion
with
-Wconversion-extra
gives the message
Warning: Conversion from INTEGER(4) to INTEGER(8) at (1) [-Wconversion-extra]
This warning is of course not really a problem, but since it is related to the
handling of the NCOPIES argument of repeat it might be related to this bug.
I'm using gfortran 9.3.0.
