[Bug tree-optimization/88970] New: ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970
Bug ID: 88970
Summary: ICE: verify_ssa failed (error: definition in block 2
follows the use)
Product: gcc
Version: unknown
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: ---
g++-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
snippet:
template int
b (T);
void
d ()
{
typedef int e[b (1)];
e f;
int c;
[&]
{
c = sizeof (f);
[&]
{
c = sizeof (f);
} ();
} ();
}
% g++-9.0.0-alpha20190120 -c tc1ytzqq.cpp
tc1ytzqq.cpp: In lambda function:
tc1ytzqq.cpp:19:1: error: definition in block 2 follows the use
19 | }
| ^
for SSA_NAME: _1 in statement:
_1 = _1 + 1;
during GIMPLE pass: ssa
tc1ytzqq.cpp:19:1: internal compiler error: verify_ssa failed
0x11be57f verify_ssa(bool, bool)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree-ssa.c:1188
0xebec5d execute_function_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/passes.c:1984
0xebfa5e execute_todo
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/passes.c:2031
But it may have a number of duplicates already…
[Bug c/88968] New: [8/9 Regression] Stack overflow in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88968
Bug ID: 88968
Summary: [8/9 Regression] Stack overflow in gimplify_expr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20190120 snapshot (r268107) demonstrates stack overflow when
compiling the following snippet w/ -fopenmp:
struct {
unsigned int hq : 16;
unsigned int dv : 1;
} __attribute__ ((__packed__)) e2;
void
yp (void)
{
#pragma omp atomic
++e2.hq;
}
% gcc-9.0.0-alpha20190120 -fopenmp -c gqqutwbw.c
gcc-9.0.0-alpha20190120: internal compiler error: Segmentation fault signal
terminated program cc1
==18746== Stack overflow in thread #1: can't grow stack to 0x1ffe001000
==18746== Can't extend stack to 0x1ffe000fd8 during signal delivery for thread
1:
==18746== no stack segment
==18746==
==18746== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==18746== Access not within mapped region at address 0x1FFE000FD8
==18746== Stack overflow in thread #1: can't grow stack to 0x1ffe001000
==18746==at 0xAE6E4B: gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int) (gimplify.c:13292)
==18746== If you believe this happened as a result of a stack
==18746== overflow in your program's main thread (unlikely but
==18746== possible), you can try to increase the size of the
==18746== main thread stack using the --main-stacksize= flag.
==18746== The main thread stack size used in this run was 16777216.
[Bug c++/88969] New: ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969
Bug ID: 88969
Summary: ICE in build_op_delete_call, at cp/call.c:6509
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following
snippet reduced from test/SemaCXX/cxx2a-destroying-delete.cpp from clang 7.0.1
test suite:
namespace std {
struct destroying_delete_t {
struct __construct { explicit __construct() = default; };
};
}
namespace delete_selection {
struct B {
void operator delete(void*) = delete;
void operator delete(B *, std::destroying_delete_t) = delete;
};
void delete_B(B *b) { delete b; }
}
% g++-9.0.0-alpha20190120 -c mi9qy2yt.cpp
mi9qy2yt.cpp: In function 'void
delete_selection::delete_B(delete_selection::B*)':
mi9qy2yt.cpp:12:32: internal compiler error: in build_op_delete_call, at
cp/call.c:6509
12 | void delete_B(B *b) { delete b; }
|^
0x5b81f3 build_op_delete_call(tree_code, tree_node*, tree_node*, bool,
tree_node*, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/call.c:6509
0x9454d8 build_delete(tree_node*, tree_node*, special_function_kind, int, int,
int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/init.c:4825
0x9b6036 cp_parser_unary_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:8196
0x98eb02 cp_parser_cast_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:9345
0x98f3da cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:9447
0x990546 cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:9744
0x99091a cp_parser_expression
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:9911
0x993e95 cp_parser_expression_statement
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:11449
0x99f578 cp_parser_statement
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:11245
0x9a0c38 cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:11592
0x9a0d18 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:11546
0x9bab16 cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:22530
0x9bab16 cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:22567
0x9bb3f0 cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:27630
0x9bc1d4 cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:27546
0x9bc1d4 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:20205
0x99d518 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:13476
0x9c2cdd cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:13173
0x9c389c cp_parser_declaration_seq_opt
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:13049
0x9c389c cp_parser_namespace_body
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/cp/parser.c:19252
[Bug c++/88967] [9 regression] openmp default(none) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967 --- Comment #3 from Roman Lebedev --- While there, any advice on how that is supposed to be rewritten? Simply adding "shared(begin, len)" makes older gcc's unhappy https://godbolt.org/z/gyZBR- Only keeping "shared(begin, len)" (and dropping "default(none)") does not work either.
[Bug c++/88967] [9 regression] openmp default(none) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967 --- Comment #2 from Roman Lebedev --- (In reply to Jakub Jelinek from comment #1) > It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping > that the change will be reverted in later OpenMP standards, in the end that > is not what is going to happen. > ... Sigh! Ok, thank you for the reply :/
[Bug c++/88967] [9 regression] openmp default(none) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- It indeed changed, already in OpenMP 4.0 actually, but I've been long hoping that the change will be reverted in later OpenMP standards, in the end that is not what is going to happen. OpenMP 3.1 and earlier had: "Variables with const-qualified type having no mutable member are shared." among the predetermined data sharing of variables for C/C++, and "Variables with const-qualified type having no mutable member may be listed in a C/C++ firstprivate clause." as an exception to the rule that variables with predetermined data sharing may not be specified in OpenMP data sharing clauses. That is gone in OpenMP 4.0, these variables are not predetermined anymore, so with default(none) they must be specified in data sharing clauses if they are referenced in the region. They can be specified in both shared and firstprivate clauses now, e.g. lastprivate/reduction/linear aren't suitable because they all need to write into the variable. If you want to write code that will work with both OpenMP 3.1 and OpenMP 4.0+ (including 5.0, which hasn't changed in this area), you need to use firstprivate(begin, len) in your example, that used to be valid in OpenMP 3.1 due to the above exception and keeps to be valid now. I've asked the ifort/clang maintainers about why they keep violating the standard, but haven't heard back from them. And I must say I was trying hard to readd the above rule + exception, but haven't succeeded. The exact wording why the above needs to be refused is: "The default(none) clause requires that each variable that is referenced in the construct, and that does not have a predetermined data-sharing attribute, must have its data-sharing attribute explicitly determined by being listed in a data-sharing attribute clause." As it is not predetermined (anymore) and is not explicitly determined either, it violates the requirement above.
[Bug c++/88475] -E -fdirectives-only clashes with raw strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475 --- Comment #3 from Allan Jensen --- No, it has to be a raw-string to be valid. https://wandbox.org/permlink/I0yF3U3OXoH6LbIM
[Bug fortran/88961] valgrind error in resolve_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-01-22 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Thomas Koenig --- (In reply to Jakub Jelinek from comment #1) > Dup of PR88871? Displays the same symptoms. What version exactly? Is it before r268092? What happens if you upgrade to current trunk?
[Bug objc/88967] New: [9 regression] openmp default(none) broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88967
Bug ID: 88967
Summary: [9 regression] openmp default(none) broken
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
https://godbolt.org/z/8WHddH
void foo(int *x);
void test1(int * const begin, const int len) {
#pragma omp parallel default(none)
#pragma omp for
for(int x = 0; x < len; x++)
foo(begin + x);
}
gcc 8.2, clang trunk is ok with that code.
gcc trunk says:
: In function 'void test1(int*, int)':
:5:9: error: 'len' not specified in enclosing 'parallel'
5 | #pragma omp for
| ^~~
:4:9: error: enclosing 'parallel'
4 | #pragma omp parallel default(none)
| ^~~
:7:9: error: 'begin' not specified in enclosing 'parallel'
7 | foo(begin + x);
| ^
:4:9: error: enclosing 'parallel'
4 | #pragma omp parallel default(none)
| ^~~
Compiler returned: 1
Since 'default(none)' is specified, i fail to see how they are not specified..
I'm also not really seeing the reasoning in the openmp 4.0 "2.14.3.1 default
clause".
Did this change in newer openmp versions?
[Bug fortran/88961] valgrind error in resolve_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Dup of PR88871?
[Bug c++/88475] -E -fdirectives-only clashes with raw strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475 --- Comment #2 from d25fe0be@ --- It looks like this was (incorrectly, I assume) rejected since GCC 4.4. https://wandbox.org/permlink/I0yF3U3OXoH6LbIM
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #20 from Chris Elrod ---
To add a little more:
I used inline asm for direct access to the rsqrt instruction "vrsqrt14ps" in
Julia. Without adding a Newton step, the answers are wrong beyond just a couple
significant digits.
With the Newton step, the answers are correct.
My point is that LLVM-compiled code (Clang/Flang/ispc) are definitely adding
the Newton step. They get the correct answer.
That leaves my best guess for the performance difference as owing to the masked
"vrsqrt14ps" that gcc is using (g++ does this too):
vcmpps $4, %zmm0, %zmm5, %k1
vrsqrt14ps %zmm0, %zmm1{%k1}{z}
Is there any way for me to test that idea?
Edit the asm to remove the vcmppss and mask, compile the asm with gcc, and
benchmark it?
Okay, I just tried playing around with flags and looking at asm.
I compiled with:
g++ -O3 -ffinite-math-only -fexcess-precision=fast -fno-math-errno
-fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math
-fno-rounding-math -fno-signaling-nans -march=native -shared -fPIC
-mprefer-vector-width=512 -fno-semantic-interposition -o
libgppvectorization_test.so vectorization_test.cpp
which is basically all flags implied by "-ffast-math", except
"-funsafe-math-optimizations". This does include the flags implied by the
unsafe-math optimizations, just not that flag itself.
This list can be simplified to (only "-fno-math-errno" is needed):
g++ -O3 -fno-math-errno -march=native -shared -fPIC -mprefer-vector-width=512
-fno-semantic-interposition -o libgppvectorization_test.so
vectorization_test.cpp
or
gfortran -O3 -fno-math-errno -march=native -shared -fPIC
-mprefer-vector-width=512 -fno-semantic-interposition -o
libgfortvectorization_test.so vectorization_test.f90
This results in the following:
vsqrtps (%r8,%rax), %zmm0
vdivps %zmm0, %zmm7, %zmm0
ie, vsqrt and a division, rather than the masked reciprocal square root.
With N = 2827, that speeds gfortran and g++ from about 4.3 microseconds to 3.5
microseconds.
For comparison, Clang takes about 2 microseconds, and Flang/ispc/and awful
looking unsafe Rust take 2.3-2.4 microseconds, using the vrsqrt14ps (without a
mask) and a Newton step, instead of vsqrtps followed by a division.
So, "-funsafe-math-optimizations" results in a regression here.
[Bug target/88965] powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
--- Comment #1 from Anton Blanchard ---
Here's something more representative. Passing the address via an explicit
pointer makes the issue go away.
#include
#include
#define LOADU(p)vec_vsx_ld(0, (vector unsigned long *)(p))
static uint64_t blake2b_IV[8] =
{
0x6a09e667f3bcc908ULL, 0xbb67ae8584caa73bULL,
0x3c6ef372fe94f82bULL, 0xa54ff53a5f1d36f1ULL,
0x510e527fade682d1ULL, 0x9b05688c2b3e6c1fULL,
0x1f83d9abfb41bd6bULL, 0x5be0cd19137e2179ULL
};
vector unsigned long ret;
int main(void)
{
#ifdef GOOD
unsigned long *p = _IV[0];
ret = LOADU(p);
#else
ret = LOADU(_IV[0]);
#endif
}
[Bug c/88966] Indirect stringification of "linux" produces "1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966 --- Comment #2 from Bin Meng --- (In reply to Dimitar Dimitrov from comment #1) > The "linux" is a predefined macro: > > $ $ gcc -E -dM - #define linux 1 > > Looks like by-design to me. Indeed "linux" is a predefined macro. But why does str(linux) and stringify(linux) give different results?
[Bug c/88966] Indirect stringification of "linux" produces "1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966 Dimitar Dimitrov changed: What|Removed |Added CC||dinuxbg at gmail dot com --- Comment #1 from Dimitar Dimitrov --- The "linux" is a predefined macro: $ $ gcc -E -dM -
[Bug tree-optimization/88713] Vectorized code slow vs. flang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88713
--- Comment #19 from Chris Elrod ---
To add a little more:
I used inline asm for direct access to the rsqrt instruction "vrsqrt14ps" in
Julia. Without adding a Newton step, the answers are wrong beyond just a couple
significant digits.
With the Newton step, the answers are correct.
My point is that LLVM-compiled code (Clang/Flang/ispc) are definitely adding
the Newton step. They get the correct answer.
That leaves my best guess for the performance difference as owing to the masked
"vrsqrt14ps" that gcc is using:
vcmpps $4, %zmm0, %zmm5, %k1
vrsqrt14ps %zmm0, %zmm1{%k1}{z}
Is there any way for me to test that idea?
Edit the asm to remove the vcmppss and mask, compile the asm with gcc, and
benchmark it?
[Bug target/88954] __attribute__((noplt)) doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #4 from H.J. Lu ---
(In reply to Martin Sebor from comment #3)
> My question is about the change you are proposing. How do you expect g() to
> be called if the test case from comment #0 is modified for example as
> follows:
>
> void f_plt(void);
> void f_noplt(void) __attribute__((noplt));
> void (*p_noplt)(void) = f_noplt;
> void g(void (*)(void));
>
> int main()
> {
> if (getenv ("USE_PLT"))
> p_noplt = f_plt; // should this be diagnosed?
f_plt will be handled by
00404020 00060007 R_X86_64_JUMP_SLO 00401040 f_plt + 0
> g (p_noplt);
> }
>
> In most other cases, initializing a pointer with the address of a function
> declared with some function attribute (e.g., const, nonnull, noreturn, pure,
> or warn_unused_result) doesn't transfer the special properties to the
> pointer, so I'm trying to understand what semantics you are after and if
> there is any potential for user errors and decide whether they should be
> detected.
>
> I happen to think it would make sense to make it possible to imbue function
> pointers with some (but not all) of the same attributes as those that apply
> to functions, but there certainly are cases where doing so could cause
> problems, just as there are cases where not doing so can.
__attribute__((noplt)) only applies to functions, which instructors
compiler to avoid PLT when accessing the marked function, via function
pointer nor direct call. The function pointer itself has no impact
on PLT.
[Bug libstdc++/86756] Don't define __cpp_lib_filesystem unless --enable-libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86756 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #6 from sandra at gcc dot gnu.org --- The patch for this issue seems to have caused several test regressions and new failures on nios2-elf, a newlib-based target with semihosted i/o. It's getting link-time errors about references to undefined symbols chdir, mkdir, etc. It's not clear how I'm supposed to fix that. Am I missing some configure option, or should I be adding dg-skip-if (or whatever) to the failing tests?
[Bug c/88966] New: Indirect stringification of "linux" produces "1"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88966 Bug ID: 88966 Summary: Indirect stringification of "linux" produces "1" Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bmeng.cn at gmail dot com Target Milestone: --- Created attachment 45487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45487=edit test case This issue is seen with GCC 5.4.0 shipped by Ubuntu 16.04, but is also reproducible with GCC 7.3.0 and 8.1.0. Use attached test case (test.c) to reproduce. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --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-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) $ gcc test.c -o test $ ./test case 1: 1 case 2: vmlinux case 3: linux4.20 case 4: weird 1 ? case 5: linux It looks the indirect stringification (two levels) has special handling of "linux". Doing just one level (see case 5) works fine.
[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317 --- Comment #11 from emsr at gcc dot gnu.org --- The work for preprocessor/83063 may have impacted this bug.
[Bug target/88877] rs6000 emits signed extension for unsigned int type(__floatunsidf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877 --- Comment #17 from Alan Modra --- > Is anything broken though? Yes, as demonstrated by the testcase. > If the libcall routines know they are called this way, all is fine. They don't. libgcc functions are mostly C code that can make use of the fact that on ppc64 an unsigned int arg will have the top 32 bits zeroed. We avoid some potential problems with things like popcount by not having a popcountsi. Instead we use popcountdi, and that results in gcc zero-extending a 32-bit value to 64 bits before we reach emit_library_call_value_1.
[Bug target/88954] __attribute__((noplt)) doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #3 from Martin Sebor ---
My question is about the change you are proposing. How do you expect g() to be
called if the test case from comment #0 is modified for example as follows:
void f_plt(void);
void f_noplt(void) __attribute__((noplt));
void (*p_noplt)(void) = f_noplt;
void g(void (*)(void));
int main()
{
if (getenv ("USE_PLT"))
p_noplt = f_plt; // should this be diagnosed?
g (p_noplt);
}
In most other cases, initializing a pointer with the address of a function
declared with some function attribute (e.g., const, nonnull, noreturn, pure, or
warn_unused_result) doesn't transfer the special properties to the pointer, so
I'm trying to understand what semantics you are after and if there is any
potential for user errors and decide whether they should be detected.
I happen to think it would make sense to make it possible to imbue function
pointers with some (but not all) of the same attributes as those that apply to
functions, but there certainly are cases where doing so could cause problems,
just as there are cases where not doing so can.
[Bug target/88965] New: powerpc64le vector builtin hits ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88965
Bug ID: 88965
Summary: powerpc64le vector builtin hits ICE in verify_gimple
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
CC: segher at gcc dot gnu.org, wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-linux
The following (admittedly odd) code results in an ICE on trunk, target
powerpc64le:
unsigned int a[1];
void b(void) { __builtin_vec_vsx_ld(0, [0]); }
...
blake.i: In function 'b':
blake.i:2:6: error: invalid address operand in MEM_REF
2 | void b(void) { __builtin_vec_vsx_ld(0, [0]); }
| ^
MEM[(void *)[0]];
_1 = MEM[(void *)[0]];
during GIMPLE pass: lower
blake.i:2:6: internal compiler error: verify_gimple failed
0x10a7ddfb verify_gimple_in_seq(gimple*)
../../gcc/gcc/tree-cfg.c:5082
0x108dcff7 execute_function_todo
../../gcc/gcc/passes.c:1979
0x108de5bb do_per_function
../../gcc/gcc/passes.c:1638
0x108de7cb execute_todo
../../gcc/gcc/passes.c:2031
[Bug target/88614] ICE: output_operand: invalid %z value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Alan Modra --- Patch applied.
[Bug target/88614] ICE: output_operand: invalid %z value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614 --- Comment #3 from Alan Modra --- Author: amodra Date: Tue Jan 22 02:29:47 2019 New Revision: 268135 URL: https://gcc.gnu.org/viewcvs?rev=268135=gcc=rev Log: [RS6000] PR88614, output_operand: invalid %z value The direct cause of this PR is the fact that tls_gdld_nomark didn't handle indirect calls. Also, most indirect calls were being optimised back to direct calls anyway, due to tls_gdld_nomark not checking any of the parallel elements except the first (plus the extra element that distinguishes this call from normal calls). There were other unwanted substitutions too. So this patch attacks the problem of handling special calls in a different way. Rather than adding another element to the call insn parallel to distinguish -mno-tls-markers __tls_get_addr calls from any other calls, we now inspect the second CALL arg. Each call_value_nonlocal and call_value_indirect insn now checks for the tlsgd/ld unspecs when !TARGET_TLS_MARKERS and emits the arg setup insns. I disallow the local call patterns since we'll only see local calls to __tls_get_addr in testcases, and it doesn't seem a good idea to complicate the patterns just for a minor optimisation. Sibling call insns aren't used for libcalls, so none of these insns need to change. The patch also fixes a minor problem with -mno-tls-markers __tls_get_addr calls causing a "li 3,0" instruction to be emitted prior to the arg setup instructions, due to using a libcall with one arg. That isn't correct when the call insn itself sets up its arg. Also, I've tidied the V4 secure-plt calls, generating them in rs6000_call_sysv rather than by splitting in rs6000.md. The CALL_INSN_FUNCTION_USAGE added in edit_tls_call_insn is no longer needed (since git commit 0a4b5c66df9). On the subject of unwanted substitutions, I also saw a _GLOBAL_OFFSET_TABLE_ symbol_ref being substituted for the GOT reg, resulting in code like "addi 3,_GLOBAL_OFFSET_TABLE_,tls_ld@got@tlsld". Fixed by the unspec_tls change. PR target/88614 * config/rs6000/predicates.md (unspec_tls): Ensure GOT reg stays a reg. Allow a const_int. * config/rs6000/rs6000-protos.h (rs6000_output_tlsargs): Declare. * config/rs6000/rs6000.h (IS_V4_FP_ARGS): Define. (IS_NOMARK_TLSGETADDR): Define. * config/rs6000/rs6000.c (edit_tls_call_insn): Delete. (rs6000_output_tlsargs): New function. (rs6000_legitimize_tls_address): Don't say a !TARGET_TLS_MARKERS __tls_get_addr call takes an arg. (rs6000_call_sysv): Generate sysv4 secure plt call pattern here.. * config/rs6000/rs6000.md (call_nonlocal_sysv): ..rather than here, delete split.. (call_value_nonlocal_sysv): ..or here, delete split. (tls_gdld_nomark): Delete. (call_value_indirect_nonlocal_sysv): Use unspec_tls as operand2 predicate. Call rs6000_output_tlsargs. Adjust length to suit. (call_value_nonlocal_sysv): Likewise. (call_value_nonlocal_sysv_secure): Likewise. (call_value_nonlocal_aix): Likewise. (call_value_indirect_aix): Likewise. (call_value_indirect_elfv2): Likewise. (call_value_local32, call_value_local64): Disable for no-mark tls. (call_value_local_aix): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md
[Bug tree-optimization/88964] [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964 Arseny Solokha changed: What|Removed |Added Known to work||7.3.0 Known to fail||8.2.0, 9.0 --- Comment #1 from Arseny Solokha --- The pass in question was introduced in gcc 8 so I'm not sure if this PR really deserves to be marked as regression.
[Bug tree-optimization/88964] New: [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88964 Bug ID: 88964 Summary: [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1561 Product: gcc Version: 8.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: --- gfortran-9.0.0-alpha20190120 snapshot (r268107) ICEs when compiling the following snippet reduced from gcc/testsuite/gfortran.dg/pr68251.f90 w/ -O3 -fno-tree-forwprop --param sccvn-max-alias-queries-per-access=1: MODULE hfx_contract_block INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE contract_block(ma_max,mb_max,mc_max,md_max,kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) REAL(KIND=dp) :: kbd(mb_max*md_max), kbc(mb_max*mc_max), & kad(ma_max*md_max), kac(ma_max*mc_max), pbd(mb_max*md_max), & pbc(mb_max*mc_max), pad(ma_max*md_max), pac(ma_max*mc_max), & prim(ma_max*mb_max*mc_max*md_max), scale CALL block_1_3_1_3(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) CALL block_1_3_1_4(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) CALL block_1_3_1_5(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) END SUBROUTINE contract_block SUBROUTINE block_1_3_1_3(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) REAL(KIND=dp) :: kbd(3*3), kbc(3*1), kad(1*3), kac(1*1), pbd(3*3), & pbc(3*1), pad(1*3), pac(1*1), prim(1*3*1*3), scale DO md = 1,3 DO mc = 1,1 DO mb = 1,3 DO ma = 1,1 kac((mc-1)*1+ma) = kac((mc-1)*1+ma)-tmp*p_bd END DO END DO END DO END DO END SUBROUTINE block_1_3_1_3 SUBROUTINE block_1_3_1_4(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) REAL(KIND=dp) :: kbd(3*4), kbc(3*1), kad(1*4), kac(1*1), pbd(3*4), & pbc(3*1), pad(1*4), pac(1*1), prim(1*3*1*4), scale DO md = 1,4 DO mc = 1,1 DO mb = 1,3 kbc((mc-1)*3+mb) = kbc((mc-1)*3+mb) - ks_bc END DO END DO END DO END SUBROUTINE block_1_3_1_4 SUBROUTINE block_1_3_1_5(kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) REAL(KIND=dp) :: kbd(3*5), kbc(3*1), kad(1*5), kac(1*1), pbd(3*5), & pbc(3*1), pad(1*5), pac(1*1), prim(1*3*1*5), scale DO md = 1,5 DO mc = 1,1 DO mb = 1,3 DO ma = 1,1 kac((mc-1)*1+ma) = kac((mc-1)*1+ma)-tmp*p_bd END DO END DO END DO END DO END SUBROUTINE block_1_3_1_5 END MODULE hfx_contract_block % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190120 -O3 -fno-tree-forwprop --param sccvn-max-alias-queries-per-access=1 -c cn013jaw.f90 during GIMPLE pass: linterchange cn013jaw.f90:4:0: 4 | SUBROUTINE contract_block(ma_max,mb_max,mc_max,md_max,kbd,kbc,kad,kac,pbd,pbc,pad,pac,prim,scale) | internal compiler error: in wide_int_to_tree_1, at tree.c:1561 0x6befc2 wide_int_to_tree_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.c:1561 0x106439e build_int_cst(tree_node*, poly_int<1u, long>) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/tree.c:1355 0x149f832 loop_cand::analyze_induction_var(tree_node*, tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-loop-interchange.cc:695 0x149fd58 loop_cand::analyze_carried_vars(loop_cand*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-loop-interchange.cc:752 0x14a2195 tree_loop_interchange::interchange(vec, vec) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-loop-interchange.cc:1600 0x14a2dcf execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190120/work/gcc-9-20190120/gcc/gimple-loop-interchange.cc:2070 (While my target here is powerpc, the ICE is not target-specific.)
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Jürgen Reuter from comment #4) > It seems that at least Thomas and Dominique believe that this can be closed. with which status?
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #20 from Segher Boessenkool --- (In reply to Wilco from comment #19) > (In reply to Segher Boessenkool from comment #18) > > https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html > > Thanks, I hadn't noticed that yet... I need to look at it in more detail, > but are you saying that combine no longer generates zero_extracts today and > all patterns that rely on it must be changed to a different canonical form? If you no longer see zero_extracts there must be some other reason for it. > I suspect the tst_5/6 cases are similar if the canonical form of rtl has > changed. It hasn't. > Note that doing (x & 63) != 0 just works fine, it's only 255 and > 65535 which appear to be treated differently... Yes, those are "simplified" to some subreg or whatever. This isn't new. It's what change_zero_ext is for, so that you don't have to deal with those forms if you have more generic instructions.
[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- The build problem is fixed, leaving the test failures for another day.
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #19 from Segher Boessenkool --- The pattern makes no sense at all for LE. If LE, (vec_concat:V2DF (vec_select:DF (match_operand:V2DF 1 "vfloat_operand" "wd,wa,wd,wa") (parallel [(const_int 1)])) (vec_select:DF (match_dup 1) (parallel [(const_int 0)]))) means exactly the same as just (match_operand:V2DF 1 "vfloat_operand" "wd,wa,wd,wa") So how does this pattern ever match for LE anyway? Are there some serious missed simplifications?
[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jan 22 00:06:44 2019 New Revision: 268131 URL: https://gcc.gnu.org/viewcvs?rev=268131=gcc=rev Log: PR go/88927 runtime, internal/cpu: fix build for ARM GNU/Linux Was failing with ../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit' 138 | doinit() | ^ Fix it by adding in Go 1.12 internal/cpu/cpu_arm.go, and the code in runtime that initializes the values. Fixes https://gcc.gnu.org/PR88927. Reviewed-on: https://go-review.googlesource.com/c/158717 Added: trunk/libgo/go/internal/cpu/cpu_arm.go Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/runtime/os_linux_arm.go
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182 --- Comment #20 from joseph at codesourcery dot com --- r261797 removed all references to _ANSI_H_ from stddef.h, so this issue can't be relevant after then.
[Bug c/88963] New: gcc generates terrible code for vectors of 64+ length which are not natively supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963
Bug ID: 88963
Summary: gcc generates terrible code for vectors of 64+ length
which are not natively supported
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
typedef int VInt __attribute__((vector_size(64)));
void test(VInt*__restrict a, VInt*__restrict b,
VInt*__restrict c)
{
*a = *b + *c;
}
[/code]
This code compiled with -O3 -march=skylake in following way:
[asm]
test(int __vector(16)*, int __vector(16)*, int __vector(16)*):
push rbp
mov rbp, rsp
and rsp, -64
sub rsp, 136
vmovdqa xmm3, XMMWORD PTR [rsi]
vmovdqa xmm4, XMMWORD PTR [rsi+16]
vmovdqa xmm5, XMMWORD PTR [rsi+32]
vmovdqa xmm6, XMMWORD PTR [rsi+48]
vmovdqa xmm7, XMMWORD PTR [rdx]
vmovaps XMMWORD PTR [rsp-56], xmm3
vmovdqa xmm1, XMMWORD PTR [rdx+16]
vmovaps XMMWORD PTR [rsp-40], xmm4
vmovdqa ymm4, YMMWORD PTR [rsp-56]
vmovdqa xmm2, XMMWORD PTR [rdx+32]
vmovaps XMMWORD PTR [rsp-8], xmm6
vmovaps XMMWORD PTR [rsp+8], xmm7
vmovdqa xmm3, XMMWORD PTR [rdx+48]
vmovaps XMMWORD PTR [rsp-24], xmm5
vmovaps XMMWORD PTR [rsp+24], xmm1
vpaddd ymm0, ymm4, YMMWORD PTR [rsp+8]
vmovdqa ymm5, YMMWORD PTR [rsp-24]
vmovaps XMMWORD PTR [rsp+40], xmm2
vmovaps XMMWORD PTR [rsp+56], xmm3
vmovdqa xmm2, xmm0
vmovdqa YMMWORD PTR [rsp-120], ymm0
vpaddd ymm0, ymm5, YMMWORD PTR [rsp+40]
vmovdqa xmm6, XMMWORD PTR [rsp-104]
vmovdqa YMMWORD PTR [rsp-88], ymm0
vmovdqa xmm7, XMMWORD PTR [rsp-72]
vmovaps XMMWORD PTR [rdi], xmm2
vmovaps XMMWORD PTR [rdi+16], xmm6
vmovaps XMMWORD PTR [rdi+32], xmm0
vmovaps XMMWORD PTR [rdi+48], xmm7
vzeroupper
leave
ret
[/asm]
Other compilers (clang, icc) produces nice code. This is from clang:
[asm]
test(int __vector(16)*, int __vector(16)*, int __vector(16)*): # @test(int
__vector(16)*, int __vector(16)*, int __vector(16)*)
vmovdqa ymm0, ymmword ptr [rdx]
vmovdqa ymm1, ymmword ptr [rdx + 32]
vpaddd ymm0, ymm0, ymmword ptr [rsi]
vpaddd ymm1, ymm1, ymmword ptr [rsi + 32]
vmovdqa ymmword ptr [rdi + 32], ymm1
vmovdqa ymmword ptr [rdi], ymm0
vzeroupper
ret
[/asm]
gcc produces pretty code for -O3 -march=skylake-avx512. Pretty code is also for
vector size 32 with AVX disabled. However for vector size 128 and -O3
-march=skylake-avx512 code is again ugly.
[Bug fortran/88821] Inline packing of non-contiguous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821 --- Comment #2 from Thomas Koenig --- Created attachment 45486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45486=edit patch that appears to work Plus a few additional test cases (it is necessary to split a few, because internal_pack is no longer called with -O0 with this approach).
[Bug c++/87996] [8/9 Regression] "size of array is negative" error when SIZE_MAX/2 < sizeof(array) <= SIZE_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87996 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Let me work on this.
[Bug c++/88949] ICE in expand_expr_real_1, at expr.c:10001 with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Jan 21 22:33:52 2019 New Revision: 268127 URL: https://gcc.gnu.org/viewcvs?rev=268127=gcc=rev Log: PR c++/88949 * optimize.c (cxx_copy_decl): New function. (clone_body): Use it instead of copy_decl_no_change. * g++.dg/gomp/pr88949.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr88949.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/optimize.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #9 from Vladimir Makarov --- (In reply to Vladimir Makarov from comment #8) > Created attachment 45485 [details] > Proposed patch Does this patch solves the problem?
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #8 from Vladimir Makarov --- Created attachment 45485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45485=edit Proposed patch
[Bug tree-optimization/88753] [9 Regression] Wrong code since r265463 in tree switch conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88753 Dimitar Dimitrov changed: What|Removed |Added CC||dinuxbg at gmail dot com --- Comment #7 from Dimitar Dimitrov --- *** Bug 88609 has been marked as a duplicate of this bug. ***
[Bug target/88609] [avr] ice: insn does not satisfy its constraints while building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88609 Dimitar Dimitrov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dimitar Dimitrov --- Not an avr backend issue, but rather due to PR88753 bug in the host toolchain. *** This bug has been marked as a duplicate of bug 88753 ***
[Bug target/88962] Invalid/inconsistent PowerPC TLS variable access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962 --- Comment #2 from Jiri Svoboda --- I added the -fno-section-anchors option to both the compile and link invocations but I am still getting the same result.
[Bug target/88954] __attribute__((noplt)) doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
--- Comment #2 from H.J. Lu ---
(In reply to Martin Sebor from comment #1)
> I'm wondering if noplt is meant to be a property of the function pointer or
> that of its type?
>
> Either way, what should happen in cases when a noplt pointer is assigned the
> address of a PLT function? E.g.,:
>
> void (*p_noplt)(void) = f_noplt;
>
> void f (int i)
> {
> if (i < 0)
> p_noplt = f_plt;
> }
>
> Do calls through p_noplt still happen without the use of the PLT after the
> assignment? Should a warning be issued when a noplt pointer is assigned the
> address of an ordinary PLT function?
noplt attribute only applies to function, not function pointer.
[Bug target/88962] Invalid/inconsistent PowerPC TLS variable access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962 --- Comment #1 from Andrew Pinski --- What happens if you use -fno-section-anchors option? My bet is the section anchor is setting the bias for the static variables to be 32k off of the center.
[Bug target/88954] __attribute__((noplt)) doesn't work with function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #1 from Martin Sebor ---
I'm wondering if noplt is meant to be a property of the function pointer or
that of its type?
Either way, what should happen in cases when a noplt pointer is assigned the
address of a PLT function? E.g.,:
void (*p_noplt)(void) = f_noplt;
void f (int i)
{
if (i < 0)
p_noplt = f_plt;
}
Do calls through p_noplt still happen without the use of the PLT after the
assignment? Should a warning be issued when a noplt pointer is assigned the
address of an ordinary PLT function?
[Bug target/88962] New: Invalid/inconsistent PowerPC TLS variable access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
Bug ID: 88962
Summary: Invalid/inconsistent PowerPC TLS variable access
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jirik.svoboda at seznam dot cz
Target Milestone: ---
If I build a GCC cross-compiler for PowerPC (ppc-linux-gnu):
binutils-2.31.1
./configure --target=ppc-linux-gnu --prefix=... --dsiable-nls --disable-werror
--enable-gold --enable-deterministic-archives
make all
make install
gcc-8.2.0
./configure --target=ppc-linux-gnu --prefix=... --with-gnu-as --with-gnu-ld
--disable-nls --disable-threads --enable-languages=c --disable-multilib
--disable-libgcj --without-headers --disable-shared --enable-lto
--disable-werror
make all-gcc
make install-gcc
and then build a shared library that accesses a static thread-local variable
and a non-static thread-local variable:
[jirka@omelette tmp]$ cat test.c
static __thread int a;
__thread int b;
int geta(void)
{
return a;
}
int getb(void)
{
return b;
}
int seta(int n)
{
a = n;
}
[jirka@omelette tmp]$ /usr/local/xcross/ppc-linux-gnu/bin/ppc-linux-gnu-gcc
-nostdlib -fPIC -O3 -c -o test.o test.c
[jirka@omelette tmp]$ /usr/local/xcross/ppc-linux-gnu/bin/ppc-linux-gnu-gcc
-nostdlib -shared -fPIC -O3 -o test.so test.o
[jirka@omelette tmp]$ /usr/local/xcross/ppc-linux-gnu/bin/ppc-linux-gnu-objdump
-D test.so
0248 :
248: 7c 08 02 a6 mflrr0
24c: 42 9f 00 09 bcl 20,4*cr7+so,254
250: 00 01 fd c4 .long 0x1fdc4
254: 7d 28 02 a6 mflrr9
258: 94 21 ff f0 stwur1,-16(r1)
25c: 80 69 00 00 lwz r3,0(r9)
260: 90 01 00 14 stw r0,20(r1)
264: 7c 69 1a 14 add r3,r9,r3
268: 93 c1 00 08 stw r30,8(r1)
26c: 38 63 ff f4 addir3,r3,-12
270: 48 01 fd f9 bl 20068 <__tls_get_addr@plt>
274: 80 01 00 14 lwz r0,20(r1)
278: 3c 63 00 00 addis r3,r3,0
27c: 83 c1 00 08 lwz r30,8(r1)
280: 38 63 80 04 addir3,r3,-32764 <--- subtract bias 32K
284: 7c 08 03 a6 mtlrr0
288: 80 63 00 00 lwz r3,0(r3)
28c: 38 21 00 10 addir1,r1,16
290: 4e 80 00 20 blr
0294 :
294: 7c 08 02 a6 mflrr0
298: 42 9f 00 09 bcl 20,4*cr7+so,2a0
29c: 00 01 fd 78 .long 0x1fd78
2a0: 7d 28 02 a6 mflrr9
2a4: 94 21 ff f0 stwur1,-16(r1)
2a8: 80 69 00 00 lwz r3,0(r9)
2ac: 90 01 00 14 stw r0,20(r1)
2b0: 7c 69 1a 14 add r3,r9,r3
2b4: 93 c1 00 08 stw r30,8(r1)
2b8: 38 63 ff ec addir3,r3,-20
2bc: 48 01 fd ad bl 20068 <__tls_get_addr@plt>
2c0: 80 01 00 14 lwz r0,20(r1)
2c4: 80 63 00 00 lwz r3,0(r3)< no bias subtracted
2c8: 83 c1 00 08 lwz r30,8(r1)
2cc: 7c 08 03 a6 mtlrr0
2d0: 38 21 00 10 addir1,r1,16
2d4: 4e 80 00 20 blr
As you can see, for static thread-local variable, we subtract 32K bias from
result of __tls_get_addr@plt. For non-static thread-local variable, we do not
subtract anything. This looks like a bug.
For -O0 optimization we never subtract anything.
Not sure which behavior is correct -- subtract 32 K or not) -- I ran into this
when implementing PowerPC architecture support for HelenOS dynamic linker. I am
inclined to think it should always subtract 32K bias according to the ABI. In
any case I think it needs to behave consistently, otherwise cannot make the TLS
work in all cases.
[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936 --- Comment #8 from Sergei Trofimovich --- (In reply to Martin Liška from comment #3) > Confirmed, started with r231498. That was really fast! Minor comment: 'git tag' says that revision was added before gcc-6.1.0. Running test locally says 6.4.0 (and 6.5.0) is also broken. Last working version was gcc-5.5.0. Or I'm interpreting the field 'Known to work: 6.4.0' incorrectly and it's the token past support horizon?
[Bug fortran/88961] New: valgrind error in resolve_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961 Bug ID: 88961 Summary: valgrind error in resolve_ref Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For a valgrind version of recent gcc trunk and testsuite file ./gfortran.dg/actual_array_substr_3.f90, I get ./gfortran.dg/actual_array_substr_3.f90 ==5000== Invalid read of size 8 ==5000==at 0x68A150: resolve_ref(gfc_expr*) (resolve.c:5082) ==5000==by 0x683DE3: resolve_variable (resolve.c:5536) ==5000==by 0x683DE3: gfc_resolve_expr(gfc_expr*) (resolve.c:6852) ==5000==by 0x68635D: resolve_actual_arglist(gfc_actual_arglist*, procedure_type, bool) (resolve.c:1916) $ ~/gcc/results/bin/gfortran -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gfortran COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.268000.valgrind/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.268000.valgrind --disable-bootstrap --disable-multilib --disable-werror --enable-checking=valgrind --enable-languages=c,c++,fortran Thread model: posix gcc version 9.0.0 20190117 (experimental) (GCC) $
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #19 from Wilco --- (In reply to Segher Boessenkool from comment #18) > https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html Thanks, I hadn't noticed that yet... I need to look at it in more detail, but are you saying that combine no longer generates zero_extracts today and all patterns that rely on it must be changed to a different canonical form? I suspect the tst_5/6 cases are similar if the canonical form of rtl has changed. Note that doing (x & 63) != 0 just works fine, it's only 255 and 65535 which appear to be treated differently...
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #18 from Jakub Jelinek --- The comment on the define_insn_and_split says: ;; Combiner patterns with the vector reduction patterns that knows we can get ;; to the top element of the V2DF array without doing an extract. So, the question is, is that ever the case for little endian also? As I said, --- gcc/config/rs6000/vsx.md2019-01-19 09:39:13.224924063 +0100 +++ gcc/config/rs6000/vsx.md2019-01-21 22:04:15.372792335 +0100 @@ -4351,7 +4351,7 @@ (match_dup 1)) (parallel [(const_int 1)]))) (clobber (match_scratch:DF 2 "=0,0,,"))] - "VECTOR_UNIT_VSX_P (V2DFmode)" + "BYTES_BIG_ENDIAN && VECTOR_UNIT_VSX_P (V2DFmode)" "#" "" [(const_int 0)] generates much better code at least on this testcase, and from bootstrap/regtest I'm not away of this pattern ever trigging for something different.
[Bug middle-end/88950] stack_protect_prologue can be reordered by sched1 around memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88950 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064 --- Comment #17 from Bill Schmidt --- Actually I *think* the *vsx_reduc__v4sf_scalar code is probably okay. This is all being done with insns that should leave the reduction result in the right-hand element of the register (element 3 for BE, as is referenced in the xxsldwi insn). I'll regtest a patch with Jakub's second alternative from above, which matches my understanding of the current flaw. Bill
[Bug c++/86943] [7/8/9 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/87064] [9 regression] libgomp.oacc-fortran/reduction-3.f90 fails starting with r263751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87064
--- Comment #16 from Bill Schmidt ---
(In reply to Jakub Jelinek from comment #13)
> So, both the following patches should fix it IMHO, but no idea which one if
> any is right.
> With
> --- gcc/config/rs6000/vsx.md.jj 2019-01-01 12:37:44.305529527 +0100
> +++ gcc/config/rs6000/vsx.md 2019-01-18 18:07:37.194899062 +0100
> @@ -4356,7 +4356,9 @@
>""
>[(const_int 0)]
> {
> - rtx hi = gen_highpart (DFmode, operands[1]);
> + rtx hi = (BYTES_BIG_ENDIAN
> + ? gen_highpart (DFmode, operands[1])
> + : gen_lowpart (DFmode, operands[1]));
>rtx lo = (GET_CODE (operands[2]) == SCRATCH)
> ? gen_reg_rtx (DFmode)
> : operands[2];
>
> the assembly changes:
> --- reduction-3.s12019-01-18 18:05:14.313229730 +0100
> +++ reduction-3.s22019-01-18 18:10:20.617233358 +0100
> @@ -27,7 +27,7 @@ MAIN__._omp_fn.0:
> addi 9,9,16
> bdnz .L2
># vec_extract to same register
> - lfd 12,-8(1)
> + lfd 12,-16(1)
> xsmaxdp 0,12,0
> stfd 0,0(10)
> blr
> with:
> --- gcc/config/rs6000/vsx.md.jj 2019-01-01 12:37:44.305529527 +0100
> +++ gcc/config/rs6000/vsx.md 2019-01-18 18:16:30.680186709 +0100
> @@ -4361,7 +4361,9 @@
> ? gen_reg_rtx (DFmode)
> : operands[2];
>
> - emit_insn (gen_vsx_extract_v2df (lo, operands[1], const1_rtx));
> + emit_insn (gen_vsx_extract_v2df (lo, operands[1],
> +BYTES_BIG_ENDIAN
> +? const1_rtx : const0_rtx));
>emit_insn (gen_df3 (operands[0], hi, lo));
>DONE;
> }
This is what looks right to me. This code all pre-dates little-endian support,
and I think we missed changing the element to be extracted in this spot. There
is probably something wrong with _v4sf_scalar also -- the gen_vsx_xxsldwi_v4sf
probably needs to be adjusted also for little-endian, but I have a hard time
following this code and I'm not certain.
Bill
> the assembly changes:
> --- reduction-3.s12019-01-18 18:05:14.313229730 +0100
> +++ reduction-3.s32019-01-18 18:17:18.977397458 +0100
> @@ -26,7 +26,7 @@ MAIN__._omp_fn.0:
> xxpermdi 0,0,0,2
> addi 9,9,16
> bdnz .L2
> - # vec_extract to same register
> + xxpermdi 0,0,0,3
> lfd 12,-8(1)
> xsmaxdp 0,12,0
> stfd 0,0(10)
>
> So just judging from this exact testcase, the first patch seems to be more
> efficient, though still unsure about that, because it goes through memory in
> either case, wouldn't it be better to emit a xxpermdi from 0 to 12 that
> swaps the two elements instead of loading it from memory?
[Bug c++/87935] [9 regression] new failures on arm since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935 Jason Merrill changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #5 from Jason Merrill --- *** Bug 88787 has been marked as a duplicate of this bug. ***
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Jason Merrill --- . *** This bug has been marked as a duplicate of bug 87935 ***
[Bug c++/87935] [9 regression] new failures on arm since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935 --- Comment #4 from Jason Merrill --- *** Bug 87893 has been marked as a duplicate of this bug. ***
[Bug c++/87893] [9 Regression] ICE in gimplify_expr, at gimplify.c:12557 on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87893 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- . *** This bug has been marked as a duplicate of bug 87935 ***
[Bug c++/87935] [9 regression] new failures on arm since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935 Jason Merrill changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Jason Merrill --- *** Bug 88616 has been marked as a duplicate of this bug. ***
[Bug target/88616] [9 Regression] ICE in gimplify_expr at gcc/gimplify.c:13363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88616 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jason Merrill --- . *** This bug has been marked as a duplicate of bug 87935 ***
[Bug c++/88787] [9 regression] C++ constexpr seems to not get expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/87770] [8/9 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770 --- Comment #5 from Konrad Dabrowski --- (In reply to Alexandre Oliva from comment #4) > Created attachment 45448 [details] > Candidate patch I don't know enough about gcc to assess whether this is the "correct" solution, but I can confirm that this patch prevents the ICE both in trunk and in the gcc-8 branch. (It also fixes the ICE in the duplicate bug #87714.)
[Bug c++/87893] [9 Regression] ICE in gimplify_expr, at gimplify.c:12557 on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87893 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/87935] [9 regression] new failures on arm since r265788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87935 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||aoliva at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/88850] [9 Regression] Hard register coming out of expand causing reload to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850 --- Comment #6 from Vladimir Makarov --- (In reply to Tamar Christina from comment #5) > So yeah it seems that there are three issues here: > > 1) We should probably have an r -> r alternative for *neon_mov. > 2) The costs are now flipped from what they were before, for some reason the > VFP regs are now way more expensive. > 3) reload shouldn't have ICEd since it says > > r113: preferred GENERAL_REGS, alternative ALL_REGS, allocno ALL_REGS > > so it hasn't excluded ALL_REGS as an alternative, which should have either > a) used the VPF register again or > b) spilled the register since we have a m -> r and r -> m pattern. p113 is used in 2 move insns, both containing 2 general hard regs (r0 and r2). So it is natural to use general regs for p113. At least arm_register_move_cost says this. LRA does not check constraints because arm_register_move_cost for general regs in any mode returns 2. Such LRA/reload behaviour for cost 2 is described in gcc documentation. So adding r,r alternative to neon_movv8qi or increasing move cost for GENERAL_REGS or both will solve the problem. Actually the cost should be increased in anyway. It can not be 2 because we need 2 general hard regs for V8QImode. And this is a work for arm target maintainers.
[Bug target/88938] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88938 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Mon Jan 21 20:14:40 2019 New Revision: 268123 URL: https://gcc.gnu.org/viewcvs?rev=268123=gcc=rev Log: PR target/88938 * config/i386/i386.c (ix86_expand_builtin) [case IX86_BUILTIN_BEXTRI32, case IX86_BUILTIN_BEXTRI64]: Sanitize operands. testsuite/ChangeLog: PR target/88938 * gcc.target/i386/pr88938.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr88938.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/88901] ICE when using -fsanitize=pointer-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #4 from Jürgen Reuter --- It seems that at least Thomas and Dominique believe that this can be closed.
[Bug fortran/88960] [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960 --- Comment #1 from Nathan Weeks --- Note that GET_TEAM() itself is currently broken in gfortran (pr88154).
[Bug sanitizer/88901] ICE when using -fsanitize=pointer-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Jan 21 19:53:04 2019 New Revision: 268122 URL: https://gcc.gnu.org/viewcvs?rev=268122=gcc=rev Log: PR sanitizer/88901 * typeck.c (cp_build_binary_op): Don't instrument SANITIZE_POINTER_COMPARE if processing_template_decl. (pointer_diff): Similarly for SANITIZE_POINTER_SUBTRACT. * g++.dg/asan/pr88901.C: New test. Added: trunk/gcc/testsuite/g++.dg/asan/pr88901.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/88956] [9 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-21 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Confirmed on x86_64-linux-gnu.
[Bug fortran/88960] New: [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88960 Bug ID: 88960 Summary: [F18] ISO_FORTRAN_ENV: add INITIAL_TEAM, PARENT_TEAM, and CURRENT_TEAM Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: weeks at iastate dot edu Target Milestone: --- The Fortran 2018 standard (N2146 draft) defines the GET_TEAM() intrinsic function as: == 16.9.85 GET_TEAM ([LEVEL]) ... 3 Argument. LEVEL (optional) shall be a scalar integer whose value is equal to one of the named constants INITIAL_TEAM, PARENT_TEAM, or CURRENT_TEAM from the intrinsic module ISO_FORTRAN_ENV. == gfortran 8.2.0 does not provide these constants in ISO_FORTRAN_ENV: == $ cat test_level.f90 use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM end $ gfortran test_level.f90 test_level.f90:1:41: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'initial_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV test_level.f90:1:55: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'parent_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV test_level.f90:1:68: use, intrinsic :: iso_fortran_env, only: INITIAL_TEAM, PARENT_TEAM, CURRENT_TEAM 1 Error: Symbol 'current_team' referenced at (1) not found in intrinsic module ISO_FORTRAN_ENV ==
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #18 from Segher Boessenkool --- https://gcc.gnu.org/ml/gcc/2019-01/msg00112.html
[Bug c++/88293] [9 Regression] ICE on C++11 code: in build_target_expr_with_type, at cp/tree.c:793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88293 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/88294] [9 Regression] ICE on (invalid) C++11 code: in tsubst_copy, at cp/pt.c:15391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Jason Merrill --- Marek, this seems related to your recent patch for 86476, want to take it?
[Bug c/88959] Unnecessary xor before bsf/tzcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Uroš Bizjak --- This is by design, see x86-tune.def: /* X86_TUNE_AVOID_FALSE_DEP_FOR_BMI: Avoid false dependency for bit-manipulation instructions. */ DEF_TUNE (X86_TUNE_AVOID_FALSE_DEP_FOR_BMI, "avoid_false_dep_for_bmi", m_SANDYBRIDGE | m_CORE_AVX2 | m_GENERIC)
[Bug c++/86205] [9 Regression] ICE on valid C++11 code: in type_dependent_expression_p, at cp/pt.c:25193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug rtl-optimization/88953] Unrecognizable insn on architecture zEC12 with boost::bimap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953 --- Comment #3 from Jakub Jelinek --- Can't reproduce with a cross-compiler, neither current 8.2.1 with -O3 -march=zEC12 nor -O3 -march=z14, nor with current trunk and the same options.
[Bug c++/88949] ICE in expand_expr_real_1, at expr.c:10001 with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-01-21 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 45484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45484=edit gcc9-pr88949.patch Untested fix.
[Bug c/88955] transparent_union for vector types not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955 --- Comment #1 from Alexander Monakov --- (In reply to Alexander Monakov from comment #0) > Adding a dummy __int128 field makes GCC accept the code (but such workaround > won't work for wider vectors, or on 32-bit). But this causes the union to be passed in a pair of general 64-bit registers (as expected for __int128) rather than in an SSE register. So that's not a suitable workaround.
[Bug tree-optimization/88916] [x86] suboptimal code generated for integer comparisons joined with boolean operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88916 --- Comment #2 from Wojciech Mula --- (In reply to Richard Biener from comment #1) > Confirmed. The first case is OK, but the second (for `both_nonzero`) is obviously wrong. Sorry for that.
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #17 from Wilco --- (In reply to Vladimir Makarov from comment #14) > I've checked cvtf_1.c generated code and I don't see additional fmov > anymore. I guess it was fixed by an ira-costs.c change (a special > consideration of moves containing hard regs). I think this PR is resolved > (although the change resulted in a new PR 88560 but it is a different story). Some failures disappeared, however various failures still exist. It appears the ones reported above are not all directly related to the move change, but another change around the same time. For example all of these are due to combine no longer creating bfi or tst instructions in trivial cases: FAIL: gcc.target/aarch64/combine_bfi_1.c scan-assembler-times \\tbfi\\t 5 FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 0, 8 FAIL: gcc.target/aarch64/insv_1.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 16, 5 FAIL: gcc.target/aarch64/insv_1.c scan-assembler movk\tx[0-9]+, 0x1d6b, lsl 32 FAIL: gcc.target/aarch64/insv_2.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 43, 5 FAIL: gcc.target/aarch64/insv_2.c scan-assembler bfi\tx[0-9]+, x[0-9]+, 56, 8 FAIL: gcc.target/aarch64/insv_2.c scan-assembler movk\tx[0-9]+, 0x1d6b, lsl 16 FAIL: gcc.target/aarch64/lsl_asr_sbfiz.c scan-assembler sbfiz\tw FAIL: gcc.target/aarch64/tst_5.c scan-assembler tst\t(x|w)[0-9]+,[ \t]*255 FAIL: gcc.target/aarch64/tst_5.c scan-assembler tst\t(x|w)[0-9]+,[ \t]*65535 FAIL: gcc.target/aarch64/tst_6.c scan-assembler tst\t(x|w)[0-9]+,[ \t]*65535 > If we want to improve the generated code size, it would be better to find > a small testcase from SPEC2006 showing what is wrong. I understand it is a > hard work but otherwise we could only speculate what is going wrongly. I > don't think that reverting the combiner change would be a solution. Yes it's hard to get good reproducible examples, especially from large functions. It's easier to first sort out the known test failures.
[Bug c/87038] diagnostics: Have -Wjump-misses-init be enabled by -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 --- Comment #23 from Harald van Dijk --- (In reply to Eric Gallager from comment #22) > (In reply to Harald van Dijk from comment #21) > > Since -Wjump-misses-init triggers too often for commonly used C patterns, > > I do not think it is appropriate to include it in -Wall. > > OK, so what about -Wextra then? My personal feeling as a user is that clang's warning is useful enough that if GCC were to implement that, that one could be included in -Wall. It avoids warning for the common cases where code works as intended, and still manages to warn for the OP's code. I do not know how much work it would be to implement that; if it would be too much work, then including -Wjump-misses-init in -Wextra makes sense to me.
[Bug target/88847] gcc.target/aarch64/sve/struct_move_1.c ICE with -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88847 --- Comment #3 from Tamar Christina --- right, so it seems this is an SVE issue and doesn't have much to do with stack protector. The issue is that aarch64_sve_struct_memory_operand_p doesn't take into account whether it is before or after reload. Before reload we need to allow any offset since reload would do what it does and either split it or make the address legitimate in some way.
[Bug c/88959] Unnecessary xor before bsf/tzcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959 --- Comment #1 from Daniel Fruzynski --- I have found that this extra xor is not added when compiling with -O3 -march=sandybridge or -O3 -march=ivydybridge. However with -O3 -march=sandybridge/ivydybridge -mbmi it is added.
[Bug c++/88501] Improve suggested alternative to be closer to typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88501 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88944 --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #9) > That's only relevant for C, not C++, so should be a separate bug. It's now bug 88944
[Bug c/87038] diagnostics: Have -Wjump-misses-init be enabled by -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 Eric Gallager changed: What|Removed |Added Summary|diagnostics: Please add |diagnostics: Have |warning for jumping over|-Wjump-misses-init be |initializers with |enabled by -Wall or -Wextra |switch/case in C mode | --- Comment #22 from Eric Gallager --- Retitling to better reflect what the debate is actually about. (In reply to Harald van Dijk from comment #21) > Since -Wjump-misses-init triggers too often for commonly used C patterns, > I do not think it is appropriate to include it in -Wall. OK, so what about -Wextra then?
[Bug c/88959] New: Unnecessary xor before bsf/tzcnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88959
Bug ID: 88959
Summary: Unnecessary xor before bsf/tzcnt
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
[code]
int test(int x)
{
return __builtin_ctz(x);
}
[/code]
gcc 4.9.1 with -O3 produces this:
[asm]
test(int):
rep bsf eax, edi
ret
[/asm]
And this with -O3 -mbmi:
[asm]
test(int):
tzcnt eax, edi
ret
[/asm]
gcc 4.9.2 and newer (including gcc 9) produces this for both cases:
[asm]
test(int):
xor eax, eax
rep bsf eax, edi
ret
[/asm]
[asm]
test(int):
xor eax, eax
tzcnt eax, edi
ret
[/asm]
This extra xor instruction is not needed here.
[Bug d/88958] ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958 --- Comment #1 from G. Steinmetz --- $ gdc-9-20190120 -c z1.d -O0 $ $ gdc-9-20190120 -c z1.d -O1 during GIMPLE pass: fre In function 'h': d21: internal compiler error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:976 0xce83a5 copy_reference_ops_from_ref ../../gcc/tree-ssa-sccvn.c:976 0xce90a5 valueize_shared_reference_ops_from_ref ../../gcc/tree-ssa-sccvn.c:1626 0xcea5a9 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool) ../../gcc/tree-ssa-sccvn.c:2708 0xcf16f9 visit_reference_op_load ../../gcc/tree-ssa-sccvn.c:4067 0xcf16f9 visit_stmt ../../gcc/tree-ssa-sccvn.c:4485 0xcf2aeb process_bb ../../gcc/tree-ssa-sccvn.c:6055 0xcf3eff do_rpo_vn ../../gcc/tree-ssa-sccvn.c:6662 0xcf4e2c execute ../../gcc/tree-ssa-sccvn.c:6797
[Bug d/88958] New: ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88958
Bug ID: 88958
Summary: ICE in walk_aliased_vdefs_1, at tree-ssa-alias.c:2887
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
With following snippet :
$ cat z1.d
void f(int) {}
void g(...) {}
void h()
{
g(*);
}
$ gdc-9-20190120 -c z1.d
$
$ gdc-9-20190120 -c z1.d -O0 -Wextra
during GIMPLE pass: *early_warn_uninitialized
In function 'h':
d21: internal compiler error: Segmentation fault
0xb821cf crash_signal
../../gcc/toplev.c:326
0xc4f63c walk_aliased_vdefs_1
../../gcc/tree-ssa-alias.c:2887
0xc4f7e1 walk_aliased_vdefs(ao_ref*, tree_node*, bool (*)(ao_ref*, tree_node*,
void*), void*, bitmap_head**, bool*, unsigned int)
../../gcc/tree-ssa-alias.c:2945
0xd34d04 warn_uninitialized_vars
../../gcc/tree-ssa-uninit.c:342
0xd34f80 execute_early_warn_uninitialized
../../gcc/tree-ssa-uninit.c:2736
0xd34f80 execute
../../gcc/tree-ssa-uninit.c:2771
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #16 from Segher Boessenkool --- (In reply to Wilco from comment #13) > (In reply to Segher Boessenkool from comment #12) > > Before the change combine forwarded all argument (etc.) hard registers > > wherever > > it could, doing part of RA's job (and doing a lousy job of it). If after > > the > > change it no longer two ranges, than a) that is a good decision, or b) there > > is > > some bug in RA. > > I think it's important not to conflate avoiding increasing live ranges of > hard registers and inserting redundant extra moves which cannot be > optimized. The former unconditionally looks like a good idea, however I > can't see any valid reasoning for the latter. Good thing then that that is not what is done! > Basically we now always get 2 moves for every physical register, Huh? The combiner inserts an extra move, yes, but it will always optimise it away again. Unless something in your target code prevents that? (The extra moves are needed because combining a move with some compare or similar can result in a two-output insn, like adds on arm for example). > and this seems to thwart register preferencing. > > > 0.05% code size is nothing, most other biggish changes have a much bigger > > effect. > > Compiler optimization is all about making many small changes which add up to > a large improvement. This is actually quite significant given practically > all code is affected negatively. No, 0.05% code size is nothing. _Especially_ where accompanied by a run time improvement. And it fixes some ICEs, too.
[Bug d/88957] New: ICE: Segmentation fault in tree_could_trap_p, at tree-eh.c:2672
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88957
Bug ID: 88957
Summary: ICE: Segmentation fault in tree_could_trap_p, at
tree-eh.c:2672
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
With option -fsanitize=undefined at -O[23] :
$ cat z1.d
int f (const int[4] x)
{
int sum = 0;
foreach (i; x) sum += i;
return sum;
}
void main ()
{
import core.simd : int4;
f(int4.init.array);
}
$ gdc-9-20190120 -c z1.d -O2
$
$ gdc-9-20190120 -c z1.d -O2 -fsanitize=undefined
during RTL pass: expand
z1.d: In function 'D main':
z1.d:10:5: internal compiler error: Segmentation fault
10 | f(int4.init.array);
| ^
0xb821cf crash_signal
../../gcc/toplev.c:326
0xbd18d3 tree_could_trap_p(tree_node*)
../../gcc/tree-eh.c:2672
0x8a09e4 set_mem_attributes_minus_bitpos(rtx_def*, tree_node*, int,
poly_int<1u, long>)
../../gcc/emit-rtl.c:2016
0x8c9c54 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10327
0x8d47f6 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5648
0x8d553e expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5431
0x7d0f28 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3752
0x7d0f28 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x7d3167 expand_gimple_basic_block
../../gcc/cfgexpand.c:5886
0x7d87a6 execute
../../gcc/cfgexpand.c:6509
[Bug c/88956] New: [9 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88956
Bug ID: 88956
Summary: [9 Regression] ICE: Floating point exception
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20180708 and 20180722 :
$ cat z1.c
const char a[0][0] = { };
char b[3];
void f (void)
{
__builtin_memcpy (b, a, 2);
}
$ gcc-9-20180708 -c z1.c
$
$ gcc-9-20190120 -c z1.c
during GIMPLE pass: lower
z1.c: In function 'f':
z1.c:3:6: internal compiler error: Floating point exception
3 | void f (void)
| ^
0xa8afef crash_signal
../../gcc/toplev.c:326
0x837abc fold_array_ctor_reference
../../gcc/gimple-fold.c:6732
0x837abc fold_ctor_reference(tree_node*, tree_node*, poly_int<1u, unsigned
long> const&, poly_int<1u, unsigned long> const&, tree_node*, unsigned long*)
../../gcc/gimple-fold.c:6925
0x7ccb38 string_constant(tree_node*, tree_node**, tree_node**, tree_node**)
../../gcc/expr.c:11533
0x6b11ee c_strlen(tree_node*, int, c_strlen_data*, unsigned int)
../../gcc/builtins.c:676
0x83c2c0 gimple_fold_builtin_memory_op
../../gcc/gimple-fold.c:760
0x83dbbf gimple_fold_builtin
../../gcc/gimple-fold.c:3849
0x8407db gimple_fold_call
../../gcc/gimple-fold.c:4354
0x8407db fold_stmt_1
../../gcc/gimple-fold.c:5019
0x1197021 lower_stmt
../../gcc/gimple-low.c:387
0x1197021 lower_sequence
../../gcc/gimple-low.c:217
0x1196e88 lower_gimple_bind
../../gcc/gimple-low.c:473
0x1197bb1 lower_function_body
../../gcc/gimple-low.c:110
0x1197bb1 execute
../../gcc/gimple-low.c:195
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #15 from Eric Botcazou --- > If we want to improve the generated code size, it would be better to find > a small testcase from SPEC2006 showing what is wrong. I understand it is a > hard work but otherwise we could only speculate what is going wrongly. I > don't think that reverting the combiner change would be a solution. Maybe not reverting, but at least making it conditional per architecture by means of a hook. We have hooks for many obscure issues so having one for this rather visible issue (at least on some architectures) is in order IMO.
[Bug c++/88949] ICE in expand_expr_real_1, at expr.c:10001 with -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88949
--- Comment #1 from Jakub Jelinek ---
As it works with -DMETHOD -fopenmp, but doesn't with -fopenmp, it must be the
cdtor copying in the FE that breaks this.
struct A {
int a;
A (int x) : a (x)
#ifdef METHOD
{}
void foo ()
#endif
{
#pragma omp parallel firstprivate (a)
--a;
}
};
int c;
int
main ()
{
A d(c);
#ifdef METHOD
d.foo ();
#endif
}
[Bug libstdc++/88947] regex_match doesn't fail early when given a non-matching pattern with a start-of-input anchor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88947 --- Comment #3 from Tim Shen --- Thanks for reporting Tomalak. Yes, I agree that "match from the first character" should be expressable in the public interface, preferrably regex_search() with "^...". In fact, internally regex_search is implemented in terms of such semantic. As for other forms like "(^...)", or "(^abc|^xyz)", I'm sure we can go down the rabbit hole and support more of them, but IMO the gain is marginal if "^..." is supported.
[Bug rtl-optimization/88953] Unrecognizable insn on architecture zEC12 with boost::bimap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88953 --- Comment #2 from Jan Kossmann --- Created attachment 45483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45483=edit Preprocessed file and minimal cpp example This archive contains the preprocessed *.ii file, a .cpp and .hpp file. I was unable to reduce the file size of the *.ii file below 1000 KB because I had to include a boost header. However, the .cpp and .hpp files are combined only 10 LOC.
[Bug c/88955] New: transparent_union for vector types not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88955
Bug ID: 88955
Summary: transparent_union for vector types not accepted
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC (and Clang) rejects an attempt to create a transparent union corresponding
to an SSE register:
typedef unsigned long u64x2 __attribute__ ((vector_size (16)));
typedef union
__attribute__((transparent_union))
{
u64x2 u64;
} v128;
The diagnostic is not very clear about the reason:
union.i:3:9: warning: union cannot be made transparent
Looking in gdb, it appears that the union has mode TI, while its TYPE_FIELDS
has V2DI mode.
Adding a dummy __int128 field makes GCC accept the code (but such workaround
won't work for wider vectors, or on 32-bit).
The intended usecase for this is a vector union type for easier interop between
Intel intrinsics and user code written with generic vectors, as suggested by
Richard in https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01186.html
[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952 Andrew Pinski changed: What|Removed |Added Target||powerpc-*-* Status|RESOLVED|NEW Keywords||documentation Last reconfirmed||2019-01-21 Component|inline-asm |target Resolution|INVALID |--- Ever confirmed|0 |1 Summary|[powerpc] asm input from C |The asm operator modifiers |expression with type larger |for rs6000 should be |than GPRs loads wrong value |documented like they are ||for x86 --- Comment #4 from Andrew Pinski --- (In reply to Christopher Leonard from comment #2) > Surely then in the example if r9 is loaded with high and r10 with low then > %0 should be r10, not r9? %0 represents the first register which in this case is r9. The pair is r9:r10 to get the low part use %L0 . Really this should be documented like they are for x86: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Extended-Asm.html#x86-Operand-Modifiers
[Bug inline-asm/88952] [powerpc] asm input from C expression with type larger than GPRs loads wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952 --- Comment #3 from Christopher Leonard --- I understand it has to split it, the problem is that %0 defaults to the register holding the most-significant part of the integer. Is this really the desired behavior?
