[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #11 from Peter Bergner ---
(In reply to Bill Seurer from comment #8)
> Cross:
> ;;
> ;; Full RTL generated for this function:
> ;;
> (note 1 0 4 NOTE_INSN_DELETED)
> (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 2 4 3 2 (set (mem/c:IF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
> A128])
> (reg:IF 33 1 [ a ])) "./signbit-1.c":7:32 -1
> (nil))
I can get close to this with a native build using -O2 -mcpu=power8 -mfloat128
-mabi=ieeelongdouble, but I still don't see an ICE:
void
do_signbit_if (__ibm128 a)
{
volatile __ibm128 dst;
dst = a;
}
Full rtl:
(insn 2 4 3 2 (set (reg/v:IF 117 [ aD.2831 ])
(reg:IF 33 1 [ aD.2831 ])) "str.i":3:1 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 0 2 (set (mem/v/c:IF (reg/f:DI 112 virtual-stack-vars) [1 dstD.2834+0
S16 A128])
(reg/v:IF 117 [ aD.2831 ])) "str.i":5:7 -1
(nil))
[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 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |10.0 Last reconfirmed||2020-03-28 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r10-317-ga52cf5cf278e4a9e58bfa2bb67a93244766a122f , latent before I think. IMHO --- gcc/cp/semantics.c.jj 2020-03-28 10:19:14.898349472 +0100 +++ gcc/cp/semantics.c 2020-03-29 00:02:40.648258781 +0100 @@ -380,7 +380,8 @@ add_stmt (tree t) /* When we expand a statement-tree, we must know whether or not the statements are full-expressions. We record that fact here. */ - STMT_IS_FULL_EXPR_P (t) = stmts_are_full_exprs_p (); + if (STATEMENT_CODE_P (TREE_CODE (t))) + STMT_IS_FULL_EXPR_P (t) = stmts_are_full_exprs_p (); } if (code == LABEL_EXPR || code == CASE_LABEL_EXPR) should fix this.
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #13 from sandra at gcc dot gnu.org ---
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.
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 target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #10 from Peter Bergner --- (In reply to Segher Boessenkool from comment #9) > So what causes this TF vs. IF? Cross and native should be exactly the same, > but perhaps there is a difference in the configurations you have for the two? Maybe on native, our long double defaults to IBM long double and on a cross build we somehow default to IEEE float 128? I wonder if the native build ICEs when using -mfloat128 -mabi=ieeelongdouble ?
[Bug c/94379] Feature request: like clang, support __attribute((__warn_unused_result__)) on structs, unions, and enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-03-28 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- Confirmed. C2X will likely have the same [[nodiscard]] attribute as C++. GCC 10 recognizes [[nodiscard]] but ignores it with a warning. In both languages the attribute can be applied to enums, structures, and unions as well. The latest proposal is http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2267.pdf. But I think it makes sense to extend warn_unused_result so that it can be used in earlier language conformance modes, and for compatibility with Clang.
[Bug fortran/94377] Won't compile when deallocating a parameterized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94377 --- Comment #2 from Fred Krogh --- I'm sorry, I made an error when making up this code from a much bigger one. There was a missing ')' at line 8. I've corrected this in the code below. Same kind of error here, but that code compiles on both Intel and NAG according to a friend. program pdt type :: av_t(n) integer, len :: n integer :: i real :: c real :: u(n) end type av_t type(av_t(:)), allocatable :: av(:) integer :: k2, k3 k2 = 3 k3 = 5 contains subroutine al_test(k) integer, intent(in) :: k integer :: ista if (k == 1) then allocate ( av_t(k2) :: av(k3), stat=ista) ! For this ista not needed return else deallocate(av, stat=ista) end if end subroutine al_test end program pdt
[Bug c++/94385] New: Internal compiler error for __builtin_convertvector + statement expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94385
Bug ID: 94385
Summary: Internal compiler error for __builtin_convertvector +
statement expr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
One of my projects is hitting an internal compiler error on GCC 10. It works
for g++ 9, and it works in C mode.
Here is a test case:
#include
typedef int32_t vec32 __attribute__((__vector_size__(16)));
typedef float vecf __attribute__((__vector_size__(16)));
vec32 foo(vecf bar) {
return (__extension__({
__builtin_convertvector(bar, vec32);
}));
}
Compiler Explorer link: https://godbolt.org/z/FMbXgs
[Bug testsuite/94384] New: FAIL: gfortran.dg/fmt_f_default_field_width_3.f90 -O (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94384
Bug ID: 94384
Summary: FAIL: gfortran.dg/fmt_f_default_field_width_3.f90 -O
(test for excess errors)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
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/fmt_f_default_field_
width_3.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdia
gnostics-color=never -fdiagnostics-urls=never -O -cpp -fdec
-fno-dec-format-defa
ults -S -o fmt_f_default_field_width_3.s
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:23:2
3: Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:26:2
3: Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:29:2
3: Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:33:2
3: Error: Nonnegative width required in format string at (1)
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:23:2
3: Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:26:2
3: Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:29:23:
Error: Nonnegative width required in format string at (1)
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:33:23:
Error: Nonnegative width required in format string at (1)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90 -O (test for errors, line
23)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90 -O (test for errors, line
26)
PASS: gfortran.dg/fmt_f_default_field_width_3.f90 -O (test for errors, line
29)
FAIL: gfortran.dg/fmt_f_default_field_width_3.f90 -O (test for excess
errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_3.f90:33:23:
Error: Nonnegative width required in format string at (1)
#ifdef __GFC_REAL_16__
real_16 = 4.18
write(buffer, fmt) ':',real_16,':' ! { dg-error "Nonnegative width
required" "" { target fortran_real_16 } }
#endif
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/
fortran_real_1611795.f90 -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never
-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/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libatomic/.libs
-B/test/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
fortran_real_1611795.exe
ld: Unsatisfied symbol "cosl" in file /var/tmp//ccuUh0M8.o
1 errors.
collect2: error: ld returned 1 exit status
compiler exited with status 1
output is:
ld: Unsatisfied symbol "cosl" in file /var/tmp//ccuUh0M8.o
1 errors.
collect2: error: ld returned 1 exit status
Seems to me the target qualifier should be removed.
[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 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-March/5 ||42861.html Target Milestone|--- |10.0 Keywords||patch --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542861.html
[Bug middle-end/90794] [8/9/10 Regression] -O3 with "VLA type" in C++ leads to an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90794 --- Comment #7 from Jonathan Wakely --- (In reply to Nicholas Krause from comment #6) > I can confirm about building trunk from yesterday that this code no longer > ICEs on 03. Can someone please close this bug as it no longer blocks C++ VLA > for gcc 10. No, because it still crashes on today's master. And even if it didn't, it's a regression on the gcc-8 and gcc-9 branches so it needs to be fixed on those branches before it can be closed.
[Bug middle-end/90794] [8/9/10 Regression] -O3 with "VLA type" in C++ leads to an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90794 Nicholas Krause changed: What|Removed |Added CC||xerofoify at gmail dot com --- Comment #6 from Nicholas Krause --- I can confirm about building trunk from yesterday that this code no longer ICEs on 03. Can someone please close this bug as it no longer blocks C++ VLA for gcc 10.
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163 --- Comment #9 from Segher Boessenkool --- So what causes this TF vs. IF? Cross and native should be exactly the same, but perhaps there is a difference in the configurations you have for the two?
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.5 Severity|normal |blocker
[Bug libfortran/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Amir Shahmoradi changed: What|Removed |Added CC||a.shahmoradi at gmail dot com --- Comment #9 from Amir Shahmoradi --- This is an old thread, but the problem does not seem to have been resolved yet, at least as of GFortran 8.3. I agree with c...@alum.mit.edu on this matter. This looks more like a bug in the design. The user should not need to rebuild an entire GNU Compiler Collection just for the sake of being able to use a compiler flag "-static-libgfortran". The lack of this feature practically makes the GFortran compiler useless in building shared libraries, as it will always have dependencies that most high-level-language users will not have installed on their systems. Requesting them to be able to install the dependencies correctly is too much, IMO. I would appreciate it very much if this build flaw in GFortran gets fixed by also adding positions-independent library builds.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Yep, bisected it to r241187.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 --- Comment #4 from Jonathan Wakely --- That would be consistent with the new field being introduced in gcc-7 (by r241187).
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 --- Comment #3 from Jonathan Wakely --- Is the difference maybe related to the empty field that is added for c++17 mode, mentioned in Bug 89358 comment 12? Is the aarch64 back end not ignoring that field?
[Bug target/94372] pthread doesn't define _REENTRANT in preprocessor on OpenRISC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94372 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-28 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Setting component=target without populating the "Target" field is meaningless, please add the output of 'gcc -dumpmachine' to the Target field.
[Bug target/84475] pthread doesn't define _REENTRANT in preprocessor on riscv-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84475 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.0
[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 #5 from Iain Sandoe --- (In reply to Iain Sandoe from comment #4) > So not sure how to proceed here at the moment (I wonder if this works for > PPC on the clang impl). It does work for X86 (and ironically, on PPC Darwin too - where the fact that we build a new "got" in each routine + no use of TOC means we can always tail call). Actually, I'm a bit suspicious of what happens in the case that two coroutines are in different DSOs for X86. apparently not: [iains@gcc1-power7 llvm-90]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17 ../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C -stdlib=libc++ -S fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail (the test case crashes the compiler for O>0). [iains@gcc1-power7 llvm-10]$ ./INSTL/bin/clang++ -fcoroutines-ts -std=c++17 ../gcc-master/src/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C -stdlib=libc++ -S fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail 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.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 --- Comment #2 from Jonathan Wakely --- https://godbolt.org/z/BnTEsn is an example with both functions in the same translation unit, showing the generated code is different for both caller and callee. If the caller and callee are not in the same TU the differences produce garbage.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 Jonathan Wakely changed: What|Removed |Added Known to work||6.4.0 Known to fail||7.5.0, 8.3.0, 9.2.1 Last reconfirmed||2020-03-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I haven't actually tested this with gcc-10 yet but I can't find an existing bug, so I assume it's also still present on master.
[Bug target/94383] New: [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Bug ID: 94383
Summary: [8/9/10 Regression] class with empty base passed
incorrectly with -std=c++17
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*-linux
This code is miscompiled on aarch64 with -std=c++17, apparently due to the
empty base class:
struct base { };
struct pair : base
{
float first;
float second;
pair(float f, float s) : first(f), second(s) { }
};
void f(pair);
int main()
{
f({3.14, 666});
}
It is wrong with any optimization level, but with -std=gnu++14 -O1 we get:
main:
stp x29, x30, [sp, -16]!
mov x29, sp
mov x0, 0
mov x1, 62915
movkx1, 0x4048, lsl 16
bfi x0, x1, 0, 32
mov x1, 32768
movkx1, 0x4426, lsl 16
bfi x0, x1, 32, 32
lsr w1, w0, 0
fmovd0, x0
ushrd1, d0, 32
fmovs0, w1
bl f(pair)
mov w0, 0
ldp x29, x30, [sp], 16
ret
With -std=gnu++17 -O1 we get:
main:
stp x29, x30, [sp, -16]!
mov x29, sp
mov x0, 0
mov x1, 62915
movkx1, 0x4048, lsl 16
bfi x0, x1, 0, 32
mov x1, 32768
movkx1, 0x4426, lsl 16
bfi x0, x1, 32, 32
bl f(pair)
mov w0, 0
ldp x29, x30, [sp], 16
ret
If the translation unit containing the called function is:
struct base { };
struct pair : base
{
float first;
float second;
pair(float f, float s) : first(f), second(s) { }
};
void f(pair lr)
{
__builtin_printf("%f %f\n", lr.first, lr.second);
}
and the caller is compiled with -std=gnu++14 and the callee is compiled with
-std=gnu++17 then the callee prints garabage:
-13874.335938 0.00
[Bug c/94382] New: conflicting function types should show more context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94382
Bug ID: 94382
Summary: conflicting function types should show more context
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matthew at wil dot cx
Target Milestone: ---
The diagnostic would be better if it showed the entire function prototype:
../fs/iomap/apply.c:13:1: error: conflicting types for ‘__iomap_apply’
13 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned
flags,
| ^
In file included from ../fs/iomap/apply.c:9:
../include/linux/iomap.h:152:1: note: previous declaration of ‘__iomap_apply’
was here
152 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned
flags,
| ^
$ grep -A3 __iomap_apply include/linux/iomap.h fs/iomap/apply.c
include/linux/iomap.h:__iomap_apply(struct inode *inode, loff_t pos, loff_t
length, unsigned flags,
include/linux/iomap.h- const struct iomap_ops *ops, iomap_actor_t
actor,
include/linux/iomap.h- struct iomap *iomap, struct iomap *srcmap);
include/linux/iomap.h-
--
include/linux/iomap.h: length = __iomap_apply(inode, pos, length, flags, ops,
actor,
include/linux/iomap.h- &iomap, &srcmap);
include/linux/iomap.h- /*
include/linux/iomap.h- * Now that we have guaranteed that the space
allocation will succeed,
--
fs/iomap/apply.c:__iomap_apply(struct inode *inode, loff_t pos, loff_t length,
unsigned flags,
fs/iomap/apply.c- struct iomap *iomap, struct iomap *srcmap,
fs/iomap/apply.c- const struct iomap_ops *ops, iomap_actor_t
actor)
fs/iomap/apply.c-{
The bug in my code is fairly obvious, but the diagnostic doesn't show the part
of the function signature that doesn't match.
[Bug web/94349] Bugzilla user preferences are blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94349 --- Comment #9 from Jonathan Wakely --- I created a pull request for the patch, it's linked to from that issue now.
[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 Last reconfirmed||2020-03-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- Also '-falign-loops' '-falign-loops=N' '-falign-loops=N:M' '-falign-loops=N:M:N2' '-falign-loops=N:M:N2:M2' and '-falign-jumps' '-falign-jumps=N' '-falign-jumps=N:M' '-falign-jumps=N:M:N2' '-falign-jumps=N:M:N2:M2' specify the maximum alignment. The actual alignment is also controlled by '-falign-labels' '-falign-labels=N' '-falign-labels=N:M' '-falign-labels=N:M:N2' '-falign-labels=N:M:N2:M2'
[Bug driver/94381] New: -falign-function/-falign-labels/-falign-loops documentation is inaccurate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94381
Bug ID: 94381
Summary: -falign-function/-falign-labels/-falign-loops
documentation is inaccurate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, skpgkp2 at gmail dot com
Target Milestone: ---
'-falign-functions'
'-falign-functions=N'
'-falign-functions=N:M'
'-falign-functions=N:M:N2'
'-falign-functions=N:M:N2:M2'
Align the start of functions to the next power-of-two greater than
N, skipping up to M-1 bytes.
But
[hjl@gnu-cfl-2 align]$ cat y.i
void
foo (void)
{
}
[hjl@gnu-cfl-2 align]$ gcc -O2 -S -falign-functions=4 y.i
[hjl@gnu-cfl-2 align]$ cat y.s
.file "y.i"
.text
.p2align 2 4 is not the next power-of-two greater than 4.
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.3.1 20200317 (Red Hat 9.3.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 align]$
It should be "the next power-of-two no less than N".
'-falign-labels'
'-falign-labels=N'
'-falign-labels=N:M'
'-falign-labels=N:M:N2'
'-falign-labels=N:M:N2:M2'
Align all branch targets to a power-of-two boundary.
and
'-falign-loops'
'-falign-loops=N'
'-falign-loops=N:M'
'-falign-loops=N:M:N2'
'-falign-loops=N:M:N2:M2'
Align loops to a power-of-two boundary.
may leave an impression of alignment is N to the power-of-two.
[Bug fortran/94348] gfortran 8/9 reject module procedure definition in same module as function interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94348 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6 commit r10-7443-g3fb7f2fbd5f109786922deb5af8fd8dd594a7ba6 Author: Tobias Burnus Date: Sat Mar 28 14:01:57 2020 +0100 [Fortran] Fix result-variable handling of MODULE PROCEDURE (PR94348) PR fortran/94348 * decl.c (gfc_match_submod_proc): Add result var to the proc's namespace. PR fortran/94348 * gfortran.dg/module_procedure_3.f90: New.
[Bug c++/94306] Improve diagnostic when "requires" used instead of "requires requires" and add fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed.
[Bug c++/94252] Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 10.
[Bug c++/94306] Improve diagnostic when "requires" used instead of "requires requires" and add fix-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94306
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7981c06ae92548bd66f07121db1802eb6aec73ed
commit r10-7442-g7981c06ae92548bd66f07121db1802eb6aec73ed
Author: Patrick Palka
Date: Sat Mar 28 08:57:11 2020 -0400
c++: Diagnose when "requires" is used instead of "requires requires"
[PR94306]
This adds support to detect and recover from the case where an opening
brace
immediately follows the start of a requires-clause. So rather than
emitting the
error
error: expected primary-expression before '{' token
followed by a slew of irrevelant errors, we now assume the user had
intended to
write "requires requires {" and diagnose and recover accordingly.
gcc/cp/ChangeLog:
PR c++/94306
* parser.c (cp_parser_requires_clause_opt): Diagnose and recover
from
"requires {" when "requires requires {" was probably intended.
gcc/testsuite/ChangeLog:
PR c++/94306
* g++.dg/concepts/diagnostic8.C: New test.
[Bug c++/94252] Can't use a lambda in a requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94252 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a7ea3d2ced786c4544fa625f34f515d89ed074fe commit r10-7441-ga7ea3d2ced786c4544fa625f34f515d89ed074fe Author: Patrick Palka Date: Sat Mar 28 08:56:59 2020 -0400 c++: requires-expression outside of a template is misevaluated [PR94252] This PR shows that a REQUIRES_EXPR outside of a template can sometimes be misevaluated. This happens because the evaluation routine tsubst_requires_expr (and diagnose_requires_expr) assumes the REQUIRES_EXPR's subtrees are templated trees and that therefore it's safe to call tsubst_expr on them. But this assumption isn't valid when we've parsed a REQUIRES_EXPR outside of a template context. In order to make this assumption valid here, this patch sets processing_template_decl to non-zero before parsing the body of a REQUIRES_EXPR so that its subtrees are indeed always templated trees. gcc/cp/ChangeLog: PR c++/94252 * constraint.cc (tsubst_compound_requirement): Always suppress errors from type_deducible_p and expression_convertible_p, as they're not substitution errors. (diagnose_atomic_constraint) : Remove this case so that we diagnose INTEGER_CST expressions of non-bool type via the default case. * cp-gimplify.c (cp_genericize_r) : New case. * parser.c (cp_parser_requires_expression): Always parse the requirement body as if we're processing a template, by temporarily incrementing processing_template_decl. Afterwards, if we're not actually in a template context, perform semantic processing to diagnose any invalid types and expressions. * pt.c (tsubst_copy_and_build) : Remove dead code. * semantics.c (finish_static_assert): Explain an assertion failure when the condition is a REQUIRES_EXPR like we do when it is a concept check. gcc/testsuite/ChangeLog: PR c++/94252 * g++.dg/concepts/diagnostic7.C: New test. * g++.dg/concepts/pr94252.C: New test. * g++.dg/cpp2a/concepts-requires18.C: Adjust to expect an additional diagnostic.
[Bug web/94349] Bugzilla user preferences are blank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94349 --- Comment #8 from Frédéric Buclin --- Created attachment 48139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48139&action=edit Fix taint issue in Template/Provider.pm I wrote a trivial patch to fix the taint issue reported in Template/Provider.pm and which is filling the web server error log. @fche: could you please attach this patch upstream on https://github.com/abw/Template2/issues/258 (I don't have nor want a github account). Thanks! :)
[Bug fortran/94380] New: Nested associate+select type blocks cause compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94380 Bug ID: 94380 Summary: Nested associate+select type blocks cause compiler segfault Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: lockywolf at gmail dot com Target Milestone: --- >>cat bugreport2.f90 module test type testtype class(*), allocatable :: t end type testtype contains subroutine testproc( x ) class(testtype) :: x associate ( temp => x%t) select type (temp) type is (integer) end select end associate end subroutine testproc end module test >> gfortran -v -save-temps -Wall -Wextra bugreport2.f90 Driving: gfortran -v -save-temps -Wall -Wextra bugreport2.f90 -l gfortran -l m -shared-libgcc Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/9.3.0/specs COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/9.3.0/lto-wrapper Target: x86_64-slackware-linux Configured with: ../gcc-9.3.0/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-languages=ada,brig,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-threads=posix --enable-checking=release --enable-objc-gc --with-system-zlib --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --disable-libstdcxx-pch --disable-libunwind-exceptions --enable-__cxa_atexit --disable-libssp --enable-gnu-unique-object --enable-plugin --enable-lto --disable-install-libiberty --enable-gnu-indirect-function --with-linker-hash-style=gnu --with-gnu-ld --with-isl --verbose --with-arch-directory=amd64 --disable-gtktest --disable-werror --enable-clocale=gnu --enable-multilib --target=x86_64-slackware-linux --build=x86_64-slackware-linux --host=x86_64-slackware-linux Thread model: posix gcc version 9.3.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-slackware-linux/9.3.0/f951 bugreport2.f90 -quiet -dumpbase bugreport2.f90 -mtune=generic -march=x86-64 -auxbase bugreport2 -Wall -Wextra -version -fintrinsic-modules-path /usr/lib64/gcc/x86_64-slackware-linux/9.3.0/finclude -fpre-include=/usr/include/finclude/math-vector-fortran.h -o bugreport2.s GNU Fortran (GCC) version 9.3.0 (x86_64-slackware-linux) compiled by GNU C version 9.3.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 9.3.0 (x86_64-slackware-linux) compiled by GNU C version 9.3.0, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f951: internal compiler error: Segmentation fault No preprocessed source is generated. SELECT TYPE can be used in the "associate form", which does not crash. But nevertheless, message-less segfault seems to be a bug.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #38 from pskocik at gmail dot com ---
I like this behavior. I use (void) casts to suppress warnings about unused
parameters and variables, but I'd rather suppressing WUR weren't that simple
because of functions whose return result represents an allocated resource
(allocated memory, FILE, filedescriptor, etc.), in which case the suppression
is in 99% cases erroneous.
Of course, WUR is also useful as an aid in enforcing consistent error checking
but a codebase using WUR like that might as well define an custom IGNORE macro
(which assigns the result to a properly typed temporary and then voids it) and
make sure such a macro only works on return values which are truly safe to
ignore (e.g., rather than returning plain int, long, etc., you might return
struct ignorable_int { int ignorable_retval; };, struct ignorable_long { long
ignorable_retval; }, etc. and have your ignore macro try and access the
specifically named member).
(An ability to directly attach WUR to such types, which clang has gcc currently
doesn't (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379), would also go
nicely with this un-void-able WURs feature (although WURs are void-able on
clang)).
[Bug c/94379] New: Feature request: like clang, support __attribute((__warn_unused_result__)) on structs, unions, and enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94379
Bug ID: 94379
Summary: Feature request: like clang, support
__attribute((__warn_unused_result__)) on structs,
unions, and enums
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
Clang supports applying the warn_unused_result attribute to enums, structs, and
unions, which has the effect that functions returning such an attributed
enum/struct/union behaves as if it itself had the warn_unused_result attribute.
Example:
typedef struct __attribute__((__warn_unused_result__)) aStructType{ int x; }
aStructType;
aStructType getStruct(void);
typedef union __attribute__((__warn_unused_result__)) aUnionType{ int x; }
aUnionType;
aUnionType getUnion(void);
typedef enum __attribute__((__warn_unused_result__)) anEnumType{
anEnumarationConstant } anEnumType;
anEnumType getEnum(void);
int main()
{
getEnum();
getStruct();
getUnion();
}
// https://gcc.godbolt.org/z/jyHhLx
I find this to be a very useful feature, and it would be nice if gcc had it
(along with its current un-void-able warn_unused_result
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425)).
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #3 from Sergei Trofimovich --- Asked gcc mailing list what interaction we do expect with configure options --disable-multilib/--with-multilib-list= and out put of 'gcc -print-multi-os-directory' as: https://gcc.gnu.org/pipermail/gcc/2020-March/231981.html
[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573 --- Comment #6 from Jakub Jelinek --- Fixed the error-recovery bug on the trunk, but the ice on the #c4 testcase is still there (and the question is if it is valid or not). If it is valid, probably the FE or gimplifier needs to turn that cast to VLA union into creation of a VLA temporary and assigning the cast operand into the right field of it.
[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c6a562de88c44a555e1688c212869b20b02151bc commit r10-7438-gc6a562de88c44a555e1688c212869b20b02151bc Author: Jakub Jelinek Date: Sat Mar 28 10:30:31 2020 +0100 c: After issuing errors about array size, for error-recovery don't make the array VLA [PR93573] After we report various errors about array size, we set for error-recovery the size to be 1, but because size_int_const is false, it still means we pretend the array is a VLA, can emit a second diagnostics in that case etc. E.g. $ ./cc1.unpatched -quiet a.c a.c:1:5: error: size of array âfâ has non-integer type 1 | int f[100.0]; | ^ a.c:1:1: warning: variably modified âfâ at file scope 1 | int f[100.0]; | ^~~ $ ./cc1 -quiet a.c a.c:1:5: error: size of array âfâ has non-integer type 1 | int f[100.0]; | ^ 2020-03-28 Jakub Jelinek PR c/93573 * c-decl.c (grokdeclarator): After issuing errors, set size_int_const to true after setting size to integer_one_node. * gcc.dg/pr93573-1.c: New test. * gcc.dg/pr93573-2.c: New test.
[Bug tree-optimization/94329] [8/9 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] error: |[8/9 Regression] error: |use_only.f90: |use_only.f90: |‘-fcompare-debug’ failure |‘-fcompare-debug’ failure |(length)|(length) --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94329 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:679becf175c5d7f6b323cd3af0a09c6039b4123d commit r10-7437-g679becf175c5d7f6b323cd3af0a09c6039b4123d Author: Jakub Jelinek Date: Sat Mar 28 10:21:52 2020 +0100 reassoc: Fix -fcompare-debug bug in reassociate_bb [PR94329] The following testcase FAILs with -fcompare-debug, because reassociate_bb mishandles the case when the last stmt in a bb has zero uses. In that case reassoc_remove_stmt (like gsi_remove) moves the iterator to the next stmt, i.e. gsi_end_p is true, which means the code sets the iterator back to gsi_last_bb. The problem is that the for loop does gsi_prev on that before handling the next statement, which means the former penultimate stmt, now last one, is not processed by reassociate_bb. Now, with -g, if there is at least one debug stmt at the end of the bb, reassoc_remove_stmt moves the iterator to that following debug stmt and we just do gsi_prev and continue with the former penultimate non-debug stmt, now last non-debug stmt. The following patch fixes that by not doing the gsi_prev in this case; there are too many continue; cases, so I didn't want to copy over the gsi_prev to all of them, so this patch uses a bool for that instead. The second gsi_end_p check isn't needed anymore, because when we don't do the undesirable gsi_prev after gsi = gsi_last_bb, the loop !gsi_end_p (gsi) condition will catch the removal of the very last stmt from a bb. 2020-03-28 Jakub Jelinek PR tree-optimization/94329 * tree-ssa-reassoc.c (reassociate_bb): When calling reassoc_remove_stmt on the last stmt in a bb, make sure gsi_prev isn't done immediately after gsi_last_bb. * gfortran.dg/pr94329.f90: New test.
[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 #4 from Iain Sandoe --- so, it seems: rs6000_function_ok_for_sibcall () calls rs6000_decl_ok_for_sibcall () which gets a NULL decl and thus this returns false /* Under the AIX or ELFv2 ABIs we can't allow calls to non-local functions, because the callee may have a different TOC pointer to the caller and there's no way to ensure we restore the TOC when we return. */ if (!decl || DECL_EXTERNAL (decl) || DECL_WEAK (decl) || !(*targetm.binds_local_p) (decl)) return false; The signature of the callee is void (void *) So not sure how to proceed here at the moment (I wonder if this works for PPC on the clang impl). The comment indicates that this is going to fail for AIX too as it stands.
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #12 from rguenther at suse dot de --- On March 27, 2020 9:19:33 PM GMT+01:00, "sandra at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 > >--- Comment #11 from sandra at gcc dot gnu.org --- >RTL before sched2 does look sane and similar to that generated for x86 >with >-m32. > >I've been trying to step through sched2. I think that where things get >interesting is the call to true_dependence at sched-deps.c:2663. > >Breakpoint 6, true_dependence (mem=0x7742c9a8, mem_mode=E_VOIDmode, > >x=0x7742cac8) >at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:3056 >3056 return true_dependence_1 (mem, mem_mode, NULL_RTX, >(gdb) print debug_rtx(mem) >(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]) >$19 = void >(gdb) print debug_rtx(x) >(mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0 S4 >A32]) >$20 = void > >This is making it all the way to the end of true_dependence_1, into >rtx_refs_may_alias_p, and into refs_may_alias_p_1, which is returning >false, >which gets propagated back up as the result of true_dependence. IIUC, >this is >what is allowing sched2 to move the read from "x" ahead of the write to >"mem". > >Before I spend more time on this, am I on the right track here? And is >this >pointing at the problem being in refs_may_alias_p_1 rather than >somewhere along >the way e.g. in true_dependence_1? Those are two stores, right? Then true_dependence is the wrong predicate to look at it should be output_dependence instead.
