[Bug tree-optimization/87022] [8/9 Regression] miscompilation with -ftree-loop-distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87022
--- Comment #2 from bin cheng ---
(In reply to Qirun Zhang from comment #0)
> It also affects gcc-8.1 at -O3. gcc-7.3 works fine.
>
> It appears that it starts at r253679.
>
>
> $ gcc-trunk -v
> Using built-in specs.
> COLLECT_GCC=gcc-trunk
> COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-
> linux-gnu/9.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
> --enable-languages=c,c++ --disable-werror --enable-multilib
> Thread model: posix
> gcc version 9.0.0 20180819 (experimental) [trunk revision 263651] (GCC)
>
>
>
> $ gcc-trunk abc.c ; ./a.out > ref.txt
> $ gcc-trunk -O3 abc.c ; ./a.out > a.txt
> $ diff ref.txt a.txt
> 25,49c25,49
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> < 0
> ---
> > 1
> > 1
> > 1
> > 1
> > 0
> > 0
> > 1
> > 1
> > 1
> > 1
> > 1
> > 0
> > 0
> > 1
> > 1
> > 1
> > 1
> > 1
> > 0
> > 0
> > 1
> > 1
> > 1
> > 1
> > 1
> $ gcc-7.3 -O3 abc.c ; ./a.out > a.txt
> $ diff ref.txt a.txt
> $
>
>
> $ cat abc.c
> void printf();
> char a[7];
> char b[10][7];
> short c;
> int d, e, f, g;
> int main() {
> for (; d <= 4; d++) {
> e = 0;
> for (; e <= 6; e++) {
> if (a[c])
> b[e + 3][d + 2] = 1;
> a[0] = 5;
> b[e][d + 2] = 0;
> }
> }
> for (; f < 10; f++) {
> g = 0;
> for (; g < 7; g++)
> printf("%d\n", b[f][g]);
> }
> }
Sorry for the breakage, I will investigate it.
Thanks,
bin
[Bug tree-optimization/87022] [8/9 Regression] miscompilation with -ftree-loop-distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87022 Alexander Monakov changed: What|Removed |Added Keywords||wrong-code CC||amker at gcc dot gnu.org, ||amonakov at gcc dot gnu.org Summary|GCC miscompiles at -O3 on |[8/9 Regression] |valid code |miscompilation with ||-ftree-loop-distribution --- Comment #1 from Alexander Monakov --- Yep, -O2 -ftree-loop-distribution is enough to trigger miscompilation.
[Bug c/87023] New: It's almost false, when c_fully_fold_internal deal with C_MAYBE_CONST_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87023
Bug ID: 87023
Summary: It's almost false, when c_fully_fold_internal deal
with C_MAYBE_CONST_EXPR.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: He.Hongjun at zte dot com.cn
Target Milestone: ---
in c_fully_fold_internal, C_MAYBE_CONST_EXPR's initial value is false. later,
using add operations, it's value is always false.
1. initial value
if (C_MAYBE_CONST_EXPR_INT_OPERANDS (expr))
{
*maybe_const_itself = false; // the initial value is false
inner = c_fully_fold_internal (inner, in_init, maybe_const_operands,
maybe_const_itself, true);
}
2. add operations
*maybe_const_itself &= op0_const_self;
*maybe_const_itself &= op1_const_self;
*maybe_const_itself &= op2_const_self;
Whether the initial value should be true?
[Bug tree-optimization/87022] New: GCC miscompiles at -O3 on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87022
Bug ID: 87022
Summary: GCC miscompiles at -O3 on valid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: helloqirun at gmail dot com
Target Milestone: ---
It also affects gcc-8.1 at -O3. gcc-7.3 works fine.
It appears that it starts at r253679.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 9.0.0 20180819 (experimental) [trunk revision 263651] (GCC)
$ gcc-trunk abc.c ; ./a.out > ref.txt
$ gcc-trunk -O3 abc.c ; ./a.out > a.txt
$ diff ref.txt a.txt
25,49c25,49
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
< 0
---
> 1
> 1
> 1
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 1
> 0
> 0
> 1
> 1
> 1
> 1
> 1
$ gcc-7.3 -O3 abc.c ; ./a.out > a.txt
$ diff ref.txt a.txt
$
$ cat abc.c
void printf();
char a[7];
char b[10][7];
short c;
int d, e, f, g;
int main() {
for (; d <= 4; d++) {
e = 0;
for (; e <= 6; e++) {
if (a[c])
b[e + 3][d + 2] = 1;
a[0] = 5;
b[e][d + 2] = 0;
}
}
for (; f < 10; f++) {
g = 0;
for (; g < 7; g++)
printf("%d\n", b[f][g]);
}
}
[Bug target/87021] New: New powerpc test cases from r263570 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87021 Bug ID: 87021 Summary: New powerpc test cases from r263570 fail Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- r263570 | willschm | 2018-08-15 15:29:04 -0500 (Wed, 15 Aug 2018) | 11 lines [testsuite] 2018-08-13 Will Schmidt * gcc.target/powerpc/fold-vec-splat-char.c: New. * gcc.target/powerpc/fold-vec-splat-floatdouble.c: New. * gcc.target/powerpc/fold-vec-splat-int.c: New. * gcc.target/powerpc/fold-vec-splat-longlong.c: New. * gcc.target/powerpc/fold-vec-splat-pixel.c: New. * gcc.target/powerpc/fold-vec-splat-short.c: New. FAIL: gcc.target/powerpc/fold-vec-splat-char.c scan-assembler-times vspltb 24 FAIL: gcc.target/powerpc/fold-vec-splat-floatdouble.c scan-assembler-times vspltw|xxspltw 9 FAIL: gcc.target/powerpc/fold-vec-splat-floatdouble.c scan-assembler-times xxpermdi 9 FAIL: gcc.target/powerpc/fold-vec-splat-int.c scan-assembler-times vspltisw 6 FAIL: gcc.target/powerpc/fold-vec-splat-int.c scan-assembler-times vspltw|xxspltw 24 FAIL: gcc.target/powerpc/fold-vec-splat-pixel.c scan-assembler-times vsplth 8 FAIL: gcc.target/powerpc/fold-vec-splat-pixel.c scan-assembler-times vspltish 2 FAIL: gcc.target/powerpc/fold-vec-splat-short.c scan-assembler-times vsplth 24 FAIL: gcc.target/powerpc/fold-vec-splat-short.c scan-assembler-times vspltish 6 These fail on power 8 (and probably 7).
[Bug libstdc++/87020] New: comparison operator isn't called for stateless allocator without is_always_equal for C++11/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87020 Bug ID: 87020 Summary: comparison operator isn't called for stateless allocator without is_always_equal for C++11/14 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: roland at rschulz dot eu Target Milestone: --- For an empty allocator the comparison operators aren't used, unless is_always_equal=std::false_type is present. This is the correct behavior with C++17 but for C++11/14 is_always_equal shouldn't have any effect. This is low impact because any well defined and state-less allocator should always be equal. But it isn't strictly compliant. This is present since GCC 6. Reproducer: https://godbolt.org/z/-5IHwC
[Bug bootstrap/87018] [9 Regression] Boostrap failure on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |9.0
[Bug fortran/87019] New: ICE: Static member of derived type, organized in coarray accessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87019 Bug ID: 87019 Summary: ICE: Static member of derived type, organized in coarray accessed Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: welttensor at web dot de Target Milestone: --- Created attachment 44560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44560&action=edit main and foo_module When inside of member routine (foo_routine) of a derived type (foo_type) a member-variable (foo_member) is accessed from a remote image, an internal compiler error is produced. This problem exists already in older versions of gfortran like 6.3 as well as 8.2.1
[Bug bootstrap/87018] New: [9 Regression] Boostrap failure on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87018 Bug ID: 87018 Summary: [9 Regression] Boostrap failure on AIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Created attachment 44559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44559&action=edit config.log from failed build This is on gcc119.fsffrance.org, in case anybody wants to reproduce. Files are in /home/tkoenig/trunk (source directory) and /home/tkoenig/trunk-bin (build-directory). Trying, from the build-directory, to run the shell script PATH=/opt/freeware/bin:$PATH ../trunk/configure --disable-werror --enable-languages=c,c++,fortran --with-gmp=/opt/cfarm --with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch --with-included-gettext --prefix=$HOME make -j32 SHELL=/bin/bash CONFIG_SHELL=/bin/bash yields the error In file included from ../../trunk/intl/plural.y:35:0: ../../trunk/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' # define PLURAL_PARSE libintl_gettextparse ^ ../../trunk/intl/plural.y:40:25: note: in expansion of macro 'PLURAL_PARSE' # define __gettextparse PLURAL_PARSE ^~~~ plural.c:184:5: note: in expansion of macro '__gettextparse' int __gettextparse (void); ^~ ../../trunk/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here # define PLURAL_PARSE libintl_gettextparse ^ ../../trunk/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' extern int PLURAL_PARSE PARAMS ((void *arg)); ^~~~ ../../trunk/intl/plural-exp.h:102:23: error: conflicting types for 'libintl_gettextparse' # define PLURAL_PARSE libintl_gettextparse ^ ../../trunk/intl/plural.y:40:25: note: in expansion of macro 'PLURAL_PARSE' # define __gettextparse PLURAL_PARSE ^~~~ plural.c:63:25: note: in expansion of macro '__gettextparse' #define yyparse __gettextparse ^~ plural.c:1129:1: note: in expansion of macro 'yyparse' yyparse (void) ^~~ ../../trunk/intl/plural-exp.h:102:23: note: previous declaration of 'libintl_gettextparse' was here # define PLURAL_PARSE libintl_gettextparse ^ ../../trunk/intl/plural-exp.h:114:12: note: in expansion of macro 'PLURAL_PARSE' extern int PLURAL_PARSE PARAMS ((void *arg)); ^~~~ plural.c: In function 'libintl_gettextparse': plural.c:64:25: error: too few arguments to function '__gettextlex' #define yylex __gettextlex ^ plural.c:1298:16: note: in expansion of macro 'yylex' yychar = yylex (&yylval); ^ plural.c:64:25: note: declared here #define yylex __gettextlex ^ ../../trunk/intl/plural.y:69:12: note: in expansion of macro 'yylex' static int yylex PARAMS ((YYSTYPE *lval, const char **pexp)); ^ ../../trunk/intl/plural.y:178:29: error: 'arg' undeclared (first use in this function) ((struct parse_args *) arg)->res = $1; ^~~ ../../trunk/intl/plural.y:178:29: note: each undeclared identifier is reported only once for each function it appears in Makefile:133: recipe for target 'plural.o' failed
[Bug c++/87017] New: vector must have the same value as its allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87017
Bug ID: 87017
Summary: vector must have the same value as its allocator
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
Target Milestone: ---
This MCVE compiles/runs with gcc 7.3, clang 6.0 and icc 18.0 [this is, what I
tested so far]:
#include
#include
#include
namespace FaF
{
template
class Allocator
{
public:
typedef T value_type;
Allocator() throw() {}
template Allocator (const Allocator&) throw() {}
~Allocator() throw() {}
T* allocate (std::size_t num, const void* hint = 0)
{
(void) hint; (void) num;
return new ( T );
}
void deallocate (T* p, std::size_t num) { (void) num; (void) p; }
};
using string = std::basic_string,
Allocator>;
using smatch = std::match_results>;
}
int main()
{
FaF::smatch results {};
std::cout << "OK\n";
}
gcc 8.2 complains here:
FaF::smatch results {};
^--- vector must have the same value as its allocator
Changing it to std::smatch then it compiles.
Compiler options:
-O3 -std=c++17 -Werror -Wextra -Wold-style-cast -Wall
Live version: https://godbolt.org/z/8wI6YS
[Bug c++/87016] New: std::optional::operator= in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87016
Bug ID: 87016
Summary: std::optional::operator= in constexpr context
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bobogu at atlas dot cz
Target Milestone: ---
Created attachment 44558
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44558&action=edit
preprocessed TU
According to the standard, there is no assignment operator that should work in
a constexpr context, however, I am able to successfully compile and use the
following snippet:
// gcc -lstdc++ -std=c++17 main.cpp @Linux laptop 4.17.11-arch1 x86_64
constexpr std::optional foo() {
std::optional bar = 3;
bar = 10;
return bar;
}
[Bug target/86994] [9 regression] 64-bit gcc.target/i386/20040112-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86994 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/86994] [9 regression] 64-bit gcc.target/i386/20040112-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86994 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Sun Aug 19 19:10:37 2018 New Revision: 263652 URL: https://gcc.gnu.org/viewcvs?rev=263652&root=gcc&view=rev Log: PR target/86994 * config/i386/i386.c (ix86_rtx_costs) [case SET]: Check source for register_operand when calling ix86_set_reg_reg_cost. [case CONST_INT, case CONST, case LABEL_REF, case SYMBOL_REF]: Set *total to 0 for operands that satisfy x86_64_immediate_operand predicate and to 1 otherwise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #4 from Andreas Schwab --- It's a 32bit store, not a load.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > > movl%eax, 8(%ebp,%ecx)# ! > > This is a 32bit zero extending load. Meaning the top 32bits of the rax register are zero.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #2 from Andrew Pinski --- > movl%eax, 8(%ebp,%ecx)# ! This is a 32bit zero extending load.
[Bug c++/87015] New: [8 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Bug ID: 87015 Summary: [8 Regression] miscompilation of template heavy Boost Spirit code Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.f.starke at freenet dot de Target Milestone: --- Starting with GCC 8.1.0 I encounter wrong code generations when using template heavy C++ code with Boost Spirit. Using Boost 1.66 with GCC 7.2.0, 7.3.0, 8.1.0 and 8.2.0 to compile https://github.com/daniel-starke/pp results in the following test case results of pp: 7.2.0 TOTAL: 767 PASSED: 767 FAILED: 0 7.3.0 TOTAL: 767 PASSED: 767 FAILED: 0 8.1.0 TOTAL: 760 PASSED: 140 FAILED: 620 8.2.0 TOTAL: 760 PASSED: 140 FAILED: 620 Tests with GCC8.2.0 did show that some errors occur because the string terminator _r2 in https://github.com/daniel-starke/pp/blob/master/src/pp/parser/Script.hpp#L396 does gets propergated to https://github.com/daniel-starke/pp/blob/master/src/pp/parser/StringLiteral.hpp#L226 but not properly set. GCC 8.2.0 was configured with: ../../src/gcc-8.2.0/configure --host=x86_64-w64-mingw32 --enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix --disable-nls --disable-shared --enable-static --enable-fully-dynamic-string --enable-lto --enable-plugins --enable-libgomp --with-dwarf2 --enable-mingw-wildcard=platform --disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all --enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4 --with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl Thread model: posix It is available here: https://sourceforge.net/projects/gcc-win64/files/8.2.0/ Due to the nature of the bug I am unable to provide a reduced test case without an better idea of what the cause of the issue is. Compiling with -Og or -O1 instead of -O2 did not change the behavior.
[Bug c++/87012] [Regression] ICE in verify_unstripped_args_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87012 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Marek Polacek --- But the code seems to be valid.
[Bug c++/87012] [Regression] ICE in verify_unstripped_args_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87012
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-19
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Marek Polacek ---
Started with r241425. Before that we issued an error:
87012.C: In instantiation of ‘struct X’:
87012.C:9:12: required from here
87012.C:7:10: error: type/value mismatch at argument 1 in template parameter
list for ‘template class T, T > struct X’
struct X { };
^
87012.C:7:10: note: expected a class template, got ‘ref’
87012.C:7:10: note: invalid template non-type parameter
87012.C:7:10: error: type/value mismatch at argument 1 in template parameter
list for ‘X >::X’
87012.C:7:10: note: expected a class template, got ‘ref’
87012.C:7:10: note: invalid template non-type parameter
[Bug middle-end/86999] Incorrect code generation and missing optimization with -fno-signed-zeros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999 --- Comment #3 from Marc Glisse --- (In reply to asd_ from comment #2) > I hope there will be one more FMA pass in the RTL stages in the future.:) A new RTL pass is not necessary for this, the GIMPLE pass could be extended to recognize (x±1)*y and (1-x)*y, if that's useful.
[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81033 --- Comment #9 from Iain Sandoe --- The fix attached to 81033 also resolves this issue, and is much less intrusive than #c6 (which is no longer applicable - obsoleted).
[Bug debug/83941] Debug info generated with -flto contains useless forwarders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83941 --- Comment #5 from dpeeters at outlook dot be --- Yes, but please have a look at https://www.datingvergelijken.be first. It's a great datingsite in Belgium. Thanks, Dirk
[Bug c++/86911] [9 Regression] ICE in gcc/c-family/c-indentation.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86911 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- (In reply to David Malcolm from comment #3) > Does r263595 fix the issue? (it relates to having stray carriage returns > somewhere above in the file, leading to line-numbering becoming confused) Yes, I can confirm that. Thanks David.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #1 from camper --- Created attachment 44557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44557&action=edit [x32] use 64-bit mov to set return address in eh_return compiles to: movlhandler(%rip), %eax movloffset(%rip), %edx movl%edx, %ecx movl%eax, %eax movq%rax, 8(%ebp,%ecx) movq-16(%ebp), %rax movq-8(%ebp), %rdx leal8(%rbp,%rcx), %ecx movl0(%ebp), %ebp movl%ecx, %esp ret
[Bug target/87014] New: [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014
Bug ID: 87014
Summary: [x32] __builtin_eh_return should use 64-bit mov to set
return address
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: theonetruecamper at gmx dot de
Target Milestone: ---
long offset;
void* ptr;
void f(void)
{
__builtin_eh_return(offset,ptr);
}
with gcc -mx32 produces (gcc (Gentoo Hardened 7.3.0-r3 p1.4) 7.3.0)
f:
pushq %rbp
movl%esp, %ebp
pushq %rdx
pushq %rax
movl%fs:24, %eax
movl%eax, -20(%ebp)
xorl%eax, %eax
movlptr(%rip), %eax
movloffset(%rip), %edx
movl%edx, %ecx
movl%eax, 8(%ebp,%ecx)# !
movq-16(%ebp), %rax
movq-8(%ebp), %rdx
leal8(%rbp,%rcx), %ecx
movl0(%ebp), %ebp
movl%ecx, %esp
ret # !!
Since the upper half of the return address is not cleared this can lead to
SIGSEGV in _Unwind_*
[Bug middle-end/86999] Incorrect code generation and missing optimization with -fno-signed-zeros.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86999
--- Comment #2 from asd_ ---
(In reply to Alexander Monakov from comment #1)
> For the first problem -fno-signed-zeros is a bit of a red herring, the real
> reason is enabling -fassociative-math makes GCC turn
>
> return n * p + p;
>
> to 'return (n + 1) * p;' and while we slightly optimize it on RTL we don't
> recover fma from it.
>
> For the second problem, the expression '(v4f)v' is {0.0f, 0.0f, -0.0f,
> -0.0f} and by specifying -fno-signed-zeros you're allowing the compiler to
> change it to all-positive-zeros, making the function a no-op. So that is not
> a bug.
Thanks for the explanation!
I hope there will be one more FMA pass in the RTL stages in the future.:)
