[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #16 from Andrew Pinski ---
The only patch which is needed now:
diff --git a/gcc/match.pd b/gcc/match.pd
index 37c5be9e5f4..ca6c9eff624 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4729,10 +4729,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(for cmp (simple_comparison)
scmp (swapped_simple_comparison)
(simplify
- (cmp (bit_not@2 @0) CONSTANT_CLASS_P@1)
+ (cmp (nop_convert?:s (bit_not@2 @0)) CONSTANT_CLASS_P@1)
(if (single_use (@2)
&& (TREE_CODE (@1) == INTEGER_CST || TREE_CODE (@1) == VECTOR_CST))
- (scmp @0 (bit_not @1)
+ (with { tree type1 = TREE_TYPE (@1); }
+(scmp (convert:type1 @0) (bit_not @1))
(for cmp (simple_comparison)
/* Fold (double)float1 CMP (double)float2 into float1 CMP float2. */
I will add a testcase and submit it in a few.
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 --- Comment #21 from Aldy Hernandez --- (In reply to Jeffrey A. Law from comment #20) > Your c#19 was a bit hard to follow. But you hit the key issue. Ughh sorry. I'm running on fumes here :-).
[Bug tree-optimization/103226] [12 Regression] Recent change to copy-headers causes execution failure for gcc.dg/torture/pr80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P4 --- Comment #20 from Jeffrey A. Law --- Your c#19 was a bit hard to follow. But you hit the key issue. Namely that the doloop pattern will set/clobber the condition codes if it gets split. Failure to show that clobber means that IRA/LRA have incorrect dataflow and make incorrect decisions. I'm testing the obvious fix of adding the clobber. It may be possible to improve on my patch, but I'll leave that to someone who really cares about the port.
[Bug c++/103339] New: [modules] ICE in exporting module on use of outside specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103339
Bug ID: 103339
Summary: [modules] ICE in exporting module on use of outside
specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/onW6h5vej.
mod.cpp:
```C++
export module mod;
export template struct trait { };
export template concept C = true;
template concept has_trait = C>;
```
test.cpp:
```C++
import mod;
template struct trait { };
```
Output:
```
test.cpp:2:31: internal compiler error: in import_entity_index, at
cp/module.cc:3953
2 | template struct trait { };
| ^
0x206aac9 internal_error(char const*, ...)
???:0
0x7d92db fancy_abort(char const*, int, char const*)
???:0
0x966072 module_may_redeclare(tree_node*)
???:0
0xaab517 begin_class_definition(tree_node*)
???:0
0xa0b065 c_parse_file()
???:0
0xb931d2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/103220] missed casting issue with |/&?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Novembe ||r/585057.html Keywords||patch --- Comment #3 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585057.html
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alexandre Oliva --- Fixed
[Bug tree-optimization/102988] ICE with -fharden-conditional-branches and C++ and pass by reference return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988 --- Comment #6 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:38e4a361e79a459947540920db645f3d7fa7221a commit r12-5429-g38e4a361e79a459947540920db645f3d7fa7221a Author: Alexandre Oliva Date: Sat Nov 20 02:51:27 2021 -0300 harden conds: detach without decls When we create copies of SSA_NAMEs to hold "detached" copies of the values for the hardening tests, we end up with assignments to SSA_NAMEs that refer to the same decls. That would be generally desirable, since it enables the variable to be recognized in dumps, and makes coalescing more likely if the original variable dies at that point. When the decl is a DECL_BY_REFERENCE, the SSA_NAME holds the address of a parm or result, and it's read-only, so we shouldn't create assignments to it. Gimple checkers flag at least the case of results. This patch arranges for us to avoid referencing the same decls, which cures the problem, but retaining the visible association between the SSA_NAMEs, by using the same identifier for the copy. for gcc/ChangeLog PR tree-optimization/102988 * gimple-harden-conditionals.cc (detach_value): Copy SSA_NAME without decl sharing. for gcc/testsuite/ChangeLog PR tree-optimization/102988 * g++.dg/pr102988.C: New.
[Bug c++/103338] [9/10/11/12 Regression] ICE: in tsubst_pack_expansion with invalid template friend and packed expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338 Andrew Pinski changed: What|Removed |Added Known to fail||7.1.0 Ever confirmed|0 |1 Last reconfirmed||2021-11-20 Status|UNCONFIRMED |NEW Summary|ICE: in |[9/10/11/12 Regression] |tsubst_pack_expansion, at |ICE: in |cp/pt.c:13167 |tsubst_pack_expansion with ||invalid template friend and ||packed expression Known to work||6.4.0 Target Milestone|--- |9.5 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/103338] New: ICE: in tsubst_pack_expansion, at cp/pt.c:13167
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338
Bug ID: 103338
Summary: ICE: in tsubst_pack_expansion, at cp/pt.c:13167
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
[7/8/9/10/11/12 Regression]
template
struct zip_view {
struct Iterator;
};
template
struct zip_transform_view;
template
struct zip_view::Iterator {
template
template
friend class zip_transform_view::Iterator;
};
zip_view<>::Iterator iter;
https://godbolt.org/z/95Yvq4heP
[Bug jit/96889] Reflection API accessible from the jit C API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- Fixed in master.
[Bug jit/96889] Reflection API accessible from the jit C API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889 --- Comment #2 from CVS Commits --- The master branch has been updated by Antoni Boucher : https://gcc.gnu.org/g:cfe8dbd9c08a5bce497646467c9d30942ec3efe0 commit r12-5428-gcfe8dbd9c08a5bce497646467c9d30942ec3efe0 Author: Antoni Boucher Date: Fri Nov 19 20:44:34 2021 -0500 libgccjit: Add some reflection functions [PR96889] 2021-11-19 Antoni Boucher gcc/jit/ PR target/96889 * docs/topics/compatibility.rst (LIBGCCJIT_ABI_16): New ABI tag. * docs/topics/functions.rst: Add documentation for the functions gcc_jit_function_get_return_type and gcc_jit_function_get_param_count * docs/topics/types.rst: Add documentation for the functions gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, and gcc_jit_struct_get_field_count * libgccjit.c: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New functions. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * libgccjit.h: (gcc_jit_function_get_return_type, gcc_jit_function_get_param_count, gcc_jit_function_type_get_return_type, gcc_jit_function_type_get_param_count, gcc_jit_function_type_get_param_type, gcc_jit_type_unqualified, gcc_jit_type_dyncast_array, gcc_jit_type_is_bool, gcc_jit_type_dyncast_function_ptr_type, gcc_jit_type_is_integral, gcc_jit_type_is_pointer, gcc_jit_type_dyncast_vector, gcc_jit_vector_type_get_element_type, gcc_jit_vector_type_get_num_units, gcc_jit_struct_get_field, gcc_jit_type_is_struct, gcc_jit_struct_get_field_count): New function declarations. (struct gcc_jit_function_type, struct gcc_jit_vector_type): New types. * jit-recording.h: New functions (is_struct and is_vector) * libgccjit.map (LIBGCCJIT_ABI_16): New ABI tag. gcc/testsuite/ PR target/96889 * jit.dg/all-non-failing-tests.h: Add test-reflection.c. * jit.dg/test-reflection.c: New test.
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
--- Comment #5 from Dominique Martinet ---
Ah, this apparently needed the unused fields in the struct, and the extra
config_init() call.
Here's something trimmed down from the actual program instead of building back
up:
-
#define _POSIX_C_SOURCE 200809L
#include
#include
#include
struct state {
const char *confpath;
const char *host;
const char *port;
const char *state_dir_prefix;
};
static inline char *xstrdup(const char *s) {
char *val = strdup(s);
if (!val)
abort();
return val;
}
int config_init(struct state *config);
int main(int argc, char *argv[]) {
int rc;
struct state state = { 0 };
config_init();
while ((rc = getopt(argc, argv, "H:p:")) != -1) {
switch (rc) {
case 'H':
free((void*)state.host);
state.host = xstrdup(optarg);
break;
case 'p':
free((void*)state.port);
state.port = xstrdup(optarg);
break;
}
}
free((void*)state.host);
free((void*)state.port);
return rc;
}
-
-
/opt/gcc/bin/gcc -fanalyzer -c ../copytool/coordinatool.c
In function ‘main’:
cc1: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak]
‘main’: events 1-4
|
|../copytool/coordinatool.c:25:5:
| 25 | int main(int argc, char *argv[]) {
| | ^~~~
| | |
| | (1) entry to ‘main’
|..
| 31 | while ((rc = getopt(argc, argv, "H:p:")) != -1) {
| |~~~
| | |
| | (2) following
‘true’ branch (when ‘rc != -1’)...
| 32 | switch (rc) {
| | ~~
| | |
| | (3) ...to here
|..
| 39 | state.port = xstrdup(optarg);
| | ~~~
| | |
| | (4) calling ‘xstrdup’ from
‘main’
|
+--> ‘xstrdup’: events 5-9
|
| 16 | static inline char *xstrdup(const char *s) {
| | ^~~
| | |
| | (5) entry to ‘xstrdup’
| 17 | char *val = strdup(s);
| | ~
| | |
| | (6) allocated here
| 18 | if (!val)
| |~
| ||
| |(7) assuming ‘val’ is non-NULL
| |(8) following ‘false’ branch (when ‘val’ is
non-NULL)...
| 19 | abort();
| 20 | return val;
| |~~~
| ||
| |(9) ...to here
|
<--+
|
‘main’: event 10
|
| 39 | state.port = xstrdup(optarg);
| | ^~~
| | |
| | (10) returning to ‘main’ from
‘xstrdup’
|
‘main’: event 11
|
|cc1:
| (11): ‘’ leaks here; was allocated at (6)
|
-
Thanks!
[Bug tree-optimization/103220] missed casting issue with |/&?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220 --- Comment #2 from Andrew Pinski --- Simple fix: diff --git a/gcc/match.pd b/gcc/match.pd index 24a84e3b504..37c5be9e5f4 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -1607,7 +1607,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (bitop (convert@2 @0) (convert?@3 @1)) (if (((TREE_CODE (@1) == INTEGER_CST && INTEGRAL_TYPE_P (TREE_TYPE (@0)) -&& int_fits_type_p (@1, TREE_TYPE (@0))) +&& (int_fits_type_p (@1, TREE_TYPE (@0)) +|| tree_nop_conversion_p (TREE_TYPE (@0), type))) || types_match (@0, @1)) /* ??? This transform conflicts with fold-const.c doing Convert (T)(x & c) into (T)x & (T)c, if c is an integer
[Bug tree-optimization/103220] missed casting issue with |/&?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Last reconfirmed||2021-11-20
--- Comment #1 from Andrew Pinski ---
This actually reduces down to just:
unsigned char f(unsigned char a)
{
signed char d = (signed char) a;
signed char e = d & ~1;
unsigned char t = e;
t &= ~2;
return t;
}
Not reducing to:
unsigned char f1(unsigned char a)
{
return a & ~3;
}
Most likely because of the int_fits_type_p in match.pd which returns false when
switching signs. Let me look into that issue.
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
Dominique Martinet changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #4 from Dominique Martinet ---
Thanks for the fix!
I've compiled gcc from master and can confirm this fixes the warning for the
example I provided... But unfortunately it doesn't fix it for my real
application, so my reproducer was simplified too much :/
(It fails on this file:
https://github.com/cea-hpc/coordinatool/blob/06c5e319e3c934256d51c2af3ba5f7551bac4bff/copytool/coordinatool.c
, but this project requires lustre development headers to compile so it's not a
good reproducer)
Here's a new attempt, this also gives a similar warning without a precise
location on gcc master:
---
#include
#include
#include
char *xstrdup(const char *src) {
char *val = strdup(src);
if (!val)
abort();
return val;
}
struct test {
char *one, *two;
};
int main(int argc, char *argv[]) {
struct test *options = calloc(1, sizeof(*options));
int rc;
if (!options)
abort();
while ((rc = getopt(argc, argv, "a:b:")) != -1) {
switch (rc) {
case 'a':
free(options->one);
options->one = xstrdup(optarg);
break;
case 'b':
free(options->two);
options->two = xstrdup(optarg);
break;
}
}
free(options->one);
free(options->two);
free(options);
return 0;
}
---
In function ‘main’:
cc1: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak]
‘main’: events 1-2
|
|/tmp/t4.c:16:5:
| 16 | int main(int argc, char *argv[]) {
| | ^~~~
| | |
| | (1) entry to ‘main’
|..
| 19 | if (!options)
| |~
| ||
| |(2) following ‘false’ branch (when ‘options’ is
non-NULL)...
|
‘main’: event 3
|
|cc1:
| (3): ...to here
|
‘main’: events 4-6
|
| 22 | while ((rc = getopt(argc, argv, "a:b:")) != -1) {
| |~~^
| | |
| | (4) following
‘true’ branch (when ‘rc != -1’)...
| 23 | switch (rc) {
| | ~~
| | |
| | (5) ...to here
|..
| 30 | options->two = xstrdup(optarg);
| |~~~
| ||
| |(6) calling ‘xstrdup’ from
‘main’
|
+--> ‘xstrdup’: events 7-11
|
|5 | char *xstrdup(const char *src) {
| | ^~~
| | |
| | (7) entry to ‘xstrdup’
|6 | char *val = strdup(src);
| | ~~~
| | |
| | (8) allocated here
|7 | if (!val)
| |~
| ||
| |(9) assuming ‘val’ is non-NULL
| |(10) following ‘false’ branch (when ‘val’ is
non-NULL)...
|8 | abort();
|9 | return val;
| |~~~
| ||
| |(11) ...to here
|
<--+
|
‘main’: event 12
|
| 30 | options->two = xstrdup(optarg);
| |^~~
| ||
| |(12) returning to ‘main’
from ‘xstrdup’
|
‘main’: event 13
|
|cc1:
| (13): ‘’ leaks here; was allocated at (8)
|
I'm not sure it's accurate enough for my usecase though: in my project the
"option" struct is declared on the stack and not dynamically allocated... and I
cannot reproduce with "struct test option = { 0 };" so I'm not sure where this
is different; I'll try a bit more and update this ticket if I find a better
reproducer.
(What do you prefer to move forward -- I've tried reopening the bug but you
really fixed something so should I open a new bz instead and keep this
resolved?)
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-11-20 --- Comment #8 from David Malcolm --- Thanks for working on this. I believe the current status is that I found some nits in review as above, along with: https://gcc.gnu.org/pipermail/jit/2021q2/001305.html so the current status is: waiting on an updated patch.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #3 from Antoni --- No. The only patch that is ready for review is "libgccjit: add some reflection functions in the jit C api".
[Bug c++/69549] Named Address Spaces does not compile in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549 --- Comment #9 from jwjagersma at gmail dot com --- Created attachment 51840 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51840=edit diagnostics This patch adds checks for: - Top-level AS-qualifiers on fields, local variables, function parameters and function return types. - Assignment of pointers and references to different address spaces. - Combining AS-qualifiers in template substitution. An appropriate error message is emitted in each case. Not detected: AS-qualifiers on non-type template parameters (but they are stripped and ignored, of course). I think this covers most invalid uses. Am I missing anything?
[Bug jit/95415] Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from David Malcolm --- Thanks for working on this. I think the current state is that I reviewed the patch here: https://gcc.gnu.org/pipermail/jit/2021q2/001306.html and found some issues with it, so this is waiting on an updated patch.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-11-20 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks for working on this; sorry for the delay in reviewing your various patches. I think that the current status of this is that I found some issues when reviewing it; see: https://gcc.gnu.org/pipermail/jit/2021q2/001303.html Is there an updated version after that that I've missed?
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 --- Comment #7 from Martin Jambor --- (In reply to hubicka from comment #5) > > I like the idea of transformation phases better than putting > > everything into tree-inline (and by extension ipa-param-manipulation) > > but perhaps we have to do aggregate constant replacements there too? > > So the situation is that we inline call A->B (where both A and B are > clones of the main function) and while we place uses of the constant > parmater in A we miss replacement in B because transform is not run on > it. No, we miss it everywhere, even in A (see that the code above is from BB 2) or probably also without any cloning whatsoever. This happens when IPA-SRA does its thing on the same parameter on which IPA-CP decided to propagate aggregate constants. In the IPA analysis stage (which creates the virtual clones), IPA-CP runs before IPA-SRA. But in the transformation phase, it is apparently the other way round - well, not exactly, IPA-SRA does not formally have a transformation phase, it happens as part of tree_function_versioning, but the effect is the same. > > I think proper solution here (discussed also few years ago) is to keep > the optimization summaries and teach value numbering to look up the > constant from the summary. > Yes, but this is another (but different) problem that we probably also should try to solve now.
[Bug c/90941] [rfe] attribute to specify write-once static variable for early-initialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941
Cristian Rodríguez changed:
What|Removed |Added
CC||crrodriguez at opensuse dot org
--- Comment #3 from Cristian Rodríguez ---
a variable __attribute__(("write_once")) will indeed be extremely useful,
genertating compile time errors if more than one write to the variable is
detected and either a warning and/or a __builtin_trap() when it cannot prove
it.
The idea of reusing restrict is also reasonable..hope this can gain some
traction.
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #6 from Jan Hubicka ---
struct a{int a,b;};
int bar (struct a *a)
{
if (!a->a)
__builtin_abort ();
}
static
__attribute__ ((noinline))
int foo (struct a a)
{
struct a b = a;
bar ();
return b.a+b.b;
}
int
test()
{
struct a a={1,2};
return foo (a);
}
Is an example where we also miss transformation with -fno-early-inlining -O2
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 --- Comment #5 from hubicka at kam dot mff.cuni.cz --- > I like the idea of transformation phases better than putting > everything into tree-inline (and by extension ipa-param-manipulation) > but perhaps we have to do aggregate constant replacements there too? So the situation is that we inline call A->B (where both A and B are clones of the main function) and while we place uses of the constant parmater in A we miss replacement in B because transform is not run on it. I think proper solution here (discussed also few years ago) is to keep the optimization summaries and teach value numbering to look up the constant from the summary. We also have other situations where the existing transform pass fails to pattern match and this lets us to feed other info, like value ranges to the optimizer. We have open PR somwhere for this problem, right?
[Bug c++/101180] [12 Regression] Rejected code since r12-299-ga0fdff3cf33f7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b751b225e4f02cf0c446e659e7c3e204096468bf
commit r12-5426-gb751b225e4f02cf0c446e659e7c3e204096468bf
Author: Jakub Jelinek
Date: Fri Nov 19 22:09:01 2021 +0100
c++: Avoid adding implicit attributes during apply_late_template_attributes
[PR101180]
decl_attributes and its caller cplus_decl_attributes sometimes add
implicit attributes, e.g. optimize attribute if #pragma GCC optimize
is active, target attribute if #pragma GCC target is active, or
e.g. omp declare target attribute if in between #pragma omp declare target
and #pragma omp end declare target.
For templates that seems highly undesirable to me though, they should
get those implicit attributes from the spot the templates were parsed
(and they do get that), then tsubst through copy_node copies those
attributes, but then apply_late_template_attributes can or does add
a new set from the spot where they are instantiated, which can be pretty
random point of first use of the template.
Consider e.g.
#pragma GCC push_options
#pragma GCC target "avx"
template
inline void foo ()
{
}
#pragma GCC pop_options
#pragma GCC push_options
#pragma GCC target "crc32"
void
bar ()
{
foo<0> ();
}
#pragma GCC pop_options
testcase where the intention is that foo has avx target attribute
and bar has crc32 target attribute, but we end up with
__attribute__((target ("crc32"), target ("avx")))
on foo<0> (and due to yet another bug actually don't enable avx
in foo<0>). In this particular case it is a regression caused
by r12-299-ga0fdff3cf33f7284 which apparently calls
cplus_decl_attributes even if attributes != NULL but late_attrs
is NULL, before those changes we didn't call it in those cases.
But, if there is at least one unrelated dependent attribute this
would happen already in older releases.
The following patch fixes that by temporarily overriding the variables
that control the addition of the implicit attributes.
Shall we also change the function so that it doesn't call
cplus_decl_attributes if late_attrs is NULL, or was that change
intentional?
2021-11-19 Jakub Jelinek
PR c++/101180
* pt.c (apply_late_template_attributes): Temporarily override
current_optimize_pragma, optimization_current_node,
current_target_pragma and
scope_chain->omp_declare_target_attribute,
so that cplus_decl_attributes doesn't add implicit attributes.
* g++.target/i386/pr101180.C: New test.
[Bug c++/96004] Copy elision with conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96004 --- Comment #1 from Óscar Fuentes --- This looks like a duplicate of PR53637 / PR53637.
[Bug c++/58487] Missed return value optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487 Óscar Fuentes changed: What|Removed |Added CC||gcc_bugzilla at axeitado dot com --- Comment #4 from Óscar Fuentes --- Isn't this PR a trivial variation of PR53637 ?
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above patch on trunk for GCC 12.
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f573d35147ca8433c102e1721d8c99fc432cb44b
commit r12-5424-gf573d35147ca8433c102e1721d8c99fc432cb44b
Author: David Malcolm
Date: Thu Nov 18 15:23:30 2021 -0500
analyzer: fix false leak due to overeager state merging [PR103217]
PR analyzer/103217 reports a false positive from -Wanalyzer-malloc-leak.
The root cause is due to overzealous state merger, where the
state-merging code decided to merge these two states by merging
the stores:
state A:
clusters within frame: âmainâ@1
cluster for: one_3: CONJURED(val_4 = strdup (src_2(D));, val_4)
cluster for: two_4: UNKNOWN(char *)
cluster for: one_21: CONJURED(val_4 = strdup (src_2(D));, val_4)
state B:
clusters within frame: âmainâ@1
cluster for: one_3: UNKNOWN(char *)
cluster for: two_4: CONJURED(val_4 = strdup (src_2(D));, val_4)
cluster for: two_18: CONJURED(val_4 = strdup (src_2(D));, val_4)
into:
clusters within frame: âmainâ@1
cluster for: one_3: UNKNOWN(char *)
cluster for: two_4: UNKNOWN(char *)
cluster for: one_21: UNKNOWN(char *)
cluster for: two_18: UNKNOWN(char *)
despite "CONJURED(val_4 = strdup (src_2(D));, val_4)" having sm-state,
in this case malloc:nonnull ({free}), thus leading to both references
to the conjured svalue being lost at merger.
This patch tweaks the state merger code so that it will not consider
merging two different svalues for the value of a region if either svalue
has non-purgable sm-state (in the above example, malloc:nonnull). This
fixes the false leak report above.
Doing so uncovered an issue with explode-2a.c in which the warnings
moved from the correct location to the "while" stmt. This turned out
to be a missing call to detect_leaks in phi-handling, which the patch
also fixes (in the PK_BEFORE_SUPERNODE case in
exploded_graph::process_node). Doing this fixed the regression in
explode-2a.c and also fixed the location of the leak warning in
explode-1.c.
The other side effect of the change is that pr94858-1.c now emits
a -Wanalyzer-too-complex warning, since pertinent state is no longer
being thrown away. There doesn't seem to be a good way of avoiding
this, so the patch also adds -Wno-analyzer-too-complex to that test
case (restoring the default).
gcc/analyzer/ChangeLog:
PR analyzer/103217
* engine.cc (exploded_graph::get_or_create_node): Pass in
m_ext_state to program_state::can_merge_with_p.
(exploded_graph::process_worklist): Likewise.
(exploded_graph::maybe_process_run_of_before_supernode_enodes):
Likewise.
(exploded_graph::process_node): Add missing call to detect_leaks
when handling phi nodes.
* program-state.cc (program_state::can_merge_with_p): Add
"ext_state" param. Pass it and state ptrs to
region_model::can_merge_with_p.
(selftest::test_program_state_merging): Update for new ext_state
param of program_state::can_merge_with_p.
(selftest::test_program_state_merging_2): Likewise.
* program-state.h (program_state::can_purge_p): Make const.
(program_state::can_merge_with_p): Add "ext_state" param.
* region-model.cc: Include "analyzer/program-state.h".
(region_model::can_merge_with_p): Add params "ext_state",
"state_a", and "state_b", use them when creating model_merger
object.
(model_merger::mergeable_svalue_p): New.
* region-model.h (region_model::can_merge_with_p): Add params
"ext_state", "state_a", and "state_b".
(model_merger::model_merger) Likewise, initializing new fields.
(model_merger::mergeable_svalue_p): New decl.
(model_merger::m_ext_state): New field.
(model_merger::m_state_a): New field.
(model_merger::m_state_b): New field.
* svalue.cc (svalue::can_merge_p): Call
model_merger::mergeable_svalue_p on both states and reject the
merger accordingly.
gcc/testsuite/ChangeLog:
PR analyzer/103217
* gcc.dg/analyzer/explode-1.c: Update for improvement to location
of leak warning.
* gcc.dg/analyzer/pr103217.c: New test.
* gcc.dg/analyzer/pr94858-1.c: Add -Wno-analyzer-too-complex.
Signed-off-by: David Malcolm
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #20 from Jonathan Wakely --- It should be fixed now.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #19 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1f8d01eb1476a997eb1fc686b60fccdf97747faa commit r12-5421-g1f8d01eb1476a997eb1fc686b60fccdf97747faa Author: Jonathan Wakely Date: Fri Nov 19 18:27:59 2021 + libstdc++: One more change for Clang to support constexpr std::string [PR103295] All writes into the allocated buffer need to be via traits_type::assign to begin lifetimes. libstdc++-v3/ChangeLog: PR libstdc++/103295 * include/bits/basic_string.tcc (_M_construct): Use the traits assign member to write into allcoated memory.
[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556 --- Comment #64 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d4943ce939d9654932624b9ece24c3a474ae4157 commit r12-5418-gd4943ce939d9654932624b9ece24c3a474ae4157 Author: Iain Sandoe Date: Mon Sep 20 18:41:56 2021 +0100 Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556]. This addresses a long-standing problem where a work-around for an unwinder issue (also a regression) regresses other functionality. The patch replaces several work-arounds with a fix for PR80556 and a work-around for PR88590. * The fix for PR80556 requires a bump to the SO name for libgcc_s, since we need to remove the unwinder symbols from it. This would trigger PR88590 hence the work-around for that. * We weaken the symbols for emulated TLS support so that it is possible for a DSO linked with static-libgcc to interoperate with a DSO linked with libgcc_s. Likewise main exes. * We remove all the gcc-4.2.1 era stubs machinery and workarounds. * libgcc is always now linked ahead of libc, which avoids fails where the libc (libSystem) builtins implementations are not up to date. * The unwinder now always comes from the system - for Darwin9 from /usr/lib/libgcc_s.1.dylib - for Darwin10 from /usr/lib/libSystem.dylib - for Darwin11+ from /usr/lib/system/libunwind.dylib. We still insert a shim on Darwin10 to fix an omitted unwind function, but the underlying unwinder remains the system one. * The work-around for PR88590 has two parts (1) we always link libgcc from its convenience lib on affected system versions (avoiding the need to find the DSO path); (2) we add and export the emutls functions from DSOs - this makes a relatively small (20k) addition to a DSO. These can be backed out when a proper fix for PR88590 is committed. For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage from exes that linked against the stubs can use a reexported libgcc_s.1.1 (since that contains all the symbols that were previously exported via the stubs). Signed-off-by: Iain Sandoe gcc/ChangeLog: PR target/80556 * config/darwin-driver.c (darwin_driver_init): Handle exported symbols and symbol lists (suppress automatic export of the TLS symbols). * config/darwin.c (darwin_rename_builtins): Remove workaround. * config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Likewise. (REAL_LIBGCC_SPEC): Handle revised library uses. * config/darwin.opt (nodefaultexport): New. * config/i386/darwin.h (PR80556_WORKAROUND): Remove. * config/i386/darwin32-biarch.h (PR80556_WORKAROUND): Likewise. * config/i386/darwin64-biarch.h (PR80556_WORKAROUND): Likewise. libgcc/ChangeLog: * config.host: Add weak emutls crt to the extra_parts. * config/i386/darwin-lib.h (DECLARE_LIBRARY_RENAMES): Remove workaround. * config/libgcc-libsystem.ver: Add exclude list for the system- provided unwinder. * config/t-slibgcc-darwin: Bump SO version, remove stubs code. * config/i386/libgcc-darwin.10.4.ver: Removed. * config/i386/libgcc-darwin.10.5.ver: Removed. * config/rs6000/libgcc-darwin.10.4.ver: Removed. * config/rs6000/libgcc-darwin.10.5.ver: Removed. * config/t-darwin-noeh: New file. gcc/testsuite/ChangeLog: * gcc.dg/torture/fp-int-convert-timode-3.c: Remove XFAIL. * gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
[Bug fortran/87851] [9/10/11/12 Regression] Wrong return type for len_trim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #15 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-November/057038.html
[Bug rtl-optimization/103336] [arm64] operations on long double generate calls to libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336 --- Comment #2 from Andrew Pinski --- If you want to have a consistency between platforms, it might be best if you use _Float128 instead of long double but _Float128 is not supported on all targets really. It is only supported on targets which have support for IEEE 128bit FP which includes x86_64, arm64 and PowerPC. Again this is not really a bug or anything GCC can do better unless the newer hardware comes out which has native support. See https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html for more details on this.
[Bug c++/103337] rejects-valid brace elision inside designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337
Marek Polacek changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed||2021-11-19
Status|UNCONFIRMED |NEW
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
And
op_t z{.put={0}};
works, so confirmed.
[Bug c++/103337] New: rejects-valid brace elision inside designated initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337
Bug ID: 103337
Summary: rejects-valid brace elision inside designated
initializer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct op_t {
struct put_t {
int x;
} put;
};
op_t x{0}; // OK
op_t y{.put=0}; // error: 'op_t::put_t' has no non-static data member named
'put'
GCC rejects the second initializer, but Clang and MSVC accept.
Doesn't appear to be a regression.
[Bug tree-optimization/103231] [12 Regression] ICE (nondeterministic/stack overflow) on valid code at -O1 on x86_64-linux-gnu: Segmentation fault since r12-5014-g6b8b959675a3e14c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231 --- Comment #12 from Andrew Macleod --- Yes, ranger can currently create some very deep call chains, especially as it evaluates values around back edges. A general query on a stmt first checks if all the operands have been resolved, and if they have not been, spawns another query to resolve the answer. If we do this along a back edge, we get into another basic block which has not been processed at all, so every operand spawns another request and the stack gets deeper and deeper until it reaches a stmt that can be resolved.. then it unwinds with all the answers, folding and setting ranges as it goes. Note that each one of the query steps can involves 4 or 5 functions calls as we look at the kind of stmt, and process it, then get values on edges, etc etc. so each "depth" of query can be up to 5 function calls. I have analyzed the call patterns and have a solution I am working on now that almost completely flattens the call chains to satisfy the dependency resolution.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #18 from Jonathan Wakely --- There's still one more fix needed for _M_construct
[Bug analyzer/103217] analyzer false positive on leak warning when using indirect strdup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-11-19 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this; I'm testing a fix.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #23 from Mikael Morin --- (In reply to Richard Biener from comment #21) > (In reply to Bernhard Reutner-Fischer from comment #17) > > Do we want to address arrays always at position 0 (maybe to help graphite ?) > > Helping graphite (and other loop optimizers) would be to not lower > multi-dimensional accesses to a single dimension (I think that's what > Sandras patches try to do). Or maybe graphite can be taught to handle flattened array access? Anyway, does the middle-end support out-of-order array access? Namely for an array arr(4, 5, 6), arr(:, 1, :) is an array of size (4, 6). Does the middle-end type system support this? In any case, it’s not for gcc 12. > The lower bound doesn't really matter here and > is well-handled by all code. Well, unless the lower bound is negative. ;-)
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Attachment #51791|0 |1 is obsolete|| --- Comment #22 from Mikael Morin --- Created attachment 51839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51839=edit third try Yet another patch. It works with comment #1 and comment #13. However, with the testsuite it is a disaster.
[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 --- Comment #4 from Martin Jambor --- Still, the interaction between IPA-CP and IPA-SRA is bad here. Just looking at the optimized dump, one of the "specialized functions" starts with: [local count: 62767467]: # DEBUG D#203 s=> row # DEBUG row => D#203 _2 = (long int) ISRA.10821_938(D); where the ISRA param contains the constant we wanted to specialize for... making the clones worse than useless. >From the IPA-CP ltrans dumps it is clear that the transformation phase of IPA-CP considers the first parameter dead and so does not perform the substitutions even though the parameter is replaced only by a "subsequent" pass. The infrastructure invokes the transform function on node digits_2.constprop.isra/157 (note the isra) which has already been modified by the subsequent pass (when it was cloned). I like the idea of transformation phases better than putting everything into tree-inline (and by extension ipa-param-manipulation) but perhaps we have to do aggregate constant replacements there too?
[Bug tree-optimization/102958] std::u8string suboptimal compared to std::string, triggers warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b8f2efaed02e8b03d215d74e42d3707761772f64 commit r12-5414-gb8f2efaed02e8b03d215d74e42d3707761772f64 Author: Jonathan Wakely Date: Fri Nov 19 18:13:10 2021 + libstdc++: Suppress -Wstringop warnings [PR103332] libstdc++-v3/ChangeLog: PR libstdc++/103332 PR libstdc++/102958 * testsuite/21_strings/basic_string/capacity/char/1.cc: Add -Wno-stringop-overflow. * testsuite/21_strings/basic_string/operators/char/1.cc: Likewise. * testsuite/experimental/filesystem/path/factory/u8path-char8_t.cc: Add -Wno-stringop-overread.
[Bug tree-optimization/103332] Spurious -Wstringop-overflow warnings in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b8f2efaed02e8b03d215d74e42d3707761772f64 commit r12-5414-gb8f2efaed02e8b03d215d74e42d3707761772f64 Author: Jonathan Wakely Date: Fri Nov 19 18:13:10 2021 + libstdc++: Suppress -Wstringop warnings [PR103332] libstdc++-v3/ChangeLog: PR libstdc++/103332 PR libstdc++/102958 * testsuite/21_strings/basic_string/capacity/char/1.cc: Add -Wno-stringop-overflow. * testsuite/21_strings/basic_string/operators/char/1.cc: Likewise. * testsuite/experimental/filesystem/path/factory/u8path-char8_t.cc: Add -Wno-stringop-overread.
[Bug libstdc++/103295] constexpr std::string does not work for clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295 --- Comment #17 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2d76292bd6719d687bc77051da265df8ed7f5a61 commit r12-5413-g2d76292bd6719d687bc77051da265df8ed7f5a61 Author: Jonathan Wakely Date: Thu Nov 18 10:33:14 2021 + libstdc++: Begin lifetime of chars in constexpr std::string [PR103295] Clang gives errors for constexpr std::string because the memory returned by std::allocator::allocate does not contain any objects yet, and attempting to set them using char_traits::assign or char_traits::copy fails with: assignment to object outside its lifetime is not allowed in a constant expression *__result = *__first; ^ This adds code to std::char_traits to use std::construct_at to begin lifetimes when called during constant evaluation. To support specializations of std::basic_string that don't use std::char_traits there is now another layer of wrapper around the allocator_traits, so that the lifetime of characters is begun as soon as the memory is allocated. By doing it in the char traits and allocator traits, the rest of basic_string can ignore the problem. While modifying char_traits::copy and char_traits::assign to begin lifetimes for the constexpr cases, I also replaced their uses of std::copy and std::fill_n respectively. That means we don't need for char_traits. libstdc++-v3/ChangeLog: PR libstdc++/103295 * include/bits/basic_string.h (_Alloc_traits): Replace typedef with struct for C++20 mode. * include/bits/basic_string.tcc (_M_replace): Use _Alloc_traits for allocation. * include/bits/char_traits.h (__gnu_cxx::char_traits::assign): Use std::_Construct during constant evaluation. (__gnu_cxx::char_traits::assign(CharT*, const CharT*, size_t)): Likewise. Replace std::fill_n with memset or manual loop. (__gnu_cxx::char_traits::copy): Likewise, replacing std::copy with memcpy. * include/ext/vstring.h: Include for std::min. * include/std/string_view: Likewise. * testsuite/21_strings/basic_string/capacity/char/resize_and_overwrite.cc: Add constexpr test.
[Bug fortran/102431] [12 Regression] ICE in lower_gimple_bind, at gimple-low.c:439 since r12-1206-g178191e1dfafd8db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
struct S { int s; } s;
void add (struct S *, struct S *);
void init (struct S *);
#pragma omp declare reduction (+:struct S:add (_out, _in)) initializer
(init (_priv))
void
foo (void)
{
int i;
#pragma omp loop bind(teams) reduction(+:s)
for (i = 0; i < 8; i++)
;
}
ICEs in both C++ (same spot) and C (different spot) and
struct S { S (); ~S (); S (const S &); void add (const S &); int s; } s;
#pragma omp declare reduction (+:S:omp_out.add (omp_in))
void
foo ()
{
#pragma omp loop bind(teams) reduction(+:s)
for (int i = 0; i < 8; i++)
;
}
ICEs in C++ too.
I guess gimplify_omp_loop when copying OMP_CLAUSE_REDUCTION_INIT and
OMP_CLAUSE_REDUCTION_MERGE (c) can't just unshare_expr those expressions and
replace the placeholders in there, but needs to also duplicate BLOCKs
referenced in there and adjust them.
[Bug rtl-optimization/103336] [arm64] operations on long double generate calls to libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Arm64 does not have native higher than 644bit floating point. That is why it is a libcall. X86_64's long double is 80bit fp too.
[Bug tree-optimization/103332] Spurious -Wstringop-overflow warnings in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332 --- Comment #2 from Jonathan Wakely --- (In reply to Martin Sebor from comment #1) > I suppressed a subset of these warnings in > g:9a27acc30a34b7854db32eac562306cebac6fa1e. Ah yes, I'll add the same again then, thanks.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #14 from Bill Schmidt --- (In reply to Segher Boessenkool from comment #13) > (In reply to Bill Schmidt from comment #11) > > As I mentioned privately, we could do with an audit of our implementation of > > standard patterns in general, since we tend to find such missing cases more > > often than I'd like... > > It would be great if there was some standard way of seeing what targets > implement (and do not implement!) what. It will be hugely useful when > implementing a new port for example, but also great when maintaining one. I agree. Some tooling around this would be a big benefit to the community. Maybe some GSOC person would like to do that. :)
[Bug rtl-optimization/103336] New: [arm64] operations on long double generate calls to libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
Bug ID: 103336
Summary: [arm64] operations on long double generate calls to
libgcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sebpop at gmail dot com
Target Milestone: ---
On testsuite/gcc.target/i386/long-double-64-1.c, gcc produces a call to
__multf3 on arm64 and the test checks that such a call is not generated on
x86_64.
$ cat a.c
long double
foo (long double x)
{
return x * x;
}
On arm64:
$ gcc -O2 -S -o- a.c
foo:
stp x29, x30, [sp, -16]!
mov v1.16b, v0.16b
mov x29, sp
bl __multf3
ldp x29, x30, [sp], 16
ret
On x64:
$ gcc -O2 -S -o- a.c
foo:
endbr64
fldt8(%rsp)
fmul%st(0), %st
ret
Why GCC does not generate an fmul on arm64 instead of calling libgcc?
There is a related performance issue in libGeos:
https://github.com/libgeos/geos/issues/509
[Bug other/103335] New: new test case gcc.dg/tree-ssa/modref-dse-4.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103335
Bug ID: 103335
Summary: new test case gcc.dg/tree-ssa/modref-dse-4.c fails
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:6dc90c4dbb6f9589dea9c670c3468496bb207de5, r12-5324
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
tree-ssa.exp=gcc.dg/tree-ssa/modref-dse-4.c"
FAIL: gcc.dg/tree-ssa/modref-dse-4.c scan-tree-dump dse2 "Deleted dead store:
kill_me"
# of expected passes1
# of unexpected failures1
This fails for 32 bits on powerpc64 BE. Works fine for 64 bits.
Perhaps related to pr103282?
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #13 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #11) > As I mentioned privately, we could do with an audit of our implementation of > standard patterns in general, since we tend to find such missing cases more > often than I'd like... It would be great if there was some standard way of seeing what targets implement (and do not implement!) what. It will be hugely useful when implementing a new port for example, but also great when maintaining one.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #12 from Segher Boessenkool --- When is the lowering done currently? Only for the ops that have no other way of doing, and things are merged back to an __int128 immediately after that? If that is what is going on, then that is unfortunate, but it may the best we can do yes. Sigh.
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/103299] [11/12 Regression] accessing incorrect storage for designated init of anonymous union at constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug fortran/103312] [9/10/11/12 Regression] ICE in gfc_find_component since r9-1098-g3cf89a7b992d483e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103312 kargl at gcc dot gnu.org changed: What|Removed |Added CC|kargl at gcc dot gnu.org | --- Comment #2 from kargl at gcc dot gnu.org --- Not regression tested. Allows the code to compile. I don't use CLASS, so have not idea if this is correct. The code in gfc_find_component is set up for only TYPE, UNION, and STRUCT. See the assert. diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 93118ad3455..997fa0d7848 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -1692,8 +1692,10 @@ generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns, final->attr.artificial = 1; final->attr.always_explicit = 1; final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL; - if (ns->proc_name->attr.flavor == FL_MODULE) + + if (ns->proc_name && ns->proc_name->attr.flavor == FL_MODULE) final->module = ns->proc_name->name; + gfc_set_sym_referenced (final); gfc_commit_symbol (final); diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index 8c9a1d00ce0..52d47b8b872 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -2492,6 +2492,8 @@ gfc_find_component (gfc_symbol *sym, const char *name, if (sym->attr.flavor == FL_DERIVED) sym = gfc_use_derived (sym); + else if (sym->ts.type == BT_DERIVED) +sym = gfc_use_derived (sym->ts.u.derived); else gcc_assert (gfc_fl_struct (sym->attr.flavor));
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #11 from Bill Schmidt --- As I mentioned privately, we could do with an audit of our implementation of standard patterns in general, since we tend to find such missing cases more often than I'd like...
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #10 from Bill Schmidt --- FWIW, I think the vector lowering pass is reasonable. These things always look horrible in isolation, but the lowering allows more optimization when the target doesn't really support the data type. This is just an oversight in our back end, and once we correct it, this should all fall out nicely (I hope).
[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #55 from Marek Polacek --- Aah, I should check is_empty_class before issuing the warning I guess.
[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- Fixed.
[Bug c++/33925] [10/11 Regression] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 Martin Sebor changed: What|Removed |Added Known to work||12.0 Summary|[10/11/12 Regression] gcc |[10/11 Regression] gcc |-Waddress lost some useful |-Waddress lost some useful |warnings|warnings Known to fail|12.0|10.2.0 --- Comment #11 from Martin Sebor --- Fixed in GCC 12.
[Bug c++/33925] [10/11/12 Regression] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:16137fbb9256ef365dd498d39024eb33de1a4cd8 commit r12-5410-g16137fbb9256ef365dd498d39024eb33de1a4cd8 Author: Martin Sebor Date: Fri Nov 19 09:44:31 2021 -0700 Restore ancient -Waddress for weak symbols [PR33925]. Resolves: PR c/33925 - gcc -Waddress lost some useful warnings PR c/102867 - -Waddress from macro expansion in readelf.c gcc/c-family/ChangeLog: PR c++/33925 PR c/102867 * c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address and improve handling tof defined symbols. gcc/c/ChangeLog: PR c++/33925 PR c/102867 * c-typeck.c (maybe_warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/cp/ChangeLog: PR c++/33925 PR c/102867 * typeck.c (warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/ChangeLog: PR c++/33925 PR c/102867 * doc/invoke.texi (-Waddress): Update. gcc/testsuite/ChangeLog: PR c++/33925 PR c/102867 * g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning. * c-c++-common/Waddress-5.c: New test. * c-c++-common/Waddress-6.c: New test. * g++.dg/warn/Waddress-7.C: New test. * gcc.dg/Walways-true-2.c: Adjust to avoid a valid warning. * gcc.dg/weak/weak-3.c: Expect a warning.
[Bug c/102867] [12 Regression] -Waddress from macro expansion in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:16137fbb9256ef365dd498d39024eb33de1a4cd8 commit r12-5410-g16137fbb9256ef365dd498d39024eb33de1a4cd8 Author: Martin Sebor Date: Fri Nov 19 09:44:31 2021 -0700 Restore ancient -Waddress for weak symbols [PR33925]. Resolves: PR c/33925 - gcc -Waddress lost some useful warnings PR c/102867 - -Waddress from macro expansion in readelf.c gcc/c-family/ChangeLog: PR c++/33925 PR c/102867 * c-common.c (decl_with_nonnull_addr_p): Call maybe_nonzero_address and improve handling tof defined symbols. gcc/c/ChangeLog: PR c++/33925 PR c/102867 * c-typeck.c (maybe_warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/cp/ChangeLog: PR c++/33925 PR c/102867 * typeck.c (warn_for_null_address): Suppress warnings for code resulting from macro expansion. gcc/ChangeLog: PR c++/33925 PR c/102867 * doc/invoke.texi (-Waddress): Update. gcc/testsuite/ChangeLog: PR c++/33925 PR c/102867 * g++.dg/warn/Walways-true-2.C: Adjust to avoid a valid warning. * c-c++-common/Waddress-5.c: New test. * c-c++-common/Waddress-6.c: New test. * g++.dg/warn/Waddress-7.C: New test. * gcc.dg/Walways-true-2.c: Adjust to avoid a valid warning. * gcc.dg/weak/weak-3.c: Expect a warning.
[Bug tree-optimization/103254] [12 Regression] Compile time hog in compare_values_warnv since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103254 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Macleod --- fixed.
[Bug tree-optimization/103254] [12 Regression] Compile time hog in compare_values_warnv since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103254 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:ee448a523d377f9ed882dac806d2f5001bfa2432 commit r12-5409-gee448a523d377f9ed882dac806d2f5001bfa2432 Author: Andrew MacLeod Date: Wed Nov 17 14:14:06 2021 -0500 Limit depth for all GORI expressions. Apply the logical_depth limit ranger uses to all stmts with multiple ssa-names to avoid excessive outgoing calculations. gcc/ PR tree-optimization/103254 * gimple-range-gori.cc (range_def_chain::get_def_chain): Limit the depth for all statements with multple ssa names. gcc/testsuite/ * gcc.dg/pr103254.c: New.
[Bug c/103334] New: missing -Wc++-compat for a function redeclared with different qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103334 Bug ID: 103334 Summary: missing -Wc++-compat for a function redeclared with different qualifiers Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Redeclaring a function that differs only in the qualifiers on the return type is rejected by G++ in all C++ modes but not diagnosed by GCC in C mode. The warbing should be enhanced to diagnose that as well (-Wignored-qualifiers is enabled by -Wextra but not -Wall). $ cat z.c && gcc -O2 -S -Wall -Wextra -Wc++-compat z.c const int f (void); volatile int f (void); z.c:1:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 1 | const int f (void); | ^ z.c:2:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 2 | volatile int f (void); | ^~~~ Compilation error for the same code with G++: $ g++ -O2 -S -Wall -Wextra -std=c++98 -xc++ z.c z.c:1:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 1 | const int f (void); | ^ z.c:2:1: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] 2 | volatile int f (void); | ^~~~ z.c:2:14: error: ambiguating new declaration of ‘volatile int f()’ 2 | volatile int f (void); | ^ z.c:1:11: note: old declaration ‘const int f()’ 1 | const int f (void); | ^
[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81674 --- Comment #7 from Eric Gallager --- (In reply to Martin Sebor from comment #6) > Reconfirmed with GCC 11. See also pr78391. The patch in pr19808 comment 29 > was either never committed or even submitted, and the other patch for the > same bug submitted last November > (https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html) wasn't > approved. Let me CC Marek to see if plans to resubmit it for GCC 12. the patch for pr19808 has been committed now
[Bug middle-end/78391] g++ (any version) at O0 (for O1, O2, O3 is ok) doesn't warn when class members are used uninitialized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78391 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (In reply to Martin Sebor from comment #7) > Patch for pr19808: > https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559162.html That's fixed now.
[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088 --- Comment #20 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #19) > Ughh, I was nerd sniped. Couldn't let it go ;-). > > The problem is this construct in Perl_do_ncmp: > > if (lnv < rnv) > return -1; > if (lnv > rnv) > return 1; > if (lnv == rnv) > return 0; > return 2; > > These are all doubles. The code is depending on a pair of values that are > neither <, >, nor ==, being a NAN. And...you can work around the problem by declaring the doubles volatile ;-): volatile NV const rnv = SvNV_nomg(right); volatile NV const lnv = SvNV_nomg(left); ... ... if (lnv < rnv) return -1; if (lnv > rnv) return 1; if (lnv == rnv) return 0; return 2;
[Bug testsuite/103282] New test case gcc.dg/tree-ssa/modref-dse-5.c in r12-5292 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103282 --- Comment #7 from seurer at gcc dot gnu.org --- Looks like it is 32 bit only.
[Bug c++/103333] New: [accepts-invalid] function template argument deduction for incompatible 'transformed A' / 'deduced A' pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: [accepts-invalid] function template argument deduction
for incompatible 'transformed A' / 'deduced A' pair
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
The following program is accepted by GCC but rejected by Clang/MSVC
(-std=c++20):
---
#include
template
struct S{
S() = default;
template::value>>
operator S() { return S{}; }
};
template
void f(S, b1>,
// ^- T in non-deduced context for func-param
#1
S)
// ^- T deduced from here
{}
int main() {
S s1{};
S s2{};
f(s1, s2);
}
---
The program is ill-formed as function template argument deduction
([temp.deduct.call]) for the first argument resolves in a mismatched deduced A
vs. transformed A that is S and S, respectively,
and none of the three special cases of [temp.deduct.call]/4 allows this
mismatch.
[temp.arg.explicit]/7 allows a function argument to be converted to the type of
the corresponding function parameter, but only if the parameter type contains
to template arguments that participate in template argument deduction [from
that function argument]. This does not apply here, as the non-type template
parameter 'b1' participates in template argument deduction for the call.
---
https://timsong-cpp.github.io/cppwp/n4861/temp.deduct.call#4
https://timsong-cpp.github.io/cppwp/n4861/temp.arg.explicit#7
[Bug tree-optimization/103088] [12 regression] 500.perlbench from spec 2017 fails since r12-4698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #19 from Aldy Hernandez ---
Ughh, I was nerd sniped. Couldn't let it go ;-).
The problem is this construct in Perl_do_ncmp:
if (lnv < rnv)
return -1;
if (lnv > rnv)
return 1;
if (lnv == rnv)
return 0;
return 2;
These are all doubles. The code is depending on a pair of values that are
neither <, >, nor ==, being a NAN.
For -ffast-math with unsafe optimizations we end up inling Perl_do_ncmp into
pp_ge():
SETs(boolSV(
(SvIOK_notUV(left) && SvIOK_notUV(right))
? (SvIVX(left) >= SvIVX(right))
: ( (do_ncmp(left, right) & 2) == 0)
));
but in doing so we destroy the 3 separate conditionals. At one point we're
making decisions based on <= on the 35->38 edge:
struct OP * Perl_pp_ge ():
...
[local count: 590686791]:
# iftmp.547_110 = PHI
if (iftmp.546_109 > iftmp.547_110)
goto ; [1.04%]
else
goto ; [98.96%]
[local count: 644407314]:
[local count: 953267993]:
# iftmp.532_21 = PHI <_sv_yes(38), _sv_no(37)>
MEM[(struct SV * *)sp_27 + -8B] = iftmp.532_21;
PL_stack_sp = sp_30;
PL_op.534_19 = PL_op;
_38 = PL_op.534_19->op_next;
[local count: 1073741826]:
# _20 = PHI <_29(5), _38(39)>
return _20;
For -fno-unsafe-math-optimizations we avoid inlining Perl_no_ncmp, which keeps
the conditionals.
So it looks like we inline the NAN checking code in unsafe mode and the
threader ends can make decisions on the return value for pp_ge(). As I said,
the threads are correct.
If anyone is curious, you can see what's going on by tagging Perl_do_ncmp()
with __attribute__((optimize("O3", "fast-math",
"no-unsafe-math-optimizations")))
and seeing the final pp_ge() output with the munged conditionals versus the
pristine code in the output for Perl_do_ncmp.
I think we can keep this PR closed. Don't use -ffast-math unless followed by
-fno-unsafe-math-optimizations.
[Bug tree-optimization/103332] Spurious -Wstringop-overflow warnings in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102958 --- Comment #1 from Martin Sebor --- Suspect at least some of these might be due to the same underlying problem as pr102958. I suppressed a subset of these warnings in g:sy9a27acc30a34b7854db32eac562306cebac6fa1e.
[Bug tree-optimization/103332] New: Spurious -Wstringop-overflow warnings in libstdc++ tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332 Bug ID: 103332 Summary: Spurious -Wstringop-overflow warnings in libstdc++ tests Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 88443 Target Milestone: --- In the $objdir/$target/libstdc++-v3/testsuite dir, running: make check RUNTESTFLAGS="conformance.exp=21_strings/basic_string/operators/char/1.cc --target_board=unix/-D_GLIBCXX_DEBUG" Results in: In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:40,^M from /home/jwakely/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operators/char/1.cc:22:^M In static member function 'static std::char_traits::char_type* std::char_traits::copy(std::char_traits::char_type*, const std::char_traits::char_type*, std::size_t)',^M inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:675,^M inlined from 'std::__cxx11::basic_string<_CharT, _Traits, _Allocator> std::operator+(std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&&, const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3552,^M inlined from 'int test01()' at /home/jwakely/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operators/char/1.cc:34:^M /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:423: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing 17 bytes into a region of size 16 overflows the destination [-Wstringop-overflow=]^M /home/jwakely/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operators/char/1.cc: In function 'int test01()':^M /home/jwakely/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/operators/char/1.cc:34: note: at offset 16 into destination object '' of size 32^M FAIL: 21_strings/basic_string/operators/char/1.cc (test for excess errors) Excess errors: /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/char_traits.h:423: warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' writing 17 bytes into a region of size 16 overflows the destination [-Wstringop-overflow=] And: make check RUNTESTFLAGS="conformance.exp=21_strings/basic_string/capacity/char/1.cc --target_board=unix/-std=gnu++20" results in: In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:40,^M from /home/jwakely/src/gcc/libstdc++-v3/testsuite/21_strings/basic_string/capacity/char/1.cc:22:^M In static member function 'static constexpr std::char_traits::char_type* std::char_traits::copy(std::char_traits::char_type*, const std::char_traits::char_type*, std::size_t)',^M inlined from 'static constexpr void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:423,^M inlined from 'static constexpr void std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:418,^M inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Allocator>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_append(const _CharT*, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:417,^M inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::append(const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]' at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1385,^M inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits, _Allocator> std::operator+(const std::__cxx11::basic_string<_CharT, _Traits, _Allocator>&,
[Bug libgomp/102838] [12 regression] Several tests SEGV in gomp_loop_ull_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102838 --- Comment #21 from Jakub Jelinek --- Yeah, but clearly not in libgomp, but in the testcase, so IMNSHO we shouldn't reuse this PR for that. On x86_64-linux I see movaps into and out from the thr.1 TLS variable and in two spots to/from stack, the thr.1 TLS var has .align 16, so all seems to be ok.
[Bug tree-optimization/102436] [11 Regression] Lost Load/Store Motion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102436 --- Comment #5 from Jeffrey A. Law --- Sounds reasonable (not backporting, but holding bug open for now). I'll probably do some testing with it internally, so if you end up wanting to revisit the backporting question, reach out I may have useful data.
[Bug tree-optimization/103311] [12 Regression] ICE in complex_mul_pattern::build(vec_info*) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #7 from Tamar Christina --- Really fixed now.
[Bug target/103330] [12 Regression] FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c by r12-5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330 Tamar Christina changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tamar Christina --- Fixed
[Bug target/103330] [12 Regression] FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c by r12-5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330 --- Comment #2 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:487d604b6fa0f0a981eadc216d9e481d08ed7e7b commit r12-5407-g487d604b6fa0f0a981eadc216d9e481d08ed7e7b Author: Tamar Christina Date: Fri Nov 19 15:12:38 2021 + middle-end: Handle FMA_CONJ correctly after SLP layout update. Apologies, I got dinged by the i386 regressions bot for a test I didn't have in my tree at the time I made the previous patch. The bot was telling me that FMA stopped working after I strengthened the FMA check in the previous patch. The reason is that the check is slightly early. The first check can indeed only exit early when either node isn't a mult. However we need to delay till we know if the node is a MUL or FMA before enforcing that both nodes must be a MULT since the node to inspect is different if the operation is a MUL or FMA. Also with the update patch for GCC 11 tree layout update to the new GCC 12 one I had missed that the difference in which node is conjucated is not symmetrical. So the test for it can just be testing the inverse order. It was Currently no detecting when the first node was conjucated instead of the second one. This also made me wonder why my own test didn't detect this. It turns out that the tests, being copied from the _Float16 ones were incorrectly marked as xfail. The _Float16 ones are marked as xfail since C doesn't have a conj operation for _Float16, which means you get extra type-casts in between. While you could use the GCC _Complex extension here I opted to mark them xfail since I wanted to include detection over the widenings next year. Secondly the double tests were being skipped because Adv. SIMD was missing from targets supporting Complex Double vectorization. With these changes all other tests run and pass and only XFAIL ones are correctly the _Float16 ones. Sorry for missing this before, testing should now cover all cases. gcc/ChangeLog: PR tree-optimization/103311 PR target/103330 * tree-vect-slp-patterns.c (vect_validate_multiplication): Fix CONJ test to new codegen. (complex_mul_pattern::matches): Move check downwards. gcc/testsuite/ChangeLog: PR tree-optimization/103311 PR target/103330 * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-double.c: Fix it. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-double.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-float.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-double.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Likewise. * lib/target-supports.exp (check_effective_target_vect_complex_add_double): Add Adv. SIMD.
[Bug tree-optimization/103311] [12 Regression] ICE in complex_mul_pattern::build(vec_info*) since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103311 --- Comment #6 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:487d604b6fa0f0a981eadc216d9e481d08ed7e7b commit r12-5407-g487d604b6fa0f0a981eadc216d9e481d08ed7e7b Author: Tamar Christina Date: Fri Nov 19 15:12:38 2021 + middle-end: Handle FMA_CONJ correctly after SLP layout update. Apologies, I got dinged by the i386 regressions bot for a test I didn't have in my tree at the time I made the previous patch. The bot was telling me that FMA stopped working after I strengthened the FMA check in the previous patch. The reason is that the check is slightly early. The first check can indeed only exit early when either node isn't a mult. However we need to delay till we know if the node is a MUL or FMA before enforcing that both nodes must be a MULT since the node to inspect is different if the operation is a MUL or FMA. Also with the update patch for GCC 11 tree layout update to the new GCC 12 one I had missed that the difference in which node is conjucated is not symmetrical. So the test for it can just be testing the inverse order. It was Currently no detecting when the first node was conjucated instead of the second one. This also made me wonder why my own test didn't detect this. It turns out that the tests, being copied from the _Float16 ones were incorrectly marked as xfail. The _Float16 ones are marked as xfail since C doesn't have a conj operation for _Float16, which means you get extra type-casts in between. While you could use the GCC _Complex extension here I opted to mark them xfail since I wanted to include detection over the widenings next year. Secondly the double tests were being skipped because Adv. SIMD was missing from targets supporting Complex Double vectorization. With these changes all other tests run and pass and only XFAIL ones are correctly the _Float16 ones. Sorry for missing this before, testing should now cover all cases. gcc/ChangeLog: PR tree-optimization/103311 PR target/103330 * tree-vect-slp-patterns.c (vect_validate_multiplication): Fix CONJ test to new codegen. (complex_mul_pattern::matches): Move check downwards. gcc/testsuite/ChangeLog: PR tree-optimization/103311 PR target/103330 * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-double.c: Fix it. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mla-float.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-double.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mls-float.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-double.c: Likewise. * gcc.dg/vect/complex/fast-math-bb-slp-complex-mul-float.c: Likewise. * lib/target-supports.exp (check_effective_target_vect_complex_add_double): Add Adv. SIMD.
[Bug c++/101731] [9/10/11/12 Regression] ICE in cp_parser_skip_to_pragma_eol, at cp/parser.c:4055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101731 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 51838 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51838=edit gcc12-pr101731.patch This brings the OpenACC handling closer to OpenMP, where fndecl_seen is set at the end of the *late_parsing* rather than in the function that finalizes it.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #9 from Segher Boessenkool --- (In reply to Richard Biener from comment #7) > > I still think it would be best if Gimple did *never* split data. It > > simply does not know enough about the machine and what the eventual > > machine code will be like to do so advantageously. This is the kind > > of thing that RTL can do much better, is much better positioned to do > > (and in fact it does do this, in all subregN passes). > > Well, we need to be able to RTL expand the GIMPLE and vector lowering > will ensure we can. Otherwise we'll just ICE ;) Aha. But RTL can handle this itself already. There is just a pass ordering problem maybe?
[Bug tree-optimization/103168] [9/10/11/12 Regression] Value numbering for PRE of pure functions can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103168 Jan Hubicka changed: What|Removed |Added Summary|Value numbering for PRE of |[9/10/11/12 Regression] |pure functions can be |Value numbering for PRE of |improved|pure functions can be ||improved --- Comment #7 from Jan Hubicka --- The testcase in comment #3 is optimized by GCC 6 but not by GCC 7 up.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #8 from Segher Boessenkool --- Btw: > mfvsrd 9,34 > mfvsrld 8,34 > mfvsrd 11,35 > mfvsrld 10,35 > li 7,1 > cmpd 0,9,11 > bgt 0,.L2 > cmpld 0,9,11 > beq 0,.L5 > .L3: > li 7,0 The fall-through here makes the code worse. > .L2: > subfic 10,7,0 > subfe 11,11,11 And we shouldn't generate this for p10 at all anyway! Something with setbc would be better. If there were no branches here RTL could have made the code a bit more reasonable again, but with branches, no such chance :-(
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #7 from Richard Biener --- (In reply to Segher Boessenkool from comment #6) > Ah, now I see. Thanks! > > Power10 has some new 128-bit insns (and p9 and p8 did before, too). > > I still think it would be best if Gimple did *never* split data. It > simply does not know enough about the machine and what the eventual > machine code will be like to do so advantageously. This is the kind > of thing that RTL can do much better, is much better positioned to do > (and in fact it does do this, in all subregN passes). Well, we need to be able to RTL expand the GIMPLE and vector lowering will ensure we can. Otherwise we'll just ICE ;)
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #6 from Segher Boessenkool --- Ah, now I see. Thanks! Power10 has some new 128-bit insns (and p9 and p8 did before, too). I still think it would be best if Gimple did *never* split data. It simply does not know enough about the machine and what the eventual machine code will be like to do so advantageously. This is the kind of thing that RTL can do much better, is much better positioned to do (and in fact it does do this, in all subregN passes).
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #5 from Bill Schmidt --- At first glance, this is probably because vector.md's definition of vec_cmp isn't defined for V1TImode. Probably needs to be changed to use VEC_IP rather than VEC_I and implement all the cases for 128-bit.
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
--- Comment #16 from Richard Biener ---
And
static void
verify_scope_blocks (tree block, tree supercontext)
{
gcc_assert (BLOCK_SUPERCONTEXT (block) == supercontext);
for (tree t = BLOCK_SUBBLOCKS (block); t; t = BLOCK_CHAIN (t))
verify_scope_blocks (t, block);
}
with checking inside gimplify_function_tree
verify_scope_blocks (DECL_INITIAL (current_function_decl),
current_function_decl);
ICEs first with
#1 0x013ca52a in verify_scope_blocks (block=,
supercontext=)
at /home/rguenther/src/gcc3/gcc/gimplify.c:16044
16044 gcc_assert (BLOCK_SUPERCONTEXT (block) == supercontext);
gdb) p cfun->decl
$1 =
(gdb) p
block->block.supercontext->block.supercontext->block.supercontext->block.supercontext
$12 =
possibly 'block' was added into another function, but it roots at NULL...
somehow all the BLOCK setup is done in poplevel() but I can't see what's wrong.
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328 --- Comment #15 from Iain Sandoe --- OK. I need to see where I slipped up - we are supposed to extract the outlined portion of the function and then wrap that in the various machinery specified in the std. However, blocks associated with parms could possibly be referred to twice (so that the location of the parms is available for debugging the outlined function). Perhaps a missing copy_node().
[Bug c++/94376] When nested inside a lambda body, [=] captures by const value instead of by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94376 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #3 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/94376] When nested inside a lambda body, [=] captures by const value instead of by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94376 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fd740165e54151ea794fca34904f5c2e2ea1dcda commit r12-5403-gfd740165e54151ea794fca34904f5c2e2ea1dcda Author: Patrick Palka Date: Fri Nov 19 08:54:25 2021 -0500 c++: nested lambda capturing a capture proxy [PR94376] Here when determining the type of the FIELD_DECL for the by-value capture of 'i' in the inner lambda, we incorrectly give it the type const int instead of int since the effective initializer is the proxy for the outer capture, and this proxy is const since the outer lambda is non-mutable. This patch fixes this by making lambda_capture_field_type handle by-value capturing of capture proxies specially, namely we instead consider the type of their FIELD_DECL which unlike the proxy has the true cv-quals of the captured entity. PR c++/94376 gcc/cp/ChangeLog: * lambda.c (lambda_capture_field_type): Simplify by handling the is_this case first. When capturing by-value a capture proxy, consider the type of the corresponding field instead. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-nested9.C: New test.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316 --- Comment #4 from Bill Schmidt --- Above was compiled with -O2 -mcpu=power10.
[Bug target/103316] PowerPC: Gimple folding of int128 comparisons produces suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #3 from Bill Schmidt ---
Sure. Consider:
#include
vector bool __int128
foo (vector signed __int128 a, vector signed __int128 b)
{
return vec_cmpgt (a, b);
}
With gimple folding we emulate in 64-bit mode:
mfvsrd 9,34
mfvsrld 8,34
mfvsrd 11,35
mfvsrld 10,35
li 7,1
cmpd 0,9,11
bgt 0,.L2
cmpld 0,9,11
beq 0,.L5
.L3:
li 7,0
.L2:
subfic 10,7,0
subfe 11,11,11
mtvsrdd 34,11,10
blr
.p2align 4,,15
.L5:
cmpld 0,8,10
bgt 0,.L2
b .L3
The desired code generation is just
vcmpgtsq 2,2,3
[Bug c++/103328] [11/12 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1921 since r11-7419-g0f161cc8494cf728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328 --- Comment #14 from Richard Biener --- Note the BLOCK is lost somewhere between CFG build (still OK as by verify_gimple_in_cfg) and free_lang_data where it is lost. Oh, so the BLOCK in question is used in two different functions BIND_EXPRs and thus during the lowering of another function the BLOCK tree of the first function referencing the BLOCK is garbled. (gdb) p cfun->decl->decl_common.initial $18 = (gdb) p cfun->decl->decl_common.initial->block.supercontext $19 = (gdb) p cfun->decl->decl_common.initial->block.supercontext->block.supercontext $20 = (gdb) p cfun->decl->decl_common.initial->block.supercontext->block.supercontext->block.supercontext->block.supercontext $21 = gcc_assert (BLOCK_SUPERCONTEXT (DECL_INITIAL (current_function_decl)) == current_function_decl); at the start of lower_function_body will trip on this. So somewhere coroutines functions are constructed we fail to copy the BLOCK tree of shared parts.
[Bug other/103331] New: There should be a rule to make build.log in the top-level Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103331 Bug ID: 103331 Summary: There should be a rule to make build.log in the top-level Makefile Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org Target Milestone: --- In the top-level Makefile, there's a target warning.log that depends on a build.log file, but trying to do `make warning.log` results in: make: *** No rule to make target `build.log', needed by `warning.log'. Stop. All files depended on by current Makefile targets should have rules to build them from the Makefiles themselves, IMO.
[Bug target/100518] [12 Regression] ICE in copy_to_mode_reg with aarch64 ILP32 and memset with -mstrict-align -O2 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100518 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Mine
[Bug middle-end/100843] [12 Regression] ICE with -O1: in try_store_by_multiple_pieces, at builtins.c:6739 since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100843 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- Mine. bug 100518 seems related, but not necessarily the same issue.
[Bug c++/103329] [11/12 Regression] Code divergence in debug info with -fdump-tree-original since r11-291-g0f50f6daa140186a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103329 --- Comment #2 from Richard Biener --- In the -fdump-tree-original=/dev/null case we have extra <1><107>: Abbrev Number: 3 (DW_TAG_structure_type) <108> DW_AT_name: (indirect string, offset: 0xb8): __is_integer <10c> DW_AT_byte_size : 1 <10c> DW_AT_decl_file : 1 <10c> DW_AT_decl_line : 2 <10d> DW_AT_decl_column : 8 <10e> DW_AT_sibling : <0x124> <2><112>: Abbrev Number: 22 (DW_TAG_enumeration_type) <113> DW_AT_encoding: 7 (unsigned) <114> DW_AT_byte_size : 4 <115> DW_AT_type: <0x57> <119> DW_AT_decl_file : 1 <11a> DW_AT_decl_line : 3 <11b> DW_AT_decl_column : 8 <3><11c>: Abbrev Number: 23 (DW_TAG_enumerator) <11d> DW_AT_name: (indirect string, offset: 0x24a): __value <121> DW_AT_const_value : 0 <3><122>: Abbrev Number: 0 <2><123>: Abbrev Number: 0
[Bug target/103330] [12 Regression] FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c by r12-5378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103330 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- Already posted a patch to ML to fix it. Will commit when I get back to a computer.
