[Bug tree-optimization/87325] determine_base_object does not consider consider address space of base expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87325
--- Comment #3 from rguenther at suse dot de ---
On Tue, 18 Sep 2018, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87325
>
> --- Comment #2 from bin cheng ---
> Seems alloc_iv doesn't infer base object correctly:
> /* Lower address expression in base except ones with DECL_P as operand.
> By doing this:
>1) More accurate cost can be computed for address expressions;
>2) Duplicate candidates won't be created for bases in different
> forms, like &a[0] and &a. */
> STRIP_NOPS (expr);
> if ((TREE_CODE (expr) == ADDR_EXPR && !DECL_P (TREE_OPERAND (expr, 0)))
> || contain_complex_addr_expr (expr))
> {
> aff_tree comb;
> tree_to_aff_combination (expr, TREE_TYPE (expr), &comb);
> base = fold_convert (TREE_TYPE (base), aff_combination_to_tree (&comb));
> }
>
> iv->base = base;
> iv->base_object = determine_base_object (base);
>
> Given:
> (gdb) call debug_generic_expr(expr)
> &ts[1].y
>
> in which "ts" is a VAR_DECL in specific address space:
> (gdb) call debug_generic_expr(*addr_p)
> ts
> (gdb) p (*addr_p)->base.code
> $8 = VAR_DECL
> (gdb) p (*addr_p)->typed.type->base.u.bits.address_space
> $10 = 7
>
> Question is, should be build appropriate pointer type for "ts[1].y", for now,
> base = build_fold_addr_expr (base);
> returns:
> (gdb) call debug_generic_expr(base)
> &ts[1].y
> (gdb) call debug_generic_expr(base->typed.type)
> float *
I think build_fold_addr_expr handles things correctly since it uses
built_pointer_type which should handle address-spaces correctly.
The question is probably whether ts[1].y has the proper address-space
qualified type (which IIRC it doesn't ...). So we'd need sth
like ref_alias_ptr_type - a ref_addr_space () we can use to extract
the address-space from an object and transfer that properly in
build_fold_addr_expr (and elsewhere we run into this issue). Whereever
RTL expansion takes the address-space from is probably the code to
mimic in said new API.
[Bug c/87345] New: The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87345
Bug ID: 87345
Summary: The compiler of the old version (for example: 4.9.3
version or 6.3.0 version) can stop the infinite
cross-border loop, but the new version does not work.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jingtian at loongson dot cn
Target Milestone: ---
Created attachment 44713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44713&action=edit
this is *.i file
Hello, in fact, I don't know if this is a bug, or I don't know if the old
version of GCC can be tolerated, but the new version of GCC has the most
stringent requirements to have such a phenomenon. Since I started to forget to
forget to provide the return value in the void* type of function, but I am
compiling on a lower version of GCC, I tried versions 4.9 and 6.3. There was no
problem at this time, but when I used the newer versions 8.1 and 8.2, it
prompted me to have a Segmentation fault (core dumped).
If I normalize my writing, such as changing void* to void, or adding a return
NULL to the void* type of function, this problem can be solved.
Below is my gcc version information（This is how I made a docker on the mips
machine with a debain system installed.Similarly, I will use gcc 8.1.0 on
fedora28 to have the same situation.）
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips64el-linux-gnuabi64/8/lto-wrapper
Target: mips64el-linux-gnuabi64
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=mips64el-linux-gnuabi64- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-multilib
--with-mips-plt --with-arch-64=mips64r2 --with-madd4=no --enable-targets=all
--with-arch-32=mips32r2 --with-fp-32=xx --enable-checking=release
--build=mips64el-linux-gnuabi64 --host=mips64el-linux-gnuabi64
--target=mips64el-linux-gnuabi64
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-4)
The GCC compile command I am using is :
gcc -g -O3 -o demotest demotest.cpp
（The same use of O1 O2 O3 will have problems, but do not choose the
optimization option, only the -o option, there will be no such situation）
Here is my code：
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include "ctype.h"
void *strlwr(char *str)
{
for(; *str!='\0'; str++)
{
*str = tolower(*str);
}
//return NULL;
}
int main()
{
char res[20];
char a[20]="ABCDEFGhijklmn";
memset(res,'\0',20*sizeof(char));
strcpy(res,a);
printf("%s\n",res);
strlwr(res);
printf("%s\n",res);
return 0;
}
This is the information that was reported during execution：
ABCDEFGhijklmn
Segmentation fault (core dumped)
I am seeing the instructions on the website, saying that this infinite loop
problem can be avoided by adding the -fno-aggressive-loop-optimizations option,
but I added this to the compile option, but it still doesn't work.
I just started to be a developer. My English is not particularly good. I have
seen the needs of the website for a long time. I don't know if I qualified to
submit this small question. If there is no good place to do it, I I am very
sorry, increasing your workload.
[Bug c/87345] The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87345
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
>void *strlwr(char *str)
> {
...
> //return NULL;
> }
This is the issue and not anything else.
In C++ (unlike C), falling through to return where there is a return type is
undefined code at that point.
(In C, it is undefined if the return value was used).
[Bug c++/87345] The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87345 Andrew Pinski changed: What|Removed |Added Component|c |c++ --- Comment #2 from Andrew Pinski --- >gcc -g -O3 -o demotest demotest.cpp That is a C++ program rather than a C program.
[Bug c/87346] New: The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87346
Bug ID: 87346
Summary: The compiler of the old version (for example: 4.9.3
version or 6.3.0 version) can stop the infinite
cross-border loop, but the new version does not work.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jingtian at loongson dot cn
Target Milestone: ---
Hello, in fact, I don't know if this is a bug, or I don't know if the old
version of GCC can be tolerated, but the new version of GCC has the most
stringent requirements to have such a phenomenon. Since I started to forget to
forget to provide the return value in the void* type of function, but I am
compiling on a lower version of GCC, I tried versions 4.9 and 6.3. There was no
problem at this time, but when I used the newer versions 8.1 and 8.2, it
prompted me to have a Segmentation fault (core dumped).
If I normalize my writing, such as changing void* to void, or adding a return
NULL to the void* type of function, this problem can be solved.
Below is my gcc version information（This is how I made a docker on the mips
machine with a debain system installed.Similarly, I will use gcc 8.1.0 on
fedora28 to have the same situation.）
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/mips64el-linux-gnuabi64/8/lto-wrapper
Target: mips64el-linux-gnuabi64
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=mips64el-linux-gnuabi64- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-multilib
--with-mips-plt --with-arch-64=mips64r2 --with-madd4=no --enable-targets=all
--with-arch-32=mips32r2 --with-fp-32=xx --enable-checking=release
--build=mips64el-linux-gnuabi64 --host=mips64el-linux-gnuabi64
--target=mips64el-linux-gnuabi64
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-4)
The GCC compile command I am using is :
gcc -g -O3 -o demotest demotest.cpp
（The same use of O1 O2 O3 will have problems, but do not choose the
optimization option, only the -o option, there will be no such situation）
Here is my code：
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include "ctype.h"
void *strlwr(char *str)
{
for(; *str!='\0'; str++)
{
*str = tolower(*str);
}
//return NULL;
}
int main()
{
char res[20];
char a[20]="ABCDEFGhijklmn";
memset(res,'\0',20*sizeof(char));
strcpy(res,a);
printf("%s\n",res);
strlwr(res);
printf("%s\n",res);
return 0;
}
This is the information that was reported during execution：
ABCDEFGhijklmn
Segmentation fault (core dumped)
I am seeing the instructions on the website, saying that this infinite loop
problem can be avoided by adding the -fno-aggressive-loop-optimizations option,
but I added this to the compile option, but it still doesn't work.
I just started to be a developer. My English is not particularly good. I have
seen the needs of the website for a long time. I don't know if I qualified to
submit this small question. If there is no good place to do it, I I am very
sorry, increasing your workload.
[Bug target/87288] [8/9 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288
Richard Biener changed:
What|Removed |Added
Known to work||7.3.1
Target Milestone|--- |8.3
Summary|Segfault after const_cast |[8/9 Regression] Segfault
|with "-O2 |after const_cast with "-O2
|-ftree-loop-vectorize" but |-ftree-loop-vectorize" but
|_without_ "-mavx" |_without_ "-mavx"
Known to fail||8.2.1
--- Comment #5 from Richard Biener ---
-fno-tree-bit-ccp happens to fix the bug but it looks latent (same bogus
value-range). Value-ranges appear from DOM and the [1, ...] one first appears
with the
vect pass:
t.C.160t.ifcvt: # RANGE ~[2147483648, 18446744071562067967]
t.C.160t.ifcvt: # RANGE [0, 18446744073709551600]
t.C.160t.ifcvt: # RANGE [-2147483647, 2147483647]
t.C.161t.vect: # RANGE [1, 2147483647] NONZERO 2147483647
t.C.161t.vect: # RANGE ~[2147483648, 18446744071562067967]
t.C.161t.vect: # RANGE [0, 18446744073709551600]
t.C.161t.vect: # RANGE [-2147483647, 2147483647]
t.C.161t.vect: # RANGE ~[2147483648, 18446744071562067967]
t.C.161t.vect: # RANGE [0, 18446744073709551600]
t.C.161t.vect: # RANGE [-2147483647, 2147483647]
it's set here:
if (!is_gimple_val (niters_vector))
{
var = create_tmp_var (type, "bnd");
gimple_seq stmts = NULL;
niters_vector = force_gimple_operand (niters_vector, &stmts, true, var);
gsi_insert_seq_on_edge_immediate (pe, stmts);
/* Peeling algorithm guarantees that vector loop bound is at least ONE,
we set range information to make niters analyzer's life easier. */
if (stmts != NULL && log_vf)
set_range_info (niters_vector, VR_RANGE,
wi::to_wide (build_int_cst (type, 1)),
wi::to_wide (fold_build2 (RSHIFT_EXPR, type,
TYPE_MAX_VALUE (type),
log_vf)));
and the loop is
[local count: 105119325]:
niters.0_25 = (unsigned int) n_15;
ni_gap.1_36 = niters.0_25 + 4294967295;
# RANGE [1, 2147483647] NONZERO 2147483647
bnd.2_37 = ni_gap.1_36 >> 1;
[local count: 567644349]:
# ivtmp_50 = PHI
ivtmp_51 = ivtmp_50 + 1;
if (ivtmp_51 >= bnd.2_37)
goto ; [16.67%]
else
goto ; [83.33%]
[local count: 473036958]:
goto ; [100.00%]
which looks good according to the comment. So the number of iterations
_is_ bnd.2_37 - 1 (that number may be zero).
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.3
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 Richard Biener changed: What|Removed |Added Keywords||build Target||ia64-*-* CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Does it work with GCC 7.3.0?
[Bug c/87346] The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87346 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Again this has nothing to do with the loop but rather the return value. If you want to detect this at runtime, you can use -fsantize=undefined . *** This bug has been marked as a duplicate of bug 87345 ***
[Bug tree-optimization/87342] [9 Regression] ICE: verify_ssa failed (error: definition in block 10 does not dominate use in block 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87342 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-18 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug c++/87345] The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87345 --- Comment #3 from Andrew Pinski --- *** Bug 87346 has been marked as a duplicate of this bug. ***
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #5 from Andrew Pinski --- (In reply to mi+gcc from comment #4) > (In reply to Andrew Pinski from comment #3) > > This is a binutils bug, in gold. > > --enable-gold > > > > Please report this to binutils instead. > > Is there a work-around, perhaps? Maybe you will get a better answer over at the binutils bugzilla. Do you know what version of binutils you are using? Maybe test out the latest release.
[Bug c/87347] ICE in warn_for_abs at gcc/c/c-parser.c:9226 since r264368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-18 CC||jamborm at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug c/87347] New: ICE in warn_for_abs at gcc/c/c-parser.c:9226 since r264368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347
Bug ID: 87347
Summary: ICE in warn_for_abs at gcc/c/c-parser.c:9226 since
r264368
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
Target Milestone: ---
I see some ICEs happening:
$ cat ice.i
int a;
int abs();
void b() { abs(a); }
$ gcc ice.i -Wabsolute-value -c
ice.i: In function ‘b’:
ice.i:3:1: internal compiler error: Segmentation fault
3 | void b() { abs(a); }
| ^~~~
0xce366f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f2113 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3112
0x7f2113 warn_for_abs
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9226
0x7f2113 c_parser_postfix_expression_after_primary
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9318
0x7e1c47 c_parser_postfix_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9006
0x7ebb82 c_parser_unary_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7266
0x7ec9ff c_parser_cast_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7110
0x7ecc73 c_parser_binary_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6913
0x7edb35 c_parser_conditional_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6647
0x7ee160 c_parser_expr_no_commas
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6564
0x7ee3b2 c_parser_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9460
0x7f0476 c_parser_expression_conv
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9493
0x7fc170 c_parser_statement_after_labels
/home/marxin/Programming/gcc/gcc/c/c-parser.c:5542
0x7fdf7e c_parser_compound_statement_nostart
/home/marxin/Programming/gcc/gcc/c/c-parser.c:5080
0x7fe6c6 c_parser_compound_statement
/home/marxin/Programming/gcc/gcc/c/c-parser.c:4914
0x7ffdb4 c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2342
0x80675f c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1643
0x806f99 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1524
0x806f99 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:18538
$ cat ice.c
void a(void) { abs(0); }
$ gcc -Wabsolute-value ice.c -c
ice.c: In function ‘a’:
ice.c:1:16: warning: implicit declaration of function ‘abs’
[-Wimplicit-function-declaration]
1 | void a(void) { abs(0); }
|^~~
ice.c:1:1: internal compiler error: Segmentation fault
1 | void a(void) { abs(0); }
| ^~~~
0xce366f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f2113 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3112
0x7f2113 warn_for_abs
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9226
0x7f2113 c_parser_postfix_expression_after_primary
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9318
0x7e1c47 c_parser_postfix_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9006
0x7ebb82 c_parser_unary_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7266
0x7ec9ff c_parser_cast_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:7110
0x7ecc73 c_parser_binary_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6913
0x7edb35 c_parser_conditional_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6647
0x7ee160 c_parser_expr_no_commas
/home/marxin/Programming/gcc/gcc/c/c-parser.c:6564
0x7ee3b2 c_parser_expression
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9460
0x7f0476 c_parser_expression_conv
/home/marxin/Programming/gcc/gcc/c/c-parser.c:9493
0x7fc170 c_parser_statement_after_labels
/home/marxin/Programming/gcc/gcc/c/c-parser.c:5542
0x7fdf7e c_parser_compound_statement_nostart
/home/marxin/Programming/gcc/gcc/c/c-parser.c:5080
0x7fe6c6 c_parser_compound_statement
/home/marxin/Programming/gcc/gcc/c/c-parser.c:4914
0x7ffdb4 c_parser_declaration_or_fndef
/home/marxin/Programming/gcc/gcc/c/c-parser.c:2342
0x80675f c_parser_external_declaration
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1643
0x806f99 c_parser_translation_unit
/home/marxin/Programming/gcc/gcc/c/c-parser.c:1524
0x806f99 c_parse_file()
/home/marxin/Programming/gcc/gcc/c/c-parser.c:18538
[Bug c++/87345] The compiler of the old version (for example: 4.9.3 version or 6.3.0 version) can stop the infinite cross-border loop, but the new version does not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87345 --- Comment #4 from jingtian at loongson dot cn --- (In reply to Andrew Pinski from comment #3) > *** Bug 87346 has been marked as a duplicate of this bug. *** It might be because of the network, I submitted twice, sorry
[Bug c/87344] archival/libarchive/decompress_gunzip.c:1139:2: error: size of unnamed array is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87344 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 CC||rguenth at gcc dot gnu.org Version|6.4.1 |6.2.0 Ever confirmed|0 |1 Known to fail||6.2.0, 6.4.0, 7.2.0 --- Comment #3 from Richard Biener --- Confirmed with your gazillion command line flags, works fine with plain -Os. Maybe you can remove the ones not necessary, it's hard to see if there's a stupid user error.
[Bug target/87196] ICE in vectorizable_load, at tree-vect-stmts.c:8043
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87196 --- Comment #1 from Martin Liška --- May I please ping this, can anybody reproduce that?
[Bug target/87344] archival/libarchive/decompress_gunzip.c:1139:2: error: size of unnamed array is negative, -mms-bitfields influences non-bitfield struct layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87344
Richard Biener changed:
What|Removed |Added
Keywords||ABI
Target||x86_64-*-*, i?86-*-*
CC|rguenth at gcc dot gnu.org |
Component|c |target
Summary|archival/libarchive/decompr |archival/libarchive/decompr
|ess_gunzip.c:1139:2: error: |ess_gunzip.c:1139:2: error:
|size of unnamed array is|size of unnamed array is
|negative|negative, -mms-bitfields
||influences non-bitfield
||struct layout
--- Comment #4 from Richard Biener ---
It's -mms-bitfields which appearantly influences layout of the following
struct:
union {
unsigned char raw[8];
struct {
uint8_t gz_method;
uint8_t flags;
uint32_t mtime;
uint8_t xtra_flags_UNUSED;
uint8_t os_flags_UNUSED;
} __attribute__ ((__packed__)) formatted;
} header;
((void)sizeof(char[1 - 2*!!(sizeof(header) != 8)]));
Not sure if the difference is intended.
[Bug target/87344] archival/libarchive/decompress_gunzip.c:1139:2: error: size of unnamed array is negative, -mms-bitfields influences non-bitfield struct layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87344 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Martin Liška --- Fixed in r258075, thus dup. *** This bug has been marked as a duplicate of bug 52991 ***
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Martin Liška changed: What|Removed |Added CC||yellowriver2010 at hotmail dot com --- Comment #35 from Martin Liška --- *** Bug 87344 has been marked as a duplicate of this bug. ***
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Is the input a valid C++ mangled name of not?
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Is the input a valid C++ mangled name of not?
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Is the input a valid C++ mangled name of not?
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-18 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- Confirmed and mine. Sorry about that, I only tested a previous iteration of the patch on non-x86_64 systems.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #15 from Martin Liška --- Ok, I played with that a bit. It would be possible to optimize the code, but before I see some significant speed up I'm not interested enough.
[Bug c/87348] Implement -Watomic-implicit-seq-cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87348 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Severity|normal |enhancement
[Bug c/87348] New: Implement -Watomic-implicit-seq-cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87348 Bug ID: 87348 Summary: Implement -Watomic-implicit-seq-cst Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Maybe we would like to implement the same warning as LLVM: https://reviews.llvm.org/rL341860
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #2 from Cheng Wen --- (In reply to Martin Liška from comment #1) > Is the input a valid C++ mangled name of not? Hi, This input is obtained through fuzzing technology. Our fuzzer get some test cases by mutating a valid input. This can not guarantee that this is a valid C++ mangled name. The program c++filt accepts the test case I uploaded. And this test case can prove that c++filt have problems. When program c++filt executing this input, a stack-overflow problem occurs. Please check this input and try to fix this bug if necessary. Thank you very much.
[Bug tree-optimization/87349] New: [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87349
Bug ID: 87349
Summary: [9 Regression] ICE: Segmentation fault (in
useless_type_conversion_p or is_gimple_reg_type)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180916 snapshot (r264351) ICEs when compiling the following
snippets w/ -O1 or -Og:
1.
void
h1 (int *fh, int pw)
{
*fh = 0;
if (*fh != 0)
for (;;)
{
fh = &pw;
if (pw == 0)
{
}
else
while (pw < 1)
{
if (pw == 0)
{
ut:
;
}
++pw;
}
if (pw == *fh)
goto ut;
}
goto ut;
}
% gcc-9.0.0-alpha20180916 -O1 -c nshv93ku.c
during GIMPLE pass: fre
nshv93ku.c: In function 'h1':
nshv93ku.c:30:1: internal compiler error: Segmentation fault
30 | }
| ^
0xcc84df crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/toplev.c:325
0xa296f0 useless_type_conversion_p(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/gimple-expr.c:70
0xd0149c verify_gimple_assign_single
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:4390
0xd0149c verify_gimple_assign
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:4612
0xd0149c verify_gimple_stmt
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:4880
0xd107b3 verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:5358
0xbe74af execute_function_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1943
0xbe839e execute_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1997
2.
--- nshv93ku.c.jj 2018-09-18 15:40:38.439857690 +0700
+++ nshv93ku.c 2018-09-18 15:40:59.678335059 +0700
@@ -22,7 +22,7 @@ h1 (int *fh, int pw)
++pw;
}
-if (pw == 0)
+if (pw == *fh)
goto ut;
}
during GIMPLE pass: fre
nshv93ku.c: In function 'h1':
nshv93ku.c:30:1: internal compiler error: Segmentation fault
30 | }
| ^
0xcc84df crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/toplev.c:325
0xa2abc1 is_gimple_reg_type
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/gimple-expr.h:75
0xa2abc1 is_gimple_val(tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/gimple-expr.c:789
0xd1044a verify_gimple_phi
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:4975
0xd1044a verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/tree-cfg.c:5303
0xbe74af execute_function_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1943
0xbe839e execute_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180916/work/gcc-9-20180916/gcc/passes.c:1997
[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55588 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2017-08-21 00:00:00 |2018-9-18 --- Comment #5 from Jonathan Wakely --- G++ and Clang still accept this, EDG still rejects it.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 --- Comment #2 from Jonathan Wakely --- No. None of them look valid.
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #2 from Cheng Wen --- (In reply to Martin Liška from comment #1) > Is the input a valid C++ mangled name of not? Hi, This input is obtained through fuzzing technology. Our fuzzer get some test cases by mutating a valid input. This can not guarantee that this is a valid C++ mangled name. The program c++filt accepts the test case I uploaded. And this test case can prove that c++filt have problems. When program c++filt executing this input, a stack-overflow problem occurs. Please check this input and try to fix this bug if necessary. Thank you very much.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #3 from Jonathan Wakely --- No, it's not a valid name. I can't reproduce a crash using the latest code from GCC though.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 --- Comment #3 from Martin Liška --- Then it would deserve something like segfault-on-invalid-input :) Or should I use ice-on-invalid-code?
[Bug c++/81880] thread_local static member template initialisation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
Latimerius changed:
What|Removed |Added
CC||latimerius at seznam dot cz
--- Comment #2 from Latimerius ---
This bug still seems to exist in the current 9.0 HEAD. Note also that another
possible work-around might be to wrap the thread_local member in an accessor
function, along the lines of
class A {
public:
template
std::unordered_map & get_m ()
{
thread_local static std::unordered_map m;
return m;
}
};
[Bug gcov-profile/85871] [8 Regression] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 --- Comment #13 from Martin Liška --- Author: marxin Date: Tue Sep 18 09:32:09 2018 New Revision: 264387 URL: https://gcc.gnu.org/viewcvs?rev=264387&root=gcc&view=rev Log: Backport r264363 2018-09-18 Martin Liska Backport from mainline 2018-09-17 Martin Liska PR gcov-profile/85871 * gcov.c (output_intermediate_file): Fix out of bounds access. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gcov.c
[Bug c/87347] ICE in warn_for_abs at gcc/c/c-parser.c:9226 since r264368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347 --- Comment #1 from Martin Jambor --- Bah, I should have thought about this. The following will fix it, I'll properly test it and submit a patch later this week. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 1766a256633..a96d15fef1d 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -9116,9 +9116,10 @@ warn_for_abs (location_t loc, tree fndecl, tree arg) -Wint-conversion warnings. Most other wrong types hopefully lead to type mismatch errors. TODO: Think about what to do with FIXED_POINT_TYPE_P types and possibly other exotic types. */ - if (!INTEGRAL_TYPE_P (atype) - && !SCALAR_FLOAT_TYPE_P (atype) - && TREE_CODE (atype) != COMPLEX_TYPE) + if ((!INTEGRAL_TYPE_P (atype) + && !SCALAR_FLOAT_TYPE_P (atype) + && TREE_CODE (atype) != COMPLEX_TYPE) + || !TYPE_ARG_TYPES (TREE_TYPE (fndecl))) return; enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
[Bug c++/87350] New: NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Bug ID: 87350 Summary: NULL-Pointer problem in cplus-dem.c when executing program c++filt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wcventure at 126 dot com Target Milestone: --- Hi, Our fuzzer caught NULL-Pointer problems in c++filt of the latest binutils code base, those inputs will cause the segment faults and I have confirmed them with address sanitizer. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. The ASAN dumps the stack trace as follows on POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/npd_r_cplus-dem.c:1345_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==23610==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f67702435a1 bp 0x7ffe2a376680 sp 0x7ffe2a375e08 T0) ==23610==The signal is caused by a READ memory access. ==23610==Hint: address points to the zero page. #0 0x7f67702435a0 /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59 #1 0x49728c in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x49728c) #2 0x8c9caa in work_stuff_copy_to_from /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1345:17 #3 0x8c553c in iterate_demangle_function /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2731:3 #4 0x8b77ec in demangle_prefix /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2971:14 #5 0x8b2d00 in internal_cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1253:14 #6 0x8afe53 in cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:918:9 #7 0x513dd5 in demangle_it /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:62:12 #8 0x5139c9 in main /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:276:4 #9 0x7f67700d6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #10 0x41a989 in _start (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x41a989) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59 ==23610==ABORTING The ASAN dumps the stack trace as follows on POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/npd_r_cplus-dem.c:1360_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==23847==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x008ca218 bp 0x7ffe44bfad50 sp 0x7ffe44bfaa10 T0) ==23847==The signal is caused by a READ memory access. ==23847==Hint: address points to the zero page. #0 0x8ca217 in work_stuff_copy_to_from /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1360:25 #1 0x8c553c in iterate_demangle_function /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2731:3 #2 0x8b77ec in demangle_prefix /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2971:14 #3 0x8b2d00 in internal_cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1253:14 #4 0x8afe53 in cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:918:9 #5 0x513dd5 in demangle_it /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:62:12 #6 0x5139c9 in main /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:276:4 #7 0x7ff52abf2b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #8 0x41a989 in _start (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x41a989) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1360:25 in work_stuff_copy_to_from ==23847==ABORTING
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #1 from Cheng Wen --- Created attachment 44714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44714&action=edit POC1
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #2 from Cheng Wen --- Created attachment 44715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44715&action=edit POC2
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- Are you sure you attached the right file? When I try to demangle the attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the name is not valid. That seems like the right result.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- The __cxa_demangle function returns 2 for each of these testcases, but the cplus_demangle function segfaults.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #5 from Cheng Wen --- (In reply to Jonathan Wakely from comment #4) > Are you sure you attached the right file? When I try to demangle the > attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the > name is not valid. That seems like the right result. I have tried to reproduce this bug on different machines. There are some questions to be confirmed. (1) Do you use the latest version of binutils(binutils-2.32/binutils-2.31)? I downloaded the package from here. https://www.gnu.org/software/binutils/ (2) Please confirm that you have used the option "-t". The command should be "./c++filt -t < $POC" (3) Do you confirm this POC with address sanitizer?
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #13 from Manuel López-Ibáñez --- This may be another case where it is worth it to print the inline stack AND silence a warning whose inline stack is within pragma GCC diagnostics. However, there seems to be another kind of missed optimization going on here.
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #3 from Cheng Wen --- Created attachment 44716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44716&action=edit POC1 I have the new POC to add. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_1 The ASAN dumps the stack trace as follows on POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==24028==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd854a7e18 (pc 0x00497287 bp 0x7ffd854a8690 sp 0x7ffd854a7e20 T0) #0 0x497286 in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) #1 0x8bdc7e in string_append /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4960:7 #2 0x8cb7f5 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4578:7 #3 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #4 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #5 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 ... ... ... #244 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #245 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 #246 0x8cc7b4 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4659:9 #247 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #248 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #249 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 SUMMARY: AddressSanitizer: stack-overflow (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) in __interceptor_strlen.part.30 ==24028==ABORTING
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #4 from Cheng Wen --- Created attachment 44717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44717&action=edit POC2 I have the new POC to add. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_2 The ASAN dumps the stack trace as follows on POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_2.err.txt AddressSanitizer:DEADLYSIGNAL = ==24101==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcd22d1fd8 (pc 0x00497287 bp 0x7ffcd22d2850 sp 0x7ffcd22d1fe0 T0) #0 0x497286 in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) #1 0x8bdc7e in string_append /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4960:7 #2 0x8cb7f5 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4578:7 #3 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #4 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #5 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 ... ... ... #245 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 #246 0x8cc7b4 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4659:9 #247 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #248 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #249 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 SUMMARY: AddressSanitizer: stack-overflow (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) in __interceptor_strlen.part.30 ==24101==ABORTING
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #6 from Jonathan Wakely --- (In reply to Cheng Wen from comment #5) > (In reply to Jonathan Wakely from comment #4) > > Are you sure you attached the right file? When I try to demangle the > > attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the > > name is not valid. That seems like the right result. > > I have tried to reproduce this bug on different machines. > There are some questions to be confirmed. > > (1) Do you use the latest version of binutils(binutils-2.32/binutils-2.31)? > I downloaded the package from here. > https://www.gnu.org/software/binutils/ Built from the binutils-gdb git repo: $ /tmp/binutils/bin/c++filt -v GNU c++filt (GNU Binutils) 2.31.51.20180918 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. > (2) Please confirm that you have used the option "-t". > The command should be "./c++filt -t < $POC" $ /tmp/binutils/bin/c++filt -t < POC-t | wc 0 1 26539 $ echo $? 0 > (3) Do you confirm this POC with address sanitizer? Yes it's linked to libasan $ ldd /tmp/binutils/bin/c++filt linux-vdso.so.1 (0x7fff0618b000) libasan.so.4 => /lib64/libasan.so.4 (0x7fc372241000) libdl.so.2 => /lib64/libdl.so.2 (0x7fc37203d000) libc.so.6 => /lib64/libc.so.6 (0x7fc371c87000) librt.so.1 => /lib64/librt.so.1 (0x7fc371a7f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7fc371861000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7fc3714d9000) libm.so.6 => /lib64/libm.so.6 (0x7fc37118e000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fc370f77000) /lib64/ld-linux-x86-64.so.2 (0x7fc3731f9000)
[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED Summary|[8 Regression] |g++.dg/gcov/gcov-8.C random |g++.dg/gcov/gcov-8.C random |failures |failures| Known to fail|8.2.0 | --- Comment #14 from Martin Liška --- Fixed on all active branches.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- (In reply to Cheng Wen from comment #1) > Created attachment 44714 [details] > POC1 You've uploaded two complete HTML pages saved from github, but the mangled name that crash are just: _GLOBAL_$D$__tf30___0__ __thunk_0__0__$__H1 $ echo '_GLOBAL_$D$__tf30___0__' | /tmp/binutils/bin/c++filt ASAN:DEADLYSIGNAL = ==6977==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f5fbbb47f31 bp 0x7fff4a202c20 sp 0x7fff4a202398 T0) ==6977==The signal is caused by a READ memory access. ==6977==Hint: address points to the zero page. #0 0x7f5fbbb47f30 in __strlen_avx2 (/lib64/libc.so.6+0x155f30) #1 0x7f5fbbffd27b (/lib64/libasan.so.4+0x5127b) #2 0x497e34 in work_stuff_copy_to_from /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1345 #3 0x49cdd8 in iterate_demangle_function /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2731 #4 0x49d962 in demangle_prefix /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2971 #5 0x49d962 in internal_cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1253 #6 0x498860 in cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:918 #7 0x402ea5 in demangle_it (/tmp/binutils/bin/c++filt+0x402ea5) #8 0x4037af in main (/tmp/binutils/bin/c++filt+0x4037af) #9 0x7f5fbba12fe9 in __libc_start_main (/lib64/libc.so.6+0x20fe9) #10 0x402d29 in _start (/tmp/binutils/bin/c++filt+0x402d29) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x155f30) in __strlen_avx2 ==6977==ABORTING wraith:tmp$ echo '__thunk_0__0__$__H1' | /tmp/binutils/bin/c++filt ASAN:DEADLYSIGNAL = ==6981==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x00497f27 bp 0x7ffc897891e0 sp 0x7ffc89789170 T0) ==6981==The signal is caused by a READ memory access. ==6981==Hint: address points to the zero page. #0 0x497f26 in work_stuff_copy_to_from /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1358 #1 0x49cdd8 in iterate_demangle_function /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2731 #2 0x49d962 in demangle_prefix /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2971 #3 0x49d962 in internal_cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1253 #4 0x498860 in cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:918 #5 0x402ea5 in demangle_it (/tmp/binutils/bin/c++filt+0x402ea5) #6 0x4037af in main (/tmp/binutils/bin/c++filt+0x4037af) #7 0x7ff5a9a18fe9 in __libc_start_main (/lib64/libc.so.6+0x20fe9) #8 0x402d29 in _start (/tmp/binutils/bin/c++filt+0x402d29) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1358 in work_stuff_copy_to_from ==6981==ABORTING
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #7 from Cheng Wen --- (In reply to Jonathan Wakely from comment #6) Considering the memory size of different machines, maybe more 'P' is needed to trigger this bug in the input.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #8 from Jonathan Wakely --- It still works for up to ten million characters: $ for i in `seq 1 10` ; do printf P ; done | /tmp/binutils/bin/c++filt -t ; echo PP $ for i in `seq 1 100` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 100 $ for i in `seq 1 1000` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 11000 $ for i in `seq 1 1` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 1 $ for i in `seq 1 10` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 10 $ for i in `seq 1 100` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 100 $ for i in `seq 1 1000` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 1000
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #4 from Cheng Wen --- Yes. One input test case is "_GLOBAL_$D$__tf30___0__". Another input test case is "__thunk_0__0__$__H1". I see that you can you can reproduce this error. Do you know the reason for this bug?
[Bug c++/54052] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54052 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2017-08-22 00:00:00 |2018-9-18 CC|redi at gcc dot gnu.org| --- Comment #9 from Jonathan Wakely --- Compiles successfully using i686-pc-linux-gnu, but takes a long time. As I said, it's an unreasonably large expression (3883 lines!) so that's not surprising. Don't write silly code if you don't have enough memory to compile it. I tried compiling it with Clang and it crashes.
[Bug tree-optimization/87342] [9 Regression] ICE: verify_ssa failed (error: definition in block 10 does not dominate use in block 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87342 --- Comment #2 from Richard Biener --- Thanks, that's another case similar to PR87263 where we cannot use dominated_by_p_w_unex. But I think the error is in computation of max_rpo for BB 15 which is 6 instead of 13. Because we're supposed to mark the respective edges executable. Needs more thinking.
[Bug preprocessor/87351] New: misleading error message: missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87351
Bug ID: 87351
Summary: misleading error message: missing binary operator
before token "("
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The error message
error: missing binary operator before token "("
from the preprocessor is misleading in general, as in most cases, it is not a
binary operator that is missing, but the error is due to the use of sizeof, a
cast, or a function-like macro that is not defined. The preprocessor could
either output a fixed error message that would reflect the most common
misusages, or try to guess what is wrong (like the use of sizeof or something
that looks like a cast).
For instance:
$ cat tst.c
#if sizeof(int) > 4
#endif
$ gcc-snapshot -E tst.c
# 1 "tst.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "tst.c"
tst.c:1:11: error: missing binary operator before token "("
1 | #if sizeof(int) > 4
| ^
Some users can get confused. For instance, see:
*
https://stackoverflow.com/questions/21338385/what-does-the-compiler-error-missing-binary-operator-before-token-mean
*
https://cboard.cprogramming.com/c-programming/158452-error-missing-binary-operator-before-token.html
*
https://www.linuxquestions.org/questions/programming-9/missing-binary-operator-before-token-4175547706/
* https://forum.kde.org/viewtopic.php?f=269&t=128141
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 --- Comment #3 from Jason Duerstock --- Yes. From the Debian build log: https://buildd.debian.org/status/fetch.php?pkg=gcc-7&arch=ia64&ver=7.3.0-29&stamp=1536161281&raw=0
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- I have a patch.
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2018-09-17 00:00:00 |2018-09-18 Assignee|unassigned at gcc dot gnu.org |siddhesh at gotplt dot org Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Assigning.
[Bug preprocessor/87351] misleading error message: missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87351 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1
[Bug fortran/87352] New: Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 Bug ID: 87352 Summary: Large stack usage with new gfortran Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeremy at jeremysanders dot net Target Milestone: --- Created attachment 44718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44718&action=edit Affected module and example main program With gcc/gfortran 7.3 and 8.2, creation of a variable in the main program with a particular type defined in a module (attached) leads to a segfault due to very large stack usage. This worked on gcc 4.8.4 and earlier versions. In addition compilation of the module creates an object file which is x1 times larger than for earlier gcc versions (200MB vs 25KB). With optimization (-O2), the compilation time is several minutes, rather than less than a second. Instructions for compilation: $ gfortran -ffixed-line-length-none -ffree-line-length-none -g -O2 -o testcomb testcomb.f90 testcomb.f90:1303:0: end module testmodule note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without $ ./testcomb $ gdb ./testcomb GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git ... (gdb) run Starting program: /home/jsanders/tmp/foo/testcomb Program received signal SIGSEGV, Segmentation fault. testprog () at testcomb.f90:1309 1309 type(instlist_type),target:: instlist It works if the stack is increased to 819200. This problem is seen using Ubuntu Bionic (18.04) on x86-64, using the built-in gcc (7.3.0), or a self-compiled version (8.2.0) with no special build options.
[Bug other/87353] New: gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353
Bug ID: 87353
Summary: gcc man page formatting issue due to leading spaces in
.texi contents
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The gcc(1) man page (gcc.1) shows as:
Therefore, the G++ and driver automatically adds -shared-libgcc
whenever you build a shared library or a main executable, because
C++
programs typically use exceptions, so this is the right thing to
do.
This is due to gcc/doc/invoke.texi containing leading spaces:
Therefore, the G++ and driver automatically adds @option{-shared-libgcc}
whenever you build a shared library or a main executable, because C++
programs typically use exceptions, so this is the right thing to do.
Removing these spaces should solve the problem (I haven't checked other parts
of the manual), but AFAIK, such spaces are valid and do not yield any issue in
generated .info files. Thus the real bug could be in conversion utilities
(contrib/texi2pod.pl, provided by GCC, or pod2man).
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #1 from Vincent Lefèvre --- The bug may be in contrib/texi2pod.pl as the following pod text is generated: Therefore, the G++ and driver automatically adds B<-shared-libgcc> whenever you build a shared library or a main executable, because C++ programs typically use exceptions, so this is the right thing to do. and the pod specification says: "A verbatim paragraph is distinguished by having its first character be a space or a tab."
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #9 from Cheng Wen --- (In reply to Jonathan Wakely from comment #8) Hi Jonathan, I debugged with this POC again. I still think it's a problem. I will show you the debug process as follow. > $ gdb ./c++filt > Reading symbols from ./c++filt...done. > (gdb) set args -t < POC-t > (gdb) b cp-demangle.c:2565 > Breakpoint 1 at 0x8d5227: file ./cp-demangle.c, line 2565. > (gdb) start > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > ... > ... > ... > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > (gdb) bt > #0 cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > #1 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #2 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #3 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #4 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > ... > ... > ... > #456 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #457 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #458 0x008dd318 in d_demangle_callback (mangled=0x18b2e40 > 'P' ..., options=283, > callback=0x8dc110 , > opaque=0x7fffd860) at ./cp-demangle.c:6245 > #459 0x008dc84f in d_demangle (mangled=0x18b2e40 'P' > ..., options=283, > palc=0x7fffd9e0) at ./cp-demangle.c:6299 > #460 0x008dc696 in cplus_demangle_v3 (mangled=0x18b2e40 > 'P' ..., options=283) > at ./cp-demangle.c:6456 > #461 0x008b1cf4 in cplus_demangle (mangled=0x18b2e40 > 'P' ..., options=27) > at ./cplus-dem.c:880 > #462 0x00517676 in demangle_it (mangled_name=0x18b2e40 > 'P' ...) at cxxfilt.c:62 > #463 0x0051726a in main (argc=2, argv=0x7fffe008) at cxxfilt.c:276 Using gdb to debug it. I set a breakpoint in cp-demangle.c:2565. After reaching this breakpoint for any time. You can see the stack backtrace. This will consume a lot of stack memory. (Caution: the command such as "gdb --args ./c++filt -t < $POC" is not valid. Please use "gdb ./c++filt", then "set args -t < $POC") Thanks Cheng Wen
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 H.J. Lu changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=23499 --- Comment #6 from H.J. Lu --- This sounds like https://sourceware.org/bugzilla/show_bug.cgi?id=23499 Please try binutils 2.31 branch.
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #26 from Richard Biener --- Author: rguenth Date: Tue Sep 18 13:26:05 2018 New Revision: 264388 URL: https://gcc.gnu.org/viewcvs?rev=264388&root=gcc&view=rev Log: 2018-09-18 Richard Biener PR middle-end/63155 * tree-ssa-coalesce.c (tree_int_map_hasher): Remove. (compute_samebase_partition_bases): Likewise. (coalesce_ssa_name): Always use compute_optimized_partition_bases. (gimple_can_coalesce_p): Simplify. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-coalesce.c
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 mi+gcc at aldan dot algebra.com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #7 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #6) > This sounds like > > https://sourceware.org/bugzilla/show_bug.cgi?id=23499 > > Please try binutils 2.31 branch. Actually, I have binutils-2.31 already -- the /usr/bin/as, that comes with RHEL6, does not understand the AVX2 instructions, so I had to build binutils of my own, and, of course, used the latest available: % /prod/pfe/local/bin/ld -v GNU ld (GNU Binutils) 2.31 and the ld used by gfortran (see the verbose output I posted) is a hardlink to the above: % /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld GNU ld (GNU Binutils) 2.31
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #8 from H.J. Lu --- (In reply to mi+gcc from comment #7) > (In reply to H.J. Lu from comment #6) > > This sounds like > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=23499 > > > > Please try binutils 2.31 branch. > > Actually, I have binutils-2.31 already -- the /usr/bin/as, that comes with > RHEL6, does not understand the AVX2 instructions, so I had to build binutils > of my own, and, of course, used the latest available: > > % /prod/pfe/local/bin/ld -v > GNU ld (GNU Binutils) 2.31 > > and the ld used by gfortran (see the verbose output I posted) is a hardlink > to the above: > > % > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux- > gnu/bin/ld > GNU ld (GNU Binutils) 2.31 I said binutils 2.31 branch, not 2.31 release.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #9 from mi+gcc at aldan dot algebra.com --- > I said binutils 2.31 branch, not 2.31 release. The work I'm doing is meant for eventual production use. The company has swallowed the use of free software, but using _unreleased_ versions may be too much. Is there a particular patch, you want me to apply to 2.31 release? I could do that... Is this it, for example: https://sourceware.org/ml/binutils/2018-08/msg00227.html ?
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 Jonathan Wakely changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Sep 18 13:52:30 2018 New Revision: 264391 URL: https://gcc.gnu.org/viewcvs?rev=264391&root=gcc&view=rev Log: [PATCH c++/86881] -Wshadow-local-compatible ICE https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00984.html PR c++/86881 cp/ * name-lookup.c (check_local_shadow): Ignore auto types. testsuite/ * g++.dg/warn/pr86881.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr86881.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #2 from Jonathan Wakely --- Also, "Therefore, the G++ and driver" is nonsense.
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #3 from Jonathan Wakely --- This was introduced by r242433 https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/invoke.texi?limit_changes=0&r1=242433&r2=242432&pathrev=242433
[Bug target/87104] missed &, == optimization makes Emacs ~0.4% slower on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104 pipcet at gmail dot com changed: What|Removed |Added Attachment #44617|0 |1 is obsolete|| --- Comment #14 from pipcet at gmail dot com --- Created attachment 44719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44719&action=edit WIP patch Okay, I've run into a few issues: 1. temacs run time changes unpredictably based on the configuration data, because of find_string_data_in_pure. 2. My CPU fuses "cmp" and a conditional branch and "test" and a conditional branch, but not "and" and a conditional branch. So we were optimizing a three-insn two-uop sequence into a two-insn two-uop sequence, and I was not seeing any performance improvement. 3. The code size changes sometimes cause branches to be mispredicted much more often for no apparent reason. I've worked around (1) and (2), by disabling find_string_data_in_pure() and making the peephole rule that turned "test" into "and" conditional on CPU type. Now I'm seeing a consistent performance improvement (as well as fewer instructions, fewer uops, and more fused branches) for Perl and Emacs.
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Fixed on arm and aarch64 with r264392. If you can confirm this fixes the other platforms please close this off.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #10 from mi+gcc at aldan dot algebra.com --- (In reply to mi+gcc from comment #9) > Is this it, for example: > > https://sourceware.org/ml/binutils/2018-08/msg00227.html Applied the patch to the 2.31 release, rebuilt/reinstalled binutils -- problem is still here...
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far, branches to follow.
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Tue Sep 18 14:19:55 2018 New Revision: 264395 URL: https://gcc.gnu.org/viewcvs?rev=264395&root=gcc&view=rev Log: PR other/87353 fix formatting and grammar in manual The changes to invoke.texi in r242433 left some unwanted spaces that texi2pod.pl interprets as verbatim formatting. There are also some grammatical errors due to the removal of references to GCJ, where the G++ driver is referred to in the plural. PR other/87353 * doc/invoke.texi (Link Options): Fix formatting and grammar. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #11 from H.J. Lu --- (In reply to mi+gcc from comment #10) > (In reply to mi+gcc from comment #9) > > Is this it, for example: > > > > https://sourceware.org/ml/binutils/2018-08/msg00227.html > > Applied the patch to the 2.31 release, rebuilt/reinstalled binutils -- > problem is still here... Please show the output of: $ objdump -T /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so | grep corrupt
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #12 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #11) > Please show the output of: > > $ objdump -T > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran. > so | grep corrupt Neither the stock /usr/bin/objdump nor the newer /prod/pfe/local/bin/objdump report any corruption (used grep -i just in case).
[Bug target/87354] New: x86-64: 16- and 32-byte register variables cannot be put in XMM16/YMM16 and up without -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87354
Bug ID: 87354
Summary: x86-64: 16- and 32-byte register variables cannot be
put in XMM16/YMM16 and up without -mavx512vl
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
The same issue had been present in gas, but was corrected by commit 6e041cf4b0:
YMM (and of course also XMM) registers can certainly be used with AVX512F
alone, just that the set of insns is pretty limited. I realize that making this
work may not be a trivial change, as assumptions to this effect appear to be
made all over the place, but this code should imo compile (and assemble) fine
with just -mavx512f, while currently only the first function compiles without
error (QI mode vectors have been used just for simplicity and to make things
look reasonably uniform):
asm(".arch generic64");
asm(".arch .avx512f");
typedef char __attribute__((vector_size(64))) v64qi_t;
typedef char __attribute__((vector_size(16))) v16qi_t;
typedef char __attribute__((vector_size(32))) v32qi_t;
v64qi_t test512(v64qi_t x) {
register v64qi_t y asm("zmm16");
asm("vmovdqa32 %1,%0" : "=v" (y) : "v" (x));
return y;
}
v16qi_t test128(v64qi_t x) {
register v16qi_t y asm("xmm16");
asm("vpmovqw %1,%0" : "=v" (y) : "v" (x));
return y;
}
v32qi_t test256(v64qi_t x) {
register v32qi_t y asm("ymm16");
asm("vpmovqd %1,%0" : "=v" (y) : "v" (x));
return y;
}
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #13 from H.J. Lu --- (In reply to mi+gcc from comment #12) > (In reply to H.J. Lu from comment #11) > > Please show the output of: > > > > $ objdump -T > > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran. > > so | grep corrupt > > Neither the stock /usr/bin/objdump nor the newer /prod/pfe/local/bin/objdump > report any corruption (used grep -i just in case). Please try binutils 2.31 branch from: https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_31-branch
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 --- Comment #4 from Nathan Sidwell --- Author: nathan Date: Tue Sep 18 15:06:35 2018 New Revision: 264396 URL: https://gcc.gnu.org/viewcvs?rev=264396&root=gcc&view=rev Log: [PATCH c++/86881] -Wshadow-local-compatible ICE https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00984.html PR c++/86881 cp/ * name-lookup.c (check_local_shadow): Ignore auto types. testsuite/ * g++.dg/warn/pr86881.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/warn/pr86881.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/name-lookup.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/85137] [concepts] ICE with undeclared concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85137 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Mine.
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Fixed trunk r264391. Fixed gcc-8 r264396.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- (In reply to Martin Liška from comment #3) > Then it would deserve something like segfault-on-invalid-input :) > Or should I use ice-on-invalid-code? Let's use ice-on-invalid. Otherwise the two will end up being used interchangeably over time.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #14 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #13) > Please try binutils 2.31 branch from: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/ > binutils-2_31-branch I'm sorry, I can not do that at this time -- I need to deliver the software for my employer and rebuilding the gcc suit with --disable-gold provides a work-around. I think, this bug-report -- against the compiler suit neither working with the latest release of binutils, nor warning about it -- ought to remain open for reasons I put forth in comment#4. The underlying problem with binutils deserves its own ticket, as Andrew suggests in comment#3. I think, I've given enough information for anyone to be able to reproduce the problem: 1. Build the gcc suit with the configure-arguments provided 2. Attempt to use the newly-built gfortran to build a FORTRAN program: PRINT *, "Hello World!" END I could create this ticket for you, if you insist, but you should be able to reproduce the problem yourself now. Thank you.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #15 from H.J. Lu --- (In reply to mi+gcc from comment #14) > (In reply to H.J. Lu from comment #13) > > Please try binutils 2.31 branch from: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/ > > binutils-2_31-branch > > I'm sorry, I can not do that at this time -- I need to deliver the software > for my employer and rebuilding the gcc suit with --disable-gold provides a > work-around. > > I think, this bug-report -- against the compiler suit neither working with > the latest release of binutils, nor warning about it -- ought to remain open > for reasons I put forth in comment#4. > > The underlying problem with binutils deserves its own ticket, as Andrew > suggests in comment#3. I think, I've given enough information for anyone to > be able to reproduce the problem: > As I said, the problem is fixed on binutils 2.31 branch.
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Tue Sep 18 16:19:56 2018 New Revision: 264400 URL: https://gcc.gnu.org/viewcvs?rev=264400&root=gcc&view=rev Log: Handle CLOBBER in reg_overlap_mentioned_p (PR86882) Combine will put CLOBBER (with a non-void mode) anywhere in a pattern to poison it. reg_overlap_mentioned_p did not handle this. This patch fixes that. PR rtl-optimization/86882 * rtlanal.c (reg_overlap_mentioned_p): Handle CLOBBER. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Tue Sep 18 16:24:58 2018 New Revision: 264401 URL: https://gcc.gnu.org/viewcvs?rev=264401&root=gcc&view=rev Log: Backport PR86882 fix to 8 PR rtl-optimization/86882 * rtlanal.c (reg_overlap_mentioned_p): Handle CLOBBER. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/rtlanal.c
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool --- Fixed on trunk and 8; closing as fixed.
[Bug c++/85065] [concepts] ICE with invalid use of a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 18 16:35:27 2018 New Revision: 264402 URL: https://gcc.gnu.org/viewcvs?rev=264402&root=gcc&view=rev Log: /cp 2018-09-18 Paolo Carlini PR c++/85065 * cp-tree.h (NON_ERROR): New. * pt.c (auto_hash::hash): Use it. (do_auto_deduction): Likewise. /testsuite 2018-09-18 Paolo Carlini PR c++/85065 * g++.dg/concepts/pr85065.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr85065.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85065] [concepts] ICE with invalid use of a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Paolo Carlini --- Fixed.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 85065, which changed state. Bug 85065 Summary: [concepts] ICE with invalid use of a concept https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 --- Comment #8 from Paul Thomas --- Author: pault Date: Tue Sep 18 17:54:20 2018 New Revision: 264404 URL: https://gcc.gnu.org/viewcvs?rev=264404&root=gcc&view=rev Log: 2018-09-18 Paul Thomas PR fortran/85954 * resolve.c (resolve_assoc_var): If the target expression is a deferred charlen dummy and the associate name shares the charlen, generate a new one. Make sure that new charlens are in the namespace list so that they get cleaned up. * trans-array.c (gfc_is_reallocatable_lhs): Associate names are not reallocatable. * trans-decl.c (gfc_get_symbol_decl): Put deferred character length dummy and result arrays on the deferred initialization list so that the variable length arrays can be correctly dealt with. * trans-expr.c (gfc_conv_string_length): Return if 'expr' is NULL rather than ICEing. 2018-09-18 Paul Thomas PR fortran/85954 * gfortran.dg/deferred_character_21.f90 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/deferred_character_21.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/fortran/trans-decl.c branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #3 from Paul Thomas --- Author: pault Date: Tue Sep 18 17:58:20 2018 New Revision: 264405 URL: https://gcc.gnu.org/viewcvs?rev=264405&root=gcc&view=rev Log: 2018-09-18 Paul Thomas PR fortran/87336 * trans-array.c (gfc_get_array_span): Try to get the element length of incomplete types. Return NULL_TREE otherwise. (gfc_conv_expr_descriptor): Only set the 'span' field if the above does not return NULL_TREE. Set 'span' field if possible for all new descriptors. 2018-09-18 Paul Thomas PR fortran/87336 * gfortran.dg/pointer_array_10.f90 : New test. * gfortran.dg/assign_10.f90 : Increase 'parm' count to 20. * gfortran.dg/transpose_optimization_2.f90 : Increase 'parm' count to 72. Added: trunk/gcc/testsuite/gfortran.dg/pointer_array_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assign_10.f90 trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on both branches. Many thanks for the report. Paul
[Bug target/87355] New: missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 Bug ID: 87355 Summary: missed comparison optimizations (grep DFA, x86-64) Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 44720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44720&action=edit source code illustrating missed optimizations I found this when attempting to tune grep's DFA code on x86-64, and simplified the issue to the attached source code t.c which defines two functions f and g that are logically equivalent, and which can both be implemented via a single machine-language comparison to THRESHOLD. However, GCC generates two comparisons for f and three comparisons for g, as shown in the attached assembly-language file t.s generated by 'gcc -O2 -S t.c'. I am running Fedora 28 x86-64 with 8.1.1 20180712 (Red Hat 8.1.1-5). I'm not sure whether this problem is limited to x86-64 or is more general, and for now am labeling its component as 'target'.
[Bug target/87355] missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 --- Comment #1 from eggert at cs dot ucla.edu --- Created attachment 44721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44721&action=edit Assembly-language output of 'gcc -O2 -S t.c'
[Bug tree-optimization/87355] missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|target |tree-optimization Severity|normal |enhancement
[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86830 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Tue Sep 18 19:16:24 2018 New Revision: 264407 URL: https://gcc.gnu.org/viewcvs?rev=264407&root=gcc&view=rev Log: 2018-09-18 Janus Weil Backport from trunk PR fortran/86830 * expr.c (gfc_is_simply_contiguous): Handle type-bound procedure calls with non-polymorphic objects. 2018-09-18 Janus Weil Backport from trunk PR fortran/86830 * gfortran.dg/typebound_call_30.f90: New test case. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/typebound_call_30.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
