[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Xi Ruoyao changed: What|Removed |Added Keywords||patch --- Comment #9 from Xi Ruoyao --- https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651026.html
[Bug tree-optimization/114967] Missed optimization: std::min((int) f, -a) ==> -a where (bool f, unsigned char a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114967 --- Comment #3 from Andrew Pinski --- I had a patch for this which I didn't finish up and I hope to get it done for GCC 15.
[Bug tree-optimization/114969] [11/12/13/14/15 Regression] Missed optimization: (bool)((std::max((unsigned long long) 0, (unsigned long long) var_0)) | ( var_0 ? 1 : 0)) => (bool) var_0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114969 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111542 --- Comment #1 from Andrew Pinski --- very similar to PR 111542 .
[Bug tree-optimization/114967] Missed optimization: std::min((int) f, -a) ==> -a where (bool f, unsigned char a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114967
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=107888
--- Comment #2 from Andrew Pinski ---
We are able to handle this:
```
void func1(bool f, unsigned char a) {
int t = f;
int tt = -a;
int ttt = t <= tt ? t : tt;
n = ttt;
}
```
And we able to handle func if we disable evrp.
So yes the issue is the same as what I mentioned. Basically this is what I
mentioned in bug 107888 comment #2 . But in the original testcase in bug 107888
was able to be handled differently, it is the other testcase that still needs
to be handled.
[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Xi Ruoyao changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67640 --- Comment #8 from Xi Ruoyao --- Very similar to PR67640.
[Bug tree-optimization/112392] `a == nonnegative ? a : abs` -> abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112392 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-May/651 ||006.html --- Comment #3 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651006.html
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2024-05-08
Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #7 from Xi Ruoyao ---
Patch only tested barely:
diff --git a/gcc/opts-common.cc b/gcc/opts-common.cc
index 4a2dff243b0..2d1e86ff94f 100644
--- a/gcc/opts-common.cc
+++ b/gcc/opts-common.cc
@@ -1152,6 +1152,7 @@ prune_options (struct cl_decoded_option
**decoded_options,
unsigned int options_to_prepend = 0;
unsigned int Wcomplain_wrong_lang_idx = 0;
unsigned int fdiagnostics_color_idx = 0;
+ unsigned int fdiagnostics_urls_idx = 0;
/* Remove arguments which are negated by others after them. */
new_decoded_options_count = 0;
@@ -1185,6 +1186,12 @@ prune_options (struct cl_decoded_option
**decoded_options,
++options_to_prepend;
fdiagnostics_color_idx = i;
continue;
+ case OPT_fdiagnostics_urls_:
+ gcc_checking_assert (i != 0);
+ if (fdiagnostics_urls_idx == 0)
+ ++options_to_prepend;
+ fdiagnostics_urls_idx = i;
+ continue;
default:
gcc_assert (opt_idx < cl_options_count);
@@ -1248,6 +1255,12 @@ keep:
= old_decoded_options[fdiagnostics_color_idx];
new_decoded_options_count++;
}
+ if (fdiagnostics_urls_idx != 0)
+ {
+ new_decoded_options[argv_0 + options_prepended++]
+ = old_decoded_options[fdiagnostics_urls_idx];
+ new_decoded_options_count++;
+ }
gcc_checking_assert (options_to_prepend == options_prepended);
}
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 Andrew Pinski changed: What|Removed |Added Known to work||11.4.1 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Andrew Pinski --- Fixed everywhere.
[Bug middle-end/88670] [meta-bug] generic vector extension issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670 Bug 88670 depends on bug 89224, which changed state. Bug 89224 Summary: [11/12/13/14/15 Regression] subscript of const vector has the wrong type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 --- Comment #22 from GCC Commits --- The releases/gcc-11 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:046aeffba336295fbdaf0e1ecf64b582d08f0aa6 commit r11-11419-g046aeffba336295fbdaf0e1ecf64b582d08f0aa6 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the array type. We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the overloads and even if it is a lvalue or rvalue is correctly done. Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb. Built and tested for aarch64-linux-gnu. PR c++/89224 gcc/c-family/ChangeLog: * c-common.c (convert_vector_to_array_for_subscript): Call build_qualified_type for the inner type. gcc/cp/ChangeLog: * constexpr.c (cxx_eval_array_reference): Compare main variants for the vector/array types instead of the types directly. gcc/testsuite/ChangeLog: * g++.dg/torture/vector-subaccess-1.C: New test. * gcc.dg/pr83415.c: Change warning to error. Signed-off-by: Andrew Pinski (cherry picked from commit 4421d35167b3083e0f2e4c84c91fded09a30cf22)
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #6 from Xi Ruoyao --- Looks like when the driver invokes cc1, -fdiagnostics-urls=never seems always after -W... options: $ echo "" | LANG= ./gcc/xgcc -fdiagnostics-urls=never -Wtarget-lifetime -x c - -B gcc -v -c Reading specs from gcc/specs COLLECT_GCC=./gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr LD=ld --enable-languages=c,c++ --enable-default-pie --enable-default-ssp --disable-multilib --disable-bootstrap --disable-fixincludes --with-system-zlib --enable-host-pie Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240507 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fdiagnostics-urls=never' '-Wtarget-lifetime' '-B' 'gcc' '-v' '-c' '-mtune=generic' '-march=x86-64' gcc/cc1 -quiet -v -iprefix /home/xry111/git-repos/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/15.0.0/ -isystem gcc/include -isystem gcc/include-fixed - -quiet -dumpbase - -mtune=generic -march=x86-64 -Wtarget-lifetime -version -fdiagnostics-urls=never -o /tmp/ccqETyrO.s cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but not for C ... ...
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
--- Comment #5 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #4)
> -fdiagnostics-plain-output does:
> /* If you have changed the default diagnostics output, and this new
> output is not appropriately "plain" (e.g., the change needs to
> be
> undone in order for the testsuite to work properly), then
> please do
> the following:
> 1. Add the necessary option to undo the new behavior to
> the array below.
> 2. Update the documentation for -fdiagnostics-plain-output
> in invoke.texi. */
> const char *const expanded_args[] = {
> "-fno-diagnostics-show-caret",
> "-fno-diagnostics-show-line-numbers",
> "-fdiagnostics-color=never",
> "-fdiagnostics-urls=never",
> "-fdiagnostics-path-format=separate-events",
> "-fdiagnostics-text-art-charset=none"
> };
The problem is -fdiagnostics-urls=never itself seems not working.
Note that if I invoke cc1 directly and put -fdiagnostics-urls=never *before*
the offending option:
echo "" | LANG= ./gcc/cc1 -fdiagnostics-urls=never -Wtarget-lifetime -x c -
cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but
not for C
It works. But if I put it *after* the offending option:
echo "" | LANG= ./gcc/cc1 -Wtarget-lifetime -fdiagnostics-urls=never -x c -
cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but
not for C
-Wtarget-lifetime in the message becomes a link.
However if I invoke the driver (xgcc) -fdiagnostics-urls=never just does not
work no matter before -Wtarget-lifetime or after it.
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
--- Comment #4 from Andrew Pinski ---
-fdiagnostics-plain-output does:
/* If you have changed the default diagnostics output, and this new
output is not appropriately "plain" (e.g., the change needs to be
undone in order for the testsuite to work properly), then please
do
the following:
1. Add the necessary option to undo the new behavior to
the array below.
2. Update the documentation for -fdiagnostics-plain-output
in invoke.texi. */
const char *const expanded_args[] = {
"-fno-diagnostics-show-caret",
"-fno-diagnostics-show-line-numbers",
"-fdiagnostics-color=never",
"-fdiagnostics-urls=never",
"-fdiagnostics-path-format=separate-events",
"-fdiagnostics-text-art-charset=none"
};
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > I have not seen this failure ... Yes it's strange. I didn't see the failures building 14.1.0-RC1 but I saw them building 14.1.0, though RC1 definitely outputs the hyperlink like 14.1.0.
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #2 from Andrew Pinski --- I have not seen this failure ...
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #1 from Xi Ruoyao --- Also happens for "command-line option ... is valid for ... but not for ..." warnings: $ env -i PATH=$PATH TERM=xterm-256colors cc hw.c -fdiagnostics-urls=never -Wtarget-lifetime cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but not for C -Wtarget-lifetime has become a hyperlink.
[Bug other/114980] New: [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
Bug ID: 114980
Summary: [14/15 Regression] -fdiagnostics-urls=never does not
suppress URLs in `'-Werror=' argument '-Werror=...'
not valid for ...` warnings
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
$ cat hw.c
#include
int
main ()
{
printf ("Hello, world.\n");
}
$ env -i PATH=$PATH TERM=xterm-256colors LANG= cc hw.c -fdiagnostics-urls=never
-Werror=target-lifetime
cc1: warning: '-Werror=' argument '-Werror=target-lifetime' is not valid for C
But with GCC 14.1.0 the "-Werror" and "-Werror=target-lifetime" are hyperlinks.
This causes several test failures like:
spawn -ignore SIGHUP /home/xry111/sources/lfs/gcc-14.1.0/build/gcc/xgcc
-B/home/xry111/sources/lfs/gcc-14.1.0/build/gcc/
/home/xry111/sources/lfs/gcc-14.1.0/gcc/testsuite/gcc.dg/pr91172.c
-fdiagnostics-plain-output -Werror=target-lifetime -S -o pr91172.s
cc1: warning:
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=^[]8;;^G'
argument
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=target-lifetime^[]8;;^G'
is not valid for C
FAIL: gcc.dg/pr91172.c at line 3 (test for warnings, line )
FAIL: gcc.dg/pr91172.c (test for excess errors)
Excess errors:
cc1: warning:
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=^[]8;;^G'
argument
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=target-lifetime^[]8;;^G'
is not valid for C
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 --- Comment #21 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:315f8a474eb1a9b2d213aa650bdb132c78546264 commit r12-10420-g315f8a474eb1a9b2d213aa650bdb132c78546264 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the array type. We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the overloads and even if it is a lvalue or rvalue is correctly done. Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb. Built and tested for aarch64-linux-gnu. PR c++/89224 gcc/c-family/ChangeLog: * c-common.cc (convert_vector_to_array_for_subscript): Call build_qualified_type for the inner type. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Compare main variants for the vector/array types instead of the types directly. gcc/testsuite/ChangeLog: * g++.dg/torture/vector-subaccess-1.C: New test. * gcc.dg/pr83415.c: Change warning to error. Signed-off-by: Andrew Pinski (cherry picked from commit 4421d35167b3083e0f2e4c84c91fded09a30cf22)
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #5 from chenglulu --- I will verify it on multiple machines to see if the problem can be reproduced.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #9 from LIU Hao --- (In reply to Jakub Jelinek from comment #8) > Created attachment 58123 [details] > gcc15-pr114968.patch > > This is what I'd do, but completely untested... Thanks. I am gonna give it a run.
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 --- Comment #20 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f5d9eef6507f36692066c0934d9f8c9d462e698f commit r13-8713-gf5d9eef6507f36692066c0934d9f8c9d462e698f Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the array type. We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the overloads and even if it is a lvalue or rvalue is correctly done. Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb. Built and tested for aarch64-linux-gnu. PR c++/89224 gcc/c-family/ChangeLog: * c-common.cc (convert_vector_to_array_for_subscript): Call build_qualified_type for the inner type. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Compare main variants for the vector/array types instead of the types directly. gcc/testsuite/ChangeLog: * g++.dg/torture/vector-subaccess-1.C: New test. * gcc.dg/pr83415.c: Change warning to error. Signed-off-by: Andrew Pinski (cherry picked from commit 4421d35167b3083e0f2e4c84c91fded09a30cf22)
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 --- Comment #19 from GCC Commits --- The releases/gcc-14 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:cacc48014c7fdb888b4449830b567e5375dfb4e3 commit r14-10183-gcacc48014c7fdb888b4449830b567e5375dfb4e3 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the array type. We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the overloads and even if it is a lvalue or rvalue is correctly done. Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb. Built and tested for aarch64-linux-gnu. PR c++/89224 gcc/c-family/ChangeLog: * c-common.cc (convert_vector_to_array_for_subscript): Call build_qualified_type for the inner type. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Compare main variants for the vector/array types instead of the types directly. gcc/testsuite/ChangeLog: * g++.dg/torture/vector-subaccess-1.C: New test. * gcc.dg/pr83415.c: Change warning to error. Signed-off-by: Andrew Pinski (cherry picked from commit 4421d35167b3083e0f2e4c84c91fded09a30cf22)
[Bug c++/114856] [14/15 regression][modules] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856 Nathaniel Shead changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Nathaniel Shead --- Fixed for GCC 14.2 and trunk.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 114856, which changed state. Bug 114856 Summary: [14/15 regression][modules] ICE (segfault) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/114856] [14/15 regression][modules] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:61a095b05c244a6e0b1aec36ee1607def00654ab commit r14-10182-g61a095b05c244a6e0b1aec36ee1607def00654ab Author: Nathaniel Shead Date: Tue Apr 30 22:29:57 2024 +1000 c++/modules: Stream unmergeable temporaries by value again [PR114856] In r14-9266-g2823b4d96d9ec4 I gave all temporary vars a DECL_CONTEXT, including those at namespace or global scope, so that they could be properly merged across importers. However, not all of these temporary vars are actually supposed to be mergeable. For instance, in the attached testcase we have an unnamed temporary var used in the NSDMI of a class member, which cannot properly merged -- but it also doesn't need to be, as it'll be thrown away when the class type itself is merged anyway. This patch reverts the change made above and instead makes a weaker adjustment that only causes temporary vars with linkage have a DECL_CONTEXT to merge from. This way these unnamed, "unmergeable" temporaries are properly streamed by value again. PR c++/114856 gcc/cp/ChangeLog: * call.cc (make_temporary_var_for_ref_to_temp): Set context for temporaries with linkage. * init.cc (create_temporary_var): Revert to only set context when in a function decl. gcc/testsuite/ChangeLog: * g++.dg/modules/pr114856.h: New test. * g++.dg/modules/pr114856_a.H: New test. * g++.dg/modules/pr114856_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill Reviewed-by: Patrick Palka (cherry picked from commit e60032b382364897a58e67994baac896bcd03327)
[Bug c++/114856] [14/15 regression][modules] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114856 --- Comment #3 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:e60032b382364897a58e67994baac896bcd03327 commit r15-310-ge60032b382364897a58e67994baac896bcd03327 Author: Nathaniel Shead Date: Tue Apr 30 22:29:57 2024 +1000 c++/modules: Stream unmergeable temporaries by value again [PR114856] In r14-9266-g2823b4d96d9ec4 I gave all temporary vars a DECL_CONTEXT, including those at namespace or global scope, so that they could be properly merged across importers. However, not all of these temporary vars are actually supposed to be mergeable. For instance, in the attached testcase we have an unnamed temporary var used in the NSDMI of a class member, which cannot properly merged -- but it also doesn't need to be, as it'll be thrown away when the class type itself is merged anyway. This patch reverts the change made above and instead makes a weaker adjustment that only causes temporary vars with linkage have a DECL_CONTEXT to merge from. This way these unnamed, "unmergeable" temporaries are properly streamed by value again. PR c++/114856 gcc/cp/ChangeLog: * call.cc (make_temporary_var_for_ref_to_temp): Set context for temporaries with linkage. * init.cc (create_temporary_var): Revert to only set context when in a function decl. gcc/testsuite/ChangeLog: * g++.dg/modules/pr114856.h: New test. * g++.dg/modules/pr114856_a.H: New test. * g++.dg/modules/pr114856_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill Reviewed-by: Patrick Palka
[Bug tree-optimization/114972] [11/12/13/14/15 Regression] Missed optimization for Dead Code Elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114972 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-05-07 --- Comment #1 from Andrew Pinski --- Confirmed. FRE was able to do: RHS a.0_13 + b.1_14 simplified to a.0_3 + b.1_4 has constants 0 But then in GCC 6 it can't see that it is that. Maybe when something moved over to match and simplify it is missed ...
[Bug c++/114974] CTAD: gcc rejects some valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114974
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-05-07
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. Slightly reduced:
```
template
struct A1 {
template
struct A2 { T2 t; };
};
void s(double k) {
A1::A2 a(2);
}
```
It looks like the deduction guide is not being generated correctly when the
inner template class is of a templated class. If A1 was not a template, GCC
acecpts the code just fine. that is:
```
struct A1 {
template
struct A2 { T2 t; };
};
void s(double k) {
A1::A2 a(2);
}
```
Works just fine.
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 Andrew Pinski changed: What|Removed |Added Known to work||15.0 --- Comment #18 from Andrew Pinski --- Fixed on the trunk, backporting as approved right now.
[Bug c++/89224] [11/12/13/14/15 Regression] subscript of const vector has the wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224 --- Comment #17 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:4421d35167b3083e0f2e4c84c91fded09a30cf22 commit r15-309-g4421d35167b3083e0f2e4c84c91fded09a30cf22 Author: Andrew Pinski Date: Tue Feb 20 13:38:28 2024 -0800 c++/c-common: Fix convert_vector_to_array_for_subscript for qualified vector types [PR89224] After r7-987-gf17a223de829cb, the access for the elements of a vector type would lose the qualifiers. So if we had `constvector[0]`, the type of the element of the array would not have const on it. This was due to a missing build_qualified_type for the inner type of the vector when building the array type. We need to add back the call to build_qualified_type and now the access has the correct qualifiers. So the overloads and even if it is a lvalue or rvalue is correctly done. Note we correctly now reject the testcase gcc.dg/pr83415.c which was incorrectly accepted after r7-987-gf17a223de829cb. Built and tested for aarch64-linux-gnu. PR c++/89224 gcc/c-family/ChangeLog: * c-common.cc (convert_vector_to_array_for_subscript): Call build_qualified_type for the inner type. gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Compare main variants for the vector/array types instead of the types directly. gcc/testsuite/ChangeLog: * g++.dg/torture/vector-subaccess-1.C: New test. * gcc.dg/pr83415.c: Change warning to error. Signed-off-by: Andrew Pinski
[Bug tree-optimization/114872] [13/14/15 Regression] Miscompilation with -O2 after commit r13-8037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114872 --- Comment #22 from Sergei Trofimovich --- Trying again to catch more precise place for SIGABRT. Beginning at the start of the possibly aborting function: (gdb) break __pyx_pf_4sage_4libs_3gap_7element_19GapElement_Function_2__call__ (gdb) continue Running step by step to get the rough location: (gdb) continue # many times (gdb) 26459 __pyx_t_6 = __Pyx_GetItemInt_List(__pyx_v_a, 2, long, 1, __Pyx_PyInt_From_long, 1, 0, 1); if (unlikely(!__pyx_t_6)) __PYX_ERR(0, 2528, __pyx_L14_error) (gdb) 26469 __pyx_v_result = GAP_CallFunc3Args(__pyx_v_self->__pyx_base.value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_5)->value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_4)->value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_6)->value); (gdb) Thread 1 "sage-ipython" received signal SIGABRT, Aborted. 0x7f73e4a617a7 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) Don't know why backtrace does not point at element.c:26459. It is this snippet: /* "sage/libs/gap/element.pyx":2525 *(a[1]).value) * elif n == 3: * result = GAP_CallFunc3Args(self.value, # << *(a[0]).value, *(a[1]).value, */ __pyx_v_result = GAP_CallFunc3Args(__pyx_v_self->__pyx_base.value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_5)->value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_4)->value, ((struct __pyx_obj_4sage_4libs_3gap_7element_GapElement *)__pyx_t_6)->value);
[Bug c++/84411] Missed optimization: static guard variable generated for empty virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 Bug 84411 depends on bug 19661, which changed state. Bug 19661 Summary: unnecessary atexit calls emitted for static objects with empty destructors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #21 from Andrew Pinski --- Fixed.
[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661 --- Comment #20 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c9dd853680b12d9c9def5de61abde5d057c526ba commit r15-308-gc9dd853680b12d9c9def5de61abde5d057c526ba Author: Andrew Pinski Date: Fri Mar 15 16:34:22 2024 -0700 DCE __cxa_atexit calls where the function is pure/const [PR19661] In C++ sometimes you have a deconstructor function which is "empty", like for an example with unions or with arrays. The front-end might not know it is empty either so this should be done on during optimization.o To implement it I added it to DCE where we mark if a statement is necessary or not. Bootstrapped and tested on x86_64-linux-gnu with no regressions. Changes since v1: * v2: Add support for __aeabi_atexit for arm-*eabi. Add extra comments. Add cxa_atexit-5.C testcase for -fPIC case. * v3: Fix testcases for the __aeabi_atexit (forgot to do in the v2). PR tree-optimization/19661 gcc/ChangeLog: * tree-ssa-dce.cc (is_cxa_atexit): New function. (is_removable_cxa_atexit_call): New function. (mark_stmt_if_obviously_necessary): Don't mark removable cxa_at_exit calls. (mark_all_reaching_defs_necessary_1): Likewise. (propagate_necessity): Likewise. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/cxa_atexit-1.C: New test. * g++.dg/tree-ssa/cxa_atexit-2.C: New test. * g++.dg/tree-ssa/cxa_atexit-3.C: New test. * g++.dg/tree-ssa/cxa_atexit-4.C: New test. * g++.dg/tree-ssa/cxa_atexit-5.C: New test. * g++.dg/tree-ssa/cxa_atexit-6.C: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/61110] Simplify value_replacement in phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110 Bug 61110 depends on bug 114894, which changed state. Bug 114894 Summary: `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b` https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/114894] `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug tree-optimization/114894] `a == 0 ? 0 : a * b` -> `a * b` likewise for `a & b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114894 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e472527c7b45d23e8dfd0fb767a6e663b4bc136e commit r15-307-ge472527c7b45d23e8dfd0fb767a6e663b4bc136e Author: Andrew Pinski Date: Tue Apr 30 14:45:26 2024 -0700 MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match This adds a few more of what is currently done in phiopt's value_replacement to match. I noticed this when I was hooking up phiopt's value_replacement code to use match and disabling the old code. But this can be done independently from the hooking up phiopt's value_replacement as phiopt is already hooked up for simplified versions already. /* a != 0 ? a / b : 0 -> a / b iff b is nonzero. */ /* a != 0 ? a * b : 0 -> a * b */ /* a != 0 ? a & b : 0 -> a & b */ We prefer the `cond ? a : 0` forms to allow optimization of `a * cond` which uses that form. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/114894 gcc/ChangeLog: * match.pd (`a != 0 ? a / b : 0`): New pattern. (`a != 0 ? a * b : 0`): New pattern. (`a != 0 ? a & b : 0`): New pattern. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-value-5.c: New test. Signed-off-by: Andrew Pinski
[Bug c++/114854] [11/12/13/14/15 Regression] checking ICE with default initializer of const reference member at cp/cp-gimplify.cc:900 since r10-5822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114854
--- Comment #2 from Marek Polacek ---
I'm using this slightly modified test:
```
class Vector {
int m_size;
};
struct S {
const Vector {};
};
void spawn(S);
void test() { spawn({}); }
```
To initialize S we generate:
D.2848 = {.vec=(const struct Vector &) _EXPR }
where the TARGET_EXPR is marked TARGET_EXPR_DIRECT_INIT_P, so we expect it to
be elided. But here it serves as a temporary for Vector{} to which the
reference is bound, so I think it can't be TARGET_EXPR_DIRECT_INIT_P.
[Bug c++/114970] [14/15 Regression] 32-bit ARM gcc-14.1 new false positive -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970 Andrew Pinski changed: What|Removed |Added Summary|32-bit ARM gcc-14.1 new |[14/15 Regression] 32-bit |false positive |ARM gcc-14.1 new false |-Wunused-value |positive -Wunused-value Target|arm |arm*-*-*eabi Target Milestone|--- |14.2 --- Comment #1 from Andrew Pinski --- This looks related to constructor return this where with ARM EABI constructors (and deconstructors return this) and we produce: <"}, (struct basic_string_view *) >; Note "this" of is there. Let me try to reduce this a little bit. I might not get to it until week after next though.
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 114459, which changed state. Bug 114459 Summary: [C++26] P2893R3 - Variadic friends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 114459, which changed state. Bug 114459 Summary: [C++26] P2893R3 - Variadic friends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114459] [C++26] P2893R3 - Variadic friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Implemented for 15.1.
[Bug c++/114459] [C++26] P2893R3 - Variadic friends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114459 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:17458d2bc74b904968e6bdc12527eb040c8d2370 commit r15-304-g17458d2bc74b904968e6bdc12527eb040c8d2370 Author: Jakub Jelinek Date: Tue May 7 22:38:01 2024 +0200 c++: Implement C++26 P2893R3 - Variadic friends [PR114459] The following patch imeplements the C++26 P2893R3 - Variadic friends paper. The paper allows for the friend type declarations to specify more than one friend type specifier and allows to specify ... at the end of each. The patch doesn't introduce tentative parsing of friend-type-declaration non-terminal, but rather just extends existing parsing where it is a friend declaration which ends with ; after the declaration specifiers to the cases where it ends with ...; or , or ..., In that case it pedwarns for cxx_dialect < cxx26, handles the ... and if there is , continues in a loop to parse the further friend type specifiers. 2024-05-07 Jakub Jelinek PR c++/114459 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_variadic_friend=202403L for C++26. gcc/cp/ * parser.cc (cp_parser_member_declaration): Implement C++26 P2893R3 - Variadic friends. Parse friend type declarations with ... or with more than one friend type specifier. * friend.cc (make_friend_class): Allow TYPE_PACK_EXPANSION. * pt.cc (instantiate_class_template): Handle PACK_EXPANSION_P in friend classes. gcc/testsuite/ * g++.dg/cpp26/feat-cxx26.C (__cpp_variadic_friend): Add test. * g++.dg/cpp26/variadic-friend1.C: New test.
[Bug target/114979] Spurious eax clears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979 --- Comment #3 from Andrew Pinski --- (In reply to Jorge Acereda from comment #2) > Thanks for the prompt reply. I understand the behaviour for external > functions, but for static functions, isn't it a missed opportunity for > optimization? The question comes is the function still a non-prototyped function or not even if there is a definition. The answer is yes it is still a non-prototyped function. Anyways this does not matter that much since C23 changes () to be always prototyped and the same as (void). Also a zeroing of the register does only takes up icache space and does not get issued as it is taken care of during rename on most (if not all) modern x86_64 cores. So this is a very very minor space savings at best.
[Bug target/114979] Spurious eax clears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979 --- Comment #2 from Jorge Acereda --- Thanks for the prompt reply. I understand the behaviour for external functions, but for static functions, isn't it a missed opportunity for optimization?
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #11 from Jakub Jelinek --- Should be fixed for 14.2+ for now.
[Bug sanitizer/114956] [11/12/13 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14/15 Regression] |[11/12/13 Regression] |Segmentation fault with |Segmentation fault with |-fsanitize=address |-fsanitize=address |-fsanitize=null -O2 when|-fsanitize=null -O2 when |attribute |attribute |no_sanitize_address is |no_sanitize_address is |enabled since r9-5742 |enabled since r9-5742 --- Comment #6 from Jakub Jelinek --- Fixed for 14.2 and later for now.
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f43f346f19889a15a171a10c6ae1b1fe0a5bc038 commit r14-10181-gf43f346f19889a15a171a10c6ae1b1fe0a5bc038 Author: Jakub Jelinek Date: Tue May 7 21:30:21 2024 +0200 expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907] The HF and BF modes have the same size/precision and neither is a subset nor superset of the other. So, using either __extendhfbf2 or __trunchfbf2 is weird. The expansion apparently emits __extendhfbf2, but on the libgcc side we apparently have __trunchfbf2 implemented. I think it is easier to switch to using what is available rather than adding new entrypoints to libgcc, even alias, because this is backportable. 2024-05-07 Jakub Jelinek PR middle-end/114907 * expr.cc (convert_mode_scalar): Use trunc_optab rather than sext_optab for HF->BF conversions. * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise. * gcc.dg/pr114907.c: New test. (cherry picked from commit 28ee13db2e9d995bd3728c4ff3a3545e24b39cd2)
[Bug sanitizer/114956] [11/12/13/14/15 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:aca573ea64ccfd54d4447e9a3200acd7a9157082 commit r14-10180-gaca573ea64ccfd54d4447e9a3200acd7a9157082 Author: Jakub Jelinek Date: Tue May 7 21:29:14 2024 +0200 tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956] In r9-5742 we've started allowing to inline always_inline functions into functions which have disabled e.g. address sanitization even when the always_inline function is implicitly from command line options sanitized. This mostly works fine because most of the asan instrumentation is done only late after ipa, but as the following testcase the .ASAN_MARK ifn calls gimplifier adds can result in ICEs. Fixed by dropping those during inlining, similarly to how we drop .TSAN_FUNC_EXIT calls. 2024-05-07 Jakub Jelinek PR sanitizer/114956 * tree-inline.cc: Include asan.h. (copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan sanitization disabled. * gcc.dg/asan/pr114956.c: New test. (cherry picked from commit d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a)
[Bug middle-end/114907] __trunchfbf2 should be renamed to __extendhfbf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114907 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:28ee13db2e9d995bd3728c4ff3a3545e24b39cd2 commit r15-303-g28ee13db2e9d995bd3728c4ff3a3545e24b39cd2 Author: Jakub Jelinek Date: Tue May 7 21:30:21 2024 +0200 expansion: Use __trunchfbf2 calls rather than __extendhfbf2 [PR114907] The HF and BF modes have the same size/precision and neither is a subset nor superset of the other. So, using either __extendhfbf2 or __trunchfbf2 is weird. The expansion apparently emits __extendhfbf2, but on the libgcc side we apparently have __trunchfbf2 implemented. I think it is easier to switch to using what is available rather than adding new entrypoints to libgcc, even alias, because this is backportable. 2024-05-07 Jakub Jelinek PR middle-end/114907 * expr.cc (convert_mode_scalar): Use trunc_optab rather than sext_optab for HF->BF conversions. * optabs-libfuncs.cc (gen_trunc_conv_libfunc): Likewise. * gcc.dg/pr114907.c: New test.
[Bug sanitizer/114956] [11/12/13/14/15 Regression] Segmentation fault with -fsanitize=address -fsanitize=null -O2 when attribute no_sanitize_address is enabled since r9-5742
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114956 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d4e25cf4f7c1f51a8824cc62bbb85a81a41b829a commit r15-302-gd4e25cf4f7c1f51a8824cc62bbb85a81a41b829a Author: Jakub Jelinek Date: Tue May 7 21:29:14 2024 +0200 tree-inline: Remove .ASAN_MARK calls when inlining functions into no_sanitize callers [PR114956] In r9-5742 we've started allowing to inline always_inline functions into functions which have disabled e.g. address sanitization even when the always_inline function is implicitly from command line options sanitized. This mostly works fine because most of the asan instrumentation is done only late after ipa, but as the following testcase the .ASAN_MARK ifn calls gimplifier adds can result in ICEs. Fixed by dropping those during inlining, similarly to how we drop .TSAN_FUNC_EXIT calls. 2024-05-07 Jakub Jelinek PR sanitizer/114956 * tree-inline.cc: Include asan.h. (copy_bb): Remove also .ASAN_MARK calls if id->dst_fn has asan/hwasan sanitization disabled. * gcc.dg/asan/pr114956.c: New test.
[Bug c/71255] Implement #pragma may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 --- Comment #31 from Florian Weimer --- Fixed via r7-1272. Thanks!
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968 --- Comment #8 from Jakub Jelinek --- Created attachment 58123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58123=edit gcc15-pr114968.patch This is what I'd do, but completely untested...
[Bug c/71255] Implement #pragma may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|SUSPENDED |RESOLVED --- Comment #30 from Marek Polacek --- Looks like there's nothing more to do.
[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/113768] gm2/extensions/run/pass/vararg2.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113768 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/113768] gm2/extensions/run/pass/vararg2.mod FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113768 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:07dab3f6b56c711dcd737d856cf01a597a2e1626 commit r14-10179-g07dab3f6b56c711dcd737d856cf01a597a2e1626 Author: Gaius Mulley Date: Tue May 7 19:51:08 2024 +0100 [PR modula2/113768][PR modula2/114133] bugfix constants must be cast prior to vararg call This bug fix corrects the test codes below by converting the constant literals to the type required by C. In the testcases below the values, 1 etc were converted into the INTEGER type before being passed to a C vararg function. By default in modula2 constant literal ordinals are represented as the ZTYPE (the largest GCC integer type node). gcc/testsuite/ChangeLog: PR modula2/113768 PR modula2/114133 * gm2/extensions/run/pass/callingc10.mod: Convert constant literal numbers into INTEGER. * gm2/extensions/run/pass/callingc11.mod: Ditto. * gm2/extensions/run/pass/vararg2.mod: Ditto. * gm2/iso/run/pass/packed.mod: Emit a printf as a runtime diagnostic. Signed-off-by: Gaius Mulley
[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133 --- Comment #5 from GCC Commits --- The releases/gcc-14 branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:07dab3f6b56c711dcd737d856cf01a597a2e1626 commit r14-10179-g07dab3f6b56c711dcd737d856cf01a597a2e1626 Author: Gaius Mulley Date: Tue May 7 19:51:08 2024 +0100 [PR modula2/113768][PR modula2/114133] bugfix constants must be cast prior to vararg call This bug fix corrects the test codes below by converting the constant literals to the type required by C. In the testcases below the values, 1 etc were converted into the INTEGER type before being passed to a C vararg function. By default in modula2 constant literal ordinals are represented as the ZTYPE (the largest GCC integer type node). gcc/testsuite/ChangeLog: PR modula2/113768 PR modula2/114133 * gm2/extensions/run/pass/callingc10.mod: Convert constant literal numbers into INTEGER. * gm2/extensions/run/pass/callingc11.mod: Ditto. * gm2/extensions/run/pass/vararg2.mod: Ditto. * gm2/iso/run/pass/packed.mod: Emit a printf as a runtime diagnostic. Signed-off-by: Gaius Mulley
[Bug tree-optimization/114952] False positive -Wmaybe-uninitialized starting at -O3 in libbpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114952 --- Comment #3 from Andrew Pinski --- Note I don't think this is a `False positive` exactly because GCC has no knowledge that errno could be non-zero after a fail call to open.
[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110908 --- Comment #6 from zach-gcc at cs dot stanford.edu --- I've resumed using GCC for this project, where I am instrumenting assembly and require that x30 only ever contain addresses (not arbitrary data). I ran into a case where GCC was storing data in x30 while compiling libgcc. The patch listed above appears to have solved the problem. If possible, it would be great for the patch to be merged into mainline. Thanks!
[Bug target/114979] Spurious eax clears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- >From the ABI: For calls that may call functions that use varargs or stdargs (prototype-less calls or calls to functions containing ellipsis (...) in the declaration) %al (16) is used as hidden argument to specify the number of vector registers used. 16) Note that the rest of %rax is undefined, only the contents of %al is defined. In this case you have a prototype-less call still. clang seems to recognize it as one having a prototype here because of the final definition but I am not 100% sure if that is correct.
[Bug modula2/114133] problem passing a string pointer to a C function on solaris 32 bit and 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114133 --- Comment #4 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:76e591200f54226290ddb49b8ac6231a694bf882 commit r15-300-g76e591200f54226290ddb49b8ac6231a694bf882 Author: Gaius Mulley Date: Tue May 7 19:24:08 2024 +0100 PR modula2/114133 bugfix constants must be cast prior to vararg call This bug fix corrects the test codes below by converting the constant literals to the type required by C. In the testcases below the values, 1 etc were converted into the INTEGER type before being passed to a C vararg function. By default in modula2 constant literal ordinals are represented as the ZTYPE (the largest GCC integer type node). gcc/testsuite/ChangeLog: PR modula2/114133 * gm2/extensions/run/pass/callingc10.mod: Convert constant literal numbers into INTEGER. * gm2/extensions/run/pass/callingc11.mod: Ditto. * gm2/extensions/run/pass/vararg2.mod: Ditto. * gm2/iso/run/pass/packed.mod: Emit a printf as a runtime diagnostic. Signed-off-by: Gaius Mulley
[Bug c/114979] New: Spurious eax clears
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114979 Bug ID: 114979 Summary: Spurious eax clears Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jacereda at gmail dot com Target Milestone: --- Created attachment 58122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58122=edit Code to reproduce the problem. This is the version I'm using (although I've checked in several versions and it's the same): COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/gnu/store/vjjk375kysja1jz0837lypd09rdgs47c-gcc-13.2.0/libexec/gcc/x86_64-unknown-linux-gnu/13.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.0 (GCC) When compiled with -O2, the attached program generates what I'd consider normal code on clang, MSVC and even MinGW gcc, that is, something that looks like: 0040 : 40: e8 eb ff ff ff call 30 45: e8 e6 ff ff ff call 30 4a: e8 e1 ff ff ff call 30 4f: e8 dc ff ff ff call 30 54: e8 d7 ff ff ff call 30 59: eb d5 jmp30 Instead, it will generate: 0040 : 40: 31 c0 xor%eax,%eax 42: e8 e9 ff ff ff call 30 47: 31 c0 xor%eax,%eax 49: e8 e2 ff ff ff call 30 4e: 31 c0 xor%eax,%eax 50: e8 db ff ff ff call 30 55: 31 c0 xor%eax,%eax 57: e8 d4 ff ff ff call 30 5c: 31 c0 xor%eax,%eax 5e: e8 cd ff ff ff call 30 63: 31 c0 xor%eax,%eax 65: eb c9 jmp30 Declaring the functions as taking void will fix the problem. Same goes for compiling with g++. I know void is the right thing in C, but I can't see any reason to perform those clears. Regards, Jorge Acereda
[Bug target/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #4 from Xi Ruoyao --- s/suspicious/skeptical/
[Bug target/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Target||loongarch64-*-* Component|fortran |target --- Comment #3 from Xi Ruoyao --- Changed component to target for now. I'm suspicious about the 10% regression on x86_64. IIRC there are already multiple bug reports complaining some 5% SPEC regression on x86_64, so I'll be really surprised if there is really a 10% regression on x86_64 but it's not already reported.
[Bug fortran/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Xi Ruoyao --- I don't have a SPEC access so I cannot confirm or dis-confirm the issue.
[Bug fortran/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Sam James changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Summary|548.exchange2_r 14%-28% |[14/14 regression] |regressions on Loongarch64 |548.exchange2_r 14%-28% |after gcc 14 snapshot |regressions on Loongarch64 |20240317|after gcc 14 snapshot ||20240317 --- Comment #1 from Sam James --- Neither of the two loong maintainers seem to have accounts on BZ (?) so CCIng xry111. Apologies if I missed their accounts.
[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #8 from Sam James --- Thanks. It will be. *** This bug has been marked as a duplicate of bug 114931 ***
[Bug c/114931] [14 regression] ICE in get_alias_set when building tcl with -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114931 --- Comment #20 from Sam James --- *** Bug 114971 has been marked as a duplicate of this bug. ***
[Bug fortran/114978] New: 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Bug ID: 114978 Summary: 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chz0808 at gmail dot com Target Milestone: --- We tested Loongarch64 CPU Loongson 3A6000 with "LA664" architecture in Linux operating system AOSC OS 11.4.0 (default gcc version is 13.2.0). And we found the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered significant regressions from 14% to 28% with various compiling options. The rate-1 results are following: after snapshot 20240317 score 14.3-19.3% lower with parameters "-g -Ofast -march=native": 13.2.0:11.7 (223s) [gcc 13.2.0, system default] 20240317: 11.0 (237s) [gcc 14 snapshot 20240317] 20240324: 8.88 (295s) [gcc 14 snapshot 20240324] 20240430: 9.03 (290s) [gcc 14 snapshot 20240430, 14.1.0-RC] 14.1.0:9.43 (278s) [gcc 14.1.0 release] after snapshot 20240317 score 16.5-20.8% lower with parameters "-g -Ofast -march=native -flto": 13.2.0:12.0 (218s) 20240317: 10.6 (248s) 20240324: 8.40 (312s) 20240430: 8.48 (309s) 14.1.0:8.85 (296s) after snapshot 20240317 score 18-23.1% lower with parameters "-g -Ofast -march=la664": 13.2.0:"-march=la664" flag is not supported 20240317: 11.5 (227s) 20240324: 8.84 (296s) 20240430: 9.43 (278s) 14.1.0:9.42 (278s) after snapshot 20240317 score 20.3-21.2% lower with parameters "-g -Ofast -march=la664 -flto": 13.2.0:"-march=la664" flag is not supported 20240317: 11.1 (236s) 20240324: 8.75 (299s) 20240430: 8.85 (296s) 14.1.0:8.85 (296s) after snapshot 20240317 score 26.3-26.6% lower with parameters "-g -Ofast -march=la464": 13.2.0:8.76 (299s) 20240317: 12.8 (205s) 20240324: 9.39 (279s) 20240430: 9.43 (278s) 14.1.0:9.43 (278s) after snapshot 20240317 score 26.6-28% lower with parameters "-g -Ofast -march=la464 -flto": 13.2.0:8.52 (307s) 20240317: 12.8 (204s) 20240324: 9.22 (284s) 20240430: 9.37 (280s) 14.1.0:9.40 (279s) The gcc 14 snapshots and gcc 14.1.0 are compiled with the following parameters: --enable-shared --enable-threads=posix --with-system-zlib --enable-gnu-indirect-function --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --disable-multilib --disable-werror --enable-pie --enable-checking=release --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --enable-default-pie --enable-default-ssp --enable-bootstrap --enable-languages=c,c++,fortran,lto --with-abi=lp64d --with-arch=loongarch64 --with-tune=la664 --build=loongarch64-aosc-linux-gnu The regression may be found on other types of CPUs as well. We did a quick test on AMD Zen4 CPU R9 7940HS and found similar but smaller regression: The rate-1 results on x86_64 (AMD R9 7940HS) with operating system Debian 12: after snapshot 20240317 score 8.6-9.6% lower with parameters "-m64 -g -Ofast -march=znver3": 12.2.0:30.1 (87.0s) [gcc 12.2.0, system default] 13.2.0:30.6 (85.7s) [gcc 13.2 release] 20240317: 31.4 (83.3s) [gcc 14 snapshot] 20240324: 28.7 (91.2s) [gcc 14 snapshot] 20240430: 28.4 (92.2s) [gcc 14 snapshot, 14.1.0-RC] after snapshot 20240317 score 10% lower with parameters "-m64 -g -Ofast -march=znver3 -flto": 12.2.0:29.0 (90.3s) 13.2.0:30.9 (84.9s) 20240317: 32.0 (81.8s) 20240324: 28.8 (90.9s) 20240430: 28.8 (91.1s) gcc13 and gcc14 are compiled with the following parameters: --enable-shared --enable-threads=posix --with-system-zlib --enable-gnu-indirect-function --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --disable-multilib --disable-werror --enable-pie --enable-checking=release --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=new --enable-default-pie --enable-default-ssp --enable-bootstrap --enable-languages=c,c++,fortran,lto --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
[Bug c/114973] 14.1.0 - internal compiler error: 'verify_type' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114973 --- Comment #4 from Ozkan Sezer --- (In reply to Richard Biener from comment #2) > This a different incarnation of PR114931, fixed on trunk as well already (I > just checked). > > *** This bug has been marked as a duplicate of bug 114931 *** Confirmed that trunk has it fixed. Fix hopefully gets backported soon.
[Bug c/114971] gcc-14.1.0, ICE in get_alias_set, at alias.cc:954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114971 --- Comment #7 from Ozkan Sezer --- (In reply to Sam James from comment #6) > Please check if trunk works, as a fix for that PR was committed not long ago. Confirmed that trunk has it fixed. Fix hopefully gets backported soon.
[Bug c++/114977] New: C++20 parenthesized aggregate initialization copy-inits from {} instead of value-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114977
Bug ID: 114977
Summary: C++20 parenthesized aggregate initialization
copy-inits from {} instead of value-init
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mital at mitalashok dot co.uk
Target Milestone: ---
When implementing , unlike when initializing with
aggregate initialization where each element that is not explicitly initialized
is initialized from `{}` (), when
direct-initializing they should be value-initialized
( for aggregate
classes, ).
It seems like GCC initializes from `{}` anyways, as seen by this compiling
:
#include
struct A {
A(std::initializer_list);
};
A a[3]({}, {}); // a[2] should be value-initialized and fail
struct B {
int i;
A a;
};
B b(1); // b.a should be value-initialized and fail
[Bug target/114976] New: MIPS64: get double high part can use mfhc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114976
Bug ID: 114976
Summary: MIPS64: get double high part can use mfhc1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: syq at gcc dot gnu.org
Target Milestone: ---
```
unsigned int
__mips_mfhc1 (double x)
{
unsigned int ret;
union {
unsigned long long i;
double d;
} xx;
xx.d=x;
ret = xx.i>>32;
return ret;
}
```
For R2+, we can just use `mfhc1`, while currently the output is
```
dmfc1 $2,$f12
jr $31
dsra$2,$2,32
```
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965 --- Comment #12 from Paul Eggert --- Thanks for fixing GCC. I installed into Gnulib a patch that clarifies strftime's implementation, and this also works around the GCC bug. It'll take some time for this to propagate out, though, as Gnulib is a source code library and each package incorporates Gnulib code when it sees fit. The patch is here: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4121ae7ad2859331447fe719d255e3d22953f327
[Bug tree-optimization/114965] [13/14/15 Regression] wrong code generated for Emacs/Gnulib strftime (regression from 13.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114965 --- Comment #11 from Jakub Jelinek --- Created attachment 58121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58121=edit gcc15-pr114965.patch Full untested fix.
[Bug libstdc++/109822] Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:4d7a770f2d1dc9d7e7b79788c201ba22bd52cf06 commit r13-8706-g4d7a770f2d1dc9d7e7b79788c201ba22bd52cf06 Author: Matthias Kretz Date: Fri Jun 2 21:33:04 2023 +0200 libstdc++: Avoid vector casts while still avoiding PR90424 Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/109822 * include/experimental/bits/simd_builtin.h (_S_store): Rewrite to avoid casts to other vector types. Implement store as succession of power-of-2 sized memcpy to avoid PR90424. (cherry picked from commit 9165ede56ababd6471e7a2ce4eab30f3d5129e14)
[Bug libstdc++/114750] converting load/store of simd fails compilation on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:4505045dadaa58b0f165479d038d8f0247aea8cc commit r13-8709-g4505045dadaa58b0f165479d038d8f0247aea8cc Author: Matthias Kretz Date: Wed Apr 17 09:11:25 2024 +0200 libstdc++: Avoid ill-formed types on ARM This resolves failing tests in check-simd. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114750 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_load, _S_store): Fall back to copying scalars if the memory type cannot be vectorized for the target. (cherry picked from commit 0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35)
[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110050 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:e6b19675fb3397992a8f88ef031d57c4dcd73cd6 commit r13-8703-ge6b19675fb3397992a8f88ef031d57c4dcd73cd6 Author: Matthias Kretz Date: Thu Jun 1 10:40:14 2023 +0200 libstdc++: Fix condition for supported SIMD types on ARMv8 Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110050 * include/experimental/bits/simd.h (__vectorized_sizeof): With __have_neon_a32 only single-precision float works (in addition to integers). (cherry picked from commit 2fbbaa77c8468ed2bdf2cfa1a5890991e4e98eef)
[Bug libstdc++/110054] stdx::simd masked store should not use non-temporal store instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110054 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:63b73f14be97a9fe8621ec1a523b6dd19bde72dc commit r13-8705-g63b73f14be97a9fe8621ec1a523b6dd19bde72dc Author: Matthias Kretz Date: Fri Jun 2 13:44:22 2023 +0200 libstdc++: Replace use of incorrect non-temporal store The call to the base implementation sometimes didn't find a matching signature because the _Abi parameter of _SimdImpl* was "wrong" after conversion. It has to call into ::_SimdImpl instead of the current ABI tag's _SimdImpl. This also reduces the number of possible template instantiations. Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/110054 * include/experimental/bits/simd_builtin.h (_S_masked_store): Call into deduced ABI's SimdImpl after conversion. * include/experimental/bits/simd_x86.h (_S_masked_store_nocvt): Don't use _mm_maskmoveu_si128. Use the generic fall-back implementation. Also fix masked stores without SSE2, which were not doing anything before. (cherry picked from commit 27e45b7597d6fb1a71927d658a0294797b720c0a)
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:6663f2a04c16288124d5ef918c661260e4f66284 commit r13-8712-g6663f2a04c16288124d5ef918c661260e4f66284 Author: Matthias Kretz Date: Mon Apr 22 16:12:34 2024 +0200 libstdc++: Fix conversion of simd to vector builtin Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114803 * include/experimental/bits/simd_builtin.h (_SimdBase2::operator __vector_type_t): There is no __builtin() function in _SimdWrapper, instead use its conversion operator. * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New test. (cherry picked from commit 7ef139146a8923a8719873ca3fdae175668e8d63)
[Bug tree-optimization/114876] [11/12/13 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13 Regression] |-fprintf-return-value |-fprintf-return-value |mishandles %lc with a '\0' |mishandles %lc with a '\0' |argument. |argument. --- Comment #8 from Jakub Jelinek --- Fixed for 14.2+ as well.
[Bug tree-optimization/114876] [11/12/13/14 Regression] -fprintf-return-value mishandles %lc with a '\0' argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114876
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a1c8ae15d9df0caa839b47c8631571a1ec27e367
commit r14-10177-ga1c8ae15d9df0caa839b47c8631571a1ec27e367
Author: Jakub Jelinek
Date: Tue Apr 30 11:22:32 2024 +0200
gimple-ssa-sprintf: Use [0, 1] range for %lc with (wint_t) 0 argument
[PR114876]
Seems when Martin S. implemented this, he coded there strict reading
of the standard, which said that %lc with (wint_t) 0 argument is handled
as wchar_t[2] temp = { arg, 0 }; %ls with temp arg and so shouldn't print
any values. But, most of the libc implementations actually handled that
case like %c with '\0' argument, adding a single NUL character, the only
known exception is musl.
Recently, C23 changed this in response to GB-141 and POSIX in
https://austingroupbugs.net/view.php?id=1647
so that it should have the same behavior as %c with '\0'.
Because there is implementation divergence, the following patch uses
a range rather than hardcoding it to all 1s (i.e. the %c behavior),
though the likely case is still 1 (forward looking plus most of
implementations).
The res.knownrange = true; assignment removed is redundant due to
the same assignment done unconditionally before the if statement,
rest is formatting fixes.
I don't think the min >= 0 && min < 128 case is right either, I'd think
it should be min >= 0 && max < 128, otherwise it is just some possible
inputs are (maybe) ASCII and there can be others, but this code is a total
mess anyway, with the min, max, likely (somewhere in [min, max]?) and then
unlikely possibly larger than max, dunno, perhaps for at least some chars
in the ASCII range the likely case could be for the ascii case; so perhaps
just the one_2_one_ascii shouldn't set max to 1 and mayfail should be true
for max >= 128. Anyway, didn't feel I should touch that right now.
2024-04-30 Jakub Jelinek
PR tree-optimization/114876
* gimple-ssa-sprintf.cc (format_character): For min == 0 && max ==
0,
set max, likely and unlikely members to 1 rather than 0. Remove
useless res.knownrange = true;. Formatting fixes.
* gcc.dg/pr114876.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust expected
diagnostics.
(cherry picked from commit 6c6b70f07208ca14ba783933988c04c6fc2fff42)
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #7 from Jakub Jelinek ---
(In reply to LIU Hao from comment #6)
> I suspect this isn't correct. I am getting strange errors like 'ld exited
> with code 5' not sure what could cause it (possibly also recent MSYS2
> updates):
>
> ```
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 2af026d255d..f5dce6a93bc 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -9669,6 +9669,16 @@ get_atexit_fn_ptr_type (void)
>
>fn_type = build_function_type_list (void_type_node,
> arg_type, NULL_TREE);
> +#ifdef IX86_CALLCVT_THISCALL
> + if (flag_use_cxa_atexit
> + && !targetm.cxx.use_atexit_for_cxa_atexit ())
> +{
> + fn_type = copy_node (fn_type);
> + TYPE_ATTRIBUTES (fn_type) = tree_cons (
> +get_identifier ("thiscall"), NULL_TREE,
> +TYPE_ATTRIBUTES (fn_type));
> +}
> +#endif
>atexit_fn_ptr_type_node = build_pointer_type (fn_type);
> }
>
> diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
> index f1ffda22fd3..00a8843fa2e 100644
> --- a/gcc/cp/except.cc
> +++ b/gcc/cp/except.cc
> @@ -648,6 +648,12 @@ build_throw (location_t loc, tree exp, tsubst_flags_t
> complain)
> {
> tree tmp = build_function_type_list (void_type_node,
> ptr_type_node, NULL_TREE);
> +#ifdef IX86_CALLCVT_THISCALL
> + tmp = copy_node (tmp);
> + TYPE_ATTRIBUTES (tmp) = tree_cons (
> +get_identifier ("thiscall"), NULL_TREE,
> +TYPE_ATTRIBUTES (tmp));
> +#endif
> cleanup_type = build_pointer_type (tmp);
> }
>
>
> ```
Besides wrong formatting and the case that you need to build_variant_type (or
build_distinct_type?, one needs to look at what will be normally done if you
do:
void (__attribute__((thiscall)) *fn) (void);
), you really can't do it like that. IX86_CALLCVT_THISCALL is defined on all
x86_64/i?86 targets, so not limited to mingw 32-bit.
[Bug target/114968] [14/15 Regression] missing `__thiscall` attribute on builtin declaration of `__cxa_thread_atexit()`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114968
--- Comment #6 from LIU Hao ---
I suspect this isn't correct. I am getting strange errors like 'ld exited with
code 5' not sure what could cause it (possibly also recent MSYS2 updates):
```
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 2af026d255d..f5dce6a93bc 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -9669,6 +9669,16 @@ get_atexit_fn_ptr_type (void)
fn_type = build_function_type_list (void_type_node,
arg_type, NULL_TREE);
+#ifdef IX86_CALLCVT_THISCALL
+ if (flag_use_cxa_atexit
+ && !targetm.cxx.use_atexit_for_cxa_atexit ())
+{
+ fn_type = copy_node (fn_type);
+ TYPE_ATTRIBUTES (fn_type) = tree_cons (
+get_identifier ("thiscall"), NULL_TREE,
+TYPE_ATTRIBUTES (fn_type));
+}
+#endif
atexit_fn_ptr_type_node = build_pointer_type (fn_type);
}
diff --git a/gcc/cp/except.cc b/gcc/cp/except.cc
index f1ffda22fd3..00a8843fa2e 100644
--- a/gcc/cp/except.cc
+++ b/gcc/cp/except.cc
@@ -648,6 +648,12 @@ build_throw (location_t loc, tree exp, tsubst_flags_t
complain)
{
tree tmp = build_function_type_list (void_type_node,
ptr_type_node, NULL_TREE);
+#ifdef IX86_CALLCVT_THISCALL
+ tmp = copy_node (tmp);
+ TYPE_ATTRIBUTES (tmp) = tree_cons (
+get_identifier ("thiscall"), NULL_TREE,
+TYPE_ATTRIBUTES (tmp));
+#endif
cleanup_type = build_pointer_type (tmp);
}
```
[Bug target/114835] AVR popcountqi2 is not fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835 --- Comment #3 from Georg-Johann Lay --- (In reply to Wolfgang Hospital from comment #0) > When establishing the "popcount" of an uint8_t, I've seen GCC to widen the > value to "half int" and use __popcountqi2 twice. This is a different issue, please f'up PR114975.
[Bug target/114835] AVR popcountqi2 is not fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Georg-Johann Lay --- Fixed in v15.
[Bug middle-end/114975] New: [AVR] Using popcounthi2 for 8-bit values despit popcountqi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114975
Bug ID: 114975
Summary: [AVR] Using popcounthi2 for 8-bit values despit
popcountqi2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
C test case
typedef __UINT8_TYPE__ uint8_t;
uint8_t use_pop (uint8_t x)
{
return __builtin_popcount (x);
}
compiles with
$ avr-gcc pop.c -Os -S
to:
use_pop:
ldi r25,0
rcall __popcounthi2
ret
.ident "GCC: (GNU) 14.0.1 20240421 (experimental)"
despite libgcc providing __popcountqi2.
I am not even sure which component is supposed to treat this. The tree
optimizers do only __builtin_popcount, and as there's nothing like popcount_u8
they cannot do anything about it. So blaming the middle-end for now.
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 --- Comment #15 from jeevitha at linux dot ibm.com --- On 07/05/24 1:53 am, bergner at gcc dot gnu.org wrote: > That said, Jeevitha, now that we're in stage1, can you please post your patch? > Sure Peter.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 114889, which changed state. Bug 114889 Summary: [modules] ICE in friend_accessible_p with imported class template specialization befriending class template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/114889] [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for GCC 14.2
[Bug c++/114889] [modules] ICE in friend_accessible_p with imported class template specialization befriending class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114889 --- Comment #2 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:390bd23fd9c98dc40856beef05364f5d1c7b9d04 commit r14-10176-g390bd23fd9c98dc40856beef05364f5d1c7b9d04 Author: Patrick Palka Date: Mon Apr 29 21:27:59 2024 -0400 c++/modules: imported spec befriending class tmpl [PR114889] When adding to CLASSTYPE_BEFRIENDING_CLASSES as part of installing an imported class definition, we need to look through TEMPLATE_DECL like make_friend_class does. Otherwise in the below testcase we won't add _Hashtable to CLASSTYPE_BEFRIENDING_CLASSES of _Map_base, which leads to a bogus access check failure for _M_hash_code. PR c++/114889 gcc/cp/ChangeLog: * module.cc (trees_in::read_class_def): Look through TEMPLATE_DECL when adding to CLASSTYPE_BEFRIENDING_CLASSES. gcc/testsuite/ChangeLog: * g++.dg/modules/friend-8_a.H: New test. * g++.dg/modules/friend-8_b.C: New test. Reviewed-by: Jason Merrill (cherry picked from commit 22b20ac6c6aead2d3f36c413a77dd0b80adfec39)
[Bug target/108189] anonymous struct declared inside parameter list will not be visible outside of this definition or declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108189 --- Comment #14 from Daniel Xu --- Yeah, I saw that. But that only makes the build not fail right? For bpftrace we are trying hard to be warning-free. FWIW I tried adding `-std=gnu2x` and it didn't help.
[Bug target/114835] AVR popcountqi2 is not fast as can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114835 --- Comment #1 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:8d2c93fcfe1afc5291bbbe162c3b7ad5764f6d8d commit r15-286-g8d2c93fcfe1afc5291bbbe162c3b7ad5764f6d8d Author: Wolfgang Hospital Date: Tue May 7 16:24:39 2024 +0200 AVR: target/114835 - Tweak popcountqi2 libgcc/ PR target/114835 * config/avr/lib1funcs.S (__popcountqi2): Use code that is one instruction shorter / faster.
[Bug c++/99678] [concepts] requires-clause allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678
Patrick Palka changed:
What|Removed |Added
Summary|c++20 trailing requires |[concepts] requires-clause
|clauses allows undeclared |allows undeclared
|identifier |identifier
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
>From PR114946:
(In reply to Nathaniel Shead from comment #0)
> The following sample compiles fine with 'g++ -std=c++20 -pedantic-errors':
>
> template
> requires
> struct S {};
>
> template
> requires
> void foo() {}
>
> Note that '' has not been declared or defined. Both MSVC and Clang
> complain about the undeclared identifier. GCC does error if we attempt to
> instantiate either of these specialisations, but they always (silently) lose
> to a better match:
>
> template struct S {};
> template requires struct S {};
>
> template void foo() {}
> template requires void foo() {}
>
> int main() {
> S x;
> foo();
> }
[Bug c++/99678] c++20 trailing requires clauses allows undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99678 Patrick Palka changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #1 from Patrick Palka --- *** Bug 114946 has been marked as a duplicate of this bug. ***
[Bug c++/114946] [concepts] No error for invalid requires constraint in declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114946 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 99678 ***
[Bug c++/114974] New: CTAD: gcc rejects some valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114974
Bug ID: 114974
Summary: CTAD: gcc rejects some valid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hokein.wu at gmail dot com
Target Milestone: ---
gcc trunk rejects the following valid CTAD code:
```
template
struct A1 {
template
struct A2 { T2 t; };
};
template
void s(K k) {
A1::A2 a(2);
}
void s() {
s(1.0);
}
```
https://godbolt.org/z/7bxEbhP47
It looks like in this case gcc fails? to generate the aggregate deduction
guide.
[Bug libstdc++/114866] [14/15 Regression] & out_ptr in freestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9927059bb88e966e0a45f09e4fd1193f93df708f commit r15-284-g9927059bb88e966e0a45f09e4fd1193f93df708f Author: Jonathan Wakely Date: Thu May 2 12:14:52 2024 +0100 libstdc++: Fix for -std=c++23 -ffreestanding [PR114866] std::shared_ptr isn't declared for freestanding, so guard uses of it with #if _GLIBCXX_HOSTED in . libstdc++-v3/ChangeLog: PR libstdc++/114866 * include/bits/out_ptr.h [!_GLIBCXX_HOSTED]: Don't refer to shared_ptr, __shared_ptr or __is_shred_ptr. * testsuite/20_util/headers/memory/114866.cc: New test.
[Bug rtl-optimization/114674] [aarch64] ldp_fusion fails to merge 2 strs due to imprecise alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alex Coplan --- Fixed for GCC 15, thanks for the report.
