[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #6 from Aldy Hernandez --- Created attachment 51654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51654&action=edit proposed patch Does this fix the problem on aarch64?
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #7 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #6) > Created attachment 51654 [details] > proposed patch > > Does this fix the problem on aarch64? I get: Running /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps threaded: 12" Let me attach the dump files.
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #8 from Andrew Pinski --- Created attachment 51655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51655&action=edit Dump files for aarch64
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 Aldy Hernandez changed: What|Removed |Added Attachment #51654|0 |1 is obsolete|| --- Comment #10 from Aldy Hernandez --- Created attachment 51656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51656&action=edit proposed patch 2 How about this?
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #9 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #7) > (In reply to Aldy Hernandez from comment #6) > > Created attachment 51654 [details] > > proposed patch > > > > Does this fix the problem on aarch64? > > I get: > Running > /home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree- > ssa.exp ... > FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps > threaded: 12" > Let me attach the dump files. $ grep Jumps.threaded *thread3 Jumps threaded: 20 The regex matches 12 but aarch64 20. I really hate this test. It never catches anything, and only creates an endless amount of busy work.
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #11 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #10) > Created attachment 51656 [details] > proposed patch 2 > > How about this? I can confirm the patch works on aarch64-linux-gnu and x86_64-linux-gnu.
[Bug testsuite/102857] [12 regression] r12-4526 caused regressions on ssa-dom-thread-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 --- Comment #12 from Aldy Hernandez --- Thank you for your help on this (and the myriad of other PRs ;-)). I'll submit upstream. On Sat, Oct 23, 2021 at 11:06 AM pinskia at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857 > > --- Comment #11 from Andrew Pinski --- > (In reply to Aldy Hernandez from comment #10) > > Created attachment 51656 [details] > > proposed patch 2 > > > > How about this? > > I can confirm the patch works on aarch64-linux-gnu and x86_64-linux-gnu. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug tree-optimization/102892] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2021-10-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #1) > Maybe a duplicate of PR102879? Hmmm, maybe not. It doesn't look like a threading thing after a quick glance. We only thread 1 path, in both 11.2 and trunk: a.c.193t.dom3: [4] Registering jump thread: (11, 3) incoming edge; (3, 5) joiner (5, 12) normal; And it's actually in DOM which has been largely untouched in this release. Could someone bisect this?
[Bug c/9262] [3.3 regression] ICE on false case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9262 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:d891ab1bc87bc5d855f6ee18337e517a2a90d759 commit r12-4640-gd891ab1bc87bc5d855f6ee18337e517a2a90d759 Author: H.J. Lu Date: Sat Oct 23 05:40:09 2021 -0700 Move bind-c-intent-out-2.f90 to gfortran.dg/ubsan Move bind-c-intent-out-2.f90 to gfortran.dg/ubsan for -fsanitize=undefined. PR fortran/9262 * gfortran.dg/bind-c-intent-out-2.f90: Moved to ... * gfortran.dg/ubsan/bind-c-intent-out-2.f90
[Bug go/102908] New: [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908 Bug ID: 102908 Summary: [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: hjl.tools at gmail dot com CC: cmang at google dot com Target Milestone: --- On Linux/x86-64, go.test/test/fixedbugs/issue16095.go hangs again as of r12-4629: FAIL: go.test/test/fixedbugs/issue16095.go execution, -O2 -g
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #8 from H.J. Lu --- Does sanitizer_common/sanitizer_platform_limits_freebsd.cpp need any header files from GCC? If yes, why aren't they needed in compiler-rt? If no, can you filter out these -I options in Makefile?
[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bec9e43e1611b62732bf29763c3e8bddea480f62 commit r10-10231-gbec9e43e1611b62732bf29763c3e8bddea480f62 Author: Harald Anlauf Date: Thu Oct 14 20:18:14 2021 +0200 Fortran: fix order of checks for the SHAPE intrinsic gcc/fortran/ChangeLog: PR fortran/102716 * check.c (gfc_check_shape): Reorder checks so that invalid KIND arguments can be detected. gcc/testsuite/ChangeLog: PR fortran/102716 * gfortran.dg/shape_10.f90: New test. (cherry picked from commit 1b115daf62d94337b3d0b2962b0bbbf005a450e0)
[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Backporting to 9-branch would require manual fixup and is not worth the effort. Closing. Thanks for the report!
[Bug fortran/102891] Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 --- Comment #2 from anlauf at gcc dot gnu.org --- Adding to main the lines print *, size (transfer ( w%z%re ,[1.0_dp])) print *, size (transfer ([w%z%re],[1.0_dp])) prints 4 2 whereas e.g. print *, size (transfer ( real (w%z, kind (w%z%re)) ,[1.0_dp])) print *, size (transfer ([real (w%z, kind (w%z%re))],[1.0_dp])) prints 2 2 The issue is likely with the combination of array/array constructor and the inquiry %re . Possibly related: pr102599.
[Bug c/102909] New: Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909
Bug ID: 102909
Summary: Missing -Wunused-but-set-variable warning
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mytbk920423 at gmail dot com
Target Milestone: ---
GCC misses the -Wunused-but-set-variable in the some code (GCC and Clang output
can be seen in https://godbolt.org/z/7658M4qra).
I first found a bug caused by the following code, in which no compilers warn:
void ioapic_set_max_vectors(void *ioapic_base, int mre_count)
{
u32 reg;
u8 count;
reg = io_apic_read(ioapic_base, 0x01);
count = reg >> 16;
if (mre_count > 0)
count = mre_count - 1;
// reg is defined but not used after this
reg &= ~(0xff << 16);
reg |= count << 16;
// ``count`` should be ``reg`` in the following line
io_apic_write(ioapic_base, 0x01, count);
}
I think that's because the variable ``reg`` is only unused in part of the
control flow, so I change the code as following. However, GCC doesn't warn on
this either.
void ioapic_set_max_vectors(void *ioapic_base, int mre_count)
{
u32 reg;
u32 new_reg;
u8 count;
reg = io_apic_read(ioapic_base, 0x01);
count = reg >> 16;
if (mre_count > 0)
count = mre_count - 1;
// new_reg is defined but not used
new_reg = reg & (~(0xff << 16));
new_reg |= count << 16;
// ``count`` should be ``new_reg`` in the following
io_apic_write(ioapic_base, 0x01, count);
}
[Bug c/102909] Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The warning works as documented. It warns about variables that are only stored to and never read. new_reg in the second testcase or reg is not such a variable, it is also read.
[Bug fortran/102903] Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102903 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-10-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. The test pr17143.f90 relies on wrapping on overflow, so it's probably a WONTFIX. Reduced test for power_8.f90: integer(1) :: j j = 7 print *, (-2_1) ** j print *, (-512_8) ** j end There are no runtime errors if I replace j with 7.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #9 from Gerald Pfeifer --- (In reply to H.J. Lu from comment #8) > Does sanitizer_common/sanitizer_platform_limits_freebsd.cpp need any header > files from GCC? >From what I found, that does not appear to be the case. > If yes, why aren't they needed in compiler-rt? > If no, can you filter out these -I options in Makefile? How do I go about that? (I did see your earlier suggestions, just ran out of time and, frankly, the experience on how to practically do this.) If you have a prototype patch to try (and maybe tweak) I'll happily do.
[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Th error for gfc_class_data_get and alloc_comp_class_4.f03 is: ../../work/gcc/fortran/trans-expr.c:230:7: runtime error: member access within null pointer of type 'union tree_node' For the ICE is internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.c:232
[Bug fortran/102901] ICE (segfault) when compiling pdt_13.f03 with -fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102901 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-10-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING --- Comment #10 from H.J. Lu --- (In reply to Gerald Pfeifer from comment #9) > > If you have a prototype patch to try (and maybe tweak) I'll happily do. Please send me all Makefiles under libsanitizer and the failed command line.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #11 from Gerald Pfeifer --- Created attachment 51657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51657&action=edit $WRKDIR/i586-unknown-freebsd11.4/libsanitizer/Makefile
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #12 from Gerald Pfeifer --- Created attachment 51658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51658&action=edit $WRKDIR/i586-unknown-freebsd11.4/libsanitizer/sanitizer_common/Makefile
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #13 from H.J. Lu --- Created attachment 51659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51659&action=edit A patch Please try this.
[Bug go/102908] [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102904 Last reconfirmed||2021-10-23 Target Milestone|--- |12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- I saw it too as of r12-4626 on aarch64. I filed PR 102904 as the hang didn't trigger the timeout even.
[Bug tree-optimization/102908] [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908 Andrew Pinski changed: What|Removed |Added Component|go |tree-optimization Keywords||wrong-code Assignee|ian at airs dot com|pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- This might be a bug in simple_dce_from_worklist which does not check stmt_unremovable_because_of_non_call_eh_p . Let me check if that solves the issue.
[Bug tree-optimization/102908] [12 Regression] go.test/test/fixedbugs/issue16095.go hangs again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102908 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > This might be a bug in simple_dce_from_worklist which does not check > stmt_unremovable_because_of_non_call_eh_p . > > Let me check if that solves the issue. The only issue here is that tree-vect-generic uses this to delete statements they have lowered but stmt_unremovable_because_of_non_call_eh_p might return true for those. So I might need an other argument to simple_dce_from_worklist about that ... Let me try without the argument first.
[Bug testsuite/102904] go testsuite does not always cause a timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102904 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-23 --- Comment #1 from H.J. Lu --- I saw WARNING: program timed out. FAIL: go.test/test/fixedbugs/issue16095.go execution, -O2 -g But the hanging issue16095.go wasn't terminated until I killed it by hand.
[Bug fortran/84007] [OOP] ICE with SAME_TYPE_AS and CLASS(*) entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- I think this issue is fixed now?
[Bug fortran/71703] [9/10/11/12 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #17 from sandra at gcc dot gnu.org --- I think this issue is fixed now?
[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 sandra at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||sandra at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #8 from sandra at gcc dot gnu.org --- This issue seems to have been fixed by the above patch.
[Bug fortran/36854] [meta-bug] fortran front-end optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854 Bug 36854 depends on bug 65819, which changed state. Bug 65819 Summary: overzealous checking in gfc_check_dependency for identical=true https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Bug 37131 depends on bug 65819, which changed state. Bug 65819 Summary: overzealous checking in gfc_check_dependency for identical=true https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/102729] Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from sandra at gcc dot gnu.org --- This is the same ICE previously reported as PR100194. *** This bug has been marked as a duplicate of bug 100194 ***
[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194 sandra at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- *** Bug 102729 has been marked as a duplicate of this bug. ***
[Bug fortran/102641] Bogus error for intent(out) dummy that is a polymorphic assumed-rank array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641 Bug 102641 depends on bug 102729, which changed state. Bug 102729 Summary: Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/102910] New: cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 Bug ID: 102910 Summary: cf-descriptor-5-c.c fails to build Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: --- Build log shows Executing on host: /usr/home/sgk/gcc/objx/gcc/testsuite/gfortran1/../../gfortran -B/usr/home/sgk/gcc/objx/gcc/testsuite/gfortran1/../../ -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/ /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output-O0 -Werror -g /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/dump-descriptors.c -dumpbase "" -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libatomic/.libs -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -lm -o ./cf-descriptor-5.exe(timeout = 300) spawn -ignore SIGHUP /usr/home/sgk/gcc/objx/gcc/testsuite/gfortran1/../../gfortran -B/usr/home/sgk/gcc/objx/gcc/testsuite/gfortran1/../../ -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/ /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -Werror -g /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/dump-descriptors.c -dumpbase -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libgfortran/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libatomic/.libs -B/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -L/usr/home/sgk/gcc/objx/x86_64-unknown-freebsd14.0/./libquadmath/.libs -lm -o ./cf-descriptor-5.exe /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c:3:10: fatal error: alloca.h: No such file or directory compilation terminated. compiler exited with status 1 FAIL: gfortran.dg/c-interop/cf-descriptor-5.f90 -O0 (test for excess errors) Excess errors: /usr/home/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c:3:10: fatal error: alloca.h: No such file or directory compilation terminated.
[Bug fortran/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 kargl at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-freebsd Target Milestone|--- |12.0
[Bug fortran/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 --- Comment #1 from kargl at gcc dot gnu.org --- This fixes the issue. The assumption that alloca.h is available on all systems is likely not a good idea. The function alloca() lives in stdlib.h on at least FreeBSD. diff --git a/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c b/gcc/testsuite/gfortran.dg/c -interop/cf-descriptor-5-c.c index 12464b55512..2a525c522b8 100644 --- a/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c +++ b/gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5-c.c @@ -1,6 +1,8 @@ #include #include +#ifndef alloca #include +#endif #include #include "dump-descriptors.h"
[Bug sanitizer/102911] New: AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102911 Bug ID: 102911 Summary: AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- On Fedora 35/x86-64 with glibc 2.34, I got [hjl@gnu-skx-1 gcc]$ /export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc -B/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/c-c++-common/asan/alloca_detect_custom_size.c -m32 -B/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/ -B/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/asan/ -L/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/asan/.libs -fsanitize=address -g -I/export/gnu/import/git/sources/gcc/gcc/testsuite/../../libsanitizer/include -fdiagnostics-plain-output-O0-lm -o ./alloca_detect_custom_size.exe.bad [hjl@gnu-skx-1 gcc]$ export LD_LIBRARY_PATH=/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/asan/.libs [hjl@gnu-skx-1 gcc]$ ./alloca_detect_custom_size.exe.bad = ==3485262==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0xffe51f80 at pc 0x08049279 bp 0xffe51e98 sp 0xffe51e8c WRITE of size 1 at 0xffe51f80 thread T0 #0 0x8049278 in foo /export/gnu/import/git/sources/gcc/gcc/testsuite/c-c++-common/asan/alloca_detect_custom_size.c:16 #1 0x80492dc in main /export/gnu/import/git/sources/gcc/gcc/testsuite/c-c++-common/asan/alloca_detect_custom_size.c:20 #2 0xf7653468 in __libc_start_call_main (/lib/libc.so.6+0x25468) #3 0xf765355f in __libc_start_main@@GLIBC_2.34 (/lib/libc.so.6+0x2555f) #4 0x80490eb in _start (/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/testsuite/gcc/alloca_detect_custom_size.exe.bad+0x80490eb) Address 0xffe51f80 is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow /export/gnu/import/git/sources/gcc/gcc/testsuite/c-c++-common/asan/alloca_detect_custom_size.c:16 in foo Shadow bytes around the buggy address: 0x3ffca3a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca3b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca3c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca3d0: 00 00 00 00 00 00 00 00 ca ca ca ca 00 00 00 00 0x3ffca3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x3ffca3f0:[cb]cb cb cb 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca410: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca420: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x3ffca440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==3485262==ABORTING [hjl@gnu-skx-1 gcc]$ export LD_LIBRARY_PATH=/export/users/hjl/build/gnu/tools-build/gcc-debug/build-x86_64-linux/x86_64-pc-linux-gnu/32/libsanitizer/asan/.libs [hjl@gnu-skx-1 gcc]$ ./alloca_detect_custom_size.exe.bad AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46 "((allocated_for_dlsym)) < ((kDlsymAllocPoolSize))" (0x421, 0x400) (tid=3485264) [hjl@gnu-skx-1 gcc]$ ls -l /export/build lrwxrwxrwx 1 hjl hjl 15 Dec 4 2018 /export/build -> users/hjl/build [hjl@gnu-skx-1 gcc]$ It is related to https://bugs.llvm.org/show_bug.cgi?id=33206
[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 Martin Sebor changed: What|Removed |Added Summary|[12 Regression] Waddress|[12 Regression] -Waddress |complaint in readelf.c |from macro expansion in ||readelf.c Keywords||patch --- Comment #5 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html
[Bug sanitizer/102911] AddressSanitizer: CHECK failed: asan_malloc_linux.cpp:46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102911 H.J. Lu changed: What|Removed |Added Last reconfirmed||2021-10-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- Also see: https://bugs.llvm.org/show_bug.cgi?id=52278
[Bug c/102909] Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909 --- Comment #2 from Iru Cai --- So it looks something like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 GCC thinks ``a`` is set but not used in ``a = 1 + b;``, but is used in ``a = 1; a += b;``.
[Bug c/102909] Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909 --- Comment #3 from Iru Cai --- Looks like this kind of things are detected in the front-end. The GNAT front-end can warn on the similar things: procedure Main is A : Integer; B : constant Integer := 1; begin A := 0; A := A + B; end Main; $ gcc -O2 -gnatwa -gnatwe -c main.adb main.adb:6:09: warning: possibly useless assignment to "A", value might not be referenced
[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102802 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #3 from TC --- No, this is valid. B's operator() is not visible, but its conversion to function pointer is, and that introduces a surrogate call function during the overload resolution for the function call expression (and it's selected because it is the only viable candidate).
[Bug testsuite/102910] cf-descriptor-5-c.c fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |testsuite Last reconfirmed||2021-10-24 Ever confirmed|0 |1 Version|unknown |12.0 --- Comment #2 from Andrew Pinski --- I think the following is better: #ifndef alloca #define alloca __builtin_alloca #endif Instead of the include of alloca.h.
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #4 from sandra at gcc dot gnu.org --- The problem noted in comment 1 looks related to PR 102641 -- automatically-inserted implicit initialization code can't cope with assumed-rank arrays. I tested the patch in comment 2 and saw a whole lot of regressions (ICEs). :-(
[Bug fortran/92701] ICE assigning to assumed rank derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- The testcase no longer ICEs on mainline head. Just mark this issue fixed, or would it be useful to identify what fixed it?
[Bug c/102909] Missing -Wunused-but-set-variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 44677. *** This bug has been marked as a duplicate of bug 44677 ***
[Bug c/44677] Warn for variables incremented but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44677 Andrew Pinski changed: What|Removed |Added CC||mytbk920423 at gmail dot com --- Comment #12 from Andrew Pinski --- *** Bug 102909 has been marked as a duplicate of this bug. ***
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 102909, which changed state. Bug 102909 Summary: Missing -Wunused-but-set-variable warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102909 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug demangler/102851] Failure to demangle c++ symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102851 --- Comment #1 from Andrew Pinski --- Do you have the C++ preprocessed source that produces this mangled symbol? The lambda part might be causing the difference between LLVM and GCC and such.
[Bug c++/102846] Misleading suggestion to include cassert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102846 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-24 --- Comment #2 from Andrew Pinski --- Confirmed, Clang message is even funnier: :15:21: error: use of undeclared identifier 'assert'; did you mean '__assert'?
