[Bug target/89835] The RISC-V target uses amoswap.w for relaxed stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89835 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk and presumably the last gcc-13 point release.
[Bug libstdc++/84568] libstdc++-v3 configure checks for atomic operations fail on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jeffrey A. Law --- Per c#13 and c#14.
[Bug target/113742] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p600-se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jeffrey A. Law --- Per c#4.
[Bug sanitizer/59748] ptrace isn't instrumented on at least arm-linux-gnueabihf and powerpc-linux.gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59748 --- Comment #2 from Andrew Pinski --- I didn't see an issue filed upstream (neither https://github.com/google/sanitizers nor https://github.com/llvm/llvm-project/issues ). Has one been filed and has this since been fixed?
[Bug target/114544] [x86] stv should transform (subreg DI (V1TI) 8) as (vec_select:DI (V2DI) (const_int 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544 --- Comment #3 from Hongtao Liu --- <__umodti3>: ... 37 58: 66 48 0f 6e c7 movq %rdi,%xmm0 38 5d: 66 48 0f 6e d6 movq %rsi,%xmm2 39 62: 66 0f 6c c2 punpcklqdq %xmm2,%xmm0 40 66: 0f 29 44 24 f0 movaps %xmm0,-0x10(%rsp) 41 6b: 48 8b 44 24 f0 mov-0x10(%rsp),%rax 42 70: 48 8b 54 24 f8 mov-0x8(%rsp),%rdx 43 75: 5b pop%rbx 44 76: c3 ret Look like the misoptimization is also in __umodti3.
[Bug c++/114632] ICE with explicit this in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114632 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/114632] New: ICE with explicit this in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114632
Bug ID: 114632
Summary: ICE with explicit this in lambda
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruck.michael at gmail dot com
Target Milestone: ---
struct S {};
auto lambda = [](this auto& self, const int x) {};
int main()
{
void (*func)(S&, int) = lambda;
return 0;
}
https://gcc.godbolt.org/z/3aW1be8PG
: In substitution of 'template constexpr::operator decltype ((static_cast(self), static_cast(x))) (*)(auto:1&,
int)() const [with auto:1 = S]':
:7:29: required from here
7 | void (*func)(S&, int) = lambda;
| ^~
:3:15: internal compiler error: Segmentation fault
3 | auto lambda = [](this auto& self, const int x) {};
| ^
0x26743fc internal_error(char const*, ...)
???:0
0xc9db80 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9d2c8 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9d032 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc9d2c8 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xc85143 instantiate_template(tree_node*, tree_node*, int)
???:0
0xcb76d5 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0xa8e3bf can_convert_arg_bad(tree_node*, tree_node*, tree_node*, int, int)
???:0
0xd38ca0 store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0xb4618e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int,
cp_decomp*)
???:0
0xc5b3ea c_parse_file()
???:0
0xdaf8b9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/57037] GCC does not generate non-temporal stores on i386 with SSE2+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57037
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
GCC has a heustrics for deciding on non-temporal stores or not (when used with
-fprefetch-loop-arrays) but it is hard not hit it sometimes.
Anyways closing as invalid as we do have 2 testcases in the testsuite that
detects nontemporal stores, gcc.dg/tree-ssa/prefetch-{8,9}.c and they still
pass.
[Bug testsuite/114614] New test case gcc.misc-tests/gcov-20.c from r14-9789-g08a52331803f66 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114614 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed||2024-04-08 CC||linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- It requires effective target profile_update_atomic.
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #22 from GCC Commits --- The master branch has been updated by LuluCheng : https://gcc.gnu.org/g:8f0ff6b998748f3581e0f06e3108193866b1209d commit r14-9824-g8f0ff6b998748f3581e0f06e3108193866b1209d Author: Lulu Cheng Date: Tue Apr 2 14:29:08 2024 +0800 LoongArch: Set default alignment for functions jumps and loops [PR112919]. Xi Ruoyao set the alignment rules under LA464 in commit r14-1839, but the macro ASM_OUTPUT_ALIGN_WITH_NOP was removed in R14-4674, which affected the alignment rules. So I set different aligns on LA464 and LA664 again to test the performance of spec2006, and modify the alignment based on the test results. gcc/ChangeLog: PR target/112919 * config/loongarch/loongarch-def.cc (la664_align): Newly defined function that sets alignment rules under the LA664 microarchitecture. * config/loongarch/loongarch-opts.cc (loongarch_target_option_override): If not optimizing for size, set the default alignment to what the target wants. * config/loongarch/loongarch-tune.h (struct loongarch_align): Add new member variables jump and loop.
[Bug target/60157] adding -mstrict-align for i386 and x86_64 architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60157 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- >-mstrict-align Will not help in this case really as GCC does not warn. Note clang does warn with -mstrict-align though: ``` :15:18: warning: field C within 'cond_mutex_t' is less aligned than 'pthread_cond_t' and is usually due to 'cond_mutex_t' being packed, which can lead to unaligned accesses [-Wunaligned-access] 15 | pthread_cond_t C; | ^ ``` But I suspect GCC should warn even without strict alignment really.
[Bug other/44414] hashtab.h functions are undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |4.6.0 Keywords||internal-improvement Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- (In reply to Rainer Orth from comment #2) > This is not proper documentation: most part of libiberty use comments which > can be extracted and put into the .texi files, while hashtab.c does not. This was fixed with r0-100573-ga9429e29f506f5, 4 days after this bug report was filed :).
[Bug c++/114631] Inconsistent behavior with infinite loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114631 --- Comment #4 from Andrew Pinski --- (In reply to Ganton from comment #3) > When that page (https://bugreports.qt.io/browse/QTBUG-33026) was written, > the behavior of GCC was not like the described in this bug report (because > the `for (doub = [...]` infinite loop was always taken into account). Do we > have a regression? 樂 No, the removal of loops which cannot prove being finite was added in GCC 10 (which was released in 2020) while the issue you pointed to was written up in 2013 which was GCC 4.8.x timeframe. In this case C++ standard has not changed, just GCC started to optimize more based on what the standard says is allowed.
[Bug c++/114631] Inconsistent behavior with infinite loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114631 --- Comment #3 from Ganton --- Note: That code was initially aimed for `decimal32` testing (https://bugreports.qt.io/browse/QTBUG-33026) because using `decimal32` instead of `double`... the `for (doub = [...]` loop is not infinite. When that page (https://bugreports.qt.io/browse/QTBUG-33026) was written, the behavior of GCC was not like the described in this bug report (because the `for (doub = [...]` infinite loop was always taken into account). Do we have a regression? 樂 Keep up the good work! Thanks a lot for GCC!
[Bug middle-end/93041] GCC 10 removes an infinite loop and causes a null pointer to dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 Andrew Pinski changed: What|Removed |Added CC||kubry at gmx dot com --- Comment #10 from Andrew Pinski --- *** Bug 114631 has been marked as a duplicate of this bug. ***
[Bug c++/114631] Inconsistent behavior with infinite loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114631 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- So the C++ standard requires forward progress, otherwise it is undefined behavior (except if the condition is a constant expression which evaluates to true [See https://wg21.link/P2809R3]) . *** This bug has been marked as a duplicate of bug 93041 ***
[Bug c++/114631] Inconsistent behavior with infinite loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114631 --- Comment #1 from Ganton --- Maybe this can be useful: "if we remove the `std::cout << doub << " ";` line... the program stops"... does that happen because an "aggressive"(?樂) optimization is made (without warning the user)? If we add a `for(;;);` after the `double doub;` line, then the program never stops. If an "aggressive"(?樂) optimization is made, why is made for one loop but not for the other loop? Is that inconsistent?
[Bug c++/114631] New: Inconsistent behavior with infinite loops?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114631
Bug ID: 114631
Summary: Inconsistent behavior with infinite loops?
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kubry at gmx dot com
Target Milestone: ---
Dear GCC developers,
First of all, thanks for your work!
This programs works as it is expected (it never stops):
```
#include
int main()
{
double doub;
// This line caused a «warning: comparing floating point with == or != is
unsafe [-Wfloat-equal]»
for (doub = 1.1; doub != 1.5; doub = doub + 0.1)
{
std::cout << doub << " ";
}
// "doubles" are not good enough for this program, the program should not
arrive there
std::cout << "double is ok." << std::endl;
}
```
however, if we remove the `std::cout << doub << " ";` line... the program stops
(!).
[Bug target/114544] [x86] stv should transform (subreg DI (V1TI) 8) as (vec_select:DI (V2DI) (const_int 1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114544 Roger Sayle changed: What|Removed |Added Last reconfirmed||2024-04-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||roger at nextmovesoftware dot com
[Bug tree-optimization/99395] s116 benchmark of TSVC is vectorized by clang and not by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 --- Comment #10 from Nick Begg --- Testcase created in PR114630... Thanks
[Bug c++/114630] New: [modules] building module with submodule causes corrupt gcm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630 Bug ID: 114630 Summary: [modules] building module with submodule causes corrupt gcm Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nickbegg at gmail dot com Target Milestone: --- Building module code with a submodule produces - failed to load pendings for ‘std::__format::__formatter_int’ This is similar to PR99426. Using test code very similar to PR113930 and PR114229. this is compiling with a trunk debug gcc, with the patch proposed for PR99426 applied. % /home/nick/inst/gcc-trunk-debug/bin/g++ --version g++ (GCC) 14.0.1 20240405 (experimental) Test code - // modA.mpp module; #include export module modA; import modB; // modB.mpp module; #include export module modB; // main.cpp #include import modA; // Compiling trips over when loading modA when compiling main.cpp. Output - modB.mpp: /home/nick/inst/gcc-trunk-debug/bin/g++ -g -std=gnu++23 -Wall -Wextra -freport-bug --param=ggc-min-expand=1 -MD -MT CMakeFiles/moduleMin.dir/modB.mpp.o -MF CMakeFiles/moduleMin.dir/modB.mpp.o.d -fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/modB.mpp.o.modmap -MD -fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/modB.mpp.o -c /home/nick/src/moduleMin/modB.mpp modA.mpp: /home/nick/inst/gcc-trunk-debug/bin/g++ -g -std=gnu++23 -Wall -Wextra -freport-bug --param=ggc-min-expand=1 -MD -MT CMakeFiles/moduleMin.dir/modA.mpp.o -MF CMakeFiles/moduleMin.dir/modA.mpp.o.d -fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/modA.mpp.o.modmap -MD -fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/modA.mpp.o -c /home/nick/src/moduleMin/modA.mpp main.cpp: /home/nick/inst/gcc-trunk-debug/bin/g++ -g -std=gnu++23 -Wall -Wextra -freport-bug --param=ggc-min-expand=1 -MD -MT CMakeFiles/moduleMin.dir/main.cpp.o -MF CMakeFiles/moduleMin.dir/main.cpp.o.d -fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/main.cpp.o.modmap -MD -fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/main.cpp.o -c /home/nick/src/moduleMin/main.cpp In module imported at /home/nick/src/moduleMin/main.cpp:3:1: modA: error: failed to read compiled module cluster 3008: Bad file data modA: note: compiled module file is ‘CMakeFiles/moduleMin.dir/modA.gcm’ modA: error: failed to read compiled module cluster 3009: Bad file data In file included from /home/nick/src/moduleMin/main.cpp:1: /home/nick/inst/gcc-trunk-debug/include/c++/14.0.1/format:1899:35: fatal error: failed to load pendings for ‘std::__format::__formatter_int’ 1899 | return _M_f._M_parse(__pc); |~~~^~ compilation terminated.
[Bug middle-end/114628] ICE with _BitInt with computed gotos with returns_twice and -g and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628
Andrew Pinski changed:
What|Removed |Added
Summary|[14 Regression] ICE in |ICE with _BitInt with
|gimple_check_failed at |computed gotos with
|gimple.cc:1337 while|returns_twice and -g and
|compiling bitint-100.c |optimization
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-04-07
Target Milestone|14.0|---
--- Comment #1 from Andrew Pinski ---
Confirmed, ICEs with just `-O1 -g`.
Reduced testcase:
```
int foo (int);
__attribute__((returns_twice)) int
bar (_BitInt(129) x);
void
corge (int x, _BitInt(129) y)
{
void *q[] = { &, & };
l2:
x = foo (foo (3));
bar (y);
#if 1
goto *q[x & 1];
#endif
l1:
}
```
Note we get 2 difference ICEs depending on if `#if ` is 1 or 0.
It seems like it would be useful if some more torture tests for _BitInt were
included so `-g` gets a little more testing.
[Bug fortran/106317] deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.5.0, 11.4.1, 12.3.0, ||13.2.0 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org Known to work||14.0 Keywords||wrong-code --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed to fail on 13-branch at r13-7813, but working at r13-8592. Also 14-mainline is ok, so must have been fixed there and backported, possibly as r13-7986.
[Bug rust/114629] rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-04-07
Status|UNCONFIRMED |NEW
Keywords||diagnostic
--- Comment #1 from Andrew Pinski ---
Confirmed.
else if (funny_error)
{
/* This was a "break rust" or "break gcc", and the identifier failed to
resolve. Emit a funny ICE. We set the finalizer to our custom one,
and use the lower-level emit_diagnostic () instead of the more common
internal_error_no_backtrace () in order to pass our locus. */
diagnostic_finalizer (global_dc) = funny_ice_finalizer;
emit_diagnostic (DK_ICE_NOBT, expr.get_locus (), -1,
"are you trying to break %s? how dare you?",
expr.as_string ().c_str ());
This is not even that funny.
I suggest to remove the idea of funny_error really.
if (ident == "rust" || ident == "gcc")
funny_error = true;
...
[Bug libfortran/113897] Consecutive tab and/or nX edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Jerry DeLisle changed: What|Removed |Added CC||urbanjost at comcast dot net --- Comment #3 from Jerry DeLisle --- *** Bug 114618 has been marked as a duplicate of this bug. ***
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Jerry DeLisle changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jerry DeLisle --- It is a duplicate of 113897 which I am still workimng on as i get time. *** This bug has been marked as a duplicate of bug 113897 ***
[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2024-04-07
--- Comment #1 from Jerry DeLisle ---
Here is a fix. It wiggles on about 5 test cases that will need to be adjusted.
diff --git a/gcc/fortran/io.cc b/gcc/fortran/io.cc
index 6fd69f7c9a8..e6a5144b028 100644
--- a/gcc/fortran/io.cc
+++ b/gcc/fortran/io.cc
@@ -1129,12 +1129,10 @@ data_desc:
break;
case FMT_H:
- if (!(gfc_option.allow_std & GFC_STD_GNU) && !inhibit_warnings)
+ if (!gfc_notify_std (GFC_STD_F95_DEL, "H format specifier at %C"))
{
if (mode != MODE_FORMAT)
format_locus.nextc += format_string_pos;
- gfc_warning (0, "The H format specifier at %L is"
- " a Fortran 95 deleted feature", _locus);
}
if (mode == MODE_STRING)
{
[Bug fortran/114626] Very long time for compilation the attached program, depends on value of a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97571 Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Note that pack( [ (k, k = 1,max_sum)], & [ ( count( [((i**3+j**3, i = 1,j), j = 1,max_ij)] == k ) > 1, k = 1,max_sum )] ) is a constant expression that the frontend tries to simplify at compile time. I assume that most of the time goes into handling of the array constructors. There's no limit implemented that checks the complexity of such expressions and to give up if that limit is reached. An expression like the above could occur in a parameter definition, and a limit then might terminate the compilation with an error. Fortunately, you've already found a workaround. For a related PR see pr97571.
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Backported to all open branches. Closing.
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:619fc13043c86d616ef57cb31f8ac5d29b059ade commit r11-11311-g619fc13043c86d616ef57cb31f8ac5d29b059ade Author: Harald Anlauf Date: Wed Mar 27 21:18:04 2024 +0100 Fortran: fix DATA and derived types with pointer components [PR114474] When matching actual arguments in match_actual_arg, these are initially treated as a possible dummy procedure, assuming that the correct type is determined later. This resolution could fail when the procedure is a derived type constructor with a pointer component and appears in a DATA statement, where the pointer shall be associated with an initial data target. Check for those cases where the type obviously has not been resolved yet, and which were missed because there was no component reference. gcc/fortran/ChangeLog: PR fortran/114474 * primary.c (gfc_variable_attr): Catch variables used in structure constructors within DATA statements that are still tagged with a temporary type BT_PROCEDURE from match_actual_arg and which have the target attribute, and fix their typespec. gcc/testsuite/ChangeLog: PR fortran/114474 * gfortran.dg/data_pointer_3.f90: New test. (cherry picked from commit bbb7c513dddc5c9b2d5e9b78bc1c2f85a0cfe07e)
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:88abe04de2f16f773126f3908632a27568330cc9 commit r12-10314-g88abe04de2f16f773126f3908632a27568330cc9 Author: Harald Anlauf Date: Wed Mar 27 21:18:04 2024 +0100 Fortran: fix DATA and derived types with pointer components [PR114474] When matching actual arguments in match_actual_arg, these are initially treated as a possible dummy procedure, assuming that the correct type is determined later. This resolution could fail when the procedure is a derived type constructor with a pointer component and appears in a DATA statement, where the pointer shall be associated with an initial data target. Check for those cases where the type obviously has not been resolved yet, and which were missed because there was no component reference. gcc/fortran/ChangeLog: PR fortran/114474 * primary.cc (gfc_variable_attr): Catch variables used in structure constructors within DATA statements that are still tagged with a temporary type BT_PROCEDURE from match_actual_arg and which have the target attribute, and fix their typespec. gcc/testsuite/ChangeLog: PR fortran/114474 * gfortran.dg/data_pointer_3.f90: New test. (cherry picked from commit bbb7c513dddc5c9b2d5e9b78bc1c2f85a0cfe07e)
[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114474 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0d4862691d2b58f7bd2d58de0e78bc574c313d39 commit r13-8592-g0d4862691d2b58f7bd2d58de0e78bc574c313d39 Author: Harald Anlauf Date: Wed Mar 27 21:18:04 2024 +0100 Fortran: fix DATA and derived types with pointer components [PR114474] When matching actual arguments in match_actual_arg, these are initially treated as a possible dummy procedure, assuming that the correct type is determined later. This resolution could fail when the procedure is a derived type constructor with a pointer component and appears in a DATA statement, where the pointer shall be associated with an initial data target. Check for those cases where the type obviously has not been resolved yet, and which were missed because there was no component reference. gcc/fortran/ChangeLog: PR fortran/114474 * primary.cc (gfc_variable_attr): Catch variables used in structure constructors within DATA statements that are still tagged with a temporary type BT_PROCEDURE from match_actual_arg and which have the target attribute, and fix their typespec. gcc/testsuite/ChangeLog: PR fortran/114474 * gfortran.dg/data_pointer_3.f90: New test. (cherry picked from commit bbb7c513dddc5c9b2d5e9b78bc1c2f85a0cfe07e)
[Bug rust/114629] New: rust-ast-resolve-expr contains bloated code for funny_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114629 Bug ID: 114629 Summary: rust-ast-resolve-expr contains bloated code for funny_error Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- The file contains funny_error, which unnecessarily bloats the executable in all installations. That's a waste of resources. The identifier funny_error should be removed, including everything that depends on it. (Background: As the German translator of GCC, I strictly oppose against insulting the GCC users, therefore I have translated that message free of any humor. There's enough code bloat already, I consider this one unnecessary.)
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 --- Comment #9 from Patrick Palka --- Huh, interesting! If --param=ggc-min-expand=1 doesn't help then it's most likely a distinct bug. A testcase would be much appreciated if possible.
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426 --- Comment #8 from Nick Begg --- I've been testing with the proposed patch, and I am still getting the same errors.. /home/nick/inst/gcc-trunk-debug/bin/g++ -g -std=gnu++23 -Wall -Wextra -freport-bug --param=ggc-min-expand=1 -MD -MT CMakeFiles/moduleMin.dir/main.cpp.o -MF CMakeFiles/moduleMin.dir/main.cpp.o.d -fmodules-ts -fmodule-mapper=CMakeFiles/moduleMin.dir/main.cpp.o.modmap -MD -fdeps-format=p1689r5 -x c++ -o CMakeFiles/moduleMin.dir/main.cpp.o -c /home/nick/src/moduleMin/main.cpp In module imported at /home/nick/src/moduleMin/main.cpp:3:1: modA: error: failed to read compiled module cluster 3000: Bad file data modA: note: compiled module file is ‘CMakeFiles/moduleMin.dir/modA.gcm’ modA: error: failed to read compiled module cluster 3001: Bad file data In file included from /home/nick/src/moduleMin/main.cpp:1: /home/nick/inst/gcc-trunk-debug/include/c++/14.0.1/format:1899:35: fatal error: failed to load pendings for ‘std::__format::__formatter_int’ 1899 | return _M_f._M_parse(__pc); |~~~^~ compilation terminated. I'm not sure if this is the same bug, or if I've uncovered a similar but distinct bug... Various values of --param=ggc-min-expand don't seem to make a difference.
[Bug rtl-optimization/113017] ICE in delete_unmarked_insns, at dce.cc:653 while compiling gfortran.dg/inline_matmul_9.f90 for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113017 Filip Kastl changed: What|Removed |Added Summary|ICE in |ICE in |delete_unmarked_insns, at |delete_unmarked_insns, at |dce.cc:653 |dce.cc:653 while compiling ||gfortran.dg/inline_matmul_9 ||.f90 for aarch64 --- Comment #1 from Filip Kastl --- Also happens with LLVM testcase flang/test/Lower/HLFIR/conversion-ops.f90 aarch64-linux-gnu-gfortran /home/worker/llvm/src/flang/test/Lower/HLFIR/conversion-ops.f90 -Oz -fschedule-insns -fharden-control-flow-redundancy -fnon-call-exceptions and with GCC testsuite testcase gfortran.dg/typebound_operator_15.f90 aarch64-linux-gnu-gfortran /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/typebound_operator_15.f90 -fno-gcse -fharden-control-flow-redundancy -flive-patching=inline-clone -O2 -fnon-call-exceptions
[Bug middle-end/114628] [14 Regression] ICE in gimple_check_failed at gimple.cc:1337 while compiling bitint-100.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628 Filip Kastl changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/114628] New: [14 Regression] ICE in gimple_check_failed at gimple.cc:1337 while compiling bitint-100.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114628 Bug ID: 114628 Summary: [14 Regression] ICE in gimple_check_failed at gimple.cc:1337 while compiling bitint-100.c Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu While compiling the gcc.dg/bitint-100.c testsuite testcase gcc src/gcc/testsuite/gcc.dg/bitint-100.c -fvar-tracking-assignments-toggle the following ICE occurs during GIMPLE pass: bitintlower0 src/gcc/testsuite/gcc.dg/bitint-100.c: In function ‘corge’: src/gcc/testsuite/gcc.dg/bitint-100.c:44:1: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_debug() in gimple_assign_lhs, at gimple.h:2663 44 | corge (int x, _BitInt(575) y, _BitInt(325) *z) | ^ 0x74f67a gimple_check_failed(gimple const*, char const*, int, char const*, gimple_code, tree_code) /home/fkastl/gcc/src/gcc/gimple.cc:1337 0x1f50114 gassign const* GIMPLE_CHECK2(gimple const*, char const*, int, char const*) /home/fkastl/gcc/src/gcc/gimple.h:74 0x1f50114 gimple_assign_lhs(gimple const*) /home/fkastl/gcc/src/gcc/gimple.h:2663 0x1f50114 gimple_lower_bitint /home/fkastl/gcc/src/gcc/gimple-lower-bitint.cc:7195 Compiler configuration (nothing special there I believe): Reading specs from /home/fkastl/gcc/build/gcc/specs COLLECT_GCC=/home/fkastl/gcc/build/gcc/xgcc COLLECT_LTO_WRAPPER=/home/fkastl/gcc/build/gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/fkastl/gcc/src/configure --disable-bootstrap --enable-checking --disable-libsanitizer --prefix=/home/fkastl/gcc/inst --enable-languages=c Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240405 (experimental) (GCC)
[Bug middle-end/114627] [14 Regression] undefined behavior in tree-profile.cc while compiling gcc.misc-tests/gcov-18.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627 Filip Kastl changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/114627] New: [14 Regression] undefined behavior in tree-profile.cc while compiling gcc.misc-tests/gcov-18.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114627 Bug ID: 114627 Summary: [14 Regression] undefined behavior in tree-profile.cc while compiling gcc.misc-tests/gcov-18.c Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Compiling gcc.misc-tests/gcov-19.c using ubsan-instrumented GCC gcc testsuite/gcc.misc-tests/gcov-19.c -fdiagnostics-plain-output -fcondition-coverage -ftest-coverage -lm -o ./gcov-19.exe results in /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/tree-profile.cc:1090:48: runtime error: shift exponent 64 is too large for 64-bit type 'long long unsigned int' Compiler configured with --enable-languages=default,jit,lto,go,d --enable-host-shared --enable-checking=release --disable-multilib --with-build-config=bootstrap-ubsan Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c++/114625] requires { T{}; } wrongly accepted when T{} is ill-formed while in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-07 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug fortran/114626] New: Very long time for compilation the attached program, depends on value of a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114626 Bug ID: 114626 Summary: Very long time for compilation the attached program, depends on value of a parameter Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arjen.markus895 at gmail dot com Target Milestone: --- Created attachment 57894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57894=edit Source of the program causing the very long compile time The attached program causes the gfortran compiler to take a very long time if the parameter max_ij is set to 100. It may not even finish. If the parameter is set to 13 (to at least give one result), it takes a few seconds but at least finishes in a reasonable time. This is with default compile options. I have not tried specific options. (Note: it is a silly program, meant for demonstration only.)
[Bug c++/114625] requires { T{}; } wrongly accepted when T{} is ill-formed while in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
Ted Lyngmo changed:
What|Removed |Added
Summary|requires { T{}; } wrongly |requires { T{}; } wrongly
|accepted when T{} is|accepted when T{} is
|ill-formed |ill-formed while in concept
CC||ted at lyncon dot se
--- Comment #1 from Ted Lyngmo ---
The assertion correctly fails with this though:
```
static_assert(requires { d{}; });
```
[Bug c++/114625] New: requires { T{}; } wrongly accepted when T{} is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114625
Bug ID: 114625
Summary: requires { T{}; } wrongly accepted when T{} is
ill-formed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ted at lyncon dot se
Target Milestone: ---
This program compiles but I'd expect both `static_assert`s to refuse it since
`d x{};` is invalid.
```
#include
template
concept default_initializable =
std::constructible_from &&
requires { T{}; } &&
requires { ::new T; };
struct b { explicit b(auto...) {} };
struct d : b {};
int main() {
static_assert(default_initializable);
static_assert(std::default_initializable);
//d x{}; // ERROR
}
```
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Target Milestone|12.4|---
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Xi Ruoyao --- I misunderstood the last change and this is not fixed: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648921.html
[Bug tree-optimization/114624] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624 Andrew Pinski changed: What|Removed |Added Keywords|ice-checking| --- Comment #2 from Andrew Pinski --- Removing `ice-checking` because you can get it to crash even without checking enabled.
[Bug tree-optimization/114624] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-04-07 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. It does not ICE with `-fno-checking` but does also ICE with `-fdump-tree-sccp-lineno` too; it also crashes with -g (though later on). I think it is crashing on: ``` d_9 = d_30; ``` statement.
[Bug tree-optimization/114624] [14 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at -O3 on |[14 Regression] ICE on |x86_64-linux-gnu: |valid code at -O3 on |Segmentation fault |x86_64-linux-gnu: ||Segmentation fault Keywords||needs-bisection Target Milestone|--- |14.0 Version|unknown |14.0 Component|middle-end |tree-optimization
[Bug middle-end/114624] New: ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114624
Bug ID: 114624
Summary: ICE on valid code at -O3 on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
Compiler Explorer: https://godbolt.org/z/neef45W14
[516] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240405 (experimental) (GCC)
[517] %
[517] % gcctk -O3 small.c
during GIMPLE pass: sccp
small.c: In function ‘main’:
small.c:2:5: internal compiler error: Segmentation fault
2 | int main() {
| ^~~~
0x116b653 crash_signal
../../gcc-trunk/gcc/toplev.cc:319
0x7fe51d50a08f ???
/build/glibc-wuryBv/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x249ec06 get_data_from_adhoc_loc(line_maps const*, unsigned int)
../../gcc-trunk/libcpp/line-map.cc:297
0x11b8216 verify_location
../../gcc-trunk/gcc/tree-cfg.cc:5384
0x11bc50f verify_gimple_in_cfg(function*, bool, bool)
../../gcc-trunk/gcc/tree-cfg.cc:5600
0x10292b4 execute_function_todo
../../gcc-trunk/gcc/passes.cc:2089
0x1029c0e execute_todo
../../gcc-trunk/gcc/passes.cc:2143
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/90905] missing -Wreturn-local-addr returning a local std::string::c_str()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90905
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2020-01-28 00:00:00 |2024-4-7
--- Comment #10 from Andrew Pinski ---
Note changing:
```
const char *p = "def";
```
To:
```
static const char *p = "def";
```
we do warn though.
But increasing the size like:
```
static const char *p = "def123123123123123123123123123123";
```
We don't warn.
With the larger size we get:
```
operator delete (_8, _12);
[local count: 1073741824]:
str ={v} {CLOBBER(eob)};
str ={v} {CLOBBER(eos)};
return _8;
```
Which is not exactly a `-Wreturn-local-addr` warning but rather a
`-Wuse-after-free` warning.
