[Bug fortran/114535] New: ICE with elemental finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114535 Bug ID: 114535 Summary: ICE with elemental finalizer Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gcc dot gnu.org Target Milestone: --- The following code (which must be in two files to trigger the error) causes an ICE using the latest gfortran. $ cat ice1.F90 module iv type, public :: vs contains final :: destructor end type vs contains elemental subroutine destructor(s) type(vs), intent(inout) :: s end subroutine destructor end module iv $ cat ice2.F90 module d contains function en() result(dd) use :: iv type(vs) :: dd return end function en end module d module ni contains subroutine iss() use :: d return end subroutine iss end module ni $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools_Devel --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240330 (experimental) (GCC) $ gfortran -c ice1.F90 -o ice1.o $ gfortran -c ice2.F90 -o ice2.o ice2.F90:16:13: 16 | end module ni | 1 internal compiler error: in gfc_trans_call, at fortran/trans-stmt.cc:400 0x78ddb6 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc-git/gcc/fortran/trans-stmt.cc:400 0xaa8a1b trans_code ../../gcc-git/gcc/fortran/trans.cc:2431 0xb47c14 gfc_trans_simple_do ../../gcc-git/gcc/fortran/trans-stmt.cc:2521 0xb47c14 gfc_trans_do(gfc_code*, tree_node*) ../../gcc-git/gcc/fortran/trans-stmt.cc:2653 0xaa898a trans_code ../../gcc-git/gcc/fortran/trans.cc:2463 0xb485e9 gfc_trans_integer_select ../../gcc-git/gcc/fortran/trans-stmt.cc:3199 0xb485e9 gfc_trans_select(gfc_code*) ../../gcc-git/gcc/fortran/trans-stmt.cc:3692 0xaa8957 trans_code ../../gcc-git/gcc/fortran/trans.cc:2475 0xadd6fb gfc_generate_function_code(gfc_namespace*) ../../gcc-git/gcc/fortran/trans-decl.cc:7879 0xaadbf1 gfc_generate_module_code(gfc_namespace*) ../../gcc-git/gcc/fortran/trans.cc:2785 0xa5113d translate_all_program_units ../../gcc-git/gcc/fortran/parse.cc:7086 0xa5113d gfc_parse_file() ../../gcc-git/gcc/fortran/parse.cc:7413 0xaa546f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.cc:241 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. This only occurs if the FINAL subroutine is ELEMENTAL.
[Bug middle-end/114030] redundant load due to unions and different size loads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
--- Comment #3 from absoler at smail dot nju.edu.cn ---
(In reply to Andrew Pinski from comment #1)
> Reduced testcase:
> ```
> union U0 {
>int f2;
>char f4;
> };
>
> int g_3;
> union U0 g_34 = {-1L};
> char func_1() {
> int t11 = g_34.f2;
> char t1 = g_34.f4;
> g_3 = t11;
> return t1;
> }
> ```
>
> This is just due to unions. I am not sure if this is important to optimize
> really since techincally the original code is undefined by the C/C++
> standard (though GCC does an extension which makes it defined). Unions used
> in this way is not used much either.
reading different field of a union seems defined in C11 standard (maybe not in
C++11).
"If the member used to read the contents of a union object is not the same as
the member last used to store a value in the object, the appropriate part of
the object representation of the value is reinterpreted as an object
representation in the new type as described in 6.2.6 (a process sometimes
called ‘type punning’). This might be a trap representation."
[Bug c++/114210] Potential bug wrt __restrict on member function decl/def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210 --- Comment #3 from Sirraide --- Ah, that makes sense: it’s basically treated like any other top-level cv-qualifier on a function parameter—it’s just that it happens to syntactically be in an unusual place compared to cv-qualifiers on regular function parameters. Thanks for clarifying this.
[Bug c++/114210] Potential bug wrt __restrict on member function decl/def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210
--- Comment #2 from Andrew Pinski ---
Exactly like the following standard C23 code:
```
void nonrestirct();
void restirctcall();
void
foo (int* a, int* __restrict b, int n);
void
foo (int* a, int* b, int n)
{
typeof(b) c = b;
_Generic (&c ,
int * __restrict*: restirctcall(),
int **: nonrestirct()
); // calls nonrestirct
}
void
foo1 (int* a, int* b, int n);
void
foo1 (int* a, int* __restrict b, int n)
{
typeof(b) c = b;
_Generic (&c ,
int * __restrict*: restirctcall(),
int **: nonrestirct()
); // calls restirctcall
}
```
[Bug c++/114210] Potential bug wrt __restrict on member function decl/def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114210
--- Comment #1 from Andrew Pinski ---
Note the class method is similar to how normal functions work:
```
void
foo (int* __restrict b);
void
foo (int* b)
{
static_assert(__is_same(decltype(b), int*));
}
void
foo1 (int* b);
void
foo1 (int* __restrict b)
{
static_assert(__is_same(decltype(b), int*__restrict));
}
```
[Bug c/90181] Feature request: provide a way to explicitly select specific named registers in constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181 --- Comment #15 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647832.html
[Bug c++/97820] VLAs in function declarations fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97820 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=51352 --- Comment #2 from Andrew Pinski --- This might be a dup of bug 51352 .
[Bug c++/114534] Feature request: extend VLA support in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114534 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97820 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I think this is a dup of bug 51352 really. And/or PR 97820 too.
[Bug c++/114534] Feature request: extend VLA support in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114534 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=51352 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 51352 really.
[Bug c++/114534] Feature request: extend VLA support in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114534 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug middle-end/114532] gcc -fno-common option causes performance degradation on certain architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-30 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- ``` Rec_Pointer Ptr_Glob, Next_Ptr_Glob; int Int_Glob; Boolean Bool_Glob; charCh_1_Glob, Ch_2_Glob; int Arr_1_Glob [50]; int Arr_2_Glob [50] [50]; ``` Maybe the order of these changed in the layout of the final executable. In the case of -fcommon, the layout of these are handled by the linker while with -fno-common, they are handled by compiler into the assembly into the specific section (and then the sections are combined/laid out by the linker). So maybe look at the linker map and compare it to what GCC does with -fno-common in the .s file.
[Bug c++/114534] New: Feature request: extend VLA support in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114534
Bug ID: 114534
Summary: Feature request: extend VLA support in C++
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
See https://gcc.gnu.org/pipermail/gcc-help/2024-March/143369.html for
reference.
The documentation at https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html
states that VLAs are supported in C++ as an extension.
Compiling the following:
void f(int a, int b[a]);
void f() {
int c[2];
f(2, c);
}
with g++ -std=gnu++20 results in the error: "use of parameter outside function
body before ']' token". The docs say nothing about partial support of VLA,
just that they can be used.
Where this is useful as an extension is in the somewhat reasonable case of
including a C header in a C++ program. If that C header declares a function
using a C99 VLA, it would be awesome if g++ were to accept it in -std=gnu++
mode (and it would be fine if it were rejected in -std=c++ mode). Consider a
situation where you cannot modify the header, and so have to use it as-is.
For comparison, clang added support for this feature in version 12. It would
be advantageous to have feature parity given that it started as a GNU
extension. Moreover, better interoperability with C is useful in its own
right.
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #30 from Eric Gallager --- (In reply to Eric Gallager from comment #29) > (In reply to Alexander Monakov from comment #28) > > The bug is about the issue of lacking diagnostics, it should be fine to make > > note of various approaches to remedy the problem in one bug report. > > > > OK, well, in this case, I'd like to make this the bug report for MSan > support in general, too, then; it's documented here: > https://github.com/google/sanitizers/wiki/MemorySanitizer ...see also this wiki page, since GCC supports building with libc++ now: https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo ...although, be aware that it's outdated, as per this issue: https://github.com/google/sanitizers/issues/1685
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #29 from Eric Gallager --- (In reply to Alexander Monakov from comment #28) > The bug is about the issue of lacking diagnostics, it should be fine to make > note of various approaches to remedy the problem in one bug report. > OK, well, in this case, I'd like to make this the bug report for MSan support in general, too, then; it's documented here: https://github.com/google/sanitizers/wiki/MemorySanitizer (In reply to Martin Liška from comment #20) > (In reply to Jan Hubicka from comment #19) > > Martin, I suppose the sanitizer bits can be tracked as enhancement and not > > regression. It is a firefox bug so I suppose we can declare this a > > non-regression. > > Sure, maybe I would return to support of MSAN in GCC 7. Maybe for GCC 14 now?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #75 from Eric Gallager --- (In reply to Dominik Vogt from comment #25) > Looks better, but now we get this quite often: > > -- > ==23722==ERROR: Your kernel seems to be vulnerable to CVE-2016-2143. Using > ASa\ > n, > MSan, TSan, DFSan or LSan with such kernel can and will crash your > machine, or worse. > -- > > I'll try to figure out what kernel version we need. Why does this error message mention all of those sanitizers, when GCC only supports some of them?
[Bug middle-end/112844] Branches under -Os (unlike -O{1, 2, 3}) do not respect __builtin_expect hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112844 --- Comment #2 from Petr Skocik --- (In reply to Jakub Jelinek from comment #1) > With -Os you ask the code to be small. So, while internally the hint is > still present in edge probabilities, -Os is considered more important and > certain code changes based on the probabilities aren't done if they are > known or expected to result in larger code. Thanks. I very much like the codegen I get with gcc -Os, often better than what I get with clang. But the sometimes counter-obvious branch layout at -Os is annoying to me, especially considering I've measured it a couple of times as being the source of a slowdown. Sure you can save a (most-often-than not 2-byte) jump by conditionally jumping over an unlikely branch instead of conditionally jumping to an unlikely branch placed after ret and having it jump back in the function body (the latter is what all the other compilers do at -Os), but I'd rather have the code spend the extra two bytes and have my happy paths be fall-through as they should be.
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #11 from cqwrteur --- (In reply to cqwrteur from comment #10) > (In reply to Jonathan Wakely from comment #8) > > Comment on attachment 55135 [details] > > config > > > > configure:18893: checking fenv.h usability > > configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 > > -fno-exceptions conftest.cpp >&5 > > configure:18893: $? = 0 > > configure:18893: result: yes > > configure:18893: checking fenv.h presence > > configure:18893: i586-msdosdjgpp-c++ -E conftest.cpp > > configure:18893: $? = 0 > > configure:18893: result: yes > > configure:18893: checking for fenv.h > > configure:18893: result: yes > > > > This means configure is finding fenv.h in your sysroot. > > i586-msdosdjgpp-c++ should use i586-msdosdjgpp-gcc to test, not > i586-msdosdjgpp-c++ i think https://github.com/gcc-mirror/gcc/blob/6fc84f680d098f82c1c43435fdb206099f0df4df/libstdc%2B%2B-v3/configure#L19263 my guess is that it tries to use detect it by using the cross toolchain's libstdc++ fenv.h despite fenv.h does not exist. probably need to detect it with -nostdinc++??
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #10 from cqwrteur --- (In reply to Jonathan Wakely from comment #8) > Comment on attachment 55135 [details] > config > > configure:18893: checking fenv.h usability > configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 > -fno-exceptions conftest.cpp >&5 > configure:18893: $? = 0 > configure:18893: result: yes > configure:18893: checking fenv.h presence > configure:18893: i586-msdosdjgpp-c++ -E conftest.cpp > configure:18893: $? = 0 > configure:18893: result: yes > configure:18893: checking for fenv.h > configure:18893: result: yes > > This means configure is finding fenv.h in your sysroot. i586-msdosdjgpp-c++ should use i586-msdosdjgpp-gcc to test, not i586-msdosdjgpp-c++ i think
[Bug libstdc++/109926] fatal error: fenv.h: No such file or directory for canadian compilation of i586-msdosdjgpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109926 --- Comment #9 from cqwrteur --- (In reply to Jonathan Wakely from comment #8) > Comment on attachment 55135 [details] > config > > configure:18893: checking fenv.h usability > configure:18893: i586-msdosdjgpp-c++ -c -g -O2 -std=c++11 > -fno-exceptions conftest.cpp >&5 > configure:18893: $? = 0 > configure:18893: result: yes > configure:18893: checking fenv.h presence > configure:18893: i586-msdosdjgpp-c++ -E conftest.cpp > configure:18893: $? = 0 > configure:18893: result: yes > configure:18893: checking for fenv.h > configure:18893: result: yes > > This means configure is finding fenv.h in your sysroot. fenv.h is in libstdc++. not in libc. djgpp libc does not provide fenv.h
[Bug libquadmath/114533] New: libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
Bug ID: 114533
Summary: libquadmath: printf: fix misaligned access on args
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
reported at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647635.html
On x86, this compiles into movdqa which segfaults on unaligned access.
This kind of failure has been seen when running against glibc 2.39,
which incidentally changed the printf implementation to move away from
alloca() for this data to instead append it at the end of an existing
"scratch buffer", with arbitrary alignment, whereas alloca() was
probably more likely to be naturally aligned.
Tested by adding the patch to the Ubuntu gcc-14 package in
https://launchpad.net/~schopin/+archive/ubuntu/libquadmath
Signed-off-by: Simon Chopin
---
libquadmath/printf/printf_fp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libquadmath/printf/printf_fp.c b/libquadmath/printf/printf_fp.c
index 8effcee88fa..d86aa650d38 100644
--- a/libquadmath/printf/printf_fp.c
+++ b/libquadmath/printf/printf_fp.c
@@ -363,7 +363,7 @@ __quadmath_printf_fp (struct __quadmath_printf_file *fp,
/* Fetch the argument value. */
{
- fpnum = **(const __float128 **) args[0];
+ memcpy(&fpnum, *(void* const *) args[0], sizeof(fpnum));
/* Check for special values: not a number or infinity. */
if (isnanq (fpnum))
[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #10 from Mikael Morin --- (In reply to Paul Thomas from comment #9) > Hi Mikael, > > I have assigned the PR to you since you have fixed it on mainline. I presume > that you will backport? > Yes. I was initially targetting master only, but then I figured this was a regression, so backporting was in order.
[Bug c/114532] New: gcc -fno-common option causes performance degradation on certain architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 Bug ID: 114532 Summary: gcc -fno-common option causes performance degradation on certain architectures Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: h13958451065 at 163 dot com Target Milestone: --- gcc 10.3 has turnd off -fcommon into fno-common by default, which led to performance decrease about 7% (CPU intel sapphire rapids) on UnixBench dhry2reg subtest. We found that L1-dcache-load-misses increased under -fno-common option than -fcommon, which we suspect is the cause of the performance decrease. L1 dcache size is 48K per core in CPU intel sapphire rapids (32 KB instruction + 48 KB data). We have compared the binary layout of the executables generated under -fcommon and -fno-common, we found that the location offset of XXX_Time and XXX_Glob global variables in BSS section increased about 10K under -fno-common. Maybe the increase of bss gap influence the probability of L1-dcache-load-miss. I am not sure about this conclusion, is there any way to verify our conjecture?
[Bug rtl-optimization/78664] LRA must honor REG_ALLOC_ORDER to pick reload registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78664 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Eric Botcazou --- .
[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- Hi Mikael, I have assigned the PR to you since you have fixed it on mainline. I presume that you will backport? Regards Paul
[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #9 from Paul Thomas --- (In reply to Paul Thomas from comment #8) > Created attachment 57835 [details] > An alternative fix for the PR > > Hi Tomas, > > Would you prefer the compiler to give warning rather than letting the > possible recursion to pass by silently? > > f951: Warning: Non-RECURSIVE procedure ‘newcopyother’ from module > ‘ftldynarrayintmodule’ is possibly calling itself recursively in procedure > ‘newcopyother’. Declare it RECURSIVE or use ‘-frecursive’ > > Cheers > > Paul After reflection, I have answered the question myself. The other part of the patch in resolve.cc should ensure that the recursion is detected in the module compilation. Paul
