[Bug tree-optimization/88497] Improve Accumulation in Auto-Vectorized Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Kewen Lin --- For the code in comment 9, now it generates the below code with the committed fix: : 0: 11 00 04 f4 lxv vs0,16(r4) 4: 11 00 c5 f4 lxv vs6,16(r5) 8: 31 00 44 f5 lxv vs10,48(r4) c: 31 00 e5 f4 lxv vs7,48(r5) 10: 01 00 84 f5 lxv vs12,0(r4) 14: 01 00 05 f5 lxv vs8,0(r5) 18: 21 00 64 f5 lxv vs11,32(r4) 1c: 21 00 25 f5 lxv vs9,32(r5) 20: 80 33 00 f0 xvmuldp vs0,vs0,vs6 24: 80 3b 4a f1 xvmuldp vs10,vs10,vs7 28: 08 43 0c f0 xvmaddadp vs0,vs12,vs8 2c: 90 54 8a f1 xxlor vs12,vs10,vs10 30: 08 4b 8b f1 xvmaddadp vs12,vs11,vs9 34: 00 63 00 f0 xvadddp vs0,vs0,vs12 38: 90 00 80 fd fmr f12,f0 3c: 50 03 00 f0 xxspltd vs0,vs0,1 40: 2a 00 0c fc faddf0,f12,f0 44: 2a 08 20 fc faddf1,f0,f1 48: 20 00 80 4e blr
[Bug tree-optimization/88497] Improve Accumulation in Auto-Vectorized Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497 --- Comment #10 from Kewen Lin --- Author: linkw Date: Mon Jul 15 05:12:05 2019 New Revision: 273490 URL: https://gcc.gnu.org/viewcvs?rev=273490=gcc=rev Log: gcc/ChangeLog 2019-07-15 Kewen Lin PR tree-optimization/88497 * tree-ssa-reassoc.c (reassociate_bb): Swap the positions of GIMPLE_BINARY_RHS check and gimple_visited_p check, call new function undistribute_bitref_for_vector. (undistribute_bitref_for_vector): New function. (cleanup_vinfo_map): Likewise. (sort_by_mach_mode): Likewise. gcc/testsuite/ChangeLog 2019-07-15 Kewen Lin PR tree-optimization/88497 * gcc.dg/tree-ssa/pr88497-1.c: New test. * gcc.dg/tree-ssa/pr88497-2.c: Likewise. * gcc.dg/tree-ssa/pr88497-3.c: Likewise. * gcc.dg/tree-ssa/pr88497-4.c: Likewise. * gcc.dg/tree-ssa/pr88497-5.c: Likewise. * gcc.dg/tree-ssa/pr88497-6.c: Likewise. * gcc.dg/tree-ssa/pr88497-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr88497-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug c++/91125] -frepo can't build tramp3d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 --- Comment #2 from Martin Liška --- Author: marxin Date: Mon Jul 15 04:11:43 2019 New Revision: 273489 URL: https://gcc.gnu.org/viewcvs?rev=273489=gcc=rev Log: Deprecate -frepo on gcc-9 branch (PR c++/91125). 2019-07-15 Martin Liska PR c++/91125 * c-opts.c (c_common_handle_option): Warn the -frepo will be removed in the future. 2019-07-15 Martin Liska PR c++/91125 * g++.dg/parse/repo1.C: Add scan for the new warning. * g++.dg/rtti/repo1.C: Likewise. * g++.dg/template/repo1.C: Likewise. * g++.dg/template/repo10.C: Likewise. * g++.dg/template/repo11.C: Likewise. * g++.dg/template/repo2.C: Likewise. * g++.dg/template/repo3.C: Likewise. * g++.dg/template/repo4.C: Likewise. * g++.dg/template/repo5.C: Likewise. * g++.dg/template/repo6.C: Likewise. * g++.dg/template/repo7.C: Likewise. * g++.dg/template/repo8.C: Likewise. * g++.dg/template/repo9.C: Likewise. * g++.old-deja/g++.pt/instantiate4.C: Likewise. * g++.old-deja/g++.pt/instantiate6.C: Likewise. * g++.old-deja/g++.pt/repo1.C: Likewise. * g++.old-deja/g++.pt/repo2.C: Likewise. * g++.old-deja/g++.pt/repo3.C: Likewise. * g++.old-deja/g++.pt/repo4.C: Likewise. Modified: branches/gcc-9-branch/gcc/c-family/ChangeLog branches/gcc-9-branch/gcc/c-family/c-opts.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/g++.dg/parse/repo1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/rtti/repo1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo1.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo10.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo11.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo2.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo3.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo4.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo5.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo6.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo7.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo8.C branches/gcc-9-branch/gcc/testsuite/g++.dg/template/repo9.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/instantiate4.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/instantiate6.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/repo1.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/repo2.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/repo3.C branches/gcc-9-branch/gcc/testsuite/g++.old-deja/g++.pt/repo4.C
[Bug rtl-optimization/90343] ICE: in verify_dominators, at dominance.c:1184 (error: dominator of 7 status unknown)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90343 Arseny Solokha changed: What|Removed |Added Known to fail|10.0| --- Comment #2 from Arseny Solokha --- I cannot reproduce it on the current trunk as of r273483. gcc 9 still ICEs w/ -fchecking, though.
[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233 --- Comment #7 from Jerry DeLisle --- Fixed on trunk. I am thinking backport this to enable gfortran 9 to not reject valid.
[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jul 14 22:52:58 2019 New Revision: 273484 URL: https://gcc.gnu.org/viewcvs?rev=273484=gcc=rev Log: 2019-07-14 Jerry DeLisle PR fortran/87233 * expr.c (check_restricted): Relax constraint C1279 which was removed from F2008 and above. * gfortran.dg/initialization_14.f90: Modify to now pass by removing two dg-error commands. Added comments. * gfortran.dg/initialization_30.f90: New test that includes the two tests removed above with the 'dg-options -std=f95'. Added: trunk/gcc/testsuite/gfortran.dg/initialization_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/initialization_14.f90
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Jakub Jelinek --- Invalid.
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158 --- Comment #7 from Cassio Neri --- (In reply to Jakub Jelinek from comment #4) Got it! Thank you, Mark and Jonathan. Please, feel free to close the ticket.
[Bug libstdc++/91156] The associated Laguerre polynomial should allow negative arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91156 --- Comment #3 from emsr at gcc dot gnu.org --- N.B. This 'bug' and the patches apply both to the 'regular' Laguerre polynomial laguerre(n,x) and to the associated Laguerre polynomial assoc_laguerre(n,m,x). Note that this gets rid of a throw or two. The mandated special function throws should become preconditions anyway. Later. Furthermore, if the not-so-special functions like pow, exp, sin, etc. can be constexpr then these can be too. Later.
[Bug libstdc++/91156] The associated Laguerre polynomial should allow negative arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91156 --- Comment #2 from emsr at gcc dot gnu.org --- Created attachment 46598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46598=edit Obvious patch... 2019-07-14 Edward Smith-Rowland <3dw...@verizon.net> * libstdc++-v3/include/tr1/poly_laguerre.tcc: Revove check for x >= 0. * libstdc++-v3/testsuite/special_functions/ 01_assoc_laguerre/check_value.cc: Extend testing to negative arguments. * libstdc++-v3/testsuite/special_functions/ 16_laguerre/check_value.cc: Ditto. * libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/ 01_assoc_laguerre/check_value.cc: Ditto. * libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/ 18_laguerre/check_value.cc: Ditto.
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158 --- Comment #6 from Marc Glisse --- A related common misconception is trying to write if constexpr (std::is_constant_evaluated()) except that this one is always true instead of always false.
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #5 from Jakub Jelinek ---
Something that might clarify it:
constexpr int foo (int n)
{
if constexpr (n)
return 1;
else
return 0;
}
constexpr int x = foo (1);
constexpr int y = foo (0);
This is invalid and rejected not just by G++ but by other compilers too. And
the thing is the same, when parsing foo, if constexpr needs a constant
expression, and n is not a constant expression at that point, even when it will
be during constexpr evaluation later on.
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Cassio Neri from comment #3) > Forget my use case and comments on dead code elimination. That was a > digression. (My bad.) In general, I don't expect `if` and `if constexpr` to > behave the same but I do in this particular case. (I might be wrong.) > Finally, since `__builtin_constant_p` is not standard this ticket is a > feature request, not a bug report. > > My reasoning is this: when the compiler sees `static_assert(f1(1));` it > enters a "constexpr evaluation mode" (not sure this is the right terminology > but you get the point). At this moment, regardless of optimization level the > compiler must propagate `1` to `f1` otherwise (generally speaking) it cannot > evaluate `f1(1)` and decide whether the `static_assert` passes or not. > Therefore, when it enters `f1` and sees `if constexpr > (__builtin_constant_p(n))` it is already in "constexpr evaluation mode" (so > `constexpr` here is redundant) and it knows `n == 1`. Hence, it should > evaluate `__builtin_constant_p(n)` to `1`. The problem is that with if constexpr, that if constexpr (__builtin_constant_p (n)) is seen already before the constexpr evaluation of the f1 function with a particular argument, during the parsing of that routine. And if constexpr says that a constant expression is needed right away at that spot, because whether the condition is true or false affects the instantiation of templates in the then or else body etc. And at that point n is a parameter, not a constant. __builtin_constant_p is either folded into 1 if the expression is constant, or deferred till later (if possible), or, if a constant value is required, folded to 0. And for if constexpr we can't defer till later and n isn't a constant, so it gets folded to 0.
[Bug c++/91165] New: error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
Bug ID: 91165
Summary: error: location references block not in block tree
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
template constexpr a b(a c) { return c; }
template struct e {
m f;
d g;
constexpr e(m c, d h) : f(c), g(h) {}
};
template constexpr e i(m &, d h) {
return e(c, b(h));
}
typedef enum { j } k;
class l {
e m_fn1() const;
};
void n() {
int a;
i(a, "");
}
e l::m_fn1() const { i(j, ""); }
compiled by recent c++ compiler with -O2, does this:
bug535.cc: In member function ‘e l::m_fn1() const’:
bug535.cc:18:40: warning: no return statement in function returning non-void
[-W
return-type]
18 | e l::m_fn1() const { i(j, ""); }
|^
bug535.cc:18:11: error: location references block not in block tree
18 | e l::m_fn1() const { i(j, ""); }
| ^
""
D.2449.g = "";
during GIMPLE pass: cfg
bug535.cc:18:11: internal compiler error: verify_gimple failed
0x1102f48 verify_gimple_in_cfg(function*, bool)
../../trunk/gcc/tree-cfg.c:5426
0xfb0e4f execute_function_todo
../../trunk/gcc/passes.c:1963
0xfb24f1 do_per_function
../../trunk/gcc/passes.c:1638
0xfb24f1 execute_todo
../../trunk/gcc/passes.c:2017
Bug first seems to occur sometime before revision 272500, dated
Jun 20 or so.
[Bug c++/91158] "if (__builtin_constant_p(n))" versus "if constexpr (__builtin_constant_p(n))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91158
--- Comment #3 from Cassio Neri ---
Forget my use case and comments on dead code elimination. That was a
digression. (My bad.) In general, I don't expect `if` and `if constexpr` to
behave the same but I do in this particular case. (I might be wrong.) Finally,
since `__builtin_constant_p` is not standard this ticket is a feature request,
not a bug report.
My reasoning is this: when the compiler sees `static_assert(f1(1));` it enters
a "constexpr evaluation mode" (not sure this is the right terminology but you
get the point). At this moment, regardless of optimization level the compiler
must propagate `1` to `f1` otherwise (generally speaking) it cannot evaluate
`f1(1)` and decide whether the `static_assert` passes or not. Therefore, when
it enters `f1` and sees `if constexpr (__builtin_constant_p(n))` it is already
in "constexpr evaluation mode" (so `constexpr` here is redundant) and it knows
`n == 1`. Hence, it should evaluate `__builtin_constant_p(n)` to `1`.
To make clear that my point is not that `if` and `if constexpr` should always
work the same, please, contrast with this program:
int main() {
if (f0(1)) puts("if : yes");
else puts("if : no");
if constexpr (f0(1)) puts("if ce: yes");
else puts("if ce: no");
}
The output in -O0 mode is `if : no` and `if ce: yes`. Since the first `if` is
not `constexpr`, the compiler doesn't need to enter "constexpr evaluation mode"
and -O0 is too low for `1` to be propagated to `f0`. The second `if`, on the
other hand, is `constexpr`. The compiler enters "constexpr evaluation mode",
propagates `1` to `f0` and evaluates `if (__builtin_constant_p(n))` to `1`
regardless that this `if` is not `constexpr`.
Also, to make clear I'm OK with `if constexpr (__builtin_constant_p(n))`
evaluating to `0` even in -O3 level, consider this:
int main() {
if (f0(1)) puts("if : yes");
else puts("if : no");
}
The output is `if : no`. Since the `if` is not `constexpr`, constant
propagation is up to the optimizer (QoI issue) and I'm OK if it enters
"constexpr evaluation mode" only inside `f1` (when it sees `if constexpr
(__builtin_constant_p(n))`) at which point is too late to know the value of `n`
and considers `n` as non constant.
Finally, I would link to link this issue with bug 70552 comment 5. Martin
Sebor, commenting on a patch for another related issue says:
"The patch referenced from it sets a precedent for the intrinsic treating
constant expressions as constant despite its late evaluation under "normal"
circumstances".
IIUIC, it says that `__builtin_constant_p(expr)` always evaluates to `1` if
expr is a C++ constant expression (e.g. a call to a `constexpr` function).
Similarly, I believe that in "constexpr evaluation mode", almost every
evaluation of `__builtin_constant_p(expr)` in the taken path should yield `1`.
(There are exceptions, notably, when `expr` is a non `constexpr` local
variable.)
[Bug c/91149] GCC 9 and later incorrectly rejects OpenMP task reduction-modifier on target parallel combined construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91149 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug lto/91163] ARM lto optimalization fail in big-endian case (error: could not unlink output file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163 --- Comment #3 from jdobry at centrum dot cz --- Here is update for big-endian multilib compilation https://pastebin.com/mzm12Q8m (fix typo in MULTILIB_MATCHES line)
[Bug lto/91163] ARM lto optimalization fail in big-endian case (error: could not unlink output file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163 --- Comment #2 from jdobry at centrum dot cz --- No, it isn't duplicate to PR90369. 1) I try to apply PR90369 patch without any difference. 2) This problem is independent to -save-temps parameter.
[Bug lto/91163] ARM lto optimalization fail in big-endian case (error: could not unlink output file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- Is it a duplicate of PR90369?
[Bug tree-optimization/87981] ICE: Segmentation fault (in add_phi_arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87981 --- Comment #2 from Arseny Solokha --- Current trunk doesn't ICE on this particular testcase anymore. Maybe it actually makes sense to close it as RESOLVED INVALID.
[Bug rtl-optimization/91164] New: [10 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 114 should be 112, not 16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91164 Bug ID: 91164 Summary: [10 Regression] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 114 should be 112, not 16) Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-10.0.0-alpha20190707 snapshot (r273184) ICEs when compiling libstdc++-v3/testsuite/28_regex/basic_regex/assign/wchar_t/string.cc w/ -O2 (-O3, -Ofast) -fdelete-dead-exceptions -fnon-call-exceptions -fno-rerun-cse-after-loop -fno-tree-forwprop: % g++-10.0.0-alpha20190707 -O2 -fdelete-dead-exceptions -fnon-call-exceptions -fno-rerun-cse-after-loop -fno-tree-forwprop -c libstdc++-v3/testsuite/28_regex/basic_regex/assign/wchar_t/string.cc In file included from /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20190707/include/g++-v10/bits/regex_compiler.h:560, from /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20190707/include/g++-v10/regex:61, from libstdc++-v3/testsuite/28_regex/basic_regex/assign/wchar_t/string.cc:25: /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20190707/include/g++-v10/bits/regex_compiler.tcc: In constructor 'std::__detail::_Compiler<_TraitsT>::_Compiler(std::__detail::_Compiler<_TraitsT>::_IterT, std::__detail::_Compiler<_TraitsT>::_IterT, const typename _TraitsT::locale_type&, std::__detail::_Compiler<_TraitsT>::_FlagT) [with _TraitsT = std::__cxx11::regex_traits]': /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20190707/include/g++-v10/bits/regex_compiler.tcc:92:5: error: dominator of 114 should be 112, not 16 92 | } | ^ during RTL pass: fwprop2 /usr/lib/gcc/x86_64-unknown-linux-gnu/10.0.0-alpha20190707/include/g++-v10/bits/regex_compiler.tcc:92:5: internal compiler error: in verify_dominators, at dominance.c:1184 0x6bcb7c verify_dominators(cdi_direction) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/dominance.c:1184 0xbb35f8 checking_verify_dominators /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/dominance.h:76 0xbb35f8 calculate_dominance_info(cdi_direction) /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/dominance.c:746 0x178a521 fwprop_init /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/fwprop.c:1508 0x178a521 fwprop /var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/fwprop.c:1560
[Bug lto/91163] New: ARM lto optimalization fail in big-endian case (error: could not unlink output file)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91163
Bug ID: 91163
Summary: ARM lto optimalization fail in big-endian case (error:
could not unlink output file)
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jdobry at centrum dot cz
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hello, in short problem is simple. Let's have file test.c with this content:
int main() {}
Compile it by this command:
arm-none-eabi-gcc -o test.elf -mcpu=cortex-r5 -mbig-endian -mthumb -T
empty.ld -Wl,--gc-sections -flto test.c
Compilation fails with this error message:
../arm-none-eabi/bin/ld.exe: error: could not unlink output file
This problem is strange, because it have strange conditions to reproduction.
* I can reproduce it on any version 8.x and 9.x which I try
* I can't reproduce it on linux, is it only windows problem? Why?
* It depend to endianity. Without -mbig-endian is is compiled successfully
* It depend to -flto. I can follow this problem into LTO plugin/wrapper (it
fails on lto-plugin.c function cleanup_handler() which try to unlink existing
temporary file test.elf.??.ltrans0.ltrans.o)
In long description we need to compile ARM big-endian code for TI TMS570
MCUs. I was create patch for this functionality till year 2011. It was not need
any changes in compiler, only compile BE variant of libraries.
We try to push this minor patch to ARM GCC distribution several times. Without
success. Reason was problems with auto test for every release of this package.
Problem happen with GCC 8 because it integrate multilib support fully. Now is
proper place to try push this patch to GCC directly. But I can't send it
include this problem.
Here is patch for bigendian multilib support, needed by TMS570 MCU family.
https://pastebin.com/hMfSd7h3
Jiri
NOTE: empty.ld is deliberately empty file
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #22 from Mike Hommey --- For the record, this also affects ppc64.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #19 from Allan Jensen --- (In reply to felix from comment #18) > So even if this feature is adopted as-is, it will necessitate some changes > in the documentation. And while I can sympathise with claims that this > behaviour is surprising, what are the alternatives? If keywords should count > as built-ins, should __has_builtin(sizeof) expand to 1? Should > __has_builtin(volatile)? No just keywords that begin with __builtin_..
[Bug c/91149] GCC 9 and later incorrectly rejects OpenMP task reduction-modifier on target parallel combined construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91149 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Sun Jul 14 08:29:38 2019 New Revision: 273478 URL: https://gcc.gnu.org/viewcvs?rev=273478=gcc=rev Log: Backported from mainline 2019-07-13 Jakub Jelinek PR c/91149 * c-omp.c (c_omp_split_clauses): Fix a pasto in OMP_CLAUSE_REDUCTION_TASK handling. * c-c++-common/gomp/reduction-task-3.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/c-c++-common/gomp/reduction-task-3.c Modified: branches/gcc-9-branch/gcc/c-family/ChangeLog branches/gcc-9-branch/gcc/c-family/c-omp.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/78884] [7/8/9] ICE when gimplifying VLA in OpenMP SIMD region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78884 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Sun Jul 14 08:28:06 2019 New Revision: 273477 URL: https://gcc.gnu.org/viewcvs?rev=273477=gcc=rev Log: Backported from mainline 2019-07-04 Jakub Jelinek PR middle-end/78884 * gimplify.c (struct gimplify_omp_ctx): Add add_safelen1 member. (gimplify_bind_expr): If seeing TREE_ADDRESSABLE VLA inside of simd loop body, set ctx->add_safelen1 instead of making it GOVD_PRIVATE. (gimplify_adjust_omp_clauses): Add safelen (1) clause if ctx->add_safelen1 is set. * gcc.dg/gomp/pr78884.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/gomp/pr78884.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/90756] [7/8/9 Regression] g++ ICE in convert_move, at expr.c:218 on i686 and s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90756 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Sun Jul 14 08:27:12 2019 New Revision: 273476 URL: https://gcc.gnu.org/viewcvs?rev=273476=gcc=rev Log: Backported from mainline 2019-07-04 Jakub Jelinek PR rtl-optimization/90756 * explow.c (promote_ssa_mode): Always use TYPE_MODE, don't bypass it for VECTOR_TYPE_P. * gcc.dg/pr90756.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr90756.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/explow.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/91148] PowerPC build gets several warnings due to -Wformat-diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Sun Jul 14 08:24:38 2019 New Revision: 273475 URL: https://gcc.gnu.org/viewcvs?rev=273475=gcc=rev Log: rs6000: Shut up -Wformat-diag a little more PR target/91148 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Remove superfluous "builtin function" phrasing. gcc/testsuite/ * gcc.target/powerpc/bfp/scalar-extract-exp-2.c: Adjust. * gcc.target/powerpc/bfp/scalar-extract-sig-2.c: Adjust. * gcc.target/powerpc/bfp/scalar-insert-exp-2.c: Adjust. * gcc.target/powerpc/bfp/scalar-insert-exp-5.c: Adjust. * gcc.target/powerpc/bfp/scalar-insert-exp-8.c: Adjust. * gcc.target/powerpc/byte-in-set-2.c: Adjust. * gcc.target/powerpc/cmpb-3.c: Adjust. * gcc.target/powerpc/vsu/vec-all-nez-7.c: Adjust. * gcc.target/powerpc/vsu/vec-any-eqz-7.c: Adjust. * gcc.target/powerpc/vsu/vec-xl-len-13.c: Adjust. * gcc.target/powerpc/vsu/vec-xst-len-12.c: Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-c.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-exp-2.c trunk/gcc/testsuite/gcc.target/powerpc/bfp/scalar-extract-sig-2.c trunk/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-2.c trunk/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-5.c trunk/gcc/testsuite/gcc.target/powerpc/bfp/scalar-insert-exp-8.c trunk/gcc/testsuite/gcc.target/powerpc/byte-in-set-2.c trunk/gcc/testsuite/gcc.target/powerpc/cmpb-3.c trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-all-nez-7.c trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eqz-7.c trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-xl-len-13.c trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-xst-len-12.c
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 --- Comment #14 from Andreas Schwab --- Since you know how to reproduce the issue, you can help by providing the requested information.
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095 --- Comment #2 from Tom Honermann --- I confirmed that Jeff's patch, applied to gcc 9.1.0, suffices to address both Hana's test case and the code in the "Emulate C++17 u8 literals" section of P1423R2 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r2.html#emulate) if the declaration of operator <=> is commented out (since gcc doesn't yet support operator <=>).
[Bug tree-optimization/91162] New: [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86 (error: invalid 'PHI' arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91162
Bug ID: 91162
Summary: [9/10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p, at gimple-expr.c:86 (error:
invalid 'PHI' argument)
Product: gcc
Version: 10.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: ---
Target: x86_64-unknown-linux-gnu
gcc-10.0.0-alpha20190707 snapshot (r273184) ICEs when compiling the following
testcase w/ -O1 -ftree-parallelize-loops=2 -fno-tree-dominator-opts --param
parloops-min-per-thread=30:
void
zf (__int128 ct)
{
__int128 *rk =
if (0)
{
int jj;
t9:
for (jj = 0; jj < 60; ++jj)
{
}
__builtin_unreachable ();
}
while (*rk < 1)
++*rk;
goto t9;
}
% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190707 -O1
-ftree-parallelize-loops=2 -fno-tree-dominator-opts --param
parloops-min-per-thread=30 -c qv6ltsdb.c
qv6ltsdb.c: In function 'zf':
qv6ltsdb.c:2:1: error: invalid 'PHI' argument
2 | zf (__int128 ct)
| ^~
_51
during GIMPLE pass: ompexpssa
qv6ltsdb.c:2:1: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in useless_type_conversion_p, at
gimple-expr.c:86
0x70656e tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/tree.c:9950
0x61d053 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/tree.h:3340
0x61d053 useless_type_conversion_p(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/gimple-expr.c:86
0xd94001 verify_gimple_phi
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/tree-cfg.c:4978
0xd94001 verify_gimple_in_cfg(function*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/tree-cfg.c:5307
0xc6e519 execute_function_todo
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/passes.c:1963
0xc6f2c6 execute_todo
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/passes.c:2017
[Bug other/87695] Arduino: ICE with avr and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87695 --- Comment #13 from OC --- Hi, This bug is open for almost 9 months. I loaded the latest GCC revision and it is not solved. Can anyone be so kind to give an estimation of repair time or any work around?
[Bug rtl-optimization/91161] New: [10 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91161
Bug ID: 91161
Summary: [10 Regression] ICE in begin_move_insn, at
sched-ebb.c:175
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-10.0.0-alpha20190707 snapshot (r273184) ICEs when compiling the following
testcase w/ -march=skylake -O2 (-O3, -Ofast) -fsched2-use-superblocks -fno-dce:
int b6, hi;
void
ni ()
{
__builtin_unreachable ();
}
void
fa (int *zr)
{
int ee;
if (b6 != 0)
{
if (ee != 0)
{
x6:
b6 = 0;
}
zr = hi;
ni (zr);
}
*zr = hi;
}
% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190707 -march=skylake -O2
-fsched2-use-superblocks -fno-dce -w -c ucjsvetc.c
during RTL pass: sched2
ucjsvetc.c: In function 'fa':
ucjsvetc.c:27:1: internal compiler error: in begin_move_insn, at
sched-ebb.c:175
27 | }
| ^
0x16480a6 begin_move_insn
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-ebb.c:175
0x16480a6 begin_move_insn
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-ebb.c:145
0x15bd4e3 commit_schedule
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/haifa-sched.c:6228
0x15bd4e3 schedule_block(basic_block_def**, void*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/haifa-sched.c:7065
0x16482ca schedule_ebb(rtx_insn*, rtx_insn*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-ebb.c:537
0x16488ba schedule_ebbs()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-ebb.c:656
0xcf7c40 rest_of_handle_sched2
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-rgn.c:3744
0xcf7c40 execute
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190707/work/gcc-10-20190707/gcc/sched-rgn.c:3882
gcc 8 and 9 also reject it w/ -fchecking (error: missing barrier after block 4)
but don't ICE.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 --- Comment #18 from felix --- Proper built-ins are ordinary identifiers subject to ordinary name resolution and shadowing, so the 'keyword built-in' case is impossible. If you don't know if (or don't want to depend on the fact that) a given built-in is a keyword or an intrinsic function, `__has_builtin(x) || !__is_identifier(x)` should suffice. In a way, that detail is already exposed to user code: `int __builtin_abort = 0;` compiles, but `int __builtin_choose_expr = 0;` doesn't. The documentation doesn't mention this, however; keyword built-ins are actually documented as being functions in the manual, either explicitly or implicitly (by being listed alongside true intrinsic functions with no discriminating features). So even if this feature is adopted as-is, it will necessitate some changes in the documentation. And while I can sympathise with claims that this behaviour is surprising, what are the alternatives? If keywords should count as built-ins, should __has_builtin(sizeof) expand to 1? Should __has_builtin(volatile)?
