[Bug fortran/93678] [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #15 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c058105bc47a0701e157d1028e60f48554561f9f commit r14-10116-gc058105bc47a0701e157d1028e60f48554561f9f Author: Paul Thomas Date: Thu Apr 25 06:56:10 2024 +0100 Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678] 2024-04-25 Paul Thomas gcc/fortran PR fortran/93678 * trans-expr.cc (gfc_conv_procedure_call): Use the interface, where possible, to obtain the type of character procedure pointers of class entities. gcc/testsuite/ PR fortran/93678 * gfortran.dg/pr93678.f90: New test.
[Bug fortran/89462] [11/12/13/14 Regression] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 --- Comment #14 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:1fd5a07444776d76cdd6a2eee7df0478201197a5 commit r14-10115-g1fd5a07444776d76cdd6a2eee7df0478201197a5 Author: Paul Thomas Date: Thu Apr 25 06:52:31 2024 +0100 Fortran: Generate new charlens for shared symbol typespecs [PR89462] 2024-04-25 Paul Thomas Jakub Jelinek gcc/fortran PR fortran/89462 * decl.cc (build_sym): Add an extra argument 'elem'. If 'elem' is greater than 1, gfc_new_charlen is called to generate a new charlen, registered in the symbol namespace. (variable_decl, enumerator_decl): Set the new argument in the calls to build_sym. gcc/testsuite/ PR fortran/89462 * gfortran.dg/pr89462.f90: New test.
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 --- Comment #5 from Richard Biener --- (In reply to Richard Biener from comment #4) > Created attachment 58024 [details] > patch > > I quickly tried this which works for the testcase but I'm sure it'll break > quickly. during GIMPLE pass: cunrolli ../../../../gcc/libgcc/soft-fp/floatsitf.c: In function '__floatsitf': ../../../../gcc/libgcc/soft-fp/floatsitf.c:34:1: internal compiler error: in unloop_loops, at tree-ssa-loop-ivcanon.cc:721 34 | __floatsitf (SItype i) | ^~~ 0x76cde9 _start ../sysdeps/x86_64/start.S:120 Please submit a full bug report, with preprocessed source (by using -freport-bug).
[Bug target/98140] Reused register by xsmincdp leads to wrong NaN propagation on Power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98140 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #2 from Jiu Fu Guo --- (In reply to Alexander Grund from comment #1) > It looks like this was fixed in 10.1 by this commit > https://github.com/gcc-mirror/gcc/commit/ > 37e0df8a9be5a8232f4ccb73cdadb02121ba523f ... > `HONOR_NANS (compare_mode)` case. However it still ignores signed zeros. 'xsmincdp' may be fine for zeros, it seems '!HONOR_SIGNED_ZEROS' is not needed. > Maybe xsmindp would be a better fit as it preserves the signed zeros. Only > downside I see is that it converts sNan to qNan which may be an issue.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Kewen Lin --- Should be fixed on trunk and active release branches.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #10 from GCC Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:02f1b5361188c9d833cef39caf723d31d44ba5d5 commit r11-11363-g02f1b5361188c9d833cef39caf723d31d44ba5d5 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.c (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.c (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test. (cherry picked from commit 26eb5f8fd173e2425ae7505528fc426de4b7e34c)
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:43c8cb0e003996b3a7a9f98923f602561f3f0ec7 commit r12-10393-g43c8cb0e003996b3a7a9f98923f602561f3f0ec7 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.cc (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a9f174f01f25fa6df989707dc2fec29ef78aad24 commit r13-8646-ga9f174f01f25fa6df989707dc2fec29ef78aad24 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.cc (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test.
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 --- Comment #4 from Abe --- Anybody who wants to chime in, but especially Eric Gallager: please let me know whether or not my patch looks good enough for submission to the gcc-patches mailing list, and if not then _why_ not [please].
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 --- Comment #3 from Abe --- Created attachment 58032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58032=edit patch for VAX messages, including localization Squashed patch based on my local Git for this PR.
[Bug target/79646] Typos in vax.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79646 Abe changed: What|Removed |Added CC||abe_skolnik at yahoo dot com --- Comment #2 from Abe --- I fixed the English as indicated, then did my best with the language translations. In at least one case [Dutch], where the translation was empty before, I left it empty. In at least one case [Greek], where the translation was empty before, I filled it in.
[Bug target/112304] cinc is not being used for (small) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112304 --- Comment #5 from Andrew Pinski --- Created attachment 58031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58031=edit Patch which I am testing Once testing is finished and GCC 15 stage 1 opens up, I will submit this.
[Bug target/112304] cinc is not being used for (small) constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112304
--- Comment #4 from Andrew Pinski ---
Note my patch does not change the fact that we don't pull the mov outside of
the loop for:
```
void f(int *a, int l)
{
for(int i = 0; i < l; i++)
a[i]=(a[i]!=0)+42;
}
```
But that is for a different issue to fix. The issue there is we have a cset/add
during the (RTL) LIM and we don't pull the constant out from the add. And then
we go and do the combine and found it is an cinc and then 42 becomes part of
the cinc. This is pre-existing issue and most likely could be reproduce with
other testcases too.
[Bug c++/94753] -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 --- Comment #2 from Andrew Pinski --- Created attachment 58030 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58030=edit Patch which I am testing I am testing this patch and will be submitting it for GCC 15.
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #23 from Nicolas Boulenguez ---
Always with gcc-13.2.0+Debian patches on arm-linux-gnueabihf,
if s-osprim__posix.adb imports and calls
int
__gnat_gettimeofday(struct timeval *restrict tv,
struct timezone *restrict tz)
{
return gettimeofday(tv, tz);
}
defined in cal.c instead of directly importing and calling the C gettimeofday
as it does for now, the returned date is correct.
This suggests that there is a distinct issue and provides a workaround for it.
[Bug c++/114841] [P0522R0] partial ordering of template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-04-24 Blocks||114840 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114840 [Bug 114840] [meta-bug] template template parameters
[Bug c++/114841] New: [P0522R0] partial ordering of template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841
Bug ID: 114841
Summary: [P0522R0] partial ordering of template template
parameters
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Target Milestone: ---
Created attachment 58029
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58029=edit
WIP patch against r8-7277-g515f874faf4562
In the 2016 CWG discussion of making P0522R0 actually work, I proposed the
adjustment that I implemented in r7-5537-g31bfc9b9dd65ec and drafted as
* X is an invented class template with the template parameter
list of A, including default arguments, except that during partial ordering
(14.5.6.2), for each non-parameter-pack template parameter of A, the
corresponding template parameter of X has a default argument which
is compatible with any other template-argument.
In a reply, Richard Smith noted that this would wrongly accept this example:
template struct match2;
template class t1,typename T>
struct match2, typename t1::type > { typedef int type; }; // #5
template class t2,typename T0,typename T1>
struct match2, typename t2::type > { typedef int type; }; //
#6
template struct Q { typedef int type; };
match2, int> m;
and indeed GCC still chooses #6, which is questionable since t1 cannot
reasonably be deduced to be both t2 and t2.
I worked on implementing this in 2017 but never finished.
His alternative suggestion was still to introduce a default argument, but
instead of having it match any other template argument, base the default on the
actual arguments, i.e. T1 or T0. I worked on this for a while in 2017 but
didn't finish. Now that Clang is implementing this
(https://github.com/llvm/llvm-project/pull/89807), it would be nice to finish
it up.
[Bug c++/114709] [12/13 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 Patrick Palka changed: What|Removed |Added Summary|[12/13/14 Regression] |[12/13 Regression] |Incorrect handling of |Incorrect handling of |inactive union member |inactive union member |access via pointer to |access via pointer to |member in constant |member in constant |evaluated context since |evaluated context since |r12-6425|r12-6425 --- Comment #4 from Patrick Palka --- Fixed for GCC 14 so far.
[Bug c++/114709] [12/13/14 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0844170e9ef60a8b2f6fba6786672f30ce1c2749 commit r14-10110-g0844170e9ef60a8b2f6fba6786672f30ce1c2749 Author: Patrick Palka Date: Wed Apr 24 17:49:56 2024 -0400 c++: constexpr union member access folding [PR114709] The object/offset canonicalization performed in cxx_fold_indirect_ref is undesirable for union member accesses because it loses information about the member being accessed which we may later need to diagnose an inactive-member access. So this patch restricts the canonicalization accordingly. PR c++/114709 gcc/cp/ChangeLog: * constexpr.cc (cxx_fold_indirect_ref): Restrict object/offset canonicalization to RECORD_TYPE member accesses. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-union8.C: New test. Reviewed-by: Jason Merrill
[Bug c++/105841] [12 Regression] Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 --- Comment #16 from Patrick Palka --- (In reply to Haojian Wu from comment #15) > Hi, I notice that the __is_deducible was hidden in the commit > https://github.com/gcc-mirror/gcc/commit/ > 30556bf81f4385c2a9c449948865dbcf35664764. > > Is there any reason behind the change? > > (Context: I'm implementing the is_deducible part for alias CTAD in clang, > and I'm considering to add a similar builtin in clang). IIRC we didn't want to commit to an API for the built-in, and we also didn't have any motivating use cases for the it within libstdc++.
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061 --- Comment #7 from Patrick Palka --- (In reply to Patrick Palka from comment #6) > It seems reasonable for this to work but there might be a defect, or at > least lack of clarity, in the standard in this situation. > > http://eel.is/c++draft/class.spaceship#3 specifies how a defaulted <=> is > defined, in terms of <=> comparisons of corresponding subobjects. But it's > not clear how each of these <=> comparisons is written. If they're always > written like operator expressions, e.g. x_i <=> y_i then if x_i / y_i are > base class subobjects that have a protected <=>, then such a definition > would indeed be ill-formed due to the protected access: > https://godbolt.org/z/5h4ednq9 The <=> comparison would need to be written > A::operator<=>(b) as mentioned in comment #2 in order for the definition to > be valid IIUC? Oops, the full CE link is https://godbolt.org/z/5h4ednq9E
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Patrick Palka --- It seems reasonable for this to work but there might be a defect, or at least lack of clarity, in the standard in this situation. http://eel.is/c++draft/class.spaceship#3 specifies how a defaulted <=> is defined, in terms of <=> comparisons of corresponding subobjects. But it's not clear how each of these <=> comparisons is written. If they're always written like operator expressions, e.g. x_i <=> y_i then if x_i / y_i are base class subobjects that have a protected <=>, then such a definition would indeed be ill-formed due to the protected access: https://godbolt.org/z/5h4ednq9 The <=> comparison would need to be written A::operator<=>(b) as mentioned in comment #2 in order for the definition to be valid IIUC?
[Bug c++/114840] [meta-bug] template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114840 Jason Merrill changed: What|Removed |Added Alias||c++-ttp Ever confirmed|0 |1 CC||jason at gcc dot gnu.org Last reconfirmed||2024-04-24 Status|UNCONFIRMED |NEW
[Bug c++/114840] New: [meta-bug] template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114840 Bug ID: 114840 Summary: [meta-bug] template template parameters Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jason at gcc dot gnu.org Target Milestone: --- Meta-bug for issues with C++ template template parameters.
[Bug fortran/114815] [PDT] internal compiler error: Segmentation fault - on creating type with len parameter and dependent on it character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114815 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- (In reply to anlauf from comment #2) > The code in comment#0 is invalid. > > Intel: > > pr114815.f90(5): error #8737: For a default initialized component every type > parameter and array bound must be a constant expression. [GENDERS] > end type Student_Group > ^ > > NAG: > > Error: pr114815.f90, line 4: Type STUDENT_GROUP default-initialised > component GENDERS has a non-constant array bound > Errors in declarations, no further processing for LAB_1_4 > > > When commenting the default initialization, the code compiles with gfortran. My first project once 14-branch is released will be to put PDTs to rights. Unfortunately, the representation is plain wrong and I don't see any point in cosmetic fixes until that is put right. Sorry Paul
[Bug target/114839] g++-linked FreeBSD static binaries abort upon exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839 --- Comment #4 from Ed Maste --- Thanks - 54568 adds some good context. Based on that I think it may that frame registration calls are not present in the FreeBSD crt bits used for static binaries, which could explain the differences in OSes. We could look into adding the registration calls, but it seems that using --eh-frame-hdr always is the best path for us.
[Bug jit/104072] Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 --- Comment #4 from Andrew Pinski --- (In reply to Andreas Schwab from comment #3) > FAIL: test-error-register-variable-size-mismatch.c.exe iteration 1 of 5: > verify_code: actual: "invalid register name for 'global_variable'" != > expected: "data type of 'global_variable' isn't suitable for a register" Yes looks like a testcase issue. What target is from? r12 is sometimes a valid register name but not always.
[Bug fortran/114815] internal compiler error: Segmentation fault - on creating type with len parameter and dependent on it character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114815 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2024-04-24 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- The code in comment#0 is invalid. Intel: pr114815.f90(5): error #8737: For a default initialized component every type parameter and array bound must be a constant expression. [GENDERS] end type Student_Group ^ NAG: Error: pr114815.f90, line 4: Type STUDENT_GROUP default-initialised component GENDERS has a non-constant array bound Errors in declarations, no further processing for LAB_1_4 When commenting the default initialization, the code compiles with gfortran.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-04-24
Keywords||wrong-code
--- Comment #5 from anlauf at gcc dot gnu.org ---
Confirmed.
Two data points which give a hint what might be wrong:
1) the valgrind error count at runtime depends on the string length passed
to foo. I get no errors for a string of length 1.
2) the dump-tree of subroutine foo looks suspicious:
if (b->_data == 0B)
{
b->_data = __builtin_malloc (MAX_EXPR <(unsigned long)
rhs.1._vptr->_size, 1>);
It looks like _size comes from:
static struct __vtype_CHARACTER_1_ __vtab_CHARACTER_1_ = {._hash=85893463,
._size=1, ._extends=0B, ._def_init=0B, ._copy=__copy_character_1, ._final=0B};
and is always 1. On the other hand, subroutine run sets:
class.2._vptr = (struct __vtype__STAR * {ref-all})
&__vtab_CHARACTER_1_;
class.2._data = (void *) &"fubarfubarfubarfubarfubarfu"[1]{lb: 1 sz:
1};
class.2._len = 27;
but _len is used in foo for the _copy, but not for the allocation.
Thus the size allocated needs to be fixed.
Changing the character argument to use kind=4, I see that _size seems to
represent the element size.
The allocation size thus should be changed to (_size * _len).
Need to find the place where this happens... Anyone?
[Bug libstdc++/114838] __gthread_cond_t et. al. used unconditionally by std_mutex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838 --- Comment #1 from Jonathan Wakely --- It's guarded with _GLIBCXX_HAS_GTHREADS which is defined by configure when __GTHREADS_CXX0X is defined by , which for gthr-win32.h means: #if _WIN32_WINNT >= 0x0600 #define __GTHREAD_HAS_COND 1 #define __GTHREADS_CXX0X 1 #endif So libstdc++ assumes that __GTHREADS_CXX0X is fixed at build-time, not something that changes from one compilation to the next.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #59 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:17212f5912d8f57b3757633444ae64c9831aa8f7 commit r11-11356-g17212f5912d8f57b3757633444ae64c9831aa8f7 Author: Iain Sandoe Date: Sat Dec 3 17:09:35 2022 + libstdc++, Darwin: Limit recursive mutex init to OS versions needing it. The problem described in pr 51906 was fixed in the next OS release. Limit the workaround to systems that need it. Signed-off-by: Iain Sandoe libstdc++-v3/ChangeLog: * config/os/bsd/darwin/os_defines.h (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro to OS versions that need it. (cherry picked from commit a044c9d25972b22c6b4c8ec27f2de5fd622573cc)
[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599 --- Comment #9 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:3bb14f6ed5bc70e25381c67963c90eaab91eca22 commit r11-11353-g3bb14f6ed5bc70e25381c67963c90eaab91eca22 Author: Iain Sandoe Date: Sun May 29 16:14:32 2022 +0100 Darwin: Fix empty g++ command lines [PR105599]. An empty g++ command line should produce a diagnostic that there are no inputs. The PR is that currently Darwin produces a dignostic about missing link items instead - this is because (errnoeously), for this driver, we are creating a link job for empty command lines. The problem occurs in four stages: The g++ driver appends -shared-libgcc to the command line. The Darwin driver_init code in the backend does not see this (it sees an empty command line). When the back end driver code driver sees an empty command line, it does not add any supplementary flags (e.g. asm-macosx-version-min) - precisely to avoid anything being claimed as an input_file and therefore triggering a link line. Since we do not have a value for asm-macosx-version-min when processing the driver specs, we unconditionally inject 'multiply_defined suppress' which is used with shared libgcc (but only intended on very old Darwin). This then causes the generation of a link job. The solution, for the present, is to move version-specific link params to the LINK_SPEC so that they are only processed when a link job has already been decided. Signed-off-by: Iain Sandoe PR target/105599 gcc/ChangeLog: * config/darwin.h: Move versions-specific handling of multiply_defined from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC. (cherry picked from commit 794737976b9a6418eab817f143bb4eb2d0c834d2)
[Bug target/114839] g++-linked FreeBSD static binaries abort upon exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839 --- Comment #3 from Ed Maste --- (In reply to Andrew Pinski from comment #2) > Is it the case that unwinder from LLVM needs a .eh_frame_hdr for static > binaries while GCC's libgcc one does not? That's possible, but in the investigation in the FreeBSD bug report I believe that GCC's libgcc is being used here: #0 0x004d4dca in thr_kill () #1 0x004c226f in raise () #2 0x004df6f9 in abort () #3 0x00402bef in uw_init_context_1 ( context=context@entry=0x7fffdfffdd50, outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x4b2326 ) at ../../../gcc-13.2.0/libgcc/unwind-dw2.c:1336 #4 0x004ad986 in _Unwind_ForcedUnwind (exc=0x800818940, stop=0x4b24d0 , stop_argument=0x0) at ../../../gcc-13.2.0/libgcc/unwind.inc:212
[Bug target/114839] g++-linked FreeBSD static binaries abort upon exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839
--- Comment #2 from Andrew Pinski ---
Hmm, I wonder why freebsd needs to be different from every most other targets
though here:
```
config/alpha/elf.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
config/arc/linux.h:#define LINK_EH_SPEC "--eh-frame-hdr "
config/dragonfly.h:#define LINK_EH_SPEC "--eh-frame-hdr"
config/freebsd.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
config/fuchsia.h: "%{!no-eh-frame-hdr: --eh-frame-hdr}" \
config/gnu-user.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
config/netbsd.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
config/openbsd.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
config/sol2.h: --eh-frame-hdr to create the required .eh_frame_hdr sections.
*/
config/sol2.h:#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
```
Is it the case that unwinder from LLVM needs a .eh_frame_hdr for static
binaries while GCC's libgcc one does not?
[Bug target/114839] g++-linked FreeBSD static binaries abort upon exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839
--- Comment #1 from Andrew Pinski ---
>From gcc/config/freebsd.h:
#if defined(HAVE_LD_EH_FRAME_HDR)
#define LINK_EH_SPEC "%{!static|static-pie:--eh-frame-hdr} "
#endif
The !static part comes from r0-95899-g2208d2ac9546de .
[Bug driver/114839] New: g++-linked FreeBSD static binaries abort upon exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839
Bug ID: 114839
Summary: g++-linked FreeBSD static binaries abort upon
exception
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: emaste at freebsd dot org
Target Milestone: ---
When compiling and statically linking a binary on FreeBSD with GCC the EH_FRAME
segment is omitted, and then libgcc's exception unwinder aborts when it cannot
find the EH_FRAME segment. See FreeBSD bug report
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 for full details and
history.
>From -dumpspecs it looks like (assuming I understand correctly) that
--eh-frame-header is not passed when static is specified:
...
*link:
%{!static|static-pie:--eh-frame-hdr} %{m32:-m elf_i386_fbsd}%{!m32:-m
elf_x86_64_fbsd} %{p:%nconsider using '-pg' instead of '-p' with gprof(1)}
%{v:-V} %{assert*} %{R*} %{rpath*} %{defsym*} %{shared:-Bshareable %{h*}
%{soname*}} %{!shared: %{!static: %{rdynamic:-export-dynamic}
-dynamic-linker %(fbsd_dynamic_linker) } %{static:-Bstatic}}
%{symbolic:-Bsymbolic}
[Bug tree-optimization/114833] --suggest-attribute=returns_nonnull misdiagnoses functions with __attribute__((nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114833 --- Comment #2 from Andrew Pinski --- The code to do the warning was added with r14-5628-g53ba8d669550d3 .
[Bug tree-optimization/114833] --suggest-attribute=returns_nonnull misdiagnoses functions with __attribute__((nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114833 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-04-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. The code which calls warn_function_returns_nonnull (or maybe warn_function_returns_nonnull should do the check) does not check for the attribute already there.
[Bug c++/114834] nontstring attribute vs. references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114834 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, rejects-valid --- Comment #1 from Andrew Pinski --- I would have assumed nonstring on std::byte would be a non-op since it is an enum and the other code checks only for character types ...
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 Nicolas Boulenguez changed: What|Removed |Added Attachment #57926|0 |1 is obsolete|| --- Comment #22 from Nicolas Boulenguez --- Created attachment 58028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58028=edit merge all definitions and conversions for timeval and timespec Hello. Moving the definitions into System.CRTL was a bad idea because they are needed before the target libgnat is built. The attached version 6 creates a new System.C_Time unit. It also adds a script testing the C_Time functions against handwritten results on 32 combinations of type sizes for Duration, time_t and suseconds_t. With the first four patches applied, gcc-13.2.0 (with Debian patches) builds on x86_64-linux-gnu and arm-linux-gnueabihf. The following program then gives the correct date on x86_64-linux-gnu but random dates or Time_Error on arm-linux-gnueabihf. So the original issue remains. -- with Ada.Calendar, Ada.Text_IO; procedure Demo is Y : Ada.Calendar.Year_Number; M : Ada.Calendar.Month_Number; D : Ada.Calendar.Day_Number; S : Duration; H, Min : Integer; begin Ada.Calendar.Split (Ada.Calendar.Clock, Y, M, D, S); H := Integer ((S / 3_600) - 0.5); S := S - 3600 * Duration (H); Min := Integer ((S / 60) - 0.5); S := S - 60 * Duration (Min); Ada.Text_IO.Put_Line (Y'Img & M'Img & D'Img & H'Img & Min'Img & S'Img); end Demo; -- The commits are rebased on the trunk, with only trivial changes but untested.
[Bug libstdc++/114838] New: __gthread_cond_t et. al. used unconditionally by std_mutex.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838 Bug ID: 114838 Summary: __gthread_cond_t et. al. used unconditionally by std_mutex.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: p...@gcc-bugzilla.mail.kapsi.fi Target Milestone: --- Hi. libstdc++/include/bits/std_mutex.h, which is included by , currently uses internal condition variable types __gthread_cond_t et. al. unconditionally. However, these types might be unavailable. For an example, libgcc/config/i386/gthr-win32.h (i.e. Windows targets) only defines these (and __GTHREAD_HAS_COND) if _WIN32_WINNT >= 0x0600. Unfortunately, it is possible, that _WIN32_WINNT is set by default to a lower value. Such is the case with gdb and it uses 0x0501 by default. As of writing, both 0x0501 (Windows XP, EOL 2014) and 0x0600 (Windows Vista, EOL 2017) have been out of support for a number of years. This issue is also present on GCC 13.
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #13 from Xi Ruoyao --- (In reply to David Malcolm from comment #10) > (In reply to Jan Hubicka from comment #4) > > I keep mentioning to Larabel that he should use -fno-semantic-interposition, > > but he doesn't. > > Possibly a silly question, but how about changing the default in GCC 15? > What proportion of users actually make use of -fsemantic-interposition ? At least if building Glibc with -fno-semantic-interposition, several tests will fail. I've not figured out if they are test-suite issues or real issues though.
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #12 from Andrew Pinski --- (In reply to Andrew Pinski from comment #11) > (In reply to David Malcolm from comment #10) > > (In reply to Jan Hubicka from comment #4) > > > I keep mentioning to Larabel that he should use > > > -fno-semantic-interposition, > > > but he doesn't. > > > > Possibly a silly question, but how about changing the default in GCC 15? > > What proportion of users actually make use of -fsemantic-interposition ? > > See https://inbox.sourceware.org/gcc-patches/ri6czn5z8mw@suse.cz/ for > previous discussion on this. Sorry https://inbox.sourceware.org/gcc-patches/20210606231215.49899-1-mask...@google.com/
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #11 from Andrew Pinski --- (In reply to David Malcolm from comment #10) > (In reply to Jan Hubicka from comment #4) > > I keep mentioning to Larabel that he should use -fno-semantic-interposition, > > but he doesn't. > > Possibly a silly question, but how about changing the default in GCC 15? > What proportion of users actually make use of -fsemantic-interposition ? See https://inbox.sourceware.org/gcc-patches/ri6czn5z8mw@suse.cz/ for previous discussion on this.
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #10 from David Malcolm --- (In reply to Jan Hubicka from comment #4) > I keep mentioning to Larabel that he should use -fno-semantic-interposition, > but he doesn't. Possibly a silly question, but how about changing the default in GCC 15? What proportion of users actually make use of -fsemantic-interposition ?
[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:97a54c05b8e338e673e1f7fb72c0e23abb571c60
commit r14-10109-g97a54c05b8e338e673e1f7fb72c0e23abb571c60
Author: Jakub Jelinek
Date: Wed Apr 24 18:29:12 2024 +0200
v2: DOCUMENTATION_ROOT_URL vs. release branches [PR114738]
This patch moves the documentation root URL infix for release branches
from get_option_url/make_doc_url to configure, such that only the default
changes and when users specify a custom documentation root URL, they don't
have to add gcc-MAJOR.MINOR.0 subdirectories for release branches.
Tested by checking
../configure --disable-bootstrap --enable-languages=c --disable-multilib
built trunk on
void
foo (int x)
{
__builtin_printf ("%ld\n", x);
}
testcase and looking for the URL in there, then repeating that after
changing gcc/BASE-VER to 14.1.0 and again after changing it to 14.1.1,
plus normal bootstrap/regtest.
2024-04-24 Jakub Jelinek
PR other/114738
* opts.cc (get_option_url): Revert 2024-04-17 changes.
* gcc-urlifier.cc: Don't include diagnostic-core.h.
(gcc_urlifier::make_doc_url): Revert 2024-04-17 changes.
* configure.ac (documentation-root-url): On release branches
append gcc-MAJOR.MINOR.0/ to the default DOCUMENTATION_ROOT_URL.
* doc/install.texi (--with-documentation-root-url=): Document
the change of the default.
* configure: Regenerate.
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 58027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58027=edit gcc14-pr114825.patch Untested fix.
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #9 from Jan Hubicka --- Phoronix still claims the difference https://www.phoronix.com/review/gcc14-clang18-amd-zen4/2
[Bug target/114837] [11/12/13/14] Fix to security weaknesses in PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #1 from Richard Ball --- https://sourceware.org/pipermail/gcc-patches/2024-April/649973.html
[Bug fortran/93678] [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
CC||pault at gcc dot gnu.org
--- Comment #14 from Paul Thomas ---
Created attachment 58026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58026=edit
Fix for this PR
I'll package it all up for the list in the next 24 hours. Regtests OK, the
testcase of comment 1 compiles and this runs fine:
! { dg-do compile }
! Test the fix for PR93678 in which the charlen for the 'unpackbytes'
! vtable field was incomplete and caused the ICE as indicated.
! Contributed by Luis Kornblueh
!
! The testcase was reduced by various gfortran regulars.
module mo_a
implicit none
type t_b
integer :: i
contains
procedure :: unpackbytes => b_unpackbytes
end type t_b
contains
function b_unpackbytes (me) result (res)
class(t_b), intent(inout) :: me
character :: res(1)
res = char (me%i)
end function b_unpackbytes
subroutine b_unpackint (me, c)
class(t_b), intent(inout) :: me
character, intent(in) :: c
! print *, b_unpackbytes (me) ! ok
if (any (me% unpackbytes () .ne. c)) stop 1 ! ICEd here
end subroutine b_unpackint
end module mo_a
use mo_a
class(t_b), allocatable :: z
allocate (z, source = t_b(97))
call b_unpackint (z, "a")
end
[Bug target/113236] WebP benchmark is 20% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236 --- Comment #3 from Jan Hubicka --- Seems this perofmance difference is still there on zen4 https://www.phoronix.com/review/gcc14-clang18-amd-zen4/3
[Bug target/114837] [11/12/13/14] Fix to security weaknesses in PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 Richard Ball changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ricbal02 at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Target||aarch64 Last reconfirmed||2024-04-24 Ever confirmed|0 |1
[Bug target/114837] New: [11/12/13/14] Fix to security weaknesses in PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 Bug ID: 114837 Summary: [11/12/13/14] Fix to security weaknesses in PCS for CMSE Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ricbal02 at gcc dot gnu.org Target Milestone: --- Security weaknesses exist in PCS for CMSE. To resolve this a patch will be upstreamed and backported which will: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch will fix the following: CVE-2024-0151.
[Bug modula2/114836] New: error messages should be translatable and follow locale convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114836 Bug ID: 114836 Summary: error messages should be translatable and follow locale convention Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- As mentioned on GCC patches the error messages should be translatable following the technique used for gcc/po/gcc.pot.
[Bug target/114835] New: AVR popcountqi2 is not fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835 Bug ID: 114835 Summary: AVR popcountqi2 is not fast as can be Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: WolfgaNg.Hospital at arcor dot de Target Milestone: --- Created attachment 58025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58025=edit AVR assembly code for __popcountqi2 For 8-bit AVRs, the current 16-instruction __popcountqi2 uses 6 ADC instructions to establish the number of bits set in a byte. In "Bit Twiddling Hacks", Sean E. Anderson presents several approaches to this; "parallel/sideways addition" can be coded with one instruction less. When establishing the "popcount" of an uint8_t, I've seen GCC to widen the value to "half int" and use __popcountqi2 twice.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #4 from Neil Carlson --- Same results with 13.2.0 configured with --enable-valgrind-annotations. Here's the output with 13.2.0 and gfortran -g -O0 -fsanitize=address foo.f90 : ==1126830==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200071 at pc 0x7fb97cc6b21d bp 0x7ffcd7a79200 sp 0x7ffcd7a789c0 WRITE of size 27 at 0x60200071 thread T0 #0 0x7fb97cc6b21c in __interceptor_memmove ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882 #1 0x4012ca in __copy_character_1 /home/nnc/Codes/petaca/bugs/foo.f90:1 #2 0x401a14 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11 #3 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6 #4 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2 #5 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2 #6 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #7 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #8 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194) 0x60200071 is located 0 bytes after 1-byte region [0x60200070,0x60200071) allocated by thread T0 here: #0 0x7fb97ccdc2ef in __interceptor_malloc ../../../../libsanitizer/asan/asan_malloc_linux.cpp:69 #1 0x4017c9 in foo /home/nnc/Codes/petaca/bugs/foo.f90:11 #2 0x401cf9 in run /home/nnc/Codes/petaca/bugs/foo.f90:6 #3 0x401374 in MAIN__ /home/nnc/Codes/petaca/bugs/foo.f90:2 #4 0x401fc6 in main /home/nnc/Codes/petaca/bugs/foo.f90:2 #5 0x7fb97c646149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #6 0x7fb97c64620a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: e0b579ca7024cf12a2686b60cf49d1d9e3ff6273) #7 0x401194 in _start (/home/nnc/Codes/petaca/bugs/a.out+0x401194) SUMMARY: AddressSanitizer: heap-buffer-overflow ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:882 in __interceptor_memmove Shadow bytes around the buggy address: 0x601ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x601fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x6020: fa fa 06 fa fa fa 07 fa fa fa 07 fa fa fa[01]fa 0x60200080: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200100: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200180: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x60200280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 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 ==1126830==ABORTING
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 Uroš Bizjak changed: What|Removed |Added Target Milestone|13.3|11.5 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #41 from Uroš Bizjak --- Fixed everywhere.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #40 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:09910b6753427eeb3f6dded4fae3578851da7422 commit r11-11352-g09910b6753427eeb3f6dded4fae3578851da7422 Author: Jakub Jelinek Date: Tue Mar 26 11:06:15 2024 +0100 tsan: Don't instrument non-generic AS accesses [PR111736] Similar to the asan and ubsan changes, we shouldn't instrument non-generic address space accesses with tsan, because we just have library functions which take address of the objects as generic address space pointers, so they can't handle anything else. 2024-03-26 Jakub Jelinek gcc/ChangeLog: PR sanitizer/111736 * tsan.c (instrument_expr): Punt on non-generic address space accesses. gcc/testsuite/ChangeLog: * gcc.dg/tsan/pr111736.c: New test. (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #39 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:624c3bb9ff762f196852dc77233610d1cdf7d7be commit r11-11351-g624c3bb9ff762f196852dc77233610d1cdf7d7be Author: Jakub Jelinek Date: Fri Mar 22 09:23:44 2024 +0100 ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736] On x86 and avr some address spaces allow 0 pointers (on avr actually even generic as, but libsanitizer isn't ported to it and I'm not convinced we should completely kill -fsanitize=null in that case). The following patch makes sure those aren't diagnosed for -fsanitize=null, though they are still sanitized for -fsanitize=alignment. 2024-03-22 Jakub Jelinek gcc/ChangeLog: PR sanitizer/111736 * ubsan.c (ubsan_expand_null_ifn, instrument_mem_ref): Avoid SANITIZE_NULL instrumentation for non-generic address spaces for which targetm.addr_space.zero_address_valid (as) is true. gcc/testsuite/ChangeLog: * gcc.dg/ubsan/pr111736.c: New test. (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #37 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b86b523fb53f5ffb0e3f3236fc526a587944d9ea commit r11-11349-gb86b523fb53f5ffb0e3f3236fc526a587944d9ea Author: Richard Biener Date: Tue Dec 5 14:00:43 2023 +0100 sanitizer/111736 - skip ASAN for globals in alternate address-space gcc/ChangeLog: PR sanitizer/111736 * asan.c (asan_protect_global): Do not protect globals in non-generic address-space. (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #38 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b4e1aee01a2fa617cf74ab04cf0ab574761aaaea commit r11-11350-gb4e1aee01a2fa617cf74ab04cf0ab574761aaaea Author: Richard Biener Date: Thu Mar 21 08:30:39 2024 +0100 tree-optimization/111736 - avoid address sanitizing of __seg_gs The following more thoroughly avoids address sanitizing accesses to non-generic address-spaces. gcc/ChangeLog: PR tree-optimization/111736 * asan.c (instrument_derefs): Do not instrument accesses to non-generic address-spaces. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111736.c: New testcase. (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)
[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #18 from Jan Hubicka --- predict.cc queries number of iterations using number_of_iterations_exit and loop_niter_by_eval and finally using estimated_stmt_executions. The first two queries are not updating the upper bounds datastructure so that is why we get around without computing them in some cases. I guess we can just drop dumping here. We now dump the recorded estimates elsehwere, so this is somewhat redundant.
[Bug libstdc++/114821] _M_realloc_append should use memcpy instead of loop to copy data when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821 --- Comment #13 from Jan Hubicka --- Thanks a lot, looks great! Do we still auto-detect memmove when the copy constructor turns out to be memcpy equivalent after optimization?
[Bug target/114734] [14] RISC-V rv64gcv_zvl256b miscompile with -flto -O3 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734 Robin Dapp changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #6 from Robin Dapp --- This one is really a bit tricky. We have the following situation: loop: # vectp_g.178_1078 = PHI _911 = vectp_g.178_1078 MASK_LEN_LOAD (_911, ...); vectp_g.178_1079 = vectp_g.178_1078 + 16; goto loop; : MASK_LEN_LOAD (_911, ...); During expand we basically convert back the _911 to vectp_g.178_1078 (reverting what we did in ivopts before). Because _911 camouflages vectp_g.178_1078 until expand we evaded the conflict checks of outof-ssa that would catch a similar, non-camouflaged situation like: # vectp_g.178_1078 = PHI MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...); vectp_g.178_1079 = vectp_g.178_1078 + 16; goto loop; MASK_LEN_LOAD (MEM... vectp_g.178_1078, ...); and would insert a copy of the definition right before the backedge. The MASK_LEN_LOAD after the loop would then use that copy. By using _911 instead of the original pointer no conflict is detected and we wrongly use the incremented pointer. Without the ivopt change for TARGET_MEM_REF Unless I'm misunderstanding some basic mechanism it's not going to work like that (and we could also have this situation on aarch64). What could help is to enhance trivially_conflicts_p in outof-ssa to catch such TARGET_MEM_REFs here and handle them similarly to a normal conflict. I did that locally and it helps for this particular case but I'd rather not post it in its current hacky state even if the riscv testsuite looks ok :) Even if that were the correct solution I'd doubt it should land in stage 4. CC'ing Richard Sandiford as he originally introduced the ivopts and expand handling.
[Bug c++/114685] [modules] ICE when exporting a type through a different alias then one declared in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- (N.B. https://gcc.gnu.org/PR114600#c10 contains a full std module with workarounds)
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 114600, which changed state. Bug 114600 Summary: [14 Regression] [modules] redefinition errors when using certain std headers in GMF https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Patrick Palka --- IIUC the regression is fixed.
[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600 --- Comment #12 from Patrick Palka --- (In reply to m.cencora from comment #10) > Created attachment 57924 [details] > Full "std' modules with workarounds > > Here is an improved version of "std" module, with workarounds for: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114683 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114685 Interesting, thanks! IIUC in light of these 'export using' bugs the most robust way to implement the std module in GCC 14 is probably: $ cat std.C export module std; export import ; $ g++ -fmodules-ts -x c++-system-header bits/stdc++.h -x c++ std.C This has the disadvantage of exposing implementation-detail entities and requiring an additional step to build the header module, but should otherwise just work.
[Bug target/53938] ARM target generates sub-optimal code (extra instructions) on load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 --- Comment #6 from rsaxvc at gmail dot com --- This also impacts Cortex-M0 & M23 on GCC13.2.0, just with the new extension instructions. Oddly, when loading a volatile u8 or u16 on Cortex-M3/4/7 does not generate extra zero extension instructions. But these cores do still have separate ldrb/ldrb + sxtab/sxtah sign extension instead of LDRSB/LDRSH.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #3 from Neil Carlson --- Those results are with 12.3.0 configured with --enable-valgrind-annotations. I'm building 13.2.0 now with the same to see if more info is generated. (I don't typically use 13.x because it finalization is broken for our code after 12.)
[Bug target/114172] [13 only] RISC-V: ICE with riscv rvv VSETVL intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114172 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kito Cheng --- Fixed, and then gcc 13.3 will contain the fix, and that should release in near future :)
[Bug c++/109966] [13 Regression] ICE in gimplify_var_or_parm_decl, à gimplify.cc:3058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109966 Marek Polacek changed: What|Removed |Added Summary|[13/14 Regression] ICE in |[13 Regression] ICE in |gimplify_var_or_parm_decl, |gimplify_var_or_parm_decl, |à gimplify.cc:3058 |à gimplify.cc:3058 --- Comment #7 from Marek Polacek --- Fixed on trunk with r14-9950-g60399256317807.
[Bug target/114172] [13 only] RISC-V: ICE with riscv rvv VSETVL intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114172
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:67e50daa5bd05f16d98c2dc651af2d6fa8335186
commit r13-8644-g67e50daa5bd05f16d98c2dc651af2d6fa8335186
Author: Kito Cheng
Date: Wed Apr 24 16:54:44 2024 +0800
RISC-V: Fix recursive vsetvli checking [PR114172]
extract_single_source will recursive checking the sources to
make sure if it's single source, however it may cause infinite
recursive when the source is come from itself, so it should just skip
first source to prevent that.
NOTE: This logic has existing on trunk/GCC 14, but it included in a big
vsetvli improvement patch, which is not backport to GCC 13.
```
void saxpy_rvv_m8(float *y, long vl)
{
for (;;)
{
vl = __riscv_vsetvl_e32m8(vl); //ICE
vfloat32m8_t y_vec;
__riscv_vse32_v_f32m8(y, y_vec, vl);
}
}
```
gcc/ChangeLog:
PR target/114172
* config/riscv/riscv-vsetvl.cc (extract_single_source):
Skip first set.
gcc/testsuite/ChangeLog:
PR target/114172
* gcc.target/riscv/rvv/vsetvl/pr114172.c: New.
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 --- Comment #4 from Richard Biener --- Created attachment 58024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58024=edit patch I quickly tried this which works for the testcase but I'm sure it'll break quickly.
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- The issue is that unloop_loops doesn't work when to unloop loops are nested. The unroller takes great care of working on a single loop level at a time, cleaning up the CFG and fixing loops inbetween but we fail to ensure this here. unlooping in CH is somewhat a wrong tool for the wrong task as it doesn't adhere to constraints present. There's the possibility this can be salvaged by making unloop_loops more robust, in particular computing loop bodies (Which is fragile) up-front. But it would be much nicer if unlooping would simply add __builtin_unreachable () as the first stmt into the latch and leave the rest to CFG cleanup.
[Bug rtl-optimization/114766] ^ constraint modifier unexpectedly affects register class selection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114766 --- Comment #3 from Vladimir Makarov --- (In reply to Tamar Christina from comment #2) > (In reply to Vladimir Makarov from comment #1) > > (In reply to Tamar Christina from comment #0) > > > The documentation for ^ states: > > > > If it works for you, we could try to use the patch (although it needs some > > investigation how other targets uses the hint). In any case, the > > documentation should be modified or made more clear depending on applying or > > not applying the patch. > > Yeah, using the patch gives us the behavior we expected, we added a > workaround for now so we can investigate what other targets do in GCC 15. > > But while looking at this we also got some unexpected behavior with using ? > > > r103 costs: W8_W11_REGS:2000 W12_W15_REGS:2000 TAILCALL_ADDR_REGS:2000 > STUB_REGS:2000 GENERAL_REGS:2000 FP_LO8_REGS:0 FP_LO_REGS:0 FP_REGS:0 > POINTER_AND_FP_REGS:7000 MEM:9000 > > In this particular pattern the ? isn't needed so we're removing it, but the > behavior is still unexpected. '?' is a very old hint (unlike ^ and @). It is used by all targets for many years. IRA cost calculation uses exactly the same algorithm as it was in now non-existing regclass.c file. Changing code related to processing '?' would have very unpredictable consequences for many targets. After many years working on RA, I am still surprised how fragile code calculating costs and reg classes and how insignificant changes can result in a cascade of GCC test failures. There are many factors which still can result in zero cost code even when '?' is used. You can try to use more one '?' and see what happens. If the cost is still zero, I could look what is going on in the cost calculation.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Eric Botcazou --- >> The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed >> successfully without regressions. >> >> However, sparc/sol2.h needed an #undef to fix [...] > Thanks, fixed. great, thanks. >> The sparc64-unknown-linux-gnu one will be running for a couple more >> hours, though. > > The change should be a no-op for this platform. True. However, I'd rather wait for the bootstrap to complete. Should be sometime tonight... >> Btw., I thought about running gcc.dg/compat against Studio 12.6 cc. I'd >> started trying some time ago, but got distracted. At the very least, I >> needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part >> of that testsuite to compile at all, for the likes of >> >> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h", >> line 7: zero-sized struct/union >> >> "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h", >> line 197: invalid type combination > > I used to do that on a regular basis 20 years ago, which led to: > https://gcc.gnu.org/gcc-3.4/sparc-abi.html > but I lost access to Sun Studio at some point. FWIW, cfarm216, the new Solaris 11.4/SPARC compile farm host, does have Studio 12.6 installed. Right now, it's only the FCS version, but I hope to get access to the studiosupport repo in the future. Besides, I've checked the testcase that prompted this PR with previous Studio versions quite some time back and their behaviour in this regard is unchanged.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #17 from Eric Botcazou --- > The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed > successfully without regressions. > > However, sparc/sol2.h needed an #undef to fix > > In file included from ./tm.h:27, > from /vol/gcc/src/hg/master/local/gcc/gencheck.cc:23: > /vol/gcc/src/hg/master/local/gcc/config/sparc/sol2.h:460:9: error: > "SUN_V9_ABI_COMPATIBILITY" redefined [-Werror] > 460 | #define SUN_V9_ABI_COMPATIBILITY 1 > | ^~~~ > In file included from ./tm.h:24: > /vol/gcc/src/hg/master/local/gcc/config/sparc/sparc.h:1705:9: note: this is > the location of the previous definition > 1705 | #define SUN_V9_ABI_COMPATIBILITY 0 > | ^~~~ Thanks, fixed. > The sparc64-unknown-linux-gnu one will be running for a couple more > hours, though. The change should be a no-op for this platform. > Btw., I thought about running gcc.dg/compat against Studio 12.6 cc. I'd > started trying some time ago, but got distracted. At the very least, I > needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part > of that testsuite to compile at all, for the likes of > > "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h", > line 7: zero-sized struct/union > > "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h", > line 197: invalid type combination I used to do that on a regular basis 20 years ago, which led to: https://gcc.gnu.org/gcc-3.4/sparc-abi.html but I lost access to Sun Studio at some point.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #14 from Eric Botcazou --- >> Do you happen to have some spare cycles to conduct a testing cycle of the >> above >> tentative fix? It only affects the 64-bit ABI so a sparc64/sparcv9 one would >> be sufficient (Unfortunately I no longer have access to my SPARC/Solaris >> setup >> and haven't tried the Compile Farm yet). > > Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC > cfarm node to myself ;-) I've also got a Linux/sparc64 LDom around > since the cfarm instance has been very unstable lately. The sparc-sun-solaris2.11 bootstrap (both multilibs) has just completed successfully without regressions. However, sparc/sol2.h needed an #undef to fix In file included from ./tm.h:27, from /vol/gcc/src/hg/master/local/gcc/gencheck.cc:23: /vol/gcc/src/hg/master/local/gcc/config/sparc/sol2.h:460:9: error: "SUN_V9_ABI_COMPATIBILITY" redefined [-Werror] 460 | #define SUN_V9_ABI_COMPATIBILITY 1 | ^~~~ In file included from ./tm.h:24: /vol/gcc/src/hg/master/local/gcc/config/sparc/sparc.h:1705:9: note: this is the location of the previous definition 1705 | #define SUN_V9_ABI_COMPATIBILITY 0 | ^~~~ The sparc64-unknown-linux-gnu one will be running for a couple more hours, though. Btw., I thought about running gcc.dg/compat against Studio 12.6 cc. I'd started trying some time ago, but got distracted. At the very least, I needed -features=extensions -DSKIP_COMPLEX_INT for a considerable part of that testsuite to compile at all, for the likes of "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/pr102024_test.h", line 7: zero-sized struct/union "/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/compat/struct-layout-1.h", line 197: invalid type combination
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #7 from Gejoe --- (In reply to Richard Biener from comment #6) > I have no idea why the values differ but I suspect the copying since we seem > to use the file modification time at some point. As a workaround I would > suggest > to binary-patch one of the file to make the stamp match the other ... We do use __gcov_dump() in the program execution to get all the gcda files, tar them up to a file name and we move that to the workspace where build was done we use a script to run gcov so that gcov files are created finally. So, will there be any changes in GCC 11.x (compared to 10.3.0) where __gcov_dump and the ensuing copy process need to be taken care in a better way ? I'm not sure of the binary-patching of the file mentioned above. Can you elaborate that suggestion ? Thank you for bearing with my queries patiently and for the possible help given.
[Bug c++/114834] New: nontstring attribute vs. references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114834 Bug ID: 114834 Summary: nontstring attribute vs. references Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- We currently allow the nonstring attribute just on pointers and arrays of char/signed char/unsigned char. Shouldn't we allow it also on references to those as well? What about arrays/pointers of std::byte (aka enumeral type with unsigned char as underlying type)?
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #21 from Matthias Klose --- trying to update your patches, the build then fails with: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -gnata -gnatn -I- -nostdinc -I/home/packages/gcc/14/gcc-14-14-20240424/build/gcc/ada/rts -I. -I/home/packages/ gcc/14/gcc-14-14-20240424/src/gcc/ada /home/packages/gcc/14/gcc-14-14-20240424/src/gcc/ada/osint.adb -o osint. o osint.adb:3281:17: error: "time_t" is undefined (more references follow) osint.adb:3295:28: error: invalid operand types for operator "*" osint.adb:3295:28: error: right operand has type universal integer make[5]: *** [../gcc-interface/Makefile:306: osint.o] Error 1
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #20 from Matthias Klose --- Nicolas, the patch series fails to apply on the trunk. Please could you update it, then post it on gcc-patches to get a proper review?
[Bug target/111935] gcc ICE with risc-v vector intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111935 Kito Cheng changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||kito at gcc dot gnu.org --- Comment #5 from Kito Cheng --- Checked this has fixed on trunk and GCC 13 branch
[Bug target/111234] [13] RISC-V: ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234 --- Comment #4 from Kito Cheng --- Fixed on trunk, but still ICE on 13
[Bug tree-optimization/114787] [13 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Richard Biener changed: What|Removed |Added Known to work||14.0 Summary|[13/14 Regression] wrong|[13 Regression] wrong code |code at -O1 on |at -O1 on x86_64-linux-gnu |x86_64-linux-gnu (the |(the generated code hangs) |generated code hangs) | Priority|P1 |P2 --- Comment #17 from Richard Biener --- Fixed on trunk (but not the -fdump-* side-effect - leaving that to Honza). The issue is latent on the branches.
[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Version|unknown |14.0 --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e28e8ab1a92e9b49f7c4045377577c8dc17751b7 commit r14-10105-ge28e8ab1a92e9b49f7c4045377577c8dc17751b7 Author: Richard Biener Date: Wed Apr 24 06:24:22 2024 +0200 tree-optimization/114832 - wrong dominator info with vect peeling When we update the dominator of the redirected exit after peeling we check whether the immediate dominator was the loop header rather than the exit source when we later want to just update it to the new source. The following fixes this oversight. PR tree-optimization/114832 * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg): Fix dominance check. * gcc.dg/vect/pr114832.c: New testcase.
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #16 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cc48418cfc2e555d837ae9138cbfac23acb3cdf9 commit r14-10106-gcc48418cfc2e555d837ae9138cbfac23acb3cdf9 Author: Richard Biener Date: Wed Apr 24 08:42:40 2024 +0200 tree-optimization/114787 - more careful loop update with CFG cleanup When CFG cleanup removes a backedge we have to be more careful with loop update. In particular we need to clear niter info and estimates and if we remove the last backedge of a loop we have to also mark it for removal to prevent a following basic block merging to associate loop info with an unrelated header. PR tree-optimization/114787 * tree-cfg.cc (remove_edge_and_dominated_blocks): When removing a loop backedge clear niter info and when removing the last backedge of a loop mark that loop for removal. * gcc.dg/torture/pr114787.c: New testcase.
[Bug jit/104072] Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 --- Comment #3 from Andreas Schwab --- FAIL: test-error-register-variable-size-mismatch.c.exe iteration 1 of 5: verify_code: actual: "invalid register name for 'global_variable'" != expected: "data type of 'global_variable' isn't suitable for a register"
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061 Tibor Billes changed: What|Removed |Added CC||gcc-90 at tbilles dot hu --- Comment #5 from Tibor Billes --- I ran into this problem, I found a detailed stackoverflow discussion that explains that the standard mandate the derived to base conversion mentioned earlier in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061#c2 It says that the list of subobjects are "formed by a sequence of derived-to-base conversions, class member access expressions, and array subscript expressions applied to x". (https://timsong-cpp.github.io/cppwp/n4868/class.compare.default#6.sentence-3) I'm not a C++ language lawyer, just wanted to provide additional information for anyone looking for this problem. And yeah, I also wish this would work.. Here is the stackoverflow discussion with all the good references to the specific sections of the standard: https://stackoverflow.com/questions/73055625/deriving-class-with-protected-equality-operator-results-in-deleted-default
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Eric Botcazou --- > OK, thanks, let's go ahead for Solaris then, but I agree that we'd better do > nothing for other platforms at this point. Right, I forgot that there are others (and I cannot test any of them at this point; I don't even know if current BSDs still support SPARC at all). > Do you happen to have some spare cycles to conduct a testing cycle of the > above > tentative fix? It only affects the 64-bit ABI so a sparc64/sparcv9 one would > be sufficient (Unfortunately I no longer have access to my SPARC/Solaris setup > and haven't tried the Compile Farm yet). Sure: I've kept one half of the T8-1 hosting the new Solaris 11.4/SPARC cfarm node to myself ;-) I've also got a Linux/sparc64 LDom around since the cfarm instance has been very unstable lately.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #14 from Eric Botcazou --- OK, thanks, let's go ahead for Solaris then, but I agree that we'd better do nothing for other platforms at this point. Do you happen to have some spare cycles to conduct a testing cycle of the above tentative fix? It only affects the 64-bit ABI so a sparc64/sparcv9 one would be sufficient (Unfortunately I no longer have access to my SPARC/Solaris setup and haven't tried the Compile Farm yet).
[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795 --- Comment #10 from porten at kde dot org --- It is! Even my original code base now fully compiles without errors. Thank you!
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #15 from Richard Biener --- Created attachment 58023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58023=edit patch I'm testing this.
[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477 --- Comment #9 from Andrew Pinski --- Created attachment 58022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58022=edit Patch which I tested I still need to add the testcases and finish up the commit message and changelogs. I will do that tomorrow. Posting this here tonight so I don't lose the patch.
[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> here is a testcase for the fcsel usage for integer cmov:
A slightly better example where there is no use of inline-asm or forcing to
specific registers:
```
#define vector16 __attribute__((vector_size(16)))
void
foo (int a, int *b, vector16 int c, vector16 int d)
{
int t = a ? c[0] : d[0];
*b = t;
}
```
We should be able to produce:
```
foo:
cmp w0, 0
fcsel s1, s1, s0, eq
str s1, [x1]
ret
```
And here is a decent one for float modes (-O2 -fno-ssa-phiopt is needed though,
otherwise the tree level does the VCE after the cmov):
```
#define vector8 __attribute__((vector_size(8)))
void
foo (int a, double *b, long long c, long long d)
{
double ct;
double dt;
__builtin_memcpy(, , sizeof(long long));
__builtin_memcpy(, , sizeof(long long));
double t = a ? ct : dt;
*b = t;
}
```
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #14 from Richard Biener --- (In reply to Jan Hubicka from comment #13) > -fdump-tree-all-all changing generated code is also bad. We probably > should avoid dumping loop bounds then they are not recorded. I added dumping > of loop bounds and this may be unexpected side effect. WIll take a look. I think consistently estimating the number of iterations here is correct. I don't think the bug should be P1, it's latent and exposed only with an artificial testcase. We've likely had similar bugs before where we end up associating estimates with a wrong loop after some CFG transform. In this case we end up with the i-loop header being associated with a former irreducible region. The fix in the past was to release estimates/niters on problematic transforms. Let me have a look.
[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #7 from Andrew Pinski ---
here is a testcase for the fcsel usage for integer cmov:
```
void
foo (int a, int *b)
{
int t = a ? 11 : 22;
register int tt __asm__("s0");
tt = t;
asm("":"+w"(tt));
*b = tt;
}
```
[Bug target/98477] aarch64: Unnecessary GPR -> FPR moves for conditional select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98477
--- Comment #6 from Andrew Pinski ---
here is a testcase for the fcsel usage for integer:
```
void
foo (int a, double *b)
{
double t = a ? 1.0 : 200.0;
register double tt __asm__("x0");
tt = t;
asm("":"+r"(tt));
*b = tt;
}
```
