[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:352811870d7d7edcca109ef50822e26ca7ef2b36 commit r10-7957-g352811870d7d7edcca109ef50822e26ca7ef2b36 Author: Jason Merrill Date: Fri Apr 24 16:27:26 2020 -0400 c++: implicit operator== with previous decl [PR94583] P2085 clarified that a defaulted comparison operator must be the first declaration of the function. Rejecting that avoids the ICE trying to compare the noexcept-specifications. gcc/cp/ChangeLog 2020-04-24 Jason Merrill PR c++/94583 * decl.c (redeclaration_error_message): Reject defaulted comparison operator that has been previously declared.
[pushed] c++: implicit operator== with previous decl [PR94583]
P2085 clarified that a defaulted comparison operator must be the first
declaration of the function. Rejecting that avoids the ICE trying to
compare the noexcept-specifications.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-04-24 Jason Merrill
PR c++/94583
* decl.c (redeclaration_error_message): Reject defaulted comparison
operator that has been previously declared.
---
gcc/cp/decl.c | 8
gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C | 11 +++
2 files changed, 19 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index c8c2f080763..31b5884ca3a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2972,6 +2972,14 @@ redeclaration_error_message (tree newdecl, tree olddecl)
}
}
+ /* [class.compare.default]: A definition of a comparison operator as
+defaulted that appears in a class shall be the first declaration of
+that function. */
+ special_function_kind sfk = special_function_p (olddecl);
+ if (sfk == sfk_comparison && DECL_DEFAULTED_FN (newdecl))
+ return G_("comparison operator %q+D defaulted after "
+ "its first declaration");
+
check_abi_tag_redeclaration
(olddecl, lookup_attribute ("abi_tag", DECL_ATTRIBUTES (olddecl)),
lookup_attribute ("abi_tag", DECL_ATTRIBUTES (newdecl)));
diff --git a/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
new file mode 100644
index 000..e8296bbb60a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/spaceship-synth6.C
@@ -0,0 +1,11 @@
+// PR c++/94583
+// { dg-do compile { target c++2a } }
+
+namespace std { struct strong_ordering { }; }
+
+bool operator==(const struct Q&, const struct Q&);
+struct Q {
+ // { dg-error "defaulted after its first declaration" "" { target *-*-* }
.+1 }
+ friend std::strong_ordering operator<=>(const Q&, const Q&) = default;
+};
+bool b = Q() == Q();
base-commit: cbd2a10dd9edadb262934aed64c0959339da68d1
--
2.18.1
[Bug c/94755] New: [10 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755
Bug ID: 94755
Summary: [10 Regression] internal compiler error: Segmentation
fault
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
extern void foo ( void ) ;
void bar ( double x )
{
if ( x == __builtin_speculation_safe_value() )
foo ( ) ;
}
$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-10 reduced.c
reduced.c: In function ‘bar’:
reduced.c:6:2: error: too few arguments to function
‘__builtin_speculation_safe_value’
6 | if ( x == __builtin_speculation_safe_value() )
| ^~
reduced.c:6:2: internal compiler error: Segmentation fault
0xdab3ef crash_signal
../../gcc-10-20200419/gcc/toplev.c:328
0x89132f vec::operator[](unsigned int)
../../gcc-10-20200419/gcc/vec.h:867
0x89132f resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc-10-20200419/gcc/c-family/c-common.c:7405
0x81a6c9 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc-10-20200419/gcc/c/c-typeck.c:3199
0x838cde c_parser_postfix_expression_after_primary
../../gcc-10-20200419/gcc/c/c-parser.c:10501
0x8307a1 c_parser_postfix_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10176
0x834ada c_parser_unary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8273
0x83632d c_parser_cast_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8115
0x83671a c_parser_binary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8041
0x837595 c_parser_conditional_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7652
0x837bb0 c_parser_expr_no_commas
../../gcc-10-20200419/gcc/c/c-parser.c:7569
0x837e11 c_parser_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10637
0x8394a4 c_parser_expression_conv
../../gcc-10-20200419/gcc/c/c-parser.c:10670
0x8394a4 c_parser_condition
../../gcc-10-20200419/gcc/c/c-parser.c:6329
0x839597 c_parser_paren_condition
../../gcc-10-20200419/gcc/c/c-parser.c:6349
0x82e3e0 c_parser_if_statement
../../gcc-10-20200419/gcc/c/c-parser.c:6528
0x82e3e0 c_parser_statement_after_labels
../../gcc-10-20200419/gcc/c/c-parser.c:6160
0x82ff71 c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5805
0x84c8c4 c_parser_compound_statement
../../gcc-10-20200419/gcc/c/c-parser.c:5617
0x84e381 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2505
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754
--- Comment #1 from Alejandro Colomar ---
__builin_unreachable() helped silencing that specific bug, as a temporary
workaround:
[[gnu::nonnull]]
static
int init_x(int cond, int **x, int *y)
{
if (!cond)
return -1;
*x = y;
return 0;
}
int foo(int cond)
{
int *x;
int y = 7;
if (cond < 2)
return -1;
/* cond >= 2 != 0, so it will initialize x and return 0 */
if (init_x(cond, , ))
__builtin_unreachable();
return *x;
}
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
Hi! On Tue, Apr 07, 2020 at 07:18:25AM +0200, Sebastian Huber wrote: > Since commit e154242724b084380e3221df7c08fcdbd8460674 the flag -many is > sometimes not passed to the assembler. Use .machine ppc to prevent > errors if these files are assembled for an ISA which does not support > FPRs. > > libgcc/ > > * config/rs6000/crtresfpr.S: Use .machine ppc. > * config/rs6000/crtresxfpr.S: Likewise. > * config/rs6000/crtsavfpr.S: Likewise. This is fine. Okay for trunk. Thank you! Also okay for backports if you want -- after letting it simmer on trunk for a week or so. Segher
[committed] d: Merge upstream dmd 09db0c41e, druntime e68a5ae3.
Hi, This patch merges the D front-end implementation with upstream dmd 09db0c41e, and the D runtime library with upstream druntime e68a5ae3. * New core.math.toPrec templates have been added as an intrinsic. Some floating point algorithms, such as Kahan-Babuska-Neumaier Summation, require rounding to specific precisions. Rounding to precision after every operation, however, loses overall precision in the general case and is a runtime performance problem. Adding these functions guarantee the rounding at required points in the code, and document where in the algorithm the requirement exists. * Support IBM long double types in core.internal.convert. * Add missing aliases for 64-bit vectors in core.simd. * RUNNABLE_PHOBOS_TEST directive has been properly integrated into the D2 language testsuite. Bootstrapped and regression tested on x86_64-linux-gnu, committed to mainline. Regards Iain --- gcc/d/ChangeLog: * intrinsics.cc (expand_intrinsic_toprec): New function. (maybe_expand_intrinsic): Handle toPrec intrinsics. * intrinsics.def (TOPRECF, TOPREC, TOPRECL): Add toPrec intrinsics. --- gcc/d/dmd/MERGE | 2 +- gcc/d/intrinsics.cc | 22 +++ gcc/d/intrinsics.def | 3 + .../gdc.test/compilable/interpret3.d | 16 ++ gcc/testsuite/gdc.test/runnable/builtin.d | 2 +- gcc/testsuite/gdc.test/runnable/complex.d | 2 +- gcc/testsuite/gdc.test/runnable/constfold.d | 3 +- gcc/testsuite/gdc.test/runnable/foreach4.d| 3 +- gcc/testsuite/gdc.test/runnable/ifti.d| 2 +- gcc/testsuite/gdc.test/runnable/implicit.d| 3 +- gcc/testsuite/gdc.test/runnable/inner.d | 3 +- gcc/testsuite/gdc.test/runnable/interpret.d | 47 - gcc/testsuite/gdc.test/runnable/issue8671.d | 2 +- gcc/testsuite/gdc.test/runnable/lazy.d| 2 +- gcc/testsuite/gdc.test/runnable/mars1.d | 2 +- gcc/testsuite/gdc.test/runnable/mixin1.d | 3 +- gcc/testsuite/gdc.test/runnable/mixin2.d | 2 +- gcc/testsuite/gdc.test/runnable/s2ir.d| 3 +- gcc/testsuite/gdc.test/runnable/stress.d | 2 +- gcc/testsuite/gdc.test/runnable/template4.d | 2 +- gcc/testsuite/gdc.test/runnable/template9.d | 2 +- gcc/testsuite/gdc.test/runnable/test10942.d | 2 +- gcc/testsuite/gdc.test/runnable/test11.d | 2 +- gcc/testsuite/gdc.test/runnable/test12.d | 2 +- gcc/testsuite/gdc.test/runnable/test12197.d | 2 +- gcc/testsuite/gdc.test/runnable/test15.d | 2 +- gcc/testsuite/gdc.test/runnable/test22.d | 2 +- gcc/testsuite/gdc.test/runnable/test23.d | 2 +- gcc/testsuite/gdc.test/runnable/test24.d | 2 +- gcc/testsuite/gdc.test/runnable/test27.d | 2 +- gcc/testsuite/gdc.test/runnable/test28.d | 2 +- gcc/testsuite/gdc.test/runnable/test34.d | 3 +- gcc/testsuite/gdc.test/runnable/test37.d | 2 +- gcc/testsuite/gdc.test/runnable/test42.d | 3 +- gcc/testsuite/gdc.test/runnable/test5305.d| 2 +- gcc/testsuite/gdc.test/runnable/test60.d | 2 +- gcc/testsuite/gdc.test/runnable/testaa.d | 2 +- .../gdc.test/runnable/testbitarray.d | 2 +- gcc/testsuite/gdc.test/runnable/testdstress.d | 2 +- gcc/testsuite/gdc.test/runnable/testfile.d| 2 +- gcc/testsuite/gdc.test/runnable/testformat.d | 2 +- gcc/testsuite/gdc.test/runnable/testline.d| 2 +- gcc/testsuite/gdc.test/runnable/testmmfile.d | 2 +- gcc/testsuite/gdc.test/runnable/testscope2.d | 2 +- gcc/testsuite/gdc.test/runnable/testsignals.d | 2 +- gcc/testsuite/gdc.test/runnable/testsocket.d | 2 +- gcc/testsuite/gdc.test/runnable/teststdio.d | 2 +- gcc/testsuite/gdc.test/runnable/testthread2.d | 2 +- gcc/testsuite/gdc.test/runnable/testtypeid.d | 3 +- gcc/testsuite/gdc.test/runnable/traits.d | 2 +- gcc/testsuite/gdc.test/runnable/wc.d | 2 +- gcc/testsuite/gdc.test/runnable/wc2.d | 2 +- gcc/testsuite/gdc.test/runnable/wc3.d | 2 +- gcc/testsuite/gdc.test/runnable/xtest46.d | 2 +- gcc/testsuite/gdc.test/runnable/xtest55.d | 2 +- libphobos/libdruntime/MERGE | 2 +- libphobos/libdruntime/core/cpuid.d| 2 +- libphobos/libdruntime/core/internal/convert.d | 170 -- libphobos/libdruntime/core/math.d | 71 libphobos/libdruntime/core/simd.d | 6 +- 60 files changed, 329 insertions(+), 121 deletions(-) diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE index 155286dd765..a878cb9f42e 100644 --- a/gcc/d/dmd/MERGE +++ b/gcc/d/dmd/MERGE @@ -1,4 +1,4 @@ -62ce36f3737de691217c21f0173f411734eb1d43 +09db0c41ee922502fa0966bde24c1cb9b15ad436 The first line of this file holds the git revision number of the last merge done from the dlang/dmd repository. diff --git a/gcc/d/intrinsics.cc b/gcc/d/intrinsics.cc index
[Bug analyzer/94754] New: -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754
Bug ID: 94754
Summary: -fanalyzer false positive due to it ignoring previous
if
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
The analyzer follows branches that are incompatible (sometimes).
Code to reproduce the bug:
[[gnu::nonnull]]
static
voidinit_x(int cond, int **x, int *y)
{
if (!cond)
return;
*x = y;
}
int foo(int cond)
{
int *x;
int y = 7;
if (cond < 2)
return -1;
/* cond >= 2 != 0, so it will initialize x */
init_x(cond, , );
return *x;
}
$ gcc-10 -c false_positive.c -o foo -fanalyzer
In function ‘foo’:
false_positive.c:22:9: warning: use of uninitialized value ‘x’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
22 | return *x;
| ^~
‘foo’: events 1-4
|
| 11 | int foo(int cond)
| | ^~~
| | |
| | (1) entry to ‘foo’
|..
| 16 | if (cond < 2)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘cond > 1’)...
|..
| 20 | init_x(cond, , );
| |
| | |
| | (3) ...to here
| | (4) calling ‘init_x’ from ‘foo’
|
+--> ‘init_x’: events 5-7
|
|3 | void init_x(int cond, int **x, int *y)
| | ^~
| | |
| | (5) entry to ‘init_x’
|..
|6 | if (!cond)
| | ~
| | |
| | (6) following ‘true’ branch (when ‘cond == 0’)...
!!! cond == 0, but previously it assumed cond > 1 !!!
|7 | return;
| | ~~
| | |
| | (7) ...to here
|
<--+
|
‘foo’: events 8-9
|
| 20 | init_x(cond, , );
| | ^~~~
| | |
| | (8) returning to ‘foo’ from ‘init_x’
| 21 |
| 22 | return *x;
| | ~~
| | |
| | (9) use of uninitialized value ‘x’ here
|
$
___
But.
- If I copy (manual inline) `init_x` code inside `foo`, the warning goes
away.
- If I use pointers instead of double pointers (`void init_x(int cond, int *x,
int y)`), the warning goes away.
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On Fri, Apr 24, 2020 at 04:47:31PM -0500, Peter Bergner wrote: > On 4/17/20 12:59 AM, Sebastian Huber wrote: > > Hello Segher, > > > > would you mind having a look at this patch. > > > > His patch is here: > > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543396.html (And at https://patchwork.ozlabs.org/project/gcc/patch/20200407051825.12516-1-sebastian.hu...@embedded-brains.de/ where you can see headers as well). Ah, I wasn't Cc:ed, and I don't have a regexp for "RS6000" :-) Segher
[Bug preprocessor/94753] New: -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 Bug ID: 94753 Summary: -undef, c++20 and feature-test macros Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: r_new at rambler dot ru Target Milestone: --- In c++20 feature-test macros (__cpp_attributes, __cpp_constexpr, ...) are standard predefined macros, must be predefined even with -undef. g++ -undef -std=c++2a -E -dM -x c++ - < /dev/null #define __STDC_HOSTED__ 1 #define __STDC_IEC_559__ 1 #define __STDC_ISO_10646__ 201706L #define __STDC_UTF_16__ 1 #define __cplusplus 201709L #define _STDC_PREDEF_H 1 #define __STDC_IEC_559_COMPLEX__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 #define _GNU_SOURCE 1 gcc version 10.0.1 20200423 (experimental) (Compiler-Explorer-Build) and gcc version 9.3.0 (Arch Linux 9.3.0-1)
[Bug middle-end/92830] -fdiagnostics-url shows the wrong URL for warnings which are not in 'gcc' but e.g. in 'gfortran'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Similarly, -fanalyzer warnings are documented within Static-Analyzer-Options.html.
[Bug c++/94751] [9/10 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- We now error_mark_node around for a longer time, so we need to handle it. Taking.
Re: [Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent
On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: > Hi, Dave, > > Thanks a lot for the review and comments. > I just updated the patch with all your suggestions, bootstrapped it > and run regression test, no any issue. > > The newest patch is attached with this email. > > Richard/Jakub, please advise on whether I can commit this patch to > Gcc10? > > Thanks a lot. > > Qing > Thanks Qing. One more wording nit (sorry!) > + if (!flag_large_source_files) > + inform (loc, > + "adding %<-flarge-source-files%> will allow for more" > + " column-tracking support, at the expense of compilation" > + " and memory"); ^ Please add "time" here i.e. " time and memory"); Dave
gcc-8-20200424 is now available
Snapshot gcc-8-20200424 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200424/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision aadc54867cc200ad7d073222769b9de7f13b5bcd You'll find: gcc-8-20200424.tar.xzComplete GCC SHA256=1663a02a7298140be92680be6104389fc9ae2a75edc07c9dee851e66a83864f3 SHA1=f4aa2e6d0ee284ca8272fb567220eab64135eb9e Diffs from 8-20200417 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug c++/94752] New: [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752
Bug ID: 94752
Summary: [coroutines] compiler ICE with coroutine with unnamed
parameter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lewissbaker.opensource at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/QCXqeo
Compile the following source code with GCC trunk.
Flags: -std=c++20 -fcoroutines
-
#include
using namespace std;
struct task {
struct promise_type {
promise_type() {}
task get_return_object() { return {}; }
suspend_never initial_suspend() { return {}; }
suspend_never final_suspend() { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
task foo(int) {
co_return;
}
-
Results in an internal-compile-error - segmentation-fault.
Pointing at closing curly-brace of 'foo()'.
Seems to be related to the parameter being unnamed as naming
the parameter results in this code compiling successfully.
[Bug c++/94751] [9/10] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.4 Last reconfirmed||2020-04-24 Ever confirmed|0 |1 Keywords||ice-on-invalid-code --- Comment #1 from Marek Polacek --- Started with r9-6097-g9d35a27a8353b57ed11fa1cb7d747edf1c4faa01
Re: [PATCH v2] aarch64: Add TX3 machine model
On Wed, Apr 22, 2020 at 8:25 PM Joel Jones wrote: > > Yes, Bellsoft's contribution is to be covered under the Marvell copyright > > assignment, as this is a work for hire. Thanks ! Ramana > > > > Joel > > > > >Yes, Bellsoft's contribution is to be covered under the Marvell copyright > > >assignment, as this is a work for hire. > > > > > >Joel > > > > > >>>Hi Anton, > > >>> > > -Original Message- > > From: Gcc-patches On Behalf Of Anton > > Youdkevitch > > Sent: 20 April 2020 19:29 > > To: gcc-patches@gcc.gnu.org > > Cc: jo...@marvell.com > > Subject: [PATCH v2] aarch64: Add TX3 machine model > > > > Here is the patch introducing thunderxt311 maching model > > for the scheduler. A name for the new chip was added to the > > list of the names to be recognized as a valid parameter for mcpu > > and mtune flags. The TX2 cost model was reused for TX3. > > > > The previously used "cryptic" name for the command line > > parameter is replaced with the same "thunderxt311" name. > > > > Bootstrapped on AArch64. > > >>> > > >>>Thanks for the patch. I had meant to ask, do you have a copyright > >>>assignment in place? > > >>>We'd need one to accept a contribution of this size. > > >>>Thanks, > > >>>Kyrill > > >>> > > > > 2020-04-20 Anton Youdkevitch > > > > * config/aarch64/aarch64-cores.def: Add the chip name. > > * config/aarch64/aarch64-tune.md: Regenerated. > > * gcc/config/aarch64/aarch64.c: Add the cost tables for the chip. > > * gcc/config/aarch64/thunderx3t11.md: New file: add the new > > machine model for the scheduler > > * gcc/config/aarch64/aarch64.md: Include the new model. > > > > --- > > gcc/config/aarch64/aarch64-cores.def | 3 + > > gcc/config/aarch64/aarch64-tune.md | 2 +- > > gcc/config/aarch64/aarch64.c | 27 + > > gcc/config/aarch64/aarch64.md| 1 + > > gcc/config/aarch64/thunderx3t11.md | 686 +++ > > 5 files changed, 718 insertions(+), 1 deletion(-) > > >>> > > >>> > > >>> > > >>> > > >
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 89430, which changed state. Bug 89430 Summary: A missing ifcvt optimization to generate csel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |--- CC||jakub at gcc dot gnu.org Status|RESOLVED|REOPENED --- Comment #13 from Jakub Jelinek --- The testcases for which this has been filed are no longer optimized, that needs more work for GCC11.
[Bug c++/94742] [8/9 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] Incorrect |Incorrect "no return|"no return statement" |statement" warning with |warning with [[noreturn]] |[[noreturn]] and|and __FUNCTION__ |__FUNCTION__| --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed.
[Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent
Hi, Dave,
Thanks a lot for the review and comments.
I just updated the patch with all your suggestions, bootstrapped it and run
regression test, no any issue.
The newest patch is attached with this email.
Richard/Jakub, please advise on whether I can commit this patch to Gcc10?
Thanks a lot.
Qing
gcc/c-family/ChangeLog:
2020-04-24 qing zhao
* c-indentation.c (get_visual_column): Add a hint to use the new
-flarge-source-files option.
gcc/ChangeLog:
2020-04-24 qing zhao
* common.opt: Add -flarge-source-files.
* doc/invoke.texi: Document it.
* toplev.c (process_options): Set line_table->default_range_bits
to 0 when flag_large_source_files is true.
gcc/testsuite/ChangeLog:
2020-04-24 qing zhao
* gcc.dg/plugin/location-overflow-test-1.c (fn_1): New message to
verify that hint about -flarge-source-files is emitted.
PR94230.patch
Description: Binary data
> On Apr 23, 2020, at 5:13 PM, David Malcolm wrote:
>
> On Thu, 2020-04-23 at 16:05 -0500, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> This is the 3rd version of the patch, updated based on your previous
>> comments.
>
> Thanks for working on this, and to Richard for the useful comments.
>
>> Please take a look at it and let me know whether it’s okay to commit?
>
> I like the overall approach.
>
> Some nits inline.
>
>
> Maybe: "Verify that hint about -flarge-source-files is emitted".
>
>
>> + if (!flag_large_source_files)
>> +inform (loc,
>> +"please add %<-flarge-source-files%> to invoke more"
>> +" column-tracking for large source files");
>
> It's great having a hint here, but I don't love the wording of the
> hint.
>
> Maybe reword to:
>
> "adding %<-flarge-source-files%> will allow for more column-tracking
> support, at the expense of compilation time and memory".
>
> or somesuch.
>
>> +This means that diagnostics for later lines do not include column numbers.
>> +It also means that options like @option{-Wmisleading-indent} cease to work
> ^^^
> This should be:-Wmisleading-indentation
>
>> +at that point, although the compiler prints a note if this happens.
>> +Passing @option{-flarge-source-files} significantly increases the number
>> +of source lines that GCC can process before it stops tracking column.
> ^^
> This should be:columns
>
>> + if (flag) x = 3; y = 2; /* { dg-message "-:disabled from this point" "add
>> '-flarge-source-files'" } */
>
> May need updating to match the hint message.
>
> [...]
>
> This is OK for stage 1 with those nits fixed.
>
> There was talk earlier in the thread about fixing this in GCC 10.
>
> Richi/Jakub: is this OK for stage 4? Although it adds a new command-
> line option, it's a workaround for a regression introduced in GCC 6 and
> should be low risk.
>
> Thanks
> Dave
>
[Bug c++/94742] [8/9/10 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ff685a8705e8ee55fa86e75afb769ffb0975aea commit r10-7953-g4ff685a8705e8ee55fa86e75afb769ffb0975aea Author: Jakub Jelinek Date: Sat Apr 25 00:11:35 2020 +0200 c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742] finish_call_expr already has code to set current_function_returns_abnormally if a template calls a noreturn function, but on the following testcase it doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case we didn't check noreturn at all and just assumed it could return. 2020-04-25 Jakub Jelinek PR c++/94742 * semantics.c (finish_call_expr): When looking if all overloads are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs. * g++.dg/warn/Wreturn-type-12.C: New test.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #18 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf39dccf9284d2fd9f9aa7050760adea110c8d88 commit r10-7952-gcf39dccf9284d2fd9f9aa7050760adea110c8d88 Author: Jakub Jelinek Date: Sat Apr 25 00:10:01 2020 +0200 cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734] As the new testcase shows, it is not safe to assume we can optimize a conditional store into an automatic non-addressable var, we can do it only if we can prove that the unconditional load or store actually will not be outside of the boundaries of the variable. If the offset and size are constant, we can, but this is already all checked in !tree_could_trap_p, otherwise we really need to check for a dominating unconditional store, or for the specific case of automatic non-addressable variables, it is enough if there is a dominating load (that is what those 4 testcases have). tree-ssa-phiopt.c has some infrastructure for this already, see the add_or_mark_expr method etc., but right now it handles only MEM_REFs with SSA_NAME first operand and some integral offset. So, I think it can be for GCC11 extended to handle other memory references, possibly up to just doing get_inner_reference and hasing based on the base, offset expressions and bit_offset and bit_size, and have also a special case that for !TREE_ADDRESSABLE automatic variables it could ignore whether something is a load or store because the local stack should be always writable. But it feels way too dangerous to do this this late for GCC10, so this patch just restricts the optimization to the safe case (where lhs doesn't trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if flag_store_data_races, because my understanding the reason for TREE_ADDRESSABLE check is that we want to avoid introducing store data races (if address of an automatic var escapes, some other thread could be accessing it concurrently). 2020-04-25 Jakub Jelinek Richard Biener PR tree-optimization/94734 PR tree-optimization/89430 * tree-ssa-phiopt.c: Include tree-eh.h. (cond_store_replacement): Return false if an automatic variable access could trap. If -fstore-data-races, don't return false just because an automatic variable is addressable. * gcc.dg/tree-ssa/pr89430-1.c: Add xfail. * gcc.dg/tree-ssa/pr89430-2.c: Add xfail. * gcc.dg/tree-ssa/pr89430-5.c: Add xfail. * gcc.dg/tree-ssa/pr89430-6.c: Add xfail. * gcc.c-torture/execute/pr94734.c: New test.
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44379.html Keywords||patch --- Comment #3 from Eric Gallager --- (In reply to Sergei Trofimovich from comment #2) > Sent as https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544379.html thanks, adding the "patch" keyword
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf39dccf9284d2fd9f9aa7050760adea110c8d88 commit r10-7952-gcf39dccf9284d2fd9f9aa7050760adea110c8d88 Author: Jakub Jelinek Date: Sat Apr 25 00:10:01 2020 +0200 cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734] As the new testcase shows, it is not safe to assume we can optimize a conditional store into an automatic non-addressable var, we can do it only if we can prove that the unconditional load or store actually will not be outside of the boundaries of the variable. If the offset and size are constant, we can, but this is already all checked in !tree_could_trap_p, otherwise we really need to check for a dominating unconditional store, or for the specific case of automatic non-addressable variables, it is enough if there is a dominating load (that is what those 4 testcases have). tree-ssa-phiopt.c has some infrastructure for this already, see the add_or_mark_expr method etc., but right now it handles only MEM_REFs with SSA_NAME first operand and some integral offset. So, I think it can be for GCC11 extended to handle other memory references, possibly up to just doing get_inner_reference and hasing based on the base, offset expressions and bit_offset and bit_size, and have also a special case that for !TREE_ADDRESSABLE automatic variables it could ignore whether something is a load or store because the local stack should be always writable. But it feels way too dangerous to do this this late for GCC10, so this patch just restricts the optimization to the safe case (where lhs doesn't trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if flag_store_data_races, because my understanding the reason for TREE_ADDRESSABLE check is that we want to avoid introducing store data races (if address of an automatic var escapes, some other thread could be accessing it concurrently). 2020-04-25 Jakub Jelinek Richard Biener PR tree-optimization/94734 PR tree-optimization/89430 * tree-ssa-phiopt.c: Include tree-eh.h. (cond_store_replacement): Return false if an automatic variable access could trap. If -fstore-data-races, don't return false just because an automatic variable is addressable. * gcc.dg/tree-ssa/pr89430-1.c: Add xfail. * gcc.dg/tree-ssa/pr89430-2.c: Add xfail. * gcc.dg/tree-ssa/pr89430-5.c: Add xfail. * gcc.dg/tree-ssa/pr89430-6.c: Add xfail. * gcc.c-torture/execute/pr94734.c: New test.
Re: [PATCH, V5] PowerPC Turn on -mpcrel by default for -mcpu=future
Hi!
On Wed, Apr 22, 2020 at 12:53:03AM -0400, Michael Meissner wrote:
> 2020-04-21 Michael Meissner
>
> * config/rs6000/linux64.h (PCREL_SUPPORTED_BY_OS): Define to
> enable PC-relative addressing for -mcpu=future.
> * config/rs6000/rs6000-cpus.def (ISA_FUTURE_MASKS_SERVER): Move
> after OTHER_FUTURE_MASKS. Use OTHER_FUTURE_MASKS.
> * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): If not defined,
> suppress PC-relative addressing.
> (rs6000_option_override_internal): Split up error messages
> checking for -mprefixed and -mpcrel. Enable -mpcrel if the target
> system supports it.
>
> --- /tmp/ud7l8s_linux64.h 2020-04-21 16:09:26.761209165 -0400
> +++ gcc/config/rs6000/linux64.h 2020-04-21 16:04:59.432652447 -0400
> @@ -640,3 +640,10 @@ extern int dot_symbols;
> enabling the __float128 keyword. */
> #undef TARGET_FLOAT128_ENABLE_TYPE
> #define TARGET_FLOAT128_ENABLE_TYPE 1
> +
> +/* Enable using prefixed PC-relative addressing on the 'future' machine if
> the
> + ABI supports it. The ELF v2 ABI only supports PC-relative relocations for
> + the medium code model. */
> +#define PCREL_SUPPORTED_BY_OS(TARGET_FUTURE && TARGET_PREFIXED
> \
> + && ELFv2_ABI_CHECK \
> + && (TARGET_CMODEL == CMODEL_MEDIUM))
No extra parens around comparisons please. If the macros malfunction
without it, fix the macros!
> + /* If the ABI has support for PC-relative relocations, enable it by
> default.
> + This test depends on the sub-target tests above setting the code model
> to
> + medium for ELF v2 systems. */
> + if (PCREL_SUPPORTED_BY_OS
> + && (rs6000_isa_flags_explicit & OPTION_MASK_PCREL) == 0)
> +rs6000_isa_flags |= OPTION_MASK_PCREL;
> +
>/* -mpcrel requires -mcmodel=medium, but we can't check TARGET_CMODEL until
>after the subtarget override options are done. */
> - if (TARGET_PCREL && TARGET_CMODEL != CMODEL_MEDIUM)
> + else if (TARGET_PCREL && TARGET_CMODEL != CMODEL_MEDIUM)
> {
>if ((rs6000_isa_flags_explicit & OPTION_MASK_PCREL) != 0)
> error ("%qs requires %qs", "-mpcrel", "-mcmodel=medium");
If pcrel is enabled by the first if(), we still need to test for cmodel,
I think? This same code won't work, of course.
Okay for trunk with that first thing fixed, and that second thing can be
dealt with in a later patch.
Thanks!
Segher
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On 4/17/20 12:59 AM, Sebastian Huber wrote: > Hello Segher, > > would you mind having a look at this patch. > His patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543396.html Peter
[committed] d: Fix order of precedence for -defaultlib and -debuglib
Hi,
The order of precedence used by the upstream reference compiler for
determining what library to link against is:
- No library if -nophoboslib or -fno-druntime was seen.
- The library passed to -debuglib if -g was also seen.
- The library passed to -defaultlib
- The in-tree libgphobos library.
This patch aligns the D language driver to follow the same rules.
Bootstrapped and regression tested on x86_64-linux-gnu, and committed to
mainline.
Regards
Iain.
---
gcc/d/ChangeLog:
* d-spec.cc (need_phobos): Remove.
(lang_specific_driver): Replace need_phobos with phobos_library.
Reorder -debuglib and -defaultlib to have precedence over libphobos.
(lang_specific_pre_link): Remove test for need_phobos.
---
gcc/d/d-spec.cc | 84 +
1 file changed, 36 insertions(+), 48 deletions(-)
diff --git a/gcc/d/d-spec.cc b/gcc/d/d-spec.cc
index e0844222520..f4744763ab6 100644
--- a/gcc/d/d-spec.cc
+++ b/gcc/d/d-spec.cc
@@ -61,10 +61,6 @@ enum phobos_action
static phobos_action phobos_library = PHOBOS_DEFAULT;
-/* If true, use the standard D runtime library when linking with
- standard libraries. */
-static bool need_phobos = true;
-
/* If true, do load libgphobos.spec even if not needed otherwise. */
static bool need_spec = false;
@@ -151,13 +147,15 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
break;
case OPT_nophoboslib:
- need_phobos = false;
+ phobos_library = PHOBOS_NOLINK;
args[i] |= SKIPOPT;
break;
case OPT_fdruntime:
if (!value)
- need_phobos = false;
+ phobos_library = PHOBOS_NOLINK;
+ else
+ phobos_library = PHOBOS_LINK;
break;
case OPT_defaultlib_:
@@ -165,7 +163,6 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
free (CONST_CAST (char *, defaultlib));
if (arg != NULL)
{
- need_phobos = false;
args[i] |= SKIPOPT;
defaultlib = XNEWVEC (char, strlen (arg));
strcpy (CONST_CAST (char *, defaultlib), arg);
@@ -177,7 +174,6 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
free (CONST_CAST (char *, debuglib));
if (arg != NULL)
{
- need_phobos = false;
args[i] |= SKIPOPT;
debuglib = XNEWVEC (char, strlen (arg));
strcpy (CONST_CAST (char *, debuglib), arg);
@@ -314,10 +310,11 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
#endif
/* Make sure to have room for the trailing NULL argument.
- - needstdcxx might add `-lstdcxx'
+ - need_stdcxx might add `-lstdcxx'
- libphobos adds `-Bstatic -lphobos -Bdynamic'
- only_source adds 1 more arg, also maybe add `-o'. */
- num_args = argc + need_stdcxx + shared_libgcc + need_phobos * 4 + 2;
+ num_args = argc + need_stdcxx + shared_libgcc
++ (phobos_library != PHOBOS_NOLINK) * 4 + 2;
new_decoded_options = XNEWVEC (cl_decoded_option, num_args);
i = 0;
@@ -409,60 +406,51 @@ lang_specific_driver (cl_decoded_option
**in_decoded_options,
}
/* Add `-lgphobos' if we haven't already done so. */
- if (phobos_library != PHOBOS_NOLINK && need_phobos)
+ if (phobos_library != PHOBOS_NOLINK)
{
/* Default to static linking. */
if (phobos_library != PHOBOS_DYNAMIC)
phobos_library = PHOBOS_STATIC;
#ifdef HAVE_LD_STATIC_DYNAMIC
- if (phobos_library == PHOBOS_DYNAMIC && static_link)
- {
- generate_option (OPT_Wl_, LD_DYNAMIC_OPTION, 1, CL_DRIVER,
- _decoded_options[j]);
- j++;
- }
- else if (phobos_library == PHOBOS_STATIC && !static_link)
+ if (phobos_library == PHOBOS_STATIC && !static_link)
{
generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
- _decoded_options[j]);
- j++;
+ _decoded_options[j++]);
}
#endif
-
- generate_option (OPT_l,
- saw_profile_flag ? LIBPHOBOS_PROFILE : LIBPHOBOS, 1,
- CL_DRIVER, _decoded_options[j]);
- added_libraries++;
- j++;
-
-#ifdef HAVE_LD_STATIC_DYNAMIC
- if (phobos_library == PHOBOS_DYNAMIC && static_link)
+ /* Order of precedence in determining what library to link against is:
+- `-l' from `-debuglib=' if `-g' was also seen.
+- `-l' from `-defaultlib='.
+- `-lgphobos' unless `-nophoboslib' or `-fno-druntime' was seen. */
+ if (debuglib && saw_debug_flag)
{
- generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
- _decoded_options[j]);
- j++;
+ generate_option (OPT_l, debuglib, 1, CL_DRIVER,
+ _decoded_options[j++]);
+ added_libraries++;
}
- else if
Re: [PATCH,rs6000] enable -fweb for small loops unrolling
Hi! On Mon, Apr 20, 2020 at 09:57:31PM +0800, guojiufu wrote: > Previously -fweb was disabled if only unroll small loops. After that > we find there is cases where it could help to rename pseudos and aovid > some anti-dependence which may occur after unroll. > > Below is a patch to disable -fweb during loop unrolling. > > Bootstrap and regtest pass on powerpc, spec2017 run shows no performance > downgrade. > > Is this ok for trunk? Yes, this is fine for trunk. Thank you! A changelog nit: > gcc/ > 2020-04-20 Jiufu Guo > > * common/config/rs6000/rs6000-common.c > (rs6000_option_optimization_table)[OPT_LEVELS_ALL]: Remove turn off > -fweb. There should be a space before the "[". Segher
Re: [PATCH] RS6000: Use .machine ppc for some CRT files
On Fri, Apr 17, 2020 at 07:59:02AM +0200, Sebastian Huber wrote: > would you mind having a look at this patch. Hi! I see no patch? Segher
Re: [PATCH v2] rs6000: Don't use HARD_FRAME_POINTER_REGNUM if it's not live in pro_and_epilogue (PR91518)
Hi!
On Fri, Apr 17, 2020 at 01:35:15PM +0800, luoxhu wrote:
> On 2020/4/17 08:52, Segher Boessenkool wrote:
> > On Mon, Apr 13, 2020 at 10:11:43AM +0800, luoxhu wrote:
> >> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> >> but regs_ever_live[31] is false, pro_and_epilogue uses it without live
> >> check causing CPU2006 465.tonto segment fault of loading from invalid
> >> addresses due to r31 not saved/restored. Thus, add
> >> HARD_FRAME_POINTER_REGNUM
> >> live check with frame_pointer_needed_indeed_p when generating
> >> pro_and_epilogue
> >> instructions.
> >
> > I see.
> >
> > Can you instead make a boolean variable "frame_pointer_needed_indeed",
> > that you set somewhere early in *logue processing? So that we can be
> > sure that it will not change behind our backs.
>
>
> Thanks, rs6000_emit_prologue seems the proper place to set the
> frame_pointer_needed_indeed,
Yeah.
> but it's strange that hard_frame_pointer_rtx will be marked USE in
> make_prologue_seq, also
This is for when profiling is enabled. If this routine itself does not
use the hard frame pointer, the profiling code (not generated by GCC
here!) could still use it, so we need the USE to make sure later GCC
passes will see the hard frame pointer as live.
This is generic code; it isn't relevant for rs6000 I think.
> need check here though not causing segfault?
I'm not sure how it would?
> function.c
> static rtx_insn *
> make_prologue_seq (void)
> {
> if (!targetm.have_prologue ())
> return NULL;
>
> start_sequence ();
> rtx_insn *seq = targetm.gen_prologue ();
> emit_insn (seq);
>
> /* Insert an explicit USE for the frame pointer
> if the profiling is on and the frame pointer is required. */
> if (crtl->profile && frame_pointer_needed)
> emit_use (hard_frame_pointer_rtx);
> ...
> Any way, update the patch as below with your previous comments:
>
>
>
> This bug is exposed by FRE refactor of r263875. Comparing the fre
> dump file shows no obvious change of the segment fault function proves
> it to be a target issue.
> frame_pointer_needed is set to true in reload pass setup_can_eliminate,
> but regs_ever_live[31] is false, pro_and_epilogue uses it without live
> check causing CPU2006 465.tonto segment fault of loading from invalid
> addresses due to r31 not saved/restored. Thus, add HARD_FRAME_POINTER_REGNUM
> live check with frame_pointer_needed_indeed when generating pro_and_epilogue
> instructions.
>
> Bootstrap and regression tested pass on Power8-LE. Backport to gcc-9
> required once approved.
>
> gcc/ChangeLog
>
> 2020-04-17 Xiong Hu Luo
>
> PR target/91518
> * config/rs6000/rs6000-logue.c (frame_pointer_needed_indeed):
> New variable.
> (rs6000_emit_prologue_components):
> Check with frame_pointer_needed_indeed.
> (rs6000_emit_epilogue_components): Likewise.
> (rs6000_emit_epilogue): Likewise.
> (rs6000_emit_prologue): Set frame_pointer_needed_indeed.
The patch is okay for trunk. (And for backports later). Thank you!
Segher
Re: Not usable email content encoding
Hi! On Fri, Apr 24, 2020 at 10:01:20PM +0200, Martin Jambor wrote: > On Fri, Apr 24 2020, Segher Boessenkool wrote: > > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > >> >Of course, better would be to remove ChangeLogs entirely (including not > >> >putting anything like them into a commit message), because they are > >> >largely not useful and are just make-work. > >> > >> I disagree. I find them quite useful. > > > > For what? And, can that be provided some other way? > > I often have a look at them when reviewing a patch. I *always* do that (approving a patch is also approving the proposed changelog for it, so :-) ) > It is great when > they clearly indicate whether a change is some form of restructuring or > a functional change and broadly speaking what it is. Then I just know > what to look for. Yeah... Ideally, you can just read the whole patch message *in order*: first the subject (before you see anything else; this is where you decide you need some more coffee first). Then, the commit message, which should tell you everything you need to know about what the patch accomplishes. Then, the changelog, which tells you all that the patch changes (which is also really handy when this does not match up 100% with what the patch does!) And finally, the patch itself. > I also find writing them useful as it forces me to go through every > patch one last time before submitting it :-) If you spend some time > configuring your text editor and git, the boilerplate stuff can be > generated automatically. One good trick is realising that if your patch series isn't structured well, writing the changelogs is much harder. This can very often be applied the other way: if you construct your patch series so that the changelogs are simple to write (i.e. boring), your patch series becomes much stronger, and much easier to understand. Only one theme per patch; if you need to restructure some existing code, do that *first*, in a *separate* patch; that kind of thing. > I do not think this can be provided in any other way that would not > resemble a ChangeLog. I do support the effort to put them into commit > messages only though (and then perhaps generate the files from that). I think if people make better patch series (small patches are *good*!), and better commit messages, changelogs will have much less value than they do today. But until people do that, dropping changelogs will be a real loss. Segher
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
On 4/24/20 4:19 AM, Szabolcs Nagy wrote:
On aarch64 -mbranch-protection=pac-ret reuses the dwarf
opcode for window_save to mean "toggle the return address
mangle state", but in the dwarf2cfi internal logic the
state was not updated when an opcode was emitted, the
currently present update logic is only valid for the
original sparc use of window_save so a separate bool is
used on aarch64 to track the state.
This bug can cause the unwinder not to authenticate return
addresses that were signed (or vice versa) which means a
runtime crash on a pauth enabled system.
Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE.
I suppose factoring things so that this logic could live in the backend
is too much trouble for how small the code is. The patch is OK.
This should be backported to gcc-9 and gcc-8 branches.
gcc/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* dwarf2cfi.c (struct GTY): Add ra_mangled.
(cfi_row_equal_p): Check ra_mangled.
(dwarf2out_frame_debug_cfa_window_save): Remove the argument,
this only handles the sparc logic now.
(dwarf2out_frame_debug_cfa_toggle_ra_mangle): New function for
the aarch64 specific logic.
(dwarf2out_frame_debug): Update to use the new subroutines.
(change_cfi_row): Check ra_mangled.
gcc/testsuite/ChangeLog:
2020-04-23 Szabolcs Nagy
PR target/94515
* g++.target/aarch64/pr94515-1.C: New test.
* g++.target/aarch64/pr94515-2.C: New test.
---
gcc/dwarf2cfi.c | 40 ++
gcc/testsuite/g++.target/aarch64/pr94515-1.C | 44
gcc/testsuite/g++.target/aarch64/pr94515-2.C | 41 ++
3 files changed, 118 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-1.C
create mode 100644 gcc/testsuite/g++.target/aarch64/pr94515-2.C
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 229fbfacc30..fa9e6089b2a 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -71,6 +71,9 @@ struct GTY(()) dw_cfi_row
/* True if the register window is saved. */
bool window_save;
+
+ /* True if the return address is in a mangled state. */
+ bool ra_mangled;
};
/* The caller's ORIG_REG is saved in SAVED_IN_REG. */
@@ -772,6 +775,9 @@ cfi_row_equal_p (dw_cfi_row *a, dw_cfi_row *b)
if (a->window_save != b->window_save)
return false;
+ if (a->ra_mangled != b->ra_mangled)
+return false;
+
return true;
}
@@ -1370,20 +1376,33 @@ dwarf2out_frame_debug_cfa_restore (rtx reg)
}
/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_WINDOW_SAVE.
- FAKE is true if this is not really a window save but something else.
??? Perhaps we should note in the CIE where windows are saved (instead
of assuming 0(cfa)) and what registers are in the window. */
static void
-dwarf2out_frame_debug_cfa_window_save (bool fake)
+dwarf2out_frame_debug_cfa_window_save (void)
+{
+ dw_cfi_ref cfi = new_cfi ();
+
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+ cur_row->window_save = true;
+}
+
+/* A subroutine of dwarf2out_frame_debug, process a REG_CFA_TOGGLE_RA_MANGLE.
+ Note: DW_CFA_GNU_window_save dwarf opcode is reused for toggling RA mangle
+ state, this is a target specific operation on AArch64 and can only be used
+ on other targets if they don't use the window save operation otherwise. */
+
+static void
+dwarf2out_frame_debug_cfa_toggle_ra_mangle (void)
{
dw_cfi_ref cfi = new_cfi ();
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
- if (!fake)
-cur_row->window_save = true;
+ cur_row->ra_mangled = !cur_row->ra_mangled;
}
/* Record call frame debugging information for an expression EXPR,
@@ -2143,13 +2162,12 @@ dwarf2out_frame_debug (rtx_insn *insn)
break;
case REG_CFA_TOGGLE_RA_MANGLE:
- /* This uses the same DWARF opcode as the next operation. */
- dwarf2out_frame_debug_cfa_window_save (true);
+ dwarf2out_frame_debug_cfa_toggle_ra_mangle ();
handled_one = true;
break;
case REG_CFA_WINDOW_SAVE:
- dwarf2out_frame_debug_cfa_window_save (false);
+ dwarf2out_frame_debug_cfa_window_save ();
handled_one = true;
break;
@@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row *new_row)
cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
add_cfi (cfi);
}
+
+ if (old_row->ra_mangled != new_row->ra_mangled)
+{
+ dw_cfi_ref cfi = new_cfi ();
+ /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
+ cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
+ add_cfi (cfi);
+}
}
/* Examine CFI and return true if a cfi label and set_loc is needed
diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-1.C
b/gcc/testsuite/g++.target/aarch64/pr94515-1.C
new file mode 100644
index
Re: [PATCH] c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742]
On 4/24/20 1:12 PM, Jakub Jelinek wrote:
Hi!
finish_call_expr already has code to set current_function_returns_abnormally
if a template calls a noreturn function, but on the following testcase it
doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case
we didn't check noreturn at all and just assumed it could return.
Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
OK.
2020-04-24 Jakub Jelinek
PR c++/94742
* semantics.c (finish_call_expr): When looking if all overloads
are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs.
* g++.dg/warn/Wreturn-type-12.C: New test.
--- gcc/cp/semantics.c.jj 2020-03-30 22:54:37.828795752 +0200
+++ gcc/cp/semantics.c 2020-04-24 14:30:36.001664888 +0200
@@ -2508,7 +2508,7 @@ finish_call_expr (tree fn, vec
+[[noreturn]] void
+foo (T const , char const *)
+{
+ throw T (t);
+}
+
+template
+int
+bar ()
+{
+ foo (42, __FUNCTION__);
+} // { dg-bogus "no return statement in function returning non-void" }
+
+int
+main ()
+{
+ bar();
+}
Jakub
Re: [PATCH] c++: add "'requires' only available with ..." note
On 4/24/20 3:52 PM, Patrick Palka wrote:
This adds a note suggesting to enable concepts whenever 'requires' is parsed as
an invalid type name with concepts disabled.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?
OK.
gcc/cp/ChangeLog:
* parser.c (cp_parser_diagnose_invalid_type_name): Suggest to enable
concepts if the invalid identifier is 'requires'.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic11.C: New test.
---
gcc/cp/parser.c | 3 +++
gcc/testsuite/g++.dg/concepts/diagnostic11.C | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic11.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 47e3f2bbd3d..337f22d2784 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -3378,6 +3378,9 @@ cp_parser_diagnose_invalid_type_name (cp_parser *parser,
tree id,
else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
inform (location, "% only available with %<-std=c++2a%> or "
"%<-fconcepts%>");
+ else if (!flag_concepts && id == ridpointers[(int)RID_REQUIRES])
+ inform (location, "% only available with %<-std=c++2a%> or "
+ "%<-fconcepts%>");
else if (processing_template_decl && current_class_type
&& TYPE_BINFO (current_class_type))
{
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic11.C
b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
new file mode 100644
index 000..7c60912352a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++17_only } }
+
+template
+ requires B // { dg-error ".requires. does not name a type" }
+// { dg-message ".requires. only available with" "" { target *-*-* } .-1 }
+void foo() { }
Re: [PATCH v2] c++: Explicit constructor called in copy-initialization [PR90320]
On 4/23/20 7:08 PM, Marek Polacek wrote:
On Thu, Apr 23, 2020 at 02:48:38PM -0400, Jason Merrill wrote:
On 4/22/20 11:27 PM, Marek Polacek wrote:
This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions. This does
not seem to be always correct. To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
1. choose a user-defined conversion to convert x to T, the result is
a prvalue,
2. use this prvalue to direct-initialize t.
In the second step, explicit constructors should be considered, since
we're direct-initializing. This is what r225705 fixed.
In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped. [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors. But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.
In this testcase we have
V v = m;
and we choose V::V(M) to convert m to V. But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.
When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags. So I've resorted to setting need_temporary_p in
a ck_rvalue, thus far unused, to signal that we're only interested in
non-explicit constructors.
LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like. DR 899 also seemed related, but that
deals with direct-init contexts only.
Does this make sense?
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/90320
* call.c (standard_conversion): Set need_temporary_p if FLAGS demands
LOOKUP_ONLYCONVERTING.
(convert_like_real) : If a ck_rvalue has
need_temporary_p set, or LOOKUP_ONLYCONVERTING into FLAGS.
* g++.dg/cpp0x/explicit13.C: New test.
---
gcc/cp/call.c | 24 +---
gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 ++
2 files changed, 31 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..d802f1a0c2f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,10 +92,10 @@ struct conversion {
language standards, e.g. disregarding pointer qualifiers or
converting integers to pointers. */
BOOL_BITFIELD bad_p : 1;
- /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+ /* If KIND is ck_ref_bind or ck_base, true to indicate that a
temporary should be created to hold the result of the
- conversion. If KIND is ck_ambig or ck_user, true means force
- copy-initialization. */
+ conversion. If KIND is ck_ambig, ck_rvalue, or ck_user, true means
+ force copy-initialization. */
BOOL_BITFIELD need_temporary_p : 1;
/* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
from a pointer-to-derived to pointer-to-base is being performed. */
@@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, bool
c_cast_p,
if (flags & LOOKUP_PREFER_RVALUE)
/* Tell convert_like_real to set LOOKUP_PREFER_RVALUE. */
conv->rvaluedness_matches_p = true;
+ if (flags & LOOKUP_ONLYCONVERTING)
+ conv->need_temporary_p = true;
Presumably we want the same thing for ck_base?
We actually already set need_temporary_p for ck_base in standard_conversion:
1529 conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
Hmm, yes. So with your patch the flag means different things for
ck_base and ck_rvalue. This suggests to me that overloading
need_temporary_p to also indicate copy-initialization is problematic,
and we should move that information to a new flag.
@@ -7654,10 +7656,18 @@ convert_like_real (conversion *convs, tree expr, tree
fn, int argnum,
destination [is treated as direct-initialization]. [dcl.init] */
flags = LOOKUP_NORMAL;
if (convs->user_conv_p)
- /* This conversion is being done in the context of a user-defined
- conversion (i.e. the second step of copy-initialization), so
- don't allow any more. */
- flags |= LOOKUP_NO_CONVERSION;
+ {
+ /* This conversion is being done in the context of a user-defined
+conversion
Re: Not usable email content encoding
Hi, On Fri, Apr 24 2020, Segher Boessenkool wrote: > Hi! > > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: >> >Of course, better would be to remove ChangeLogs entirely (including not >> >putting anything like them into a commit message), because they are >> >largely not useful and are just make-work. >> >> I disagree. I find them quite useful. > > For what? And, can that be provided some other way? I often have a look at them when reviewing a patch. It is great when they clearly indicate whether a change is some form of restructuring or a functional change and broadly speaking what it is. Then I just know what to look for. I also find writing them useful as it forces me to go through every patch one last time before submitting it :-) If you spend some time configuring your text editor and git, the boilerplate stuff can be generated automatically. I do not think this can be provided in any other way that would not resemble a ChangeLog. I do support the effort to put them into commit messages only though (and then perhaps generate the files from that). Martin
[Bug libstdc++/94747] Confusing code in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-04-24 Summary|Undefined behavior: integer |Confusing code in |overflow in |libsupc++/dyncast.cc |libsupc++/dyncast.cc| CC||nathan at gcc dot gnu.org Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Nathan Sidwell --- While the code is well formed, it does not convey intent well. I wrote that code, and probably even considered spelling as -ptrdiff_t (offsetof ...). but didn't because it causes a line wrap and has no semantic difference. negating unsigned numbers often shows programmer confusion, and can cause bugs on I32LP64 systems, where the negation happens at a lower precision than expected. That's not the case here. If size_t has fewer bits than a pointer, there cannot be overflow from the top size_t bit to the pointer arithmetic -- that breaks C & C++ semantics. Something for stage 1
[PATCH] c++: add "'requires' only available with ..." note
This adds a note suggesting to enable concepts whenever 'requires' is parsed as
an invalid type name with concepts disabled.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?
gcc/cp/ChangeLog:
* parser.c (cp_parser_diagnose_invalid_type_name): Suggest to enable
concepts if the invalid identifier is 'requires'.
gcc/testsuite/ChangeLog:
* g++.dg/concepts/diagnostic11.C: New test.
---
gcc/cp/parser.c | 3 +++
gcc/testsuite/g++.dg/concepts/diagnostic11.C | 6 ++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic11.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 47e3f2bbd3d..337f22d2784 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -3378,6 +3378,9 @@ cp_parser_diagnose_invalid_type_name (cp_parser *parser,
tree id,
else if (!flag_concepts && id == ridpointers[(int)RID_CONCEPT])
inform (location, "% only available with %<-std=c++2a%> or "
"%<-fconcepts%>");
+ else if (!flag_concepts && id == ridpointers[(int)RID_REQUIRES])
+ inform (location, "% only available with %<-std=c++2a%> or "
+ "%<-fconcepts%>");
else if (processing_template_decl && current_class_type
&& TYPE_BINFO (current_class_type))
{
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic11.C
b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
new file mode 100644
index 000..7c60912352a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic11.C
@@ -0,0 +1,6 @@
+// { dg-do compile { target c++17_only } }
+
+template
+ requires B // { dg-error ".requires. does not name a type" }
+// { dg-message ".requires. only available with" "" { target *-*-* } .-1 }
+void foo() { }
--
2.26.2.266.ge870325ee8
[Bug c++/94750] [10 Regression] Redundant identical using-declaration rejected since r10-554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94750 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Patrick Palka --- Never mind -- I think this is invalid.
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-04-24 Keywords||patch Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44535.html --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544535.html
[PATCH] Enable Intel CET in liblto_plugin.so on Intel CET enabled host
Since ld is Intel CET enabled on Intel CET enabled host, dlopen fails on
liblto_plugin.so if it isn't Intel CET enabled. Add GCC_CET_HOST_FLAGS
to cet.m4, use it in libiberty and lto-plugin to always enable Intel
CET in liblto_plugin.so on Intel CET enabled host.
On Linux/x86 host, enable Intel CET by default if assembler and compiler
support Intel CET so that generated the liblto_plugin.so can be used on
both CET and non-CET machines. It is an error to disable Intel CET in
liblto_plugin.so on Intel CET enabled host.
OK for master?
Thanks.
H.J.
---
config/
PR bootstrap/94739
* cet.m4 (GCC_CET_HOST_FLAGS): New.
libiberty/
PR bootstrap/94739
* Makefile.in (COMPILE.c): Add @CET_HOST_FLAGS@.
(configure_deps): Add $(srcdir)/../config/cet.m4 and
$(srcdir)/../config/enable.m4.
* aclocal.m4: Include ../config/cet.m4 and ../config/enable.m4.
* configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and
AC_SUBST(CET_HOST_FLAGS).
* configure: Regenerated.
lto-plugin/
PR bootstrap/94739
* Makefile.am (AM_CFLAGS): Add $(CET_HOST_FLAGS).
* configure.ac: Add GCC_CET_HOST_FLAGS(CET_HOST_FLAGS) and
AC_SUBST(CET_HOST_FLAGS).
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
---
config/cet.m4 | 94 +
libiberty/Makefile.in | 5 +-
libiberty/aclocal.m4| 2 +
libiberty/configure | 145 ++
libiberty/configure.ac | 3 +
lto-plugin/Makefile.am | 2 +-
lto-plugin/Makefile.in | 5 +-
lto-plugin/aclocal.m4 | 2 +
lto-plugin/configure| 149 +++-
lto-plugin/configure.ac | 3 +
10 files changed, 405 insertions(+), 5 deletions(-)
diff --git a/config/cet.m4 b/config/cet.m4
index b53c1bbd5cd..8b9e01fd492 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -48,3 +48,97 @@ else
AC_MSG_RESULT([no])
fi
])
+
+dnl
+dnl GCC_CET_HOST_FLAGS
+dnl(SHELL-CODE_HANDLER)
+dnl
+AC_DEFUN([GCC_CET_HOST_FLAGS],[dnl
+GCC_ENABLE(cet, auto, ,[enable Intel CET in host libraries],
+ permit yes|no|auto)
+AC_MSG_CHECKING([for CET support])
+
+case "$host" in
+ i[[34567]]86-*-linux* | x86_64-*-linux*)
+may_have_cet=yes
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -fcf-protection"
+case "$enable_cet" in
+ auto)
+ # Check if target supports multi-byte NOPs
+ # and if assembler supports CET insn.
+ AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM(
+ [],
+ [
+#if !defined(__SSE2__)
+#error target does not support multi-byte NOPs
+#else
+asm ("setssbsy");
+#endif
+ ])],
+[enable_cet=yes],
+[enable_cet=no])
+ ;;
+ yes)
+ # Check if assembler supports CET.
+ AC_COMPILE_IFELSE(
+[AC_LANG_PROGRAM(
+ [],
+ [asm ("setssbsy");])],
+[],
+[AC_MSG_ERROR([assembler with CET support is required for
--enable-cet])])
+ ;;
+esac
+CFLAGS="$save_CFLAGS"
+;;
+ *)
+may_have_cet=no
+enable_cet=no
+;;
+esac
+
+if test x$may_have_cet = xyes; then
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS -Wl,-z,ibt,-z,shstk"
+ AC_TRY_RUN([
+static void
+foo (void)
+{
+}
+
+static void
+__attribute__ ((noinline, noclone))
+xxx (void (*f) (void))
+{
+ f ();
+}
+
+static void
+__attribute__ ((noinline, noclone))
+bar (void)
+{
+ xxx (foo);
+}
+
+int
+main ()
+{
+ bar ();
+ return 0;
+}
+ ],
+ [have_cet=no],
+ [have_cet=yes])
+ LDFLAGS="$save_LDFLAGS"
+ if test x$enable_cet = xno -a x$have_cet = xyes; then
+AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
+ fi
+fi
+if test x$enable_cet = xyes; then
+ $1="-fcf-protection"
+ AC_MSG_RESULT([yes])
+else
+ AC_MSG_RESULT([no])
+fi
+])
diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index fe738d0db43..d6b302e02fd 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -112,7 +112,8 @@ installcheck: installcheck-subdir
INCDIR=$(srcdir)/$(MULTISRCTOP)../include
COMPILE.c = $(CC) -c @DEFS@ $(CFLAGS) $(CPPFLAGS) -I. -I$(INCDIR) \
- $(HDEFINES) @ac_libiberty_warn_cflags@ -D_GNU_SOURCE
+ $(HDEFINES) @ac_libiberty_warn_cflags@ -D_GNU_SOURCE \
+ @CET_HOST_FLAGS@
# Just to make sure we don't use a built-in rule with VPATH
.c.$(objext):
@@ -481,6 +482,8 @@ config.status: $(srcdir)/configure
AUTOCONF = autoconf
configure_deps = $(srcdir)/aclocal.m4 \
$(srcdir)/../config/acx.m4 \
+ $(srcdir)/../config/cet.m4 \
+ $(srcdir)/../config/enable.m4 \
$(srcdir)/../config/no-executables.m4 \
$(srcdir)/../config/override.m4 \
$(srcdir)/../config/picflag.m4 \
diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4
index bf8a907100f..34c0a5bab62 100644
--- a/libiberty/aclocal.m4
+++ b/libiberty/aclocal.m4
@@ -1,4 +1,6 @@
sinclude(../config/acx.m4)
Re: C (not C++) compiler plugins
On Fri, 2020-04-24 at 13:03 -0600, Maurice Smulders via Gcc wrote:
> Hello,
>
> Hugo Landau figured out why it didn't load:
> Yes.
>
>
> The reference to cp_global_trees appears to be caused by the below
> code,
> which only relates to C++. For C, try commenting it out like this:
>
> OUTF ("- !compex/method\n", i);
> OUTF (" name: %s\n", method_name);
> OUTF (" asm: %s\n", mangled_name);
> #if 0
> _bool(" virtual", DECL_VIRTUAL_P(arg));
> _bool(" artificial", DECL_ARTIFICIAL(arg));
> _bool(" const", DECL_CONST_MEMFUNC_P(arg));
> _bool(" static", DECL_STATIC_FUNCTION_P(arg));
> _bool(" constructor", DECL_CONSTRUCTOR_P(arg));
> _bool(" destructor", DECL_DESTRUCTOR_P(arg));
> _bool(" copyconstructor", DECL_COPY_CONSTRUCTOR_P(arg));
> _bool(" baseconstructor", DECL_BASE_CONSTRUCTOR_P(arg));
> _bool(" completeconstructor",
> DECL_COMPLETE_CONSTRUCTOR_P(arg));
> _bool(" completedestructor",
> DECL_COMPLETE_DESTRUCTOR_P(arg));
> _bool(" operator", DECL_OVERLOADED_OPERATOR_P(arg));
> _bool(" castoperator", DECL_CONV_FN_P(arg));
> _bool(" thunk", DECL_THUNK_P(arg));
> _bool(" nothrow", TYPE_NOTHROW_P(TREE_TYPE(arg)));
> #endif
>
> However, trying to run it on a C file like
>
> struct __attribute__((compex_tag("x" foo { int x; };
> int main(int argc, char **argv) { return 0; }
>
> results in a segfault at this line in `_finish_type`:
>
> const char *struct_name = decl ?
> IDENTIFIER_POINTER(DECL_NAME(decl)) : NULL;
>
> It appears that the pointer DECL_NAME(decl) is corrupt,
Maybe DECL_NAME(decl) is NULL?
> but I can't
> figure out why that is. I'm no expert on writing GCC plugins and this
> was an amateur attempt, I'm not sure I ever tested it with C.
>
> But it still has a problem...
>
> Has this functionality been used for the C compiler, if not, how can
> I
> debug this the easiest way?
Yes, plugins do work with cc1 (I first got into GCC development by
writing plugins, and most of my work was on analyzing C code)
I wrote a guide to debugging GCC which you may find helpful:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
FWIW it's possible to write a plugin that will work with both the C and
C++ frontends while accessing FE-specific things like cp_global_trees
without rebuilding, by using weak symbols. This is something of a
hack, but I've used it successfully in a few places in my gcc-python-
plugin. See e.g.:
https://github.com/davidmalcolm/gcc-python-plugin/blob/master/gcc-python-tree.c#L51
for an example of using decl_as_string from the C++ FE if available,
and it being NULL in other FEs.
Hope this is helpful; good luck.
Dave
>
> Kind regards,
>
> Maurice Smulders
>
> On Fri, Apr 24, 2020 at 9:17 AM Maurice Smulders
> wrote:
> > Hello,
> >
> > Is it possible to make plugins for the C compiler (not the C++)
> > compiler? I was trying the (old) sample code at
> > https://github.com/hlandau/compex to make a plugin, but the plugin
> > only works with C++. when trying to use the C compiler it complains
> > about
> >
> > gcc -fplugin=/usr/local/lib/compex_gcc.so -D__COMPEX__=1
> > -fplugin-arg-compex_gcc-o=test_c.compex -o test_c test_c.c
> > cc1: error: cannot load plugin /usr/local/lib/compex_gcc.so
> >/usr/local/lib/compex_gcc.so: undefined symbol: cp_global_trees
> >
> > Is the mechanism differently, or are plugins even supported on the
> > C compiler?
[committed] amdgcn: Fix wrong-code bug in 64-bit masked add
This patch fixes a bug in which the high-part of a 64-bit add doesn't always merge in the masked lanes properly, depending on register allocation. Unfortunately I don't have a small reproducer for this one, so there's no testcase. Andrew amdgcn: Fix wrong-code bug in 64-bit masked add 2020-04-24 Andrew Stubbs gcc/ * config/gcn/gcn-valu.md (add_zext_dup2_exec): Fix merge of high-part. (add_sext_dup2_exec): Likewise. diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md index 0422e153cf3..d3badb4059c 100644 --- a/gcc/config/gcn/gcn-valu.md +++ b/gcc/config/gcn/gcn-valu.md @@ -1497,7 +1497,8 @@ rtx dsthi = gcn_operand_part (mode, operands[0], 1); emit_insn (gen_vec_duplicate_exec (dsthi, gcn_operand_part (DImode, operands[2], 1), - gcn_gen_undef (mode), operands[4])); + gcn_operand_part (mode, operands[3], 1), + operands[4])); emit_insn (gen_addc3_exec (dsthi, dsthi, const0_rtx, vcc, vcc, gcn_operand_part (mode, operands[3], 1), @@ -1564,7 +1565,8 @@ rtx dsthi = gcn_operand_part (mode, operands[0], 1); emit_insn (gen_vec_duplicate_exec (dsthi, gcn_operand_part (DImode, operands[2], 1), - gcn_gen_undef (mode), operands[4])); + gcn_operand_part (mode, operands[3], 1), + operands[4])); emit_insn (gen_addc3_exec (dsthi, dsthi, operands[5], vcc, vcc, gcn_operand_part (mode, operands[3], 1),
[Bug target/94710] [8/9 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Segher Boessenkool changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] |[8/9 Regression] Assembler |Assembler messages: Error: |messages: Error: operand |operand out of range (4 is |out of range (4 is not |not between 0 and 3)|between 0 and 3) (xxsldwi |(xxsldwi 0,32,33,4) |0,32,33,4) Known to fail|10.0| --- Comment #10 from Segher Boessenkool --- Fixed on trunk (so far).
Re: C (not C++) compiler plugins
Hello,
Hugo Landau figured out why it didn't load:
Yes.
The reference to cp_global_trees appears to be caused by the below code,
which only relates to C++. For C, try commenting it out like this:
OUTF ("- !compex/method\n", i);
OUTF (" name: %s\n", method_name);
OUTF (" asm: %s\n", mangled_name);
#if 0
_bool(" virtual", DECL_VIRTUAL_P(arg));
_bool(" artificial", DECL_ARTIFICIAL(arg));
_bool(" const", DECL_CONST_MEMFUNC_P(arg));
_bool(" static", DECL_STATIC_FUNCTION_P(arg));
_bool(" constructor", DECL_CONSTRUCTOR_P(arg));
_bool(" destructor", DECL_DESTRUCTOR_P(arg));
_bool(" copyconstructor", DECL_COPY_CONSTRUCTOR_P(arg));
_bool(" baseconstructor", DECL_BASE_CONSTRUCTOR_P(arg));
_bool(" completeconstructor", DECL_COMPLETE_CONSTRUCTOR_P(arg));
_bool(" completedestructor", DECL_COMPLETE_DESTRUCTOR_P(arg));
_bool(" operator", DECL_OVERLOADED_OPERATOR_P(arg));
_bool(" castoperator", DECL_CONV_FN_P(arg));
_bool(" thunk", DECL_THUNK_P(arg));
_bool(" nothrow", TYPE_NOTHROW_P(TREE_TYPE(arg)));
#endif
However, trying to run it on a C file like
struct __attribute__((compex_tag("x" foo { int x; };
int main(int argc, char **argv) { return 0; }
results in a segfault at this line in `_finish_type`:
const char *struct_name = decl ? IDENTIFIER_POINTER(DECL_NAME(decl)) : NULL;
It appears that the pointer DECL_NAME(decl) is corrupt, but I can't
figure out why that is. I'm no expert on writing GCC plugins and this
was an amateur attempt, I'm not sure I ever tested it with C.
But it still has a problem...
Has this functionality been used for the C compiler, if not, how can I
debug this the easiest way?
Kind regards,
Maurice Smulders
On Fri, Apr 24, 2020 at 9:17 AM Maurice Smulders
wrote:
>
> Hello,
>
> Is it possible to make plugins for the C compiler (not the C++)
> compiler? I was trying the (old) sample code at
> https://github.com/hlandau/compex to make a plugin, but the plugin
> only works with C++. when trying to use the C compiler it complains
> about
>
> gcc -fplugin=/usr/local/lib/compex_gcc.so -D__COMPEX__=1
> -fplugin-arg-compex_gcc-o=test_c.compex -o test_c test_c.c
> cc1: error: cannot load plugin /usr/local/lib/compex_gcc.so
>/usr/local/lib/compex_gcc.so: undefined symbol: cp_global_trees
>
> Is the mechanism differently, or are plugins even supported on the C compiler?
>
> - Maurice
--
Maurice Smulders
720-514-0310
Geneva Technologies Inc.
255 Jefferson Street, Ste 104
Monument, CO 80132
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #9 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:9c725245beed2f056b67f5dc218fef6cb869c5f2 commit r10-7949-g9c725245beed2f056b67f5dc218fef6cb869c5f2 Author: Segher Boessenkool Date: Fri Apr 24 13:33:14 2020 + rs6000: Properly handle LE index munging in vec_shr (PR94710) The PR shows the compiler crashing with -mvsx -mlittle -O0. This turns out to be caused by a failure to make of the higher bits in an index endian conversion. 2020-04-24 Segher Boessenkool PR target/94710 * config/rs6000/vector.md (vec_shr_ for VEC_L): Correct little endian byteshift_val calculation.
[Bug c++/94751] New: [9/10] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751
Bug ID: 94751
Summary: [9/10] ICE on invalid code in
maybe_instantiate_noexcept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
gcc version:
gcc version 10.0.1 20200329 (experimental) (GCC)
ICEs on the following (invalid) input:
-- x.cc -
struct Algorithm
{
Algorithm( float );
};
template
struct ToolWithConstants
: public Algorithm
{
using Algorithm::Algorithm;
struct Constant
{
Constant (int name);
};
Constant c { "order" };
};
class unique_ptr {};
unique_ptr make()
{
return unique_ptr (new ToolWithConstants (10.5));
}
like this:
[sss@karma rootaccess]$ g++ -c x.cc
x.cc: In function ‘unique_ptr make()’:
x.cc:25:60: internal compiler error: Segmentation fault
25 | return unique_ptr (new ToolWithConstants (10.5));
|^
0xc4fe4f crash_signal
/home/sss/gcc/gcc/gcc/toplev.c:328
0x7f4d24bf8ebf ???
/usr/src/debug/glibc-2.29-51-g845278f2c6/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x759eff maybe_instantiate_noexcept(tree_node*, int)
/home/sss/gcc/gcc/gcc/cp/pt.c:25032
0x6b8388 mark_used(tree_node*, int)
/home/sss/gcc/gcc/gcc/cp/decl2.c:5512
0x644892 build_over_call
/home/sss/gcc/gcc/gcc/cp/call.c:9048
0x646ade build_new_method_call_1
/home/sss/gcc/gcc/gcc/cp/call.c:10338
0x647796 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/sss/gcc/gcc/gcc/cp/call.c:10413
0x647796 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/sss/gcc/gcc/gcc/cp/call.c:9814
0x6cec5f build_new_1
/home/sss/gcc/gcc/gcc/cp/init.c:3588
0x6cf9f8 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
/home/sss/gcc/gcc/gcc/cp/init.c:3905
0x729a37 cp_parser_new_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:8825
0x72a057 cp_parser_unary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:8418
0x706b1a cp_parser_binary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x70a668 cp_parser_parenthesized_expression_list
/home/sss/gcc/gcc/gcc/cp/parser.c:7981
0x70ada2 cp_parser_functional_cast
/home/sss/gcc/gcc/gcc/cp/parser.c:29572
0x721f24 cp_parser_postfix_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:7180
0x706b1a cp_parser_binary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x7084e2 cp_parser_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:10027
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
A crash is also observed with a 20200424 version as well as
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
thanks,
sss
[Bug c++/94750] New: [10 Regression] Redundant identical using-declaration rejected since r10-554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94750
Bug ID: 94750
Summary: [10 Regression] Redundant identical using-declaration
rejected since r10-554
Product: gcc
Version: 10.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: ---
$ cat testcase.C
namespace ns
{
using type = int;
}
int
main()
{
using ns::type;
using ns::type;
}
$ g++ testcase.C
testcase.C: In function ‘int main()’:
testcase.C: error: redeclaration of ‘using type = int’
10 | using ns::type;
| ^~~~
testcase.C: note: previous declaration ‘using type = int’
3 | using type = int;
| ^~~~
[PATCH] rs6000: Properly handle LE index munging in vec_shr (PR94710)
The PR shows the compiler crashing with -mvsx -mlittle -O0. This turns
out to be caused by a failure to make of the higher bits in an index
endian conversion.
Tested on powerpc64-linux {-m32,-m64} and on powerpc64le-linux.
Committing to trunk.
(This will need backports).
Segher
2020-04-24 Segher Boessenkool
PR target/94710
* config/rs6000/vector.md (vec_shr_ for VEC_L): Correct little
endian byteshift_val calculation.
---
gcc/config/rs6000/vector.md | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 5bc8f80..662521e 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1426,7 +1426,8 @@ (define_expand "vec_shr_"
emit_move_insn (zero_reg, CONST0_RTX (mode));
if (!BYTES_BIG_ENDIAN)
{
- byteshift_val = 16 - byteshift_val;
+ /* Note, byteshift_val can be 0! */
+ byteshift_val = -byteshift_val & 15;
op1 = zero_reg;
op2 = operands[1];
}
--
1.8.3.1
[Bug libstdc++/94747] Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- (In reply to AK from comment #0) > Integer overflow reported by asan with the following stack trace. asan?! Are you sure? As Jakub says, this is probably the dumb "unsigned-integer-overflow" sanitizer, which is dumb because unsigned integers can't overflow by definition (they wrap) and because that wrapping is never undefined. The code is fine.
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 Richard Biener changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- If you want to detect whether a warning is supported use -Wfoo, not -Wno-foo.
Re: [PATCH] cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734]
On Fri, 24 Apr 2020, Jakub Jelinek wrote:
> Hi!
>
> As the new testcase shows, it is not safe to assume we can optimize
> a conditional store into an automatic non-addressable var, we can do it
> only if we can prove that the unconditional load or store actually will
> not be outside of the boundaries of the variable.
> If the offset and size are constant, we can, but this is already all
> checked in !tree_could_trap_p, otherwise we really need to check for
> a dominating unconditional store, or for the specific case of automatic
> non-addressable variables, it is enough if there is a dominating load
> (that is what those 4 testcases have). tree-ssa-phiopt.c has some
> infrastructure for this already, see the add_or_mark_expr method etc.,
> but right now it handles only MEM_REFs with SSA_NAME first operand
> and some integral offset. So, I think it can be for GCC11 extended
> to handle other memory references, possibly up to just doing
> get_inner_reference and hasing based on the base, offset expressions
> and bit_offset and bit_size, and have also a special case that for
> !TREE_ADDRESSABLE automatic variables it could ignore whether something
> is a load or store because the local stack should be always writable.
> But it feels way too dangerous to do this this late for GCC10, so this
> patch just restricts the optimization to the safe case (where lhs doesn't
> trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if
> flag_store_data_races, because my understanding the reason for
> TREE_ADDRESSABLE check is that we want to avoid introducing
> store data races (if address of an automatic var escapes, some other thread
> could be accessing it concurrently).
>
> Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2020-04-24 Jakub Jelinek
> Richard Biener
>
> PR tree-optimization/94734
> PR tree-optimization/89430
> * tree-ssa-phiopt.c: Include tree-eh.h.
> (cond_store_replacement): Return false if an automatic variable
> access could trap. If -fstore-data-races, don't return false
> just because an automatic variable is addressable.
>
> * gcc.dg/tree-ssa/pr89430-1.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-2.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-5.c: Add xfail.
> * gcc.dg/tree-ssa/pr89430-6.c: Add xfail.
> * gcc.c-torture/execute/pr94734.c: New test.
>
> --- gcc/tree-ssa-phiopt.c.jj 2020-03-19 10:23:50.542872359 +0100
> +++ gcc/tree-ssa-phiopt.c 2020-04-24 12:33:02.368355735 +0200
> @@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
> #include "tree-scalar-evolution.h"
> #include "tree-inline.h"
> #include "case-cfn-macros.h"
> +#include "tree-eh.h"
>
> static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
> static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
> @@ -2237,10 +2238,13 @@ cond_store_replacement (basic_block midd
> whose value is not available readily, which we want to avoid. */
>if (!nontrap->contains (lhs))
> {
> - /* If LHS is a local variable without address-taken, we could
> + /* If LHS is an access to a local variable without address-taken
> + (or when we allow data races) and known not to trap, we could
>always safely move down the store. */
>tree base = get_base_address (lhs);
> - if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
> + if (!auto_var_p (base)
> + || (TREE_ADDRESSABLE (base) && !flag_store_data_races)
> + || tree_could_trap_p (lhs))
> return false;
> }
>
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c 2020-04-24 11:26:45.021425675
> +0200
> @@ -9,4 +9,4 @@ unsigned test(unsigned k, unsigned b) {
> return a[0]+a[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail *-*-* } } } */
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c 2020-04-24 11:26:52.319316212
> +0200
> @@ -11,4 +11,4 @@ unsigned test(unsigned k, unsigned b) {
> return a[0]+a[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail *-*-* } } } */
> --- gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c.jj 2020-01-12
> 11:54:37.606395410 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c 2020-04-24 11:26:59.782204277
> +0200
> @@ -13,4 +13,4 @@ int test(int b, int k) {
> return a.data[0] + a.data[1];
> }
>
> -/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } }
> */
> +/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
> xfail
[PATCH v4] aarch64: Add TX3 machine model
Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.
The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.
Added the new chip name to the documentation. Fixed
copyright names and dates.
Lowering the chip capabilities to v8.3 to be on the
safe side.
Bootstrapped on AArch64.
2020-04-23 Anton Youdkevitch
* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c: Add the cost tables for the chip.
* config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* config/aarch64/aarch64.md: Include the new model.
* doc/invoke.texi: Add the new name to the list
---
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarch64/aarch64.c | 27 ++
gcc/config/aarch64/aarch64.md| 1 +
gcc/config/aarch64/thunderx3t11.md | 686 +
gcc/doc/invoke.texi | 2 +-
6 files changed, 719 insertions(+), 2 deletions(-)
>From 4c2c69ab7327bda62d2380139cd2825bcc647988 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch
Date: Mon, 23 Mar 2020 13:22:35 -0700
Subject: [PATCH] TX3 scheduling and tuning implementation
Added the scheduler descriptions for TX3 and the
cost tables borrowed them from TX2.
---
gcc/config/aarch64/aarch64-cores.def | 3 +
gcc/config/aarch64/aarch64-tune.md | 2 +-
gcc/config/aarch64/aarch64.c | 27 ++
gcc/config/aarch64/aarch64.md| 1 +
gcc/config/aarch64/thunderx3t11.md | 686 +++
gcc/doc/invoke.texi | 2 +-
6 files changed, 719 insertions(+), 2 deletions(-)
create mode 100644 gcc/config/aarch64/thunderx3t11.md
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..4269c6c 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan", vulcan, thunderx2t99, 8_1A, AARCH64_FL_FOR_ARCH8_1 | AA
/* Cavium ('C') cores. */
AARCH64_CORE("thunderx2t99", thunderx2t99, thunderx2t99, 8_1A, AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t11", thunderx3t11, thunderx3t11, 8_3A, AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t11, 0x43, 0x0b8, 0x0a)
+
/* ARMv8.2-A Architecture Processors. */
/* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3cc1c4d..573a4a9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
;; -*- buffer-read-only: t -*-
;; Generated automatically by gentune.sh from aarch64-cores.def
(define_attr "tune"
- "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+ "cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,thunderx3t11,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 24c055d..7abce6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1216,6 +1216,33 @@ static const struct tune_params thunderx2t99_tunings =
_prefetch_tune
};
+static const struct tune_params thunderx3t11_tunings =
+{
+ _extra_costs,
+ _addrcost_table,
+ _regmove_cost,
+ _vector_cost,
+ _branch_cost,
+ _approx_modes,
+ SVE_NOT_IMPLEMENTED, /* sve_width */
+ 4, /* memmov_cost. */
+ 4, /* issue_rate. */
+ (AARCH64_FUSE_ALU_BRANCH | AARCH64_FUSE_AES_AESMC
+ | AARCH64_FUSE_ALU_CBZ), /* fusible_ops */
+ "16", /*
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740 --- Comment #4 from Peter Bergner --- Removing the bswap and recompiling, the non-bswap load pattern has no problem accepting an address like that, so this looks like a target issue with that pattern.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 --- Comment #17 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9407f0c32b215d55d3474a234b0043bddc185b1c commit r10-7948-g9407f0c32b215d55d3474a234b0043bddc185b1c Author: Jakub Jelinek Date: Fri Apr 24 19:14:27 2020 +0200 testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383] > I haven't added (yet) checks if the alternate compiler does support these > options (I think that can be done incrementally), so for now this testing is > done only if the alternate compiler is not used. This patch does that, so now when testing against not too old compiler it can do the -std=c++14 vs. -std=c++17 testing also between under test and alt compilers. 2020-04-24 Jakub Jelinek PR c++/94383 * g++.dg/compat/struct-layout-1.exp: Use the -std=c++14 vs. -std=c++17 ABI compatibility testing even with ALT_CXX_UNDER_TEST, as long as that compiler accepts -std=c++14 and -std=c++17 options.
[PATCH] c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742]
Hi!
finish_call_expr already has code to set current_function_returns_abnormally
if a template calls a noreturn function, but on the following testcase it
doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case
we didn't check noreturn at all and just assumed it could return.
Fixed thusly, bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
2020-04-24 Jakub Jelinek
PR c++/94742
* semantics.c (finish_call_expr): When looking if all overloads
are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs.
* g++.dg/warn/Wreturn-type-12.C: New test.
--- gcc/cp/semantics.c.jj 2020-03-30 22:54:37.828795752 +0200
+++ gcc/cp/semantics.c 2020-04-24 14:30:36.001664888 +0200
@@ -2508,7 +2508,7 @@ finish_call_expr (tree fn, vec
+[[noreturn]] void
+foo (T const , char const *)
+{
+ throw T (t);
+}
+
+template
+int
+bar ()
+{
+ foo (42, __FUNCTION__);
+} // { dg-bogus "no return statement in function returning non-void" }
+
+int
+main ()
+{
+ bar();
+}
Jakub
[Bug libstdc++/94749] New: std::istream::ignore discards too many characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
Bug ID: 94749
Summary: std::istream::ignore discards too many characters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: serpent7776 at gmail dot com
Target Milestone: ---
Created attachment 48369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48369=edit
full source example
The following code results in '=' assigned to c when using libstdc++, but '+'
is assigned when using libc++, I believe libc++ is correct here
std::stringstream s(" +=");
char c;
s.ignore(1, '+');
s >> c;
Tested this on godbolt with newest gcc and locally on FreeBSD with gcc7
(command: g++7 -Wall -Wextra -pedantic test.cpp)
https://godbolt.org/z/yS5je8
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #3 from Peter Bergner ---
Here's a simpler test case that fails the same way:
int array[8];
int
foo (void)
{
return __builtin_bswap32 (array[1]);
}
So before CSE, we have:
(insn 5 2 6 2 (set (reg/f:DI 121)
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182]))
{*pcrel_local_addr})
(insn 6 5 7 2 (set (reg:DI 123)
(const_int 4 [0x4])) {*movdi_internal64})
(insn 7 6 8 2 (set (reg:SI 122)
(bswap:SI (mem/c:SI (plus:DI (reg/f:DI 121)
(reg:DI 123)
{bswapsi2_load}
(expr_list:REG_EQUAL (bswap:SI (mem/c:SI (plus:DI (reg/f:DI 121)
(const_int 4 [0x4]))
...
After CSE, we then have all the way up to LRA:
(insn 7 9 14 2 (set (reg:SI 122)
(bswap:SI (mem/c:SI (plus:DI (symbol_ref:DI ("*.LANCHOR0")
[flags 0x182])
(const_int 4) {bswapsi2_load})
...
LRA then calls decompse_address with the above address, which causes us to go
sideways. Not sure why yet. Maybe our bswap2_load pattern needs help?
Re: [PATCH] testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383]
On Thu, 2020-04-23 at 21:08 +0200, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> On Tue, Apr 21, 2020 at 11:57:02AM +0200, Jakub Jelinek wrote:
> > I haven't added (yet) checks if the alternate compiler does support these
> > options (I think that can be done incrementally), so for now this testing is
> > done only if the alternate compiler is not used.
>
> This patch does that, so now when testing against not too old compiler
> it can do the -std=c++14 vs. -std=c++17 testing also between under test and
> alt compilers.
>
> Tested on x86_64-linux, without ALT_CXX_UNDER_TEST (all tests still used),
> with ALT_CXX_UNDER_TEST=g++ (all tests still used too), and after tweaking
> it to test -std=c++20 instead of -std=c++17 that my system g++ doesn't
> support, where it only used tests before *_32* and bootstrapped/regtested
> on powerpc64{,le}-linux, ok for trunk?
>
> 2020-04-23 Jakub Jelinek
>
> PR c++/94383
> * g++.dg/compat/struct-layout-1.exp: Use the -std=c++14 vs. -std=c++17
> ABI compatibility testing even with ALT_CXX_UNDER_TEST, as long as
> that compiler accepts -std=c++14 and -std=c++17 options.
OK
jeff
>
[PATCH] cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734]
Hi!
As the new testcase shows, it is not safe to assume we can optimize
a conditional store into an automatic non-addressable var, we can do it
only if we can prove that the unconditional load or store actually will
not be outside of the boundaries of the variable.
If the offset and size are constant, we can, but this is already all
checked in !tree_could_trap_p, otherwise we really need to check for
a dominating unconditional store, or for the specific case of automatic
non-addressable variables, it is enough if there is a dominating load
(that is what those 4 testcases have). tree-ssa-phiopt.c has some
infrastructure for this already, see the add_or_mark_expr method etc.,
but right now it handles only MEM_REFs with SSA_NAME first operand
and some integral offset. So, I think it can be for GCC11 extended
to handle other memory references, possibly up to just doing
get_inner_reference and hasing based on the base, offset expressions
and bit_offset and bit_size, and have also a special case that for
!TREE_ADDRESSABLE automatic variables it could ignore whether something
is a load or store because the local stack should be always writable.
But it feels way too dangerous to do this this late for GCC10, so this
patch just restricts the optimization to the safe case (where lhs doesn't
trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if
flag_store_data_races, because my understanding the reason for
TREE_ADDRESSABLE check is that we want to avoid introducing
store data races (if address of an automatic var escapes, some other thread
could be accessing it concurrently).
Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?
2020-04-24 Jakub Jelinek
Richard Biener
PR tree-optimization/94734
PR tree-optimization/89430
* tree-ssa-phiopt.c: Include tree-eh.h.
(cond_store_replacement): Return false if an automatic variable
access could trap. If -fstore-data-races, don't return false
just because an automatic variable is addressable.
* gcc.dg/tree-ssa/pr89430-1.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-2.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-5.c: Add xfail.
* gcc.dg/tree-ssa/pr89430-6.c: Add xfail.
* gcc.c-torture/execute/pr94734.c: New test.
--- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
+++ gcc/tree-ssa-phiopt.c 2020-04-24 12:33:02.368355735 +0200
@@ -45,6 +45,7 @@ along with GCC; see the file COPYING3.
#include "tree-scalar-evolution.h"
#include "tree-inline.h"
#include "case-cfn-macros.h"
+#include "tree-eh.h"
static unsigned int tree_ssa_phiopt_worker (bool, bool, bool);
static bool two_value_replacement (basic_block, basic_block, edge, gphi *,
@@ -2237,10 +2238,13 @@ cond_store_replacement (basic_block midd
whose value is not available readily, which we want to avoid. */
if (!nontrap->contains (lhs))
{
- /* If LHS is a local variable without address-taken, we could
+ /* If LHS is an access to a local variable without address-taken
+(or when we allow data races) and known not to trap, we could
always safely move down the store. */
tree base = get_base_address (lhs);
- if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
+ if (!auto_var_p (base)
+ || (TREE_ADDRESSABLE (base) && !flag_store_data_races)
+ || tree_could_trap_p (lhs))
return false;
}
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-1.c 2020-04-24 11:26:45.021425675
+0200
@@ -9,4 +9,4 @@ unsigned test(unsigned k, unsigned b) {
return a[0]+a[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-2.c 2020-04-24 11:26:52.319316212
+0200
@@ -11,4 +11,4 @@ unsigned test(unsigned k, unsigned b) {
return a[0]+a[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-5.c 2020-04-24 11:26:59.782204277
+0200
@@ -13,4 +13,4 @@ int test(int b, int k) {
return a.data[0] + a.data[1];
}
-/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" } } */
+/* { dg-final { scan-tree-dump "Conditional store replacement" "cselim" {
xfail *-*-* } } } */
--- gcc/testsuite/gcc.dg/tree-ssa/pr89430-6.c.jj2020-01-12
11:54:37.606395410 +0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr89430-6.c 2020-04-24 11:27:06.456104170
+0200
@@ -16,4 +16,4 @@ int test(int b, int k)
Re: Not usable email content encoding
Hi! On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > >Of course, better would be to remove ChangeLogs entirely (including not > >putting anything like them into a commit message), because they are > >largely not useful and are just make-work. > > I disagree. I find them quite useful. For what? And, can that be provided some other way? Segher
[Bug target/94748] New: aarch64: many unnecessary bti j emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
Bug ID: 94748
Summary: aarch64: many unnecessary bti j emitted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
__attribute__((target("branch-protection=bti")))
int foo(void)
{
label:
return 0;
}
compiles to
foo:
hint34 // bti c
hint36 // bti j
mov w0, 0
ret
the bti j is not necessary and bti j should be rarely emitted
otherwise the security architecture is weakened.
[Bug libstdc++/94747] Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Negation of unsigned long value is well defined for all possible values, including 16. Is that with the flawed clang -fsanitize=unsigned-integer-overflow ? GCC doesn't implement that for a reason.
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-24 --- Comment #2 from Peter Bergner --- Confirmed. I'll have a quick look.
[committed] amdgcn: Split 64-bit constant loads post-reload
This patch changes the split-point of 64-bit moves to after register
allocation. This means that LRA sees a simpler instruction stream, and
seems to produce better code on some testcases.
Andrew
amdgcn: Split 64-bit constant loads post-reload
This helps avoid spilling 64-bit constant loads to stack by simplifying the
code that LRA sees.
2020-04-17 Andrew Stubbs
gcc/
* config/gcn/gcn.md (*mov_insn): Only split post-reload.
diff --git a/gcc/config/gcn/gcn.md b/gcc/config/gcn/gcn.md
index 702ba55c11a..8f5937781b2 100644
--- a/gcc/config/gcn/gcn.md
+++ b/gcc/config/gcn/gcn.md
@@ -615,9 +615,11 @@
ds_read_b64\t%0, %A1%O1\;s_waitcnt\tlgkmcnt(0)
global_load_dwordx2\t%0, %A1%O1%g1\;s_waitcnt\tvmcnt(0)
global_store_dwordx2\t%A0, %1%O0%g0"
- "(reload_completed && !MEM_P (operands[0]) && !MEM_P (operands[1])
-&& !gcn_sgpr_move_p (operands[0], operands[1]))
- || (GET_CODE (operands[1]) == CONST_INT && !gcn_constant64_p (operands[1]))"
+ "reload_completed
+ && ((!MEM_P (operands[0]) && !MEM_P (operands[1])
+&& !gcn_sgpr_move_p (operands[0], operands[1]))
+ || (GET_CODE (operands[1]) == CONST_INT
+ && !gcn_constant64_p (operands[1])))"
[(set (match_dup 0) (match_dup 1))
(set (match_dup 2) (match_dup 3))]
{
Re: Not usable email content encoding
Of course, better would be to remove ChangeLogs entirely (including not putting anything like them into a commit message), because they are largely not useful and are just make-work. I disagree. I find them quite useful.
[Bug libstdc++/94747] New: Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Bug ID: 94747 Summary: Undefined behavior: integer overflow in libsupc++/dyncast.cc Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- Integer overflow reported by asan with the following stack trace. If this is not sufficient I can try to provide a repro gcc/7.x/libstdc++-v3/libsupc++/dyncast.cc:53:11: runtime error: negation of 16 cannot be represented in type 'unsigned long' > #0 in __dynamic_cast gcc/7.x/libstdc++-v3/libsupc++/dyncast.cc:53 > #1 in bool std::has_facet >(std::locale const&) > gcc/7.x/.../bits/locale_classes.tcc:110 > #2 in std::basic_ios > >::_M_cache_locale(std::locale const&) gcc/7.x/.../bits/basic_ios.tcc:159 > #3 in std::basic_ios > >::init(std::basic_streambuf >*) > gcc/7.x/.../bits/basic_ios.tcc:132 > #4 in std::basic_ostream > >::basic_ostream(std::basic_streambuf >*) > gcc/7.x/.../ostream:85 > #5 in std::ios_base::Init::Init() > gcc/7.x/libstdc++-v3/src/c++98/ios_init.cc:91 > #6 in __cxx_global_var_init gcc/7.x/.../iostream:74
[Bug target/92950] Wrong load instructions emitted for movv1qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Andreas Krebbel --- Fixed
[Bug target/92950] Wrong load instructions emitted for movv1qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Assuming fixed.
C (not C++) compiler plugins
Hello, Is it possible to make plugins for the C compiler (not the C++) compiler? I was trying the (old) sample code at https://github.com/hlandau/compex to make a plugin, but the plugin only works with C++. when trying to use the C compiler it complains about gcc -fplugin=/usr/local/lib/compex_gcc.so -D__COMPEX__=1 -fplugin-arg-compex_gcc-o=test_c.compex -o test_c test_c.c cc1: error: cannot load plugin /usr/local/lib/compex_gcc.so /usr/local/lib/compex_gcc.so: undefined symbol: cp_global_trees Is the mechanism differently, or are plugins even supported on the C compiler? - Maurice
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #17 from Martin Sebor ---
As you observed, the warning disappears if the assert is removed, so that's one
workaround. But rather than working around it I would suggest to rewrite the
code to avoid the pointer subtraction. Chances are it will not only avoid the
warning but help improve the emitted object code. I'm not sure I understand
correctly what the test case is meant to do but the example below shows what
I'm thinking of. If modifying the code isn't feasible then #pragma GCC
diagnostic is the recommended suppression mechanism.
typedef unsigned char byte;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
typedef __SIZE_TYPE__ size_t;
typedef struct pstream_t {
const byte * p;
ptrdiff_t n;
} pstream_t;
static inline _Bool ps_has (const pstream_t *ps, size_t len)
{
return (size_t)ps->n >= len;
}
static inline int __ps_skip (pstream_t * ps, size_t len)
{
if (!ps_has (ps, len))
__builtin_abort ();
ps->p += len;
ps->n -= len;
return 0;
}
static inline int ps_skip (pstream_t * ps, size_t len)
{
return ps_has (ps, len) ? __ps_skip(ps, len) : -1;
}
byte c;
int c_len;
void f(void)
{
pstream_t ps = { , c_len };
ps_skip (, 7);
}
[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Slightly more reduced testcase:
template struct A;
struct C {
template static int c ();
};
template struct D : C {
using c = decltype (c);
using E = A;
};
D g;
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
The 04/24/2020 15:17, Richard Sandiford wrote:
> Szabolcs Nagy writes:
> > @@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row
> > *new_row)
> >cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> >add_cfi (cfi);
> > }
> > +
> > + if (old_row->ra_mangled != new_row->ra_mangled)
> > +{
> > + dw_cfi_ref cfi = new_cfi ();
> > + /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
> > + cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> > + add_cfi (cfi);
> > +}
> > }
> >
> > /* Examine CFI and return true if a cfi label and set_loc is needed
>
> I wonder if it would be worth asserting:
>
> gcc_assert (!old_row->ra_mangled && !new_row->ra_mangled);
>
> in the "SPARC" block and:
>
> gcc_assert (!old_row->window_save && !new_row->window_save);
>
> in the "aarch64" block?
makes sense.
i'll fix it.
> > diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > new file mode 100644
> > index 000..1f13e1200ad
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> > @@ -0,0 +1,41 @@
> > +/* PR target/94515. Check .cfi_window_save with multiple return paths. */
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target lp64 } */
> > +/* { dg-additional-options "-O2 -mbranch-protection=pac-ret" } */
> > +
> > +volatile int zero = 0;
> > +int global = 0;
> > +
> > +__attribute__((noinline))
> > +int bar(void)
> > +{
> > + if (zero == 0) return 3;
> > + return 0;
> > +}
> > +
> > +__attribute__((noinline, noreturn))
> > +void unwind (void)
> > +{
> > + throw 42;
> > +}
> > +
> > +__attribute__((noinline, noipa, target("branch-protection=pac-ret")))
>
> I'm probably just showing my ignorance, but is this target attribute
> needed? It looks like all functions in the test are compiled with pac-ret.
no, that's left over before i added it to the cflags,
i'll fix it.
>
> LGTM otherwise, but please give others 24 hrs to object.
thanks.
>
> Thanks,
> Richard
--
Re: [rs6000] fix mffsl emulation
Hi! On Fri, Apr 24, 2020 at 04:52:46AM -0300, Alexandre Oliva wrote: > On Apr 23, 2020, Segher Boessenkool wrote: > > On Thu, Apr 23, 2020 at 05:08:55AM -0300, Alexandre Oliva wrote: > >> I wasn't sure simplify_gen_subreg might possibly emit any code in > >> obscure cases, > > > It never does, it just returns an RTX. Where would it emit the insns to? > > I'm pretty sure there are or were subreg-extraction functions that could > emit new insns onto whatever insn stream was active in certain unusual > circumstances; Yeah, I think so too. > I wasn't sure whether this was one of them. Doesn't look that way, thankfully :-) > > since all the top bits are zeros always, it will always be a subnormal > > number, so all comparisons will work as expected / wanted. > > *nod*, as long as there's no trapping on subnormals. There isn't :-) I did say this isn't clean at all, just *happens* to work, right? :-) > >> Yet another issue is that the test assumed the mmfs bits not extracted > >> by mffsl are all zero. > > > All those extra bits are required to be set to 0. > > Not in the mffs output, no. See, at this point I'm not talking about > the emulation, but about the mffs use in the test proper. Hrm, I don't see it then. > Consider the case of emulated mffsl: we end up comparing the mffs output > value with a masked version thereof. If any of the mffs output bits > could possibly be nonzero, the compare would fail, not because the > emulation is wrong, but because the test is comparing the output of > mffsl with that of mffs, with all its bits. Oh. I thought that was masked as well. > In my testing, mffs output zero in this program, so it worked, but are > all the non-mffsl bits of FPSCR guaranteed to be zero, so the output of > mffs doesn't have to be masked out by the test? No, and there are many bits not yet defined, so it may change for future versions of the ISA. > What if some future CPU defines some of the reserved bits in FPSCR in a > way that they should be nonzero? In a way different between mffs and mffsl. Yeah. > (And, could the ISA of such a future CPU possibly specify that mffsl > should preserve those extra bits from FPSCR, rather than zero them out?) Yes, I don't see why not? Hrm, the exact language for the mffsl description does not allow that, but that wouldn't be the best thing to reply on. > >> for gcc/ChangeLog > >> > >> * gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to > >> output operand in emulation. Simplify. > > > Indent with a tab please. > > Erhm, what I posted had TABs there. Did it get mangled? :-( Yes, to eight spaces, so that aligned "output" under "gcc". > >> + rtx tmp_df = operands[0]; > > > Please don't reuse pseudos > > Aah, I see, that's what the original tmp_di was trying to accomplish! :-) > I'm familiar with that general guidance, but I didn't think there's much > for optimizers to do with an mffs output, and the predicate ensures we > have a reg, but... I suppose additional pseudos make the subregging > safer, and not adding extra uses for operands[0] might help with > register allocation for it, so... How about this, to also avoid reusing > tmpdi as anddi input and output? No pseudo should be assigned to more than once. A la SSA, or "webs". Many of our optimisers do not work well otherwise. > rtx tmp_df = gen_reg_rtx (DFmode); > > /* The mffs instruction reads the entire FPSCR. Emulate the mffsl >instruction using the mffs instruction and masking off the bits >the mmsl instruction actually reads. */ > emit_insn (gen_rs6000_mffs (tmp_df)); > > rtx tmp_df_as_di = simplify_gen_subreg (DImode, tmp_df, DFmode, 0); > rtx tmp_di = gen_reg_rtx (DImode); > emit_insn (gen_anddi3 (tmp_di, tmp_df_as_di, GEN_INT (0x70007f0ffLL))); > > rtx tmp_di_as_df = simplify_gen_subreg (DFmode, tmp_di, DImode, 0); > emit_move_insn (operands[0], tmp_di_as_df); > DONE; Sure, that looks fine. Maybe tmp1, tmp2, etc. woukld be clearer here? :-) > > "mffsl instruction". Heh, I see the original was bad already, oops. > > Double oops. I had that typo fixed in some earlier version of the > patch, but somehow I managed to drop that fix. > > >> + if (operands[0] != tmp_df) > >> + emit_move_insn (operands[0], tmp_df); > >> + DONE; > > > That "==" won't do what you want, I guess? > > If the incoming operands[0] is a REG, we'd be back to it after > subregging back and forth; if it was a SUBREG to begin with, the cheap > test would fail and we'd output the redundant move, that later passes > will catch. Anyway, that's gone in the snippet above. > > > (Is there a PR, btw?) > > Not that I know of; we've hit the testcase FAIL in our own testing. Could you open one? This patch will need backporting, etc. I can do it, if you really hate bugzilla, but I think it is easier for you to do it :-) Thanks! Segher
[Bug middle-end/93488] [OpenACC] ICE in type-cast 'async', 'wait' clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93488 Andrew Stubbs changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Andrew Stubbs --- I think this is done now.
[GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te".
Hello,
This patches changes the constraint "e" to "Te".
Regression tested on arm-none-eabi and found no regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2020-04-24 Srinath Parvathaneni
* config/arm/constraints.md (e): Remove constraint.
(Te): Define constraint.
* config/arm/mve.md (vaddvq_): Modify constraint in
operand 0 from "e" to "Te".
(vaddvaq_): Likewise.
(vaddvq_p_): Likewise.
(vmladavq_): Likewise.
(vmladavxq_s): Likewise.
(vmlsdavq_s): Likewise.
(vmlsdavxq_s): Likewise.
(vaddvaq_p_): Likewise.
(vmladavaq_): Likewise.
(vmladavq_p_): Likewise.
(vmladavxq_p_s): Likewise.
(vmlsdavq_p_s): Likewise.
(vmlsdavxq_p_s): Likewise.
(vmlsdavaxq_s): Likewise.
(vmlsdavaq_s): Likewise.
(vmladavaxq_s): Likewise.
(vmladavaq_p_): Likewise.
(vmladavaxq_p_s): Likewise.
(vmlsdavaq_p_s): Likewise.
(vmlsdavaxq_p_s): Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/constraints.md b/gcc/config/arm/constraints.md
index
41a85e2713b59f75f0b191b6be03a7ac8f6e321e..fed6c7c84032dd8aba45142b59b980b4a6240d6d
100644
--- a/gcc/config/arm/constraints.md
+++ b/gcc/config/arm/constraints.md
@@ -32,7 +32,7 @@
;; The following multi-letter normal constraints have been used:
;; in ARM/Thumb-2 state: Da, Db, Dc, Dd, Dn, DN, Dm, Dl, DL, Do, Dv, Dy, Di,
-;; Dt, Dp, Dz, Tu
+;; Dt, Dp, Dz, Tu, Te
;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe
;; in Thumb-2 state: Ha, Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py, Pz, Rd, Rf, Rb,
Ra,
;; Rg, Ri
@@ -50,8 +50,8 @@
(define_register_constraint "Uf" "TARGET_HAVE_MVE ? VFPCC_REG : NO_REGS"
"MVE FPCCR register")
-(define_register_constraint "e" "TARGET_HAVE_MVE ? EVEN_REG : NO_REGS"
- "MVE EVEN registers @code{r0}, @code{r2}, @code{r4}, @code{r6}, @code{r8},
+(define_register_constraint "Te" "TARGET_HAVE_MVE ? EVEN_REG : NO_REGS"
+ "EVEN core registers @code{r0}, @code{r2}, @code{r4}, @code{r6}, @code{r8},
@code{r10}, @code{r12}, @code{r14}")
(define_constraint "Rd"
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index
9cb18ef50e8320b2d7160346361343c4ab1685b9..f43dabbfd4f15b602f0627a9b0ea423064501e51
100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -1102,7 +1102,7 @@
;;
(define_insn "mve_vaddvq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")]
VADDVQ))
]
@@ -1477,7 +1477,7 @@
;;
(define_insn "mve_vaddvaq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:SI 1 "s_register_operand" "0")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VADDVAQ))
@@ -1492,7 +1492,7 @@
;;
(define_insn "mve_vaddvq_p_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:HI 2 "vpr_register_operand" "Up")]
VADDVQ_P))
@@ -2032,7 +2032,7 @@
;;
(define_insn "mve_vmladavq_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLADAVQ))
@@ -2047,7 +2047,7 @@
;;
(define_insn "mve_vmladavxq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLADAVXQ_S))
@@ -2062,7 +2062,7 @@
;;
(define_insn "mve_vmlsdavq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLSDAVQ_S))
@@ -2077,7 +2077,7 @@
;;
(define_insn "mve_vmlsdavxq_s"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
(match_operand:MVE_2 2 "s_register_operand" "w")]
VMLSDAVXQ_S))
@@ -3685,7 +3685,7 @@
;;
(define_insn "mve_vaddvaq_p_"
[
- (set (match_operand:SI 0 "s_register_operand" "=e")
+ (set (match_operand:SI 0 "s_register_operand" "=Te")
(unspec:SI [(match_operand:SI 1 "s_register_operand" "0")
Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]
Szabolcs Nagy writes:
> @@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row
> *new_row)
>cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
>add_cfi (cfi);
> }
> +
> + if (old_row->ra_mangled != new_row->ra_mangled)
> +{
> + dw_cfi_ref cfi = new_cfi ();
> + /* DW_CFA_GNU_window_save is reused for toggling RA mangle state. */
> + cfi->dw_cfi_opc = DW_CFA_GNU_window_save;
> + add_cfi (cfi);
> +}
> }
>
> /* Examine CFI and return true if a cfi label and set_loc is needed
I wonder if it would be worth asserting:
gcc_assert (!old_row->ra_mangled && !new_row->ra_mangled);
in the "SPARC" block and:
gcc_assert (!old_row->window_save && !new_row->window_save);
in the "aarch64" block?
> diff --git a/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> new file mode 100644
> index 000..1f13e1200ad
> --- /dev/null
> +++ b/gcc/testsuite/g++.target/aarch64/pr94515-2.C
> @@ -0,0 +1,41 @@
> +/* PR target/94515. Check .cfi_window_save with multiple return paths. */
> +/* { dg-do run } */
> +/* { dg-require-effective-target lp64 } */
> +/* { dg-additional-options "-O2 -mbranch-protection=pac-ret" } */
> +
> +volatile int zero = 0;
> +int global = 0;
> +
> +__attribute__((noinline))
> +int bar(void)
> +{
> + if (zero == 0) return 3;
> + return 0;
> +}
> +
> +__attribute__((noinline, noreturn))
> +void unwind (void)
> +{
> + throw 42;
> +}
> +
> +__attribute__((noinline, noipa, target("branch-protection=pac-ret")))
I'm probably just showing my ignorance, but is this target attribute
needed? It looks like all functions in the test are compiled with pac-ret.
LGTM otherwise, but please give others 24 hrs to object.
Thanks,
Richard
[committed] amdgcn: Testsuite tweaks
This patch tweaks the testsuite expectations for amdgcn.
The result on the testsuite is a lot of removed failures, some new
passes, and a few new fails that are at least accurate.
Andrew
amdgcn: Testsuite tweaks
The vector size chosen here is for V64DImode. The concept of this setting is
not well adapted for GCN, in which the vector size varies with the number of
lanes, not the other way around, but this is ok for now.
2020-04-24 Andrew Stubbs
gcc/testsuite/
* lib/target-supports.exp (available_vector_sizes): Add amdgcn.
(check_effective_target_vect_cmdline_needed): Disable for amdgcn.
(check_effective_target_vect_pack_trunc): Add amdgcn.
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 008def691b3..f416d5cafda 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3261,7 +3261,8 @@ proc check_effective_target_vect_cmdline_needed { } {
|| [check_effective_target_powerpc_altivec]))
|| ([istarget sparc*-*-*] && [check_effective_target_sparc_vis])
|| ([istarget arm*-*-*] && [check_effective_target_arm_neon])
- || [istarget aarch64*-*-*] } {
+ || [istarget aarch64*-*-*]
+ || [istarget amdgcn*-*-*]} {
return 0
} else {
return 1
@@ -6806,7 +6807,8 @@ proc check_effective_target_vect_pack_trunc { } {
|| ([istarget mips*-*-*]
&& [et-is-effective-target mips_msa])
|| ([istarget s390*-*-*]
- && [check_effective_target_s390_vx]) }}]
+ && [check_effective_target_s390_vx])
+ || [istarget amdgcn*-*-*] }}]
}
# Return 1 if the target plus current options supports a vector
@@ -7231,6 +7233,8 @@ proc available_vector_sizes { } {
}
} elseif { [istarget sparc*-*-*] } {
lappend result 64
+} elseif { [istarget amdgcn*-*-*] } {
+ lappend result 4096
} else {
# The traditional default asumption.
lappend result 128
Re: [PATCH] libstdc++: don't use #include_next in c_global headers
On 23/04/20 09:23 +0100, Jonathan Wakely wrote: On 23/04/20 06:32 +0200, Helmut Grohne wrote: Hi, On Mon, Apr 20, 2020 at 10:12:37AM +0100, Jonathan Wakely wrote: Now you are probably going to say that "-isystem /usr/include" is a bad idea and that you shouldn't do that. Right. I'm inclined to agree. This isn't a problem just yet. Debian wants to move /usr/include/stdlib.h to /usr/include//stdlib.h. After that move, the problematic flag becomes "-isystem /usr/include/". Unfortunately, around 30 Debian packages[1] do pass exactly that flag. Regardless whether doing so is a bad idea, I guess we will have to support that. Or Debian should fix what they're going to break. This is not quite precise. The offending -isystem /usr/include/ flag is already being passed. According to what you write later, doing so is broken today. It just happens to work by accident. So all we do is making the present breakage visible. I am proposing to replace those two #include_next with plain #include. That'll solve the problem described above, but it is not entirely obvious that doing so doesn't break something else. After switching those #include_next to #include, libstdc++-v3/include/c_global/cstdlib will continue to temporarily will #include . Now, it'll search all include directories. It may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's version. We cannot tell which. If it finds the one from libstdc++-v3, the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and immediately #include_next skipping the rest of the header. That in turn will find the libc version. So in both cases, it ends up using the right one. Precisely what we wanted. As Marc said, this doesn't work. That is not very precise either. Marc said that it won't fix all cases. In practice, it would make those work that don't #include but use #include instead. Marc also indicated that using include_next for a header of a different name is wrong. So this is a bug in libstdc++ regardless of whether it breaks or unbreaks other pieces of software. He said he doesn't like it, that doesn't mean it's a bug or actually causes incorrect results. Whereas using -isystem provably *does* break the implementation, making it impossible for #include to meet the requirements of the C++ standard. And your proposed patch doesn't prevent that. If a program tries to include it needs to get the libstdc++ version, otherwise only the libc versions of certain functions are defined. That means the additional C++ overloads such as ::abs(long) and ::abs(long long) won't be defined. That is the reason why libstdc++ provides its own . And if you do -isystem /usr/include (or any other option that causes libstdc++'s to be skipped) that doesn't work. Only ::abs(int) gets defined. So -isystem /usr/include breaks code, with or without your patch. It is very difficult to disagree with -isystem /usr/include or -isystem /usr/include/ being broken and unsupported. Having you state it that clearly does help with communicating to other upstreams. For this reason, I've looked into the remaining cases. It turns out that there aren't that many left. In particular chromium, opencv and vtk got fixed in the mean time. Basically all remaining failures could be attributed to qmake, which passes all directories below /usr/include (including /usr/include and /usr/include/ if a .pc file mentions them) using -isystem. I've sent a patch https://bugs.debian.org/958479 to make qmake stop doing that. I therefore agree with you that the patch I sent for libstdc++ is not necessary to make packages build on Debian. Removing the offending -isystem flags from the respective builds is a manageable option and has already happened to a large extend. Yes, I introduced the current and wrappers years ago in GCC 6, and so I'm surprised to see it coming up again now. Several packages had problems and already fixed them. We can conclude that the motivation for my patch is not a good one, because it embraces broken behaviour. However, the use of include_next remains a bug, because the name of the including and the name of the included header differ, and it should be fixed on that ground. Not liking something is not a bug. You need to demonstrate an actual bug (e.g. failure to compile, non-conformance to the C++ standard) that is not caused by user error (like misuse of -isystem) to argue for fixing something. N.B. the GCC docs are quite clear that reordering include directories risk breaking GCC's necessary use of #include_next: If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option is ignored. The directory is still searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC's procedure to fix buggy system headers and the ordering for the "#include_next" directive are not inadvertently changed. If you really need to change
[Bug c/94746] New: -Wsizeof-pointer-div not triggered by system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746
Bug ID: 94746
Summary: -Wsizeof-pointer-div not triggered by system header
macros
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
I found out that the macro `#define __arraycount(__x) (sizeof(__x) /
sizeof(__x[0]))` which is in libbsd's doesn't trigger any warning
when applied to a pointer.
I investigated the reason, and I found out that my own `#define ARRAY_SIZE(arr)
(sizeof(arr) / sizeof((arr)[0]))` doesn't trigger any warnings either (it is
installed in `/usr/local/include/`, but it does trigger warnings when compiling
before installing it.
So I came to the conclusion that the bug is the following:
GCC suppresses warnings in system headers, which of course is a generally good
thing, but in this case it is not a good thing.
Maybe a solution would be to not suppress warnings about macros defined in
system headers (this might suddenly trigger lots of warnings, some of them
maybe unwanted, I don't know). There might be more bugs like this one being
ignored.
Code to reproduce the bug:
#include
int main(void)
{
int *p;
return __arraycount(p);
}
Minimum compilation settings to reproduce the bug:
$ gcc -Wsizeof-pointer-div bug.c `pkg-config --cflags libbsd-overlay`
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #2 from Jonathan Wakely --- (In reply to Louis Dionne from comment #0) > This makes detecting whether GCC supports a given warning flag very > challenging in build systems. You're doing it wrong then. Try 'g++ -Q --help=warnings' instead of probing individual options.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #8 from Segher Boessenkool --- Patch is bootstrapping.
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #1 from Jonathan Wakely --- This is by design. It means that makefiles written for different versions of GCC do not trigger spurious diagnostics. If somebody says "I don't want warnings about cat noises" and their version of GCC doesn't support -Wmeow then their request is granted. Warning about it would cause valid compilations to fail. If other diagnostics are being emitted anyway, then adding one to point out the unrecognized option isn't going to make a build go from passing to failing.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 9.4
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 --- Comment #3 from Jonathan Wakely --- Fixed now.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:942b32e261c414a033766ed7848d923f9630b991 commit r9-8543-g942b32e261c414a033766ed7848d923f9630b991 Author: Jonathan Wakely Date: Fri Apr 24 14:29:37 2020 +0100 libstdc++: Fix type-erasure in experimental::net::executor (PR 94203) The _Tgt and _TgtImpl types that implement type-erasure didn't agree on the virtual interface, so failed as soon as they were instantiated. With Clang they failed even sooner. The interface was also dependent on whether RTTI was enabled or not. This patch fixes the broken virtual functions and makes the type work without RTTI, by using a pointer to a specialization of a function template (similar to the approaches in std::function and std::any). The changes to the virtual functions would be an ABI change, except that the previous code didn't even compile if instantiated. This is experimental TS material anyway. Backport from mainline 2020-03-18 Jonathan Wakely PR libstdc++/94203 * include/experimental/executor (executor::executor(Executor)): Call make_shared directly instead of _M_create. Create _Tgt1 object. (executor::executor(allocator_arg_t, const ProtoAlloc&, Executor)): Call allocate_shared directly instead of _M_create. Create _Tgt2 object. (executor::target_type): Add cast needed for new _Tgt interface. (executor::target): Define when RTTI is disabled. Use _Tgt::_M_func. (executor::_Tgt): Define the same interface whether RTTI is enabled or not. (executor::_Tgt::target_type, executor::_Tgt::target): Do not use std::type_info in the interface. (executor::_Tgt::_M_func): Add data member. (executor::_TgtImpl): Replace with _Tgt1 and _Tgt2 class templates. (executor::_Tgt1::_S_func): Define function to access target without depending on RTTI. (executor::_M_create): Remove. (operator==, operator!=): Simplify comparisons for executor. * include/experimental/socket (is_error_code_enum): Define specialization before use. * testsuite/experimental/net/executor/1.cc: New test.
[Bug c++/94745] New: No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 Bug ID: 94745 Summary: No error emitted for unknown -Wno-meow argument Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- GCC does not diagnose unsupported -Wno-meow command line flags unless another error happens during compilation. For example, the following compiles just fine even though -Wno-foo doesn't exist: $ echo | g++ -xc++ - -Werror -fsyntax-only -Wno-foo If, however, another error happens during compilation, the unsupported command-line flag is reported: $ echo '#error' | g++ -xc++ - -Werror -fsyntax-only -Wno-foo :1:2: error: #error cc1plus: error: unrecognized command line option '-Wno-foo' [-Werror] cc1plus: all warnings being treated as errors This makes detecting whether GCC supports a given warning flag very challenging in build systems. This issue popped up while trying to support GCC when running the libc++ Standard Library conformance test suite.
Re: [committed] libstdc++: Add default constructor to net::service_already_exists (PR 94199)
On 16/03/20 22:54 +, Jonathan Wakely wrote:
The service_already_exists exception type specified in the TS doesn't
have any constructors defined. Since its base class isn't default
constructible, that means has no usable constructors. This may be a
defect in the TS.
This patch fixes it by adding a default constructor, but making it
private. The make_service function is declared as a friend to be able to
call that private constructor.
PR libstdc++/94199
* include/experimental/executor (service_already_exists): Add default
constructor. Declare make_service to be a friend.
* testsuite/experimental/net/execution_context/make_service.cc: New
test.
LWG preferred to make the constrcutor public, so this patch does that.
Tested x86_64-linux, committed to master.
commit 00082ff88cf4e25fc1041e9effd1c92fbaaa8d62
Author: Jonathan Wakely
Date: Fri Apr 24 14:15:51 2020 +0100
libstdc++: Make net::service_already_exists default constructible
The LWG issue I created is Tentatively Ready and proposes to declare a
public default constructor, rather than the private one I added
recently.
* include/experimental/executor (service_already_exists): Make default
constructor public (LWG 3414).
* testsuite/experimental/net/execution_context/make_service.cc: Check
the service_already_exists can be default constructed.
diff --git a/libstdc++-v3/include/experimental/executor b/libstdc++-v3/include/experimental/executor
index fa39eaa0468..3560e345e8a 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -129,10 +129,9 @@ inline namespace v1
class service_already_exists : public logic_error
{
-template
- friend _Service&
- make_service(execution_context&, _Args&&...);
-
+ public:
+// _GLIBCXX_RESOLVE_LIB_DEFECTS
+// 3414. service_already_exists has no usable constructors
service_already_exists() : logic_error("service already exists") { }
};
diff --git a/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
index f134add48b5..0898d12927a 100644
--- a/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
+++ b/libstdc++-v3/testsuite/experimental/net/execution_context/make_service.cc
@@ -34,3 +34,6 @@ void test01(net::execution_context& c)
{
net::make_service(c);
}
+
+static_assert(std::is_default_constructible(),
+ "LWG 3414. service_already_exists has no usable constructors");
[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
So, seems the second argument of the call is some empty class - struct
._anon_2, 1 byte long, and the FE in the CALL_EXPR passes an empty CONSTRUCTOR
of that type.
The gimplifier then creates a temporary for that (and doesn't initialize it),
so we have:
struct ._anon_2 D.3223;
:
= fooV<{const char*, int, double, char, float, short int, unsigned
int}>operator()::, const char*,
int, double, char, float, short int, unsigned int> (0B, D.3223, _2(D)
, _3(D), _4(D), _5(D), _6(D), _7(D), _8(D)); [return slot optimization]
up to *.optimized in a thunk, D.3223 is not initialized (contains just padding)
and is passed by value to the call.
Now, on powerpc -m32, the ABI wants to pass that by reference -
if (pass_by_reference (args_so_far_pnt, arg))
is true, and we enter:
/* If we're compiling a thunk, pass through invisible references
instead of making a copy. */
if (call_from_thunk_p
|| (callee_copies
&& !TREE_ADDRESSABLE (type)
&& (base = get_base_address (args[i].tree_value))
&& TREE_CODE (base) != SSA_NAME
&& (!DECL_P (base) || MEM_P (DECL_RTL (base)
block because call_from_thunk_p is true. But, base is a DECL with DECL_RTL of
a (reg:QI ...).
The code calls mark_addressable on args[i].tree_value, but that doesn't do
anything immediately, because currently_expanding_to_rtl is true (but even if
it would, that doesn't change DECL_RTL of the arg being passed).
Later the code calls build_fold_addr_expr_loc and ICEs when expanding that,
because trying to expand ADDR_EXPR on a VAR_DECL with DECL_RTL of (reg:QI ...)
doesn't work.
I don't see how this can be implemented other than actually making a copy,
so wonder if the condition shouldn't be
if ((call_from_thunk_p || callee_copies)
&& !TREE_ADDRESSABLE (type)
&& ...
instead. But what do I know about thunks.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 Jonathan Wakely changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Jonathan Wakely --- *** Bug 94744 has been marked as a duplicate of this bug. ***
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- This is PR 94203, which is still open until I backport it. The added test on the branch reveals the latent bug. *** This bug has been marked as a duplicate of bug 94203 ***
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2020-04-24 Target Milestone|--- |9.4 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jonathan Wakely --- I think I need to backport g:98f29f5638f73d8e55590eba8098a537ba746287
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- A test case from the original post was committed as r10-7944-g1d072f3eeac4 (I missed the PR number from the commit) so fixed.
[committed] coroutines, testsuite: Add test for fixed pr [PR94288]
Hi,
This is a version of the reproducer in the PR, usable on multiple platforms.
tested on x86_64-linux/darwin, powerpc64-linux,
pushed to master,
thanks
Iain
gcc/testsuite/
2020-04-24 Iain Sandoe
PR c++/94288
* g++.dg/coroutines/pr94288.C: New test.
diff --git a/gcc/testsuite/g++.dg/coroutines/pr94288.C
b/gcc/testsuite/g++.dg/coroutines/pr94288.C
new file mode 100644
index 000..2557e3e0f2b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr94288.C
@@ -0,0 +1,70 @@
+// { dg-additional-options "-w" }
+
+#include "coro.h"
+
+#include
+
+template struct promise {
+ T _value;
+ coro::coroutine_handle<> _continuation = nullptr;
+
+ struct final_awaitable {
+bool _has_continuation;
+final_awaitable(bool has_continuation)
+: _has_continuation(has_continuation) {}
+
+bool await_ready() const noexcept { return !_has_continuation; }
+
+template
+coro::coroutine_handle<>
+await_suspend(coro::coroutine_handle coro) noexcept {
+ return coro.promise()._continuation;
+}
+
+void await_resume() noexcept {}
+ };
+
+ auto get_return_object() noexcept {
+return coro::coroutine_handle::from_promise(*this);
+ }
+
+ auto initial_suspend() noexcept { return coro::suspend_always(); }
+
+ auto final_suspend() noexcept {
+return final_awaitable(_continuation != nullptr);
+ }
+
+ void return_value(T value) { _value = value; }
+
+ void unhandled_exception() { /*std::terminate();*/ }
+
+};
+
+template struct task {
+ using promise_type = promise;
+ coro::coroutine_handle> _handle;
+
+ task(coro::coroutine_handle> handle) : _handle(handle) {}
+
+ bool await_ready() noexcept { return _handle.done(); }
+
+ coro::coroutine_handle<>
+ await_suspend(coro::coroutine_handle<> handle) noexcept {
+_handle.promise()._continuation = handle;
+return _handle;
+ }
+
+ T await_resume() noexcept { return _handle.promise()._value; }
+};
+
+task> foo()
+{
+ co_return std::vector();
+}
+
+task bar()
+{
+ while ((co_await foo()).empty()) {
+ }
+ co_return 0;
+}
--
2.24.1
[Bug libstdc++/94744] New: [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Bug ID: 94744 Summary: [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors) Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Fedora 31, r9-8540 gave Executing on host: /export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs -B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem /usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include -fchecking=1 -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs -lm -o ./1.exe(timeout = 600) spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs -B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem /usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include -fchecking=1 -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs -lm -o ./1.exe In file included from /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:20: /export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor: In instantiation of '_Executor* std::experimental::net::v1::executor::target() [with _Executor = test02()::E]': /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:71: required from here /export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor:1112: error: no matching function for call to 'test02()::E::E(const void*&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: candidate: 'constexpr test02()::E::E(const test02()::E&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: no known conversion for argument 1 from 'const void*' to 'const test02()::E&' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: candidate: 'constexpr test02()::E::E(test02()::E&&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45:
[Bug c++/94742] [8/9/10 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-04-24 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 48368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48368=edit gcc10-pr94742.patch Untested fix.
[Bug target/94743] New: IRQ handler implementation wrong when using __attribute__ ((interrupt("IRQ")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Bug ID: 94743
Summary: IRQ handler implementation wrong when using
__attribute__ ((interrupt("IRQ")))
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
As described in https://bugs.linaro.org/show_bug.cgi?id=5614:
IRQ implementation when using __attribute__ ((interrupt("IRQ"))) by GCC does
not save/restore NEON scratch registers when using -mfloat-abi=hard
-mfpu=neon-fp16.
But if the handler calls a function that uses Neon scratch registers, this will
corrupt the values seen by the program when the IRQ handler completes.
An easy example uses memcpy in the handler:
=== irq_test.c ===
typedef struct {
int data[32];
} dummy_t ;
extern void foo(dummy_t d);
__attribute__ ((interrupt("IRQ"))) void IRQ_HDLR_Test(void) {
dummy_t d;
d.data[3] = 3;
foo(d);
}
===
Compile with arm-none-eabi-gcc -mcpu=cortex-a9 -mtune=cortex-a9 -marm
-mfloat-abi=hard -mfpu=neon-fp16 -Ofast irq_test.c
The generated code looks like:
21IRQ_HDLR_Test:
22@ Interrupt Service Routine.
23@ args = 0, pretend = 0, frame = 128
24@ frame_needed = 0, uses_anonymous_args = 0
25 04E04EE2 sub lr, lr, #4
26 0004 0F502DE9 push{r0, r1, r2, r3, ip, lr}
27 0008 F0D04DE2 sub sp, sp, #240
28 000c 0330A0E3 mov r3, #3
29 0010 80108DE2 add r1, sp, #128
30 0014 7020A0E3 mov r2, #112
31 0018 0D00A0E1 mov r0, sp
32 001c 7C308DE5 str r3, [sp, #124]
33 0020 FEEB bl memcpy
34 0024 70308DE2 add r3, sp, #112
35 0028 0F0093E8 ldm r3, {r0, r1, r2, r3}
36 002c FEEB bl foo
37 0030 F0D08DE2 add sp, sp, #240
38@ sp needed
39 0034 0F90FDE8 ldmfd sp!, {r0, r1, r2, r3, ip, pc}^
In this case, the newlib version of memcpy uses NEON code and will clobber NEON
registers.
To be safe, the IRQ handler should
push {d0-d7, d16-d31}
This can be costly in terms of CPU cycles for an IRQ handler, so maybe we could
think of adding another attribute but it would be hard for the end-user to
guess that he might use Neon registers in an implicit way (like here where the
compiler calls memcpy)
