[Bug c++/93244] New: std::filesystem::path::generic_string doesn't convert the first slash on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93244
Bug ID: 93244
Summary: std::filesystem::path::generic_string doesn't convert
the first slash on Windows
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: orgads at gmail dot com
Target Milestone: ---
#include
int main()
{
std::cout << std::filesystem::current_path().generic_string() << std::endl;
}
Prints F:\Projects/test/foo/bar/baz
I debugged it a bit, and from
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/fs_path.h#L1136
I saw that the elements are:
* _Root_name (F:) - __add_slash remains false
* _Root_dir (\) - It is appended as it is (that's the bug), and __add_slash
remains false
* From this point, the elements are all _Filename, and forward slashes are
appended.
[Bug c++/93048] [10 Regression] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048 --- Comment #7 from Pilar Latiesa --- (In reply to Andrew Pinski from comment #6) > This might already been fixed. The testcases, as well as the codebase from which they were reduced, compile fine now. Shall I change the PR status to resolved? Thanks so much
[Bug c/93241] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241
--- Comment #3 from joseph at codesourcery dot com ---
I think this is actually a regression in 4.5 and later relative to 4.4.
It can be demonstrated in older versions using a different test, with
-std=c99 -pedantic-errors.
#include
struct s { int a: 0? (_Bool)(INT_MAX+1) : 1; };
I'll look at fixing this, since I'm familiar with the integer constant
expression handling.
[Bug c/93241] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241 --- Comment #2 from joseph at codesourcery dot com --- I think this is a bug. The expression meets all the requirements for integer constant expressions (the unevaluated part of the expression has only permitted operands and casts, much like the "2 || 1 / 0" example).
[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 --- Comment #2 from Hongtao.liu --- > The diffs in the source code are: > #if CASE & 1 > #define CMP(a, b) ((a) < (b)) > #else > #define CMP(a, b) (((a) - (b)) < 0) > #endiF > (a) < (b) is not equal to ((a) - (b) < 0) Compiler will trait them differently.
[Bug c++/93238] [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238 --- Comment #2 from Jason Merrill --- Created attachment 47642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47642&action=edit fix
[Bug c++/93238] [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234 --- Comment #2 from urbanjost at comcast dot net --- Created attachment 47641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47641&action=edit NAMELIST dumper of all INQUIRE parameters I did not see anything else undefined. I had to chop it down because it used to much of my customized programming environment, but the attached program shows everything you can get from an INQUIRE, I think. I saw some values I was a bit confused by, but nothing else came me an out and out error. I was trying to keep the test case simple, but in case I missed something it might be useful to run the attached program.
[Bug c/93241] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241 --- Comment #1 from Andrew Pinski --- The issue comes from is 0 ? expression : 1 ; Does expression need to be an constant expresison and be evaluated? 6.6/10 allows applies here too: An implementation may accept other forms of constant expressions.
[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-13
CC||jvdelisle at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
The enumerators in inquire.c do not match those set in unit.c.
Something like this is needed.
diff --git a/libgfortran/io/inquire.c b/libgfortran/io/inquire.c
index e6b22eb0b33..62aca71a162 100644
--- a/libgfortran/io/inquire.c
+++ b/libgfortran/io/inquire.c
@@ -371,7 +371,7 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit *u)
else
switch (u->flags.sign)
{
- case SIGN_PROCDEFINED:
+ case SIGN_UNSPECIFIED:
p = "PROCESSOR_DEFINED";
break;
case SIGN_SUPPRESS:
@@ -409,7 +409,7 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit *u)
case ROUND_COMPATIBLE:
p = "COMPATIBLE";
break;
- case ROUND_PROCDEFINED:
+ case ROUND_UNSPECIFIED:
p = "PROCESSOR_DEFINED";
break;
default:
I wonder if they are off for any others?
[Bug tree-optimization/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243 Leo Yuriev changed: What|Removed |Added Keywords|missed-optimization | Target|x86_64 | Component|target |tree-optimization --- Comment #1 from Leo Yuriev --- Minor additions: - benchmarks results above made with -Ofast. - one of gcc 9.x -Os result is below. ./heapsort-bench, cc 9.2.1 20191008 pass 1, small: 0.805970 seconds, baseline 0.799507 seconds, case-1, 99.2% of baseline 0.784975 seconds, case-2, 97.4% of baseline 0.789067 seconds, case-1+2, 97.9% of baseline pass 1, large: 2.859491 seconds, baseline 2.779411 seconds, case-1, 97.2% of baseline 2.782386 seconds, case-2, 97.3% of baseline 2.743033 seconds, case-1+2, 95.9% of baseline I.e. gcc 9.2.x with -Os faster then -Ofast.
[Bug tree-optimization/93243] New: misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93243
Bug ID: 93243
Summary: misoptimization: minor changes of the code leads
change up to +/- 30% performance on x86_64, -Os faster
than -Ofast/O2/O3
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: leo at yuriev dot ru
Target Milestone: ---
Briefly:
./heapsort-bench, cc 9.2.1 20191008
pass 1, small:
1.138047 seconds, baseline
1.090476 seconds, case-1, 95.8% of baseline
0.957207 seconds, case-2, 84.1% of baseline
1.163323 seconds, case-1+2, 102.2% of baseline
pass 1, large:
2.766881 seconds, baseline
2.677642 seconds, case-1, 96.8% of baseline
3.230149 seconds, case-2, 116.7% of baseline
2.758408 seconds, case-1+2, 99.7% of baseline
./heapsort-bench, cc Clang 9.0.0 (tags/RELEASE_900/final)
pass 1, small:
1.048489 seconds, baseline
1.050220 seconds, case-1, 100.2% of baseline
1.056953 seconds, case-2, 100.8% of baseline
1.050501 seconds, case-1+2, 100.2% of baseline
pass 1, large:
2.588565 seconds, baseline
2.585488 seconds, case-1, 99.9% of baseline
2.610508 seconds, case-2, 100.8% of baseline
2.587282 seconds, case-1+2, 100.0% of baseline
./heapsort-bench, gcc 7.4.0 (ubuntu)
pass 1, small:
0.893917 seconds, baseline
1.135796 seconds, case-1, 127.1% of baseline
0.920338 seconds, case-2, 103.0% of baseline
1.140505 seconds, case-1+2, 127.6% of baseline
pass 1, large:
3.804271 seconds, baseline
2.955773 seconds, case-1, 77.7% of baseline
3.908621 seconds, case-2, 102.7% of baseline
2.925845 seconds, case-1+2, 76.9% of baseline
The diffs in the source code are:
#if CASE & 1
#define CMP(a, b) ((a) < (b))
#else
#define CMP(a, b) (((a) - (b)) < 0)
#endiF
#if CASE & 2
for (size_t root = from; (root + root) <= to;) {
size_t child = root << 1;
#else
for (size_t child, root = from; (child = root + root) <= to;) {
#endif
gcc 9.x and clang 9.x shows (nearly) the same results on Fedora 31 and Ubunto
19.10.
gcc 7.4 probed only on ubuntu, moreover clang 6.0 shown stable results like
clang 9.
Source code of testcase at https://github.com/leo-yuriev/gcc-issues
$ wc heapsort.c
165 528 4309 heapsort.c
Using PGO (included in the testcase) does not significantly change the result.
Basically these words is seems enough, but more ones I will add tomorrow
(likely after afternoon UTC+03).
Regards,
Leonid.
[Bug target/93242] New: [MIPS] patchable-function-entry broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93242
Bug ID: 93242
Summary: [MIPS] patchable-function-entry broken
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: renat at idrisov dot info
Target Milestone: ---
Created attachment 47640
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47640&action=edit
preprocessed file
Hi All,
when I try to use -fpatchable-function-entry on MIPS, it produces broken
assembly file:
c++ -mips64r6 -mabi=64 -o empty.o -c empty.c -fpatchable-function-entry=1 -v
-save-temps
...
empty.s: Assembler messages:
empty.s:14: Error: junk at end of line, first unrecognized character is `%'
I have attached preprocessed file, but it contains nothing special, source
program is:
```
int main() {
return 0;
}
```
If I look at assembly file, it indeed has a bogus:
```
.module fp=64
.module oddspreg
.text
.align 2
.globl main
.section__patchable_function_entries,"a",@progbits
.8byte $LPFE1
.text
$LPFE1:
%(nop%) < no such instruction
$LFB0 = .
.cfi_startproc
.setnomips16
.setnomicromips
.entmain
.type main, @function
main:
.frame $fp,16,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x4000,-8
.fmask 0x,0
...
```
I can provide a patch to fix it, but first I want to confirm it is a bug.
Thank you!
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1f4b95dfdcdc4ed7c6952285d494983103b678b8 commit r9-8120-g1f4b95dfdcdc4ed7c6952285d494983103b678b8 Author: Jakub Jelinek Date: Sun Jan 12 22:51:15 2020 +0100 Test git hooks interaction with Bugzilla. PR c/93218 * Test git hooks interaction with Bugzilla.
[Bug libgcc/61752] on cygwin, aborts during exit() with a dynamically loaded C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752 Jon Turney changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jon Turney --- (In reply to Jon Turney from comment #2) > Better patch: https://cygwin.com/ml/cygwin/2014-07/msg00180.html That patch was applied as svn commit 213009.
[Bug c++/93238] [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
--- Comment #1 from Stephan Bergmann ---
I assume that current trunk
> $ cat test.cc
> enum { E };
> int f(short n) { return n >> E; }
> $ g++ -fsyntax-only test.cc
> test.cc: In function ‘int f(short int)’:
> test.cc:2:30: internal compiler error: tree check: expected integer_cst, have
> nop_expr in to_wide, at tree.h:5860
> 2 | int f(short n) { return n >> E; }
> | ^
[...]
is the same issue. (Goes away when reverting
g:337ea6b216afd412b85f3fda78a36467ffe4a817.)
[Bug c/93241] New: _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93241 Bug ID: 93241 Summary: _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pskocik at gmail dot com Target Milestone: --- About the simplest example of this I could get: //erroneously warns about non-constness under -pedantic _Static_assert( 0? (_Bool)(INT_MAX+1) : 1 ,""); https://gcc.godbolt.org/z/W_tvTS The problem seems to have existed since gcc 5.
[Bug c/93240] [frontend] 'align_value' attribute not suported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93240 Roman Lebedev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- Summary|[frontend] 'align_value'|[frontend] 'align_value' |attribute not honored to|attribute not suported |variables in types | --- Comment #3 from Roman Lebedev --- (In reply to Andrew Pinski from comment #1) > align_value does not exist in GCC at all. Oh interesting, i missed that somehow. > you want aligned. > > https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes. > html#Common-Type-Attributes I really don't think i do. From that description it is evident that it would *not* specify the alignment of &(s->y[0]), but of &(s->y). (In reply to Andrew Pinski from comment #2) > Or you suggesting GCC should add it? > > https://reviews.llvm.org/D4635 Then i suppose so, yes. > Why not use __builtin_assume_aligned instead?
[Bug c/93240] [frontend] 'align_value' attribute not honored to variables in types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93240 --- Comment #2 from Andrew Pinski --- Or you suggesting GCC should add it? https://reviews.llvm.org/D4635 Why not use __builtin_assume_aligned instead?
[Bug tree-optimization/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967
--- Comment #8 from David Binderman ---
Reduced code:
template void c(b d) { d >>= a * 4; }
template void g(e, f) {
char h;
c<1>(h);
}
int i;
void j() { g(j, i); }
[Bug c/93240] [frontend] 'align_value' attribute not honored to variables in types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93240 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- align_value does not exist in GCC at all. you want aligned. https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Common-Type-Attributes.html#Common-Type-Attributes
[Bug tree-optimization/87967] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87967 David Binderman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from David Binderman --- Seems re-broken sometime between revision 280100 and 2810150. No -O3 required. /home/dcb/gcc/results.28/bin/gcc /home/dcb/gcc/results.280050/bin/gcc /home/dcb/gcc/results.280100/bin/gcc /home/dcb/gcc/results.280150/bin/gcc ../../rak/string_manip.h:180:5: internal compiler error: tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5860 I'll have a go at reducing the code.
[Bug c/93240] New: [frontend] 'align_value' attribute not honored to variables in types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93240
Bug ID: 93240
Summary: [frontend] 'align_value' attribute not honored to
variables in types
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/-ExpDY
typedef double * aligned_double_ptr __attribute__((align_value(64)));
struct S {
aligned_double_ptr y;
};
void foo(S*s){
s->y[0] = 0;
}
:1:68: warning: 'align_value' attribute directive ignored
[-Wattributes]
1 | typedef double * aligned_double_ptr __attribute__((align_value(64)));
|^
Compiler returned: 0
With clang that correctly results in alignment being lowered and used
as alignment for the store: https://godbolt.org/z/SybzgM
[Bug c/93239] New: Enhancement: allow unevaluated statement expressions at filescope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
Bug ID: 93239
Summary: Enhancement: allow unevaluated statement expressions
at filescope
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pskocik at gmail dot com
Target Milestone: ---
I've noticed gcc seems to syntactically disallow statement expressions at
filescope even in contexts where they wouldn't be evaluated such as:
1) inside sizeof/__typeof/_Alignof
2) inside _Generic branches that aren't taken
I'm currently trying to use 2) to implement some generic numerical macros that
evaluate to an integer constant expression iff their arguments are integer
constant expressions and at the same time don't double-evaluate their arguments
(if those aren't integer constant expressions).
A simple example would be:
#define SQ(X) _Generic(0?(void*)((X)*0):(int*)0, \
int*: /*isconstexpr(X)==1*/ (X)*(X), \
void *: /*isconstexpr(X)==0*/ (__extension__({
__typeof(X) SQ = (X); SQ *= (X); })) )
Interestingly this works on tinycc (a much more primitive compiler) where it
can be used in filescope to give enum values, array sizes, or bit-field widths
or inside static asserts at filescope, but on gcc/clang, all of these must be
inside a function.
Of course, this can worked around by using an (inline) function for each
integer type and a second _Generic in the non-constexpr branch of the macro
that enumerates the helper functions, but that seems like a rather bloated
workaround necessitated only by what seems to be an unnecessary restriction in
the compiler.
[Bug c++/93238] [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-12 Known to work||9.2.0 Version|9.0 |10.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
[Bug c++/93238] New: [10 Regression] ICE in tree check: expected integer_cst, have mult_expr in to_wide, at tree.h:5855 since g:337ea6b216afd412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93238
Bug ID: 93238
Summary: [10 Regression] ICE in tree check: expected
integer_cst, have mult_expr in to_wide, at tree.h:5855
since g:337ea6b216afd412
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
It's reduced from 541.leela_r SPEC benchmark:
$ cat 1.ii
class A {
public:
short operator[](long);
};
class B {
enum { BLACK };
float m_fn1();
A m_neighbours;
};
float B::m_fn1() {
m_neighbours[0] >> 4 * BLACK;
return 0.0f;
}
$ g++ 1.ii -c
1.ii: In member function 'float B::m_fn1()':
1.ii:11:26: internal compiler error: tree check: expected integer_cst, have
mult_expr in to_wide, at tree.h:5860
11 | m_neighbours[0] >> 4 * BLACK;
| ^
0x815ae4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marxin/Programming/gcc/gcc/tree.c:9685
0x818129 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3534
0x818129 wi::to_wide(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.h:5860
0x818129 tree_int_cst_sgn(tree_node const*)
/home/marxin/Programming/gcc/gcc/tree.c:7382
0xaebfa9 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:5609
0x90ca37 build_new_op_1
/home/marxin/Programming/gcc/gcc/cp/call.c:6475
0x90d38d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/call.c:6520
0xade183 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:4245
0xa0df91 cp_parser_binary_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9648
0xa0ee07 cp_parser_assignment_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9783
0xa0f0fd cp_parser_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9951
0xa128c8 cp_parser_expression_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11602
0xa1e3e9 cp_parser_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11398
0xa1fba2 cp_parser_statement_seq_opt
/home/marxin/Programming/gcc/gcc/cp/parser.c:11745
0xa1fc78 cp_parser_compound_statement
/home/marxin/Programming/gcc/gcc/cp/parser.c:11699
0xa383e5 cp_parser_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:22901
0xa383e5 cp_parser_ctor_initializer_opt_and_function_body
/home/marxin/Programming/gcc/gcc/cp/parser.c:22952
0xa3b721 cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:28739
0xa3c4c1 cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:28655
0xa3c4c1 cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:20530
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/93237] vector defined using inserts is not converted into constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93237 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-12 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine, working on it with a patch to reassociate where we will reassociate bit_inserts and remove un-needed ones and then we add this optimization in the same location where we know have the vector fully defined by inserts and also by just by elements (not sub-elements).
[Bug tree-optimization/93237] New: vector defined using inserts is not converted into constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93237
Bug ID: 93237
Summary: vector defined using inserts is not converted into
constructors
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take this stupid code:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-optimized" } */
#define vector __attribute__((__vector_size__(4*sizeof(int)) ))
vector int f(int b)
{
vector int a = {0,0,0,0};
a[0] = b;
a[1] = b;
a[2] = b;
a[3] = b;
return a;
}
/* { dg-final { scan-tree-dump-times "BIT_INSERT_EXPR" 0 "optimized" } } */
- CUT ---
In the end, we should generate a CONSTRUCTOR with just b's.
[Bug sanitizer/89868] -fsanitize=address inhibits core dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868 Andrew Pinski changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||dvyukov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||kcc at gcc dot gnu.org Component|c++ |sanitizer Summary|-fsanitize=address inhibits |-fsanitize=address inhibits |C++ unhandled exception |core dumps |core dump | --- Comment #7 from Andrew Pinski --- (In reply to Jonny Grant from comment #6) > Hi Andrew > Thank you for tracking that down. It is a shame, there isn't a > WCORETOOLARGE, or WUNABLETOCOREDUMP etc.. I wonder really how big the core > must be to be unable to save You can look into the kernel sources to figure it out. ulimit sets some limits of the core file but there might be some other sys related ones. asan needs to have a huge area where it does a shadow memory; it is compressed but still big.
[Bug libstdc++/92192] Undefined symbols in libstdc++ when compiled with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92192 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #2 from Xi Ruoyao --- Blocked by PR48200.
[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92949 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-12 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Andrew Pinski --- So for BIT_INSERT_EXPR, I am not going to handle it in store merging but rather Reassociation pass instead because I am going to handle reordering of BIT_INSERT_EXPR there too.
[Bug target/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 --- Comment #6 from Andrew Pinski --- (In reply to Segher Boessenkool from comment #5) > (In reply to Andrew Pinski from comment #4) > > >Linux system calls and Linux VDSO calls > > > > System calls, I can understand But why is it required by VDSO calls too? > > That seems backwards and also means VDSO functions are not the same ABI as > > normal functions. > > It is how it is, we have to implement it whatever strange things are > required ;-) > > Part of the reason may be that vdso calls *are* a lot like system calls; the > fallback for an unimplemented vdso call is the corresponding system call, for > example. That is fine but they still should be different ABIs. Anything else seems broken and wrong.
[Bug target/92769] Powerpc: No way to set CR0[SO] on function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92769 --- Comment #5 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #4) > >Linux system calls and Linux VDSO calls > > System calls, I can understand But why is it required by VDSO calls too? > That seems backwards and also means VDSO functions are not the same ABI as > normal functions. It is how it is, we have to implement it whatever strange things are required ;-) Part of the reason may be that vdso calls *are* a lot like system calls; the fallback for an unimplemented vdso call is the corresponding system call, for example.
[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
