[Bug c++/94257] New: ICE in inline nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94257
Bug ID: 94257
Summary: ICE in inline nested namespace
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pacoarjonilla at yahoo dot es
Target Milestone: ---
Only in GCC10
inline namespace B {
inline namespace B { }
}
inline namespace B {
class C {
friend void f();
};
}
$> g++10 bug.cc
cairo.cc:4:18: error: ‘namespace B { }’ conflicts with a previous declaration
4 | inline namespace B {
| ^
cairo.cc:1:18: note: previous declaration ‘namespace B { }’
1 | inline namespace B {
| ^
cairo.cc:6:19: internal compiler error: in do_push_nested_namespace, at
cp/name-lookup.c:7225
6 | friend void f();
| ^
0x65c058 do_push_nested_namespace
../../gcc/gcc/cp/name-lookup.c:7225
0x991b8c push_nested_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:7494
0x951384 do_friend(tree_node*, tree_node*, tree_node*, tree_node*,
overload_flags, bool)
../../gcc/gcc/cp/friend.c:626
0x91cb5e grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:13364
0x93877f grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:841
0x9d936b cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:25259
0x9adb31 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:24703
0x9adb31 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:23800
0x9afbe3 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:24107
0x9afbe3 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17666
0x9b0cbb cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:14314
0x9b1701 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13568
0x9da782 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13388
0x9da4c2 cp_parser_toplevel_declaration
../../gcc/gcc/cp/parser.c:13416
0x9da4c2 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:13264
0x9da4c2 cp_parser_namespace_body
../../gcc/gcc/cp/parser.c:19644
0x9da4c2 cp_parser_namespace_definition
../../gcc/gcc/cp/parser.c:19622
0x9da8c8 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13368
0x9daf0a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4731
0x9daf0a c_parse_file()
../../gcc/gcc/cp/parser.c:43758
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/94043] [9/10 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 --- Comment #8 from Kewen Lin --- > It's most likely either SCEV or expand_simple_operations looking throuhg > the single-arg PHI (which we should avoid for LC PHI nodes) Thanks Richi, I found the loop-closed PHI form was broken after we finished the vectorization on the loop 2, BB 38 was inserted, the function gimple_find_edge_insert_loc will get one new BB if the dest has phis, even it's unrelated. ;; basic block 4, loop depth 2 ;; pred: 11 ;; 37 ... _15 = e2.2_31 + 1; ... if (ivtmp_59 >= 1) goto ; [100.00%] else goto ; [0.00%] ;; succ: 38 ;; 11 ;; basic block 38, loop depth 1 ;; pred: 4 _40 = BIT_FIELD_REF ; ;; succ: 33 ;; basic block 33, loop depth 1 ;; pred: 38 # _51 = PHI <_15(38)> ;; succ: 34 The alternatives seems could be 1) extend the current gimple_find_edge_insert_loc to handle the phi nodes, if the phis aren't related, just insert there, otherwise, insert some phis for uses of those stmts and remove the related phis and create new assignments after those new stmts, or 2) call rewrite_into_loop_closed_ssa for each successful vectorization.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #4 from Martin Liška --- Ah, ok. Can you please do some basic debugging what's hapenning? Btw. is the Solaris using ELF?
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 Zdenek Sojka changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #1 from Zdenek Sojka --- I observe the same issue, and it breaks libgcc build for me: $ /repo/build-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/./gcc/xgcc -B/repo/build-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/./gcc/ -B/repo/gcc-trunk//binary-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/powerpc-unknown-linux-gnu/bin/ -B/repo/gcc-trunk//binary-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/powerpc-unknown-linux-gnu/lib/ -isystem /repo/gcc-trunk//binary-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/powerpc-unknown-linux-gnu/include -isystem /repo/gcc-trunk//binary-trunk-r10-7320-20200321085330-g497498c878d-checking-yes-rtl-df-extra-powerpc/powerpc-unknown-linux-gnu/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I/repo/gcc-trunk/libgcc -I/repo/gcc-trunk/libgcc/. -I/repo/gcc-trunk/libgcc/../gcc -I/repo/gcc-trunk/libgcc/../include -I/repo/gcc-trunk/libgcc/../libdecnumber/dpd -I/repo/gcc-trunk/libgcc/../libdecnumber -DHAVE_CC_TLS -o _sd_to_si.o -MT _sd_to_si.o -MD -MP -MF _sd_to_si.dep -DFINE_GRAINED_LIBRARIES -DL_sd_to_si -DWIDTH=32 -c /repo/gcc-trunk/libgcc/dfp-bit.c hangs; I can provide reduced testcase if needed (for reasons unknown to me, git gcc-descr returns "r10-7320" for me for the same git checkout as in #c0)
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Martin Liška --- > Ah, ok. Can you please do some basic debugging what's hapenning? Can you provide some pointers where to look? I'm totally unfamiliar with this code. Maybe it's easier for you to try the Solaris/SPARC system in the cfarm? No idea if they have Linux/HP-PA there as well... > Btw. is the Solaris using ELF? Sure: it's SysVr4 based, they invented ELF together with AT&T.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #2 from Zdenek Sojka --- (In reply to Zdenek Sojka from comment #1) > I observe the same issue, and it breaks libgcc build for me: ... > > (for reasons unknown to me, git gcc-descr returns "r10-7320" for me for the > same git checkout as in #c0) Sorry, I accidentally sent the message before I removed this part of the comment; apparently git gcc-descr works with the most recent commit in the branch, not with the actual checkout.
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 --- Comment #4 from Emil Fihlman --- Problem persists with gcc 9.3, though it's no longer dependent on the bitfield. https://godbolt.org/z/RGu6hu If a free is behind a flag.
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 --- Comment #5 from Emil Fihlman --- If a free is behind a flag gcc and the allocation is also behind a flag, gcc should not complain.
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 --- Comment #6 from Jakub Jelinek --- It is not going to be fixed in GCC 9, only in 10, where it should be fixed already.
[Bug c/94258] New: Warning Correction while using format specifiers %hx and %ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258 Bug ID: 94258 Summary: Warning Correction while using format specifiers %hx and %ho Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ravivasani75 at gmail dot com Target Milestone: --- Created attachment 48079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48079&action=edit outputs are 'short int's, but warning is specifying that %hx and %ho need 'int' argument Warning informs that %hx and %ho need 'int' argument, but printf prints it as 'short int'
[Bug lto/94259] New: --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 Bug ID: 94259 Summary: --without-zstd seems to have no effect and links libzstd if available Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru CC: marxin at gcc dot gnu.org Target Milestone: --- Built gcc with --without-zstd as: $ ../gcc/configure --enable-languages=c,c++ --disable-bootstrap --with-multilib-list=m64 --prefix=/home/slyfox/dev/git/gcc-native-quick/../gcc-native-quick-installed --disable-nls --without-isl --disable-libsanitizer --disable-libvtv --disable-libgomp --disable-libstdcxx-pch --disable-libunwind-exceptions CFLAGS=-O1 CXXFLAGS=-O1 --with-sysroot=/usr/x86_64-HEAD-linux-gnu --without-zstd But cc1plus still links to libzstd: ldd ./gcc/cc1plus linux-vdso.so.1 (0x7ffed53f) libmpc.so.3 => /usr/lib64/libmpc.so.3 (0x7ff32f12a000) libmpfr.so.6 => /usr/lib64/libmpfr.so.6 (0x7ff32f0a9000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x7ff32f02f000) libdl.so.2 => /lib64/libdl.so.2 (0x7ff32f029000) libzstd.so.1 => /usr/lib64/libzstd.so.1 (0x7ff32ef95000) libm.so.6 => /lib64/libm.so.6 (0x7ff32ee52000) libc.so.6 => /lib64/libc.so.6 (0x7ff32ec7e000) /lib64/ld-linux-x86-64.so.2 (0x7ff32f1d4000) Loks like it happens because library/header detection happens regardless of user's setting in gcc/configure.ac: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=0d6230e0ca1bdd1f7de34ad452efac867351121a;hb=HEAD#l1316 1323 AC_ARG_WITH(zstd, 1324 [AS_HELP_STRING([--with-zstd=PATH], 1325 [specify prefix directory for installed zstd library. 1326 Equivalent to --with-zstd-include=PATH/include 1327 plus --with-zstd-lib=PATH/lib])]) ... 1374 # LTO can use zstd compression algorithm 1375 save_LIBS="$LIBS" 1376 LIBS= 1377 AC_SEARCH_LIBS(ZSTD_compress, zstd) 1378 ZSTD_LIB="$LIBS" 1379 LIBS="$save_LIBS" 1380 AC_SUBST(ZSTD_LIB) It looks like headers/library detection happens regardless of --with-zstd/--without-zstd flag being passed. I have zstd installed in /usr and it always get picked up.
[Bug c++/94260] New: Specific friend function inside c++20 concept-constrained class template triggers 'not usable in a constant expression' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94260
Bug ID: 94260
Summary: Specific friend function inside c++20
concept-constrained class template triggers 'not
usable in a constant expression' error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: niekb at scintilla dot utwente.nl
Target Milestone: ---
Dear GCC-devs,
I stumbled upon the following error, while working with a particular friend
function inside a concepts-contrained templated class. I tried to make a
minimal example, but maybe it can be further slimmed down.
I am not sure if this is a bug in GCC; however, on clang-trunk the same code
compiles with no error.
I've created examples on Godbolt's Compiler Explorer. The example on which
GCC-trunk fails is:
https://godbolt.org/z/fc3HbB
The same code compiles successfully with Clang-trunk:
https://godbolt.org/z/JiB_UB
The error disappears when removing the concept-constraint from the class
definition.
The error also disappears when turning the 'fun' function into an non-friend
function.
kind regards,
Niek
NB: I've also copy-pasted the source code below:
#include
#include
#include
template
concept my_concept = std::regular;
template
class wrapper
{
T d;
runtime_t& x;
public:
wrapper(T&& data, runtime_t& runtime) :
d(std::move(data)),
x(runtime) {}
T& fut()
{
return d;
}
runtime_t& runtime()
{
return x;
}
};
template
//template // replacing the above line by this line
fixes the compilation error on GGC-trunk
class test {
public:
friend auto fun(wrapper,
test>& a,
wrapper,
test>& b)
-> wrapper, test>
{
return wrapper, test>
(
std::async(std::launch::deferred, [a,b]() mutable { return
a.fut().get() + b.fut().get(); }),
a.runtime()
);
}
};
int main(){
static_assert(std::regular);
test t;
std::shared_future f1 = std::async(std::launch::deferred, []() {
return 42; });
std::shared_future f2 = std::async(std::launch::deferred, []() {
return 42; });
wrapper, test> a(std::move(f1),t);
wrapper, test> b(std::move(f2),t);
fun(a, b);
}
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 --- Comment #1 from Sergei Trofimovich --- I also noticed a minor infelicity: if you pass just --with-zstd build system will do a few unexpected things: - it will not fail of zstd is not present in system but will silently skip zstd support - it will use 'yes/include' and 'yes/lib' as paths to zstd. I think it's never an expected location. 1334 case "x$with_zstd" in 1335 x) ;; 1336 xno) 1337 ZSTD_INCLUDE=no 1338 ZSTD_LIB=no 1339 ;; 1340 *) ZSTD_INCLUDE=$with_zstd/include 1341 ZSTD_LIB=$with_zstd/lib 1342 ;; 1343 esac
[Bug tree-optimization/94261] New: [10 Regression] ICE in vect_get_vec_def_for_operand_1 for 3-element condition reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
Bug ID: 94261
Summary: [10 Regression] ICE in vect_get_vec_def_for_operand_1
for 3-element condition reduction
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: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
The following test ICEs when compiled with
-O3 -ffinite-math-only -march=armv8.2-a+sve
on aarch64:
void
f (float *x, float *y, float z)
{
float res0 = 0, res1 = 1, res2 = 2;
for (int i = 0; i < 100; ++i)
{
res0 = 100 <= y[i * 3] ? res0 : z;
res1 = 101 <= y[i * 3 + 1] ? res1 : z;
res2 = y[i * 3 + 2] < 102 ? z : res2;
}
x[0] = res0;
x[1] = res1;
x[2] = res2;
}
The ICE is:
b.c:2:1: internal compiler error: in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1555
2 | f (float *x, float *y, float z)
| ^
0x10a86c3 vect_get_vec_def_for_operand_1(_stmt_vec_info*, vect_def_type)
gcc/tree-vect-stmts.c:1555
0x10af8e1 vect_get_vec_def_for_operand(tree_node*, _stmt_vec_info*, tree_node*)
gcc/tree-vect-stmts.c:1617
0x10b258f vectorizable_condition
gcc/tree-vect-stmts.c:10213
0x10d01ea vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
gcc/tree-vect-stmts.c:11012
0x10d4226 vect_transform_loop_stmt
gcc/tree-vect-loop.c:8307
0x10ec31a vect_transform_loop(_loop_vec_info*, gimple*)
gcc/tree-vect-loop.c:8707
0x110f797 try_vectorize_loop_1
gcc/tree-vectorizer.c:990
0x1110319 vectorize_loops()
gcc/tree-vectorizer.c:1126
The problem comes from trying both SVE and Advanced SIMD and
eventually picking SVE. The SVE version can't treat the loop
as a single 3-element SLP reduction because we don't yet
support loading { 100, 101, 102 } repeating for variable-length
vectors. We therefore fail the SLP build before doing anything
about the awkward comparison arrangement. With this version,
each ?: is a separate reduction and each one has its own,
correct, STMT_VINFO_REDUC_IDX.
But then we try the Advanced SIMD version. This doesn't have
a problem with loading the constants, so we get as far as
dealing with mismatched comparisons:
/* Swap. */
if (*swap == 1)
{
swap_ssa_operands (stmt, &TREE_OPERAND (cond, 0),
&TREE_OPERAND (cond, 1));
TREE_SET_CODE (cond, swap_tree_comparison (code));
}
/* Invert. */
else
{
swap_ssa_operands (stmt, gimple_assign_rhs2_ptr (stmt),
gimple_assign_rhs3_ptr (stmt));
if (STMT_VINFO_REDUC_IDX (stmt_info) == 1)
STMT_VINFO_REDUC_IDX (stmt_info) = 2;
else if (STMT_VINFO_REDUC_IDX (stmt_info) == 2)
STMT_VINFO_REDUC_IDX (stmt_info) = 1;
bool honor_nans = HONOR_NANS (TREE_OPERAND (cond, 0));
code = invert_tree_comparison (TREE_CODE (cond), honor_nans);
gcc_assert (code != ERROR_MARK);
TREE_SET_CODE (cond, code);
}
But these changes to the gimple stmt persist even if the SLP build
fails later, or if the SLP build succeeds and we decide not to
vectorise that way. That doesn't matter too much for the current
loop_vinfo, because the STMT_VINFO_REDUC_IDXs are still consistent
with the gimple stmt. But it means that the STMT_VINFO_REDUC_IDXs
for the older SVE loop_vinfo are now no longer correct.
The ICE triggers when we go back to the SVE loop_vinfo as the
cheapest implementation and try to code-generate the reduction.
The testcase is reduced from 481.wrf compiled with LTO.
[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621 --- Comment #4 from Arseny Solokha --- (In reply to Jan Hubicka from comment #3) > The testcase builds for me now It still ICEs for me.
[Bug tree-optimization/94261] [10 Regression] ICE in vect_get_vec_def_for_operand_1 for 3-element condition reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
--- Comment #1 from rguenther at suse dot de ---
On March 22, 2020 12:46:45 PM GMT+01:00, "rsandifo at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94261
>
>Bug ID: 94261
> Summary: [10 Regression] ICE in vect_get_vec_def_for_operand_1
>for 3-element condition reduction
> 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: rsandifo at gcc dot gnu.org
>CC: rguenth at gcc dot gnu.org
> Target Milestone: ---
>Target: aarch64*-*-*
>
>The following test ICEs when compiled with
>-O3 -ffinite-math-only -march=armv8.2-a+sve
>on aarch64:
>
>void
>f (float *x, float *y, float z)
>{
> float res0 = 0, res1 = 1, res2 = 2;
> for (int i = 0; i < 100; ++i)
>{
> res0 = 100 <= y[i * 3] ? res0 : z;
> res1 = 101 <= y[i * 3 + 1] ? res1 : z;
> res2 = y[i * 3 + 2] < 102 ? z : res2;
>}
> x[0] = res0;
> x[1] = res1;
> x[2] = res2;
>}
>
>The ICE is:
>
>b.c:2:1: internal compiler error: in vect_get_vec_def_for_operand_1, at
>tree-vect-stmts.c:1555
>2 | f (float *x, float *y, float z)
> | ^
>0x10a86c3 vect_get_vec_def_for_operand_1(_stmt_vec_info*,
>vect_def_type)
>gcc/tree-vect-stmts.c:1555
>0x10af8e1 vect_get_vec_def_for_operand(tree_node*, _stmt_vec_info*,
>tree_node*)
>gcc/tree-vect-stmts.c:1617
>0x10b258f vectorizable_condition
>gcc/tree-vect-stmts.c:10213
>0x10d01ea vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
>_slp_tree*, _slp_instance*)
>gcc/tree-vect-stmts.c:11012
>0x10d4226 vect_transform_loop_stmt
>gcc/tree-vect-loop.c:8307
>0x10ec31a vect_transform_loop(_loop_vec_info*, gimple*)
>gcc/tree-vect-loop.c:8707
>0x110f797 try_vectorize_loop_1
>gcc/tree-vectorizer.c:990
>0x1110319 vectorize_loops()
>gcc/tree-vectorizer.c:1126
>
>The problem comes from trying both SVE and Advanced SIMD and
>eventually picking SVE. The SVE version can't treat the loop
>as a single 3-element SLP reduction because we don't yet
>support loading { 100, 101, 102 } repeating for variable-length
>vectors. We therefore fail the SLP build before doing anything
>about the awkward comparison arrangement. With this version,
>each ?: is a separate reduction and each one has its own,
>correct, STMT_VINFO_REDUC_IDX.
>
>But then we try the Advanced SIMD version. This doesn't have
>a problem with loading the constants, so we get as far as
>dealing with mismatched comparisons:
>
> /* Swap. */
> if (*swap == 1)
>{
> swap_ssa_operands (stmt, &TREE_OPERAND (cond, 0),
> &TREE_OPERAND (cond, 1));
> TREE_SET_CODE (cond, swap_tree_comparison (code));
>}
> /* Invert. */
> else
>{
> swap_ssa_operands (stmt, gimple_assign_rhs2_ptr (stmt),
> gimple_assign_rhs3_ptr (stmt));
> if (STMT_VINFO_REDUC_IDX (stmt_info) == 1)
>STMT_VINFO_REDUC_IDX (stmt_info) = 2;
> else if (STMT_VINFO_REDUC_IDX (stmt_info) == 2)
>STMT_VINFO_REDUC_IDX (stmt_info) = 1;
> bool honor_nans = HONOR_NANS (TREE_OPERAND (cond, 0));
> code = invert_tree_comparison (TREE_CODE (cond), honor_nans);
> gcc_assert (code != ERROR_MARK);
> TREE_SET_CODE (cond, code);
>}
>
>But these changes to the gimple stmt persist even if the SLP build
>fails later, or if the SLP build succeeds and we decide not to
>vectorise that way. That doesn't matter too much for the current
>loop_vinfo, because the STMT_VINFO_REDUC_IDXs are still consistent
>with the gimple stmt. But it means that the STMT_VINFO_REDUC_IDXs
>for the older SVE loop_vinfo are now no longer correct.
>
>The ICE triggers when we go back to the SVE loop_vinfo as the
>cheapest implementation and try to code-generate the reduction.
>
>The testcase is reduced from 481.wrf compiled with LTO.
Stmt modifications considered harmful.. I've pondered with using alternate
Gimple stmts for the slp node here, similar to patterns but of course not
registered with the main stmt_info as that would get us back to the very same
issue.
But only pondered, not actually tried implementing this.
[Bug d/93038] Missing dependencies in depfile for imported files at compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:fbe60463bb80d859d4842f0113a6b24fe9cc9bd4 commit r10-7323-gfbe60463bb80d859d4842f0113a6b24fe9cc9bd4 Author: Iain Buclaw Date: Sun Mar 22 13:11:10 2020 +0100 d: Generate phony targets for content imported files (PR93038) This is in addition to the last change which started including them in the make dependency list. gcc/d/ChangeLog: 2020-03-22 Iain Buclaw PR d/93038 * d-lang.cc (deps_write): Generate phony targets for content imported files. gcc/testsuite/ChangeLog: 2020-03-22 Iain Buclaw PR d/93038 * gdc.dg/pr93038b.d: New test.
[Bug rtl-optimization/94256] Setting max-sched-region-blocks to >48 causes GCC memory usage to explode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256
--- Comment #2 from Sultan Alsawaf ---
(In reply to Andrew Pinski from comment #1)
> That is why it is limited in the first place:
> /* Update number of blocks and the estimate for number of insns
>in the region. Return true if the region is "too large" for interblock
>scheduling (compile time considerations). */
>
> static bool
> too_large (int block, int *num_bbs, int *num_insns)
> {
> (*num_bbs)++;
> (*num_insns) += (common_sched_info->estimate_number_of_insns
>(BASIC_BLOCK_FOR_FN (cfun, block)));
>
> return ((*num_bbs > param_max_sched_region_blocks)
> || (*num_insns > param_max_sched_region_insns));
> }
>
> CUT -
> having a more than 10 basic blocks in a region is huge really.
Yes, I'm aware of that code snippet. However, the parameter does not have any
limits specified in params.def, and I didn't notice *any* difference in
resource consumption at 48 compared to 10, so why should I be allowed to set
49+ and break GCC entirely?
[Bug c/94258] Warning Correction while using format specifiers %hx and %ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258 --- Comment #1 from Andrew Pinski --- Short types are promoted to int when passed to variable arguments functions.
[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jakub Jelinek --- > Yes, see https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542459.html > Sorry for that. I've just applied your patch (the primary one above), rebuilt cc1 on both i386-pc-solaris2.11 and sparc-sun-solaris2.11 (where the failures had apppeared in this Friday's bootstaps, too), and run the two affected tests for both 32 and 64-bit: both failures are gone now. Thanks. Rainer
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||rsandifo at gcc dot gnu.org Last reconfirmed||2020-03-22 --- Comment #3 from rsandifo at gcc dot gnu.org --- Mine.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #23 from Iain Sandoe --- > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK >= > Xcode commandline tools 11.3b. I've recently tried both building gcc 8.3.0 (build only) and master (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode 11.3.1. Both worked *provided the build and target compilers were configured with the approriate --with-sysroot to account for the lack of /usr/include and startup objects in /usr/lib*. > If there's no additional information I propose we close this PR after another > week. I guess that's fine. Thanks. Rainer
[Bug c/94262] New: valgrind error in get_pure_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262
Bug ID: 94262
Summary: valgrind error in get_pure_location
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For testsuite file ./gcc.dg/visibility-10.c, compiled by recent gcc
trunk in a valgrind version, I get
./gcc.dg/visibility-10.c:19: error: expected ‘{’ at end of input
19 | int l;
|
==1850702== Conditional jump or move depends on uninitialised value(s)
==1850702==at 0x14367D5: get_pure_location(line_maps*, unsigned int)
(line-map.c:322)
==1850702==by 0xD4E4A7: get_pure_location (input.h:148)
==1850702==by 0xD4E4A7: set_block(unsigned int, tree_node*) (tree.c:14835)
==1850702==by 0x12E0DED: gimple_set_block (gimple.h:1865)
Command line is
$ /home/dcb/gcc/results/bin/gcc -c ./gcc.dg/visibility-10.c
[Bug lto/94259] --without-zstd seems to have no effect and links libzstd if available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94259 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-03-22 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Mine.
[Bug c/94262] valgrind error in get_pure_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-03-22 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- I'll try to take a look.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Martin Liška --- > Can you provide some pointers where to look? I'm totally unfamiliar > with this code. Maybe it's easier for you to try the Solaris/SPARC > system in the cfarm? No idea if they have Linux/HP-PA there as well... > Ok, I'll start with that tomorrow in the morning and let you know.
[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 since r10-5567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621 --- Comment #5 from Martin Liška --- Yes, I can confirm it still ICEs.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #25 from Iain Sandoe --- (In reply to r...@cebitec.uni-bielefeld.de from comment #24) > > --- Comment #23 from Iain Sandoe --- > > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any SDK > > >= > > Xcode commandline tools 11.3b. > > I've recently tried both building gcc 8.3.0 (build only) and master > (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode > 11.3.1. Both worked *provided the build and target compilers were > configured with the approriate --with-sysroot to account for the lack of > /usr/include and startup objects in /usr/lib*. That's not going to change, I think (at least, the underlying behaviour). We could entertain and implement a change to Darwin's configuration that automatically discovers the /Library/Developer/CommandLineTools .. or /Applications/Xcode... for Darwin versions >= X and complains of fails to configure if those can't be seen (asking for a --with-sysroot=). We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from 7.5+. The only irritation is that we can't use 'gcc' or 'g++' in that position, because xcrun places the clang/++ aliases ahead of the GCC in the PATH (even if the GCC install is first) [last time I tried]. There's also an API to obtain the info - but only on 10.15+ and it forces one to install XCode I suspect to use it, I'm not keen on making new dependencies on things outside our control - I'd rather make use of OSS equivalents. > > If there's no additional information I propose we close this PR after > > another > > week. > > I guess that's fine. I think we have the /usr/local/include issue tracked elsewhere.
[Bug d/90136] [d] Merge UDAs between function prototype and definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90136 Iain Buclaw changed: What|Removed |Added Target Milestone|9.4 |10.0 --- Comment #4 from Iain Buclaw --- Setting milestone to version 10, as it's a feature request that affects an extension to the language, not the core language itself.
[Bug c/94262] valgrind error in get_pure_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94262 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org Status|ASSIGNED|RESOLVED --- Comment #2 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 94239 ***
[Bug c/94239] [10 regression] cc1 SEGV in get_location_from_adhoc_loc with gcc.dg/pr20245-1.c etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94239 Jakub Jelinek changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from Jakub Jelinek --- *** Bug 94262 has been marked as a duplicate of this bug. ***
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
--- Comment #4 from rsandifo at gcc dot gnu.org
---
The cycling comes from reloading:
(insn 7 6 8 2 (set (reg:SD 122 [ a32 ])
(mem/c:SD (reg/f:DI 120) [1 a32+0 S4 A32]))
"gcc/testsuite/gcc.target/powerpc/pr39902-2.c":15:13 516 {movsd_hardfloat}
(expr_list:REG_DEAD (reg/f:DI 120)
(nil)))
r122 is assigned an FPR, and the power6 pattern doesn't provide
any alternatives that load from memory into FPRs, so we convert
this into a secondary memory reload.
Doing that for SDmode memory would cycle, but the rs6000 port has:
/* Implement TARGET_SECONDARY_RELOAD_NEEDED_MODE. For SDmode values we
need to use DDmode, in all other cases we can use the same mode. */
static machine_mode
rs6000_secondary_memory_needed_mode (machine_mode mode)
{
if (lra_in_progress && mode == SDmode)
return DDmode;
return mode;
}
which says that the move should happen in DDmode instead.
This means that the eventual FPR reload will happen in DDmode
rather than SDmode.
The problem is that rs6000_can_change_mode_class doesn't allow
FPRs to change from SDmode to DDmode:
if (from_size < 8 || to_size < 8)
return false;
So there seems to be a contradiction here: secondary memory
reloads for FPRs have to happen in DDmode rather than SDmode,
but FPRs aren't allowed to change to DDmode from SDmode.
Previously this worked because LRA ignored
rs6000_can_change_mode_class and changed the mode of the
FPR regardless. I guess that must have been the right
thing to do in context, but it would be good to pin down
exactly why the SD->DD mode change is OK for rs6000 in the
specific context of secondary memory reloads but not otherwise.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #5 from rsandifo at gcc dot gnu.org --- (In reply to Zdenek Sojka from comment #1) > I observe the same issue, and it breaks libgcc build for me: What configure arguments do you use?
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Martin Liška --- >> Can you provide some pointers where to look? I'm totally unfamiliar >> with this code. Maybe it's easier for you to try the Solaris/SPARC >> system in the cfarm? No idea if they have Linux/HP-PA there as well... > > Ok, I'll start with that tomorrow in the morning and let you know. Fine, thanks. Just FYI, I built binutils master to check if the issue also exists with the v2 plugin interface. One previously failing testcase now PASSes with gld 2.34.50. I'm now running full bootstraps on both sparc-sun-solaris2.11 and i386-pc-solaris2.11 with that gld. This wouldn't be a solution, of course, just an additional datapoint.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Iain Sandoe --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #24) >> > --- Comment #23 from Iain Sandoe --- >> > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any >> > SDK >= >> > Xcode commandline tools 11.3b. >> >> I've recently tried both building gcc 8.3.0 (build only) and master >> (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode >> 11.3.1. Both worked *provided the build and target compilers were >> configured with the approriate --with-sysroot to account for the lack of >> /usr/include and startup objects in /usr/lib*. > > That's not going to change, I think (at least, the underlying behaviour). Indeed, we'll have to live with that. > We could entertain and implement a change to Darwin's configuration that > automatically discovers the /Library/Developer/CommandLineTools .. or > /Applications/Xcode... for Darwin versions >= X and complains of fails to > configure if those can't be seen (asking for a --with-sysroot=). That's one option, certainly easier for the users. At the least, the issue should be documented in install.texi so they can add --with-sysroot manually if need be. I just noticed that the install docs only have a small section on PowerPC Darwin, nothing else... > We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not > called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from > 7.5+. > > The only irritation is that we can't use 'gcc' or 'g++' in that position, > because xcrun places the clang/++ aliases ahead of the GCC in the PATH (even > if > the GCC install is first) [last time I tried]. Sounds like a bad mess and totally unexpected. Besides, the additional exec will have some cost. No idea how measurable it would be for a bootstrap, though. > There's also an API to obtain the info - but only on 10.15+ and it forces one > to install XCode I suspect to use it, I'm not keen on making new dependencies > on things outside our control - I'd rather make use of OSS equivalents. Understood. In particular when Xcode.app can be installed anywhere, not just in /Applications. Maybe something to talk about with Jeremy Sequoia, perhaps it can be provided from some stable location?
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #6 from Zdenek Sojka --- (In reply to rsand...@gcc.gnu.org from comment #5) > (In reply to Zdenek Sojka from comment #1) > > I observe the same issue, and it breaks libgcc build for me: > > What configure arguments do you use? Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu --with-ld=/usr/bin/powerpc-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r10-7229-20200317212116-cd0b7124273-checking-yes-rtl-df-extra-powerpc
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #7 from rsandifo at gcc dot gnu.org --- Created attachment 48080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48080&action=edit Proof-of-concept hack to back up the point in comment 4 This hack shows what I mean in comment 4. It "fixes" the three testcases but almost certainly isn't correct. The point is that before r10-7312 we did the mode change regardless of what rs6000_can_change_mode_class said. I don't know enough about powerpc to know what cases: if (from_size < 8 || to_size < 8) return false; is handling.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- [...] > Fine, thanks. Just FYI, I built binutils master to check if the issue > also exists with the v2 plugin interface. One previously failing > testcase now PASSes with gld 2.34.50. I'm now running full bootstraps > on both sparc-sun-solaris2.11 and i386-pc-solaris2.11 with that gld. Both have just completed: the x86 results are unchanged from gld 2.34, the sparc results are back to what they were before your patch.
[Bug c/94263] New: build wxpython raspian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94263 Bug ID: 94263 Summary: build wxpython raspian Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tom.fitzsimons at whiffonline dot com Target Milestone: --- I hope this isn't a waste of someones time. I have tried to build wxpython on a raspian buster os on a Rpi3B. I keep running into this error. Maybe my fault (hope not) g++: internal compiler error: Segmentation fault signal terminated program cc1plus Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [Makefile:38633: advdll_animatecmn.o] Error 4 make: *** Waiting for unfinished jobs Error building ERROR: failed building wxWidgets Traceback (most recent call last): File "build.py", line 1468, in cmd_build_wx wxbuild.main(wxDir(), build_options) File "/home/pi/wxPython-4.0.7.post2/buildtools/build_wxwidgets.py", line 497, in main exitIfError(wxBuilder.build(dir=buildDir, options=args), "Error building") File "/home/pi/wxPython-4.0.7.post2/buildtools/build_wxwidgets.py", line 85, in exitIfError raise builder.BuildError(msg) buildtools.builder.BuildError: Error building Finished command: build_wx (11m8.805s) Finished command: build (11m8.805s)
[Bug c/94258] Warning Correction while using format specifiers %hx and %ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
t444.c: In function ‘main’:
t444.c:4:12: warning: format ‘%ho’ expects argument of type ‘int’, but argument
2 has type ‘double’ [-Wformat=]
4 | printf("%ho\n", 0.0);
| ~~^ ~~~
|| |
|int double
| %f
t444.c:5:12: warning: format ‘%hx’ expects argument of type ‘int’, but argument
2 has type ‘double’ [-Wformat=]
5 | printf("%hx\n", 0.0);
| ~~^ ~~~
|| |
|int double
| %f
That is correct warning as I mentioned. There is no short when passed via
variable arugments.
[Bug c++/94264] New: Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264
Bug ID: 94264
Summary: Array-to-pointer conversion not performed on array
prvalues
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ndkrempel at gmail dot com
Target Milestone: ---
I think the most clearcut example is:
int main() {
using T = int[];
T{1, 2} == nullptr;
}
This compiles fine with clang, and is supported by the standard: the ==
operator explicitly performs array-to-pointer conversion
(https://eel.is/c++draft/expr#eq-1), and array-to-pointer conversion is
explicitly defined for rvalue arrays (https://eel.is/c++draft/expr#conv.array).
Other examples (which again all compile with clang) are:
+T{1, 2};
Here the standard wording seems to have a minor bug, as unary "+" does not
explicitly perform the array-to-pointer conversion, and the general rubric for
applying it (https://eel.is/c++draft/expr#basic.lval-6) only applies to
glvalues as written.
T{1, 2} + 1;
Ditto.
*(T{1, 2} + 1);
Interesting as T{1, 2}[1] should be equivalent to this (modulo the value
category of the result, https://eel.is/c++draft/expr#sub), yet the former is
rejected by gcc and the latter accepted.
[Bug c++/94265] New: wrong warning "duplicated 'if' condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94265
Bug ID: 94265
Summary: wrong warning "duplicated 'if' condition"
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat t.cpp
#include
struct S { int a, b; };
int main ()
{
if (auto [a,b] = S { 0, 1 }; a) { }
else if (std::tie (a, b) = std::tuple (2, 3); a) { }
}
% g++ -std=c++17 -Wduplicated-cond t.cpp
t.cpp: In function 'int main()':
t.cpp:8:8: warning: duplicated 'if' condition [-Wduplicated-cond]
8 | else if (std::tie (a, b) = std::tuple (2, 3); a) { }
|^~
t.cpp:7:3: note: previously used here
7 | if (auto [a,b] = S { 0, 1 }; a) { }
| ^~
Though the condition "a" looks the same in both "if" statements, the value of a
can change in between, and in fact does in this example (the second "if" branch
is actually taken).
Unless the "tie" assignment to "auto []" pseudo-variables is for some reason
incorrect, but then of course gcc should mention that.
[Bug lto/94249] [10 regression] Many -flto -fuse-linker-plugin tests FAIL: could not add symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94249 --- Comment #9 from dave.anglin at bell dot net --- This is with Debian ld 2.34 on hppa-linux.
[Bug target/94254] [10 regression] r10-7312 causes compiler hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254 --- Comment #8 from Segher Boessenkool --- SFmode values are stored as DP IEEE float normally. There may be other cases as well, but this is the obvious one.
[Bug target/90835] Incompatibilities with macOS 10.15 headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #27 from Eric Gallager --- (In reply to r...@cebitec.uni-bielefeld.de from comment #26) > > --- Comment #25 from Iain Sandoe --- > > (In reply to r...@cebitec.uni-bielefeld.de from comment #24) > >> > --- Comment #23 from Iain Sandoe --- > >> > unpatched GCC master, gcc-9.x, gcc-8.x and gcc-7.5 work for me with any > >> > SDK >= > >> > Xcode commandline tools 11.3b. > >> > >> I've recently tried both building gcc 8.3.0 (build only) and master > >> (full bootstrap and test) on macOS 10.14.6 and 10.15.3, each with Xcode > >> 11.3.1. Both worked *provided the build and target compilers were > >> configured with the approriate --with-sysroot to account for the lack of > >> /usr/include and startup objects in /usr/lib*. > > > > That's not going to change, I think (at least, the underlying behaviour). > > Indeed, we'll have to live with that. > > > We could entertain and implement a change to Darwin's configuration that > > automatically discovers the /Library/Developer/CommandLineTools .. or > > /Applications/Xcode... for Darwin versions >= X and complains of fails to > > configure if those can't be seen (asking for a --with-sysroot=). > > That's one option, certainly easier for the users. At the least, the > issue should be documented in install.texi so they can add > --with-sysroot manually if need be. I just noticed that the install > docs only have a small section on PowerPC Darwin, nothing else... > > > We can already invoke GCC like "xcrun /path/to/gcc-exe" provided that is not > > called "gcc" or "g++" it will work to set the SDKROOT which gcc honours from > > 7.5+. > > > > The only irritation is that we can't use 'gcc' or 'g++' in that position, > > because xcrun places the clang/++ aliases ahead of the GCC in the PATH > > (even if > > the GCC install is first) [last time I tried]. > > Sounds like a bad mess and totally unexpected. Besides, the additional > exec will have some cost. No idea how measurable it would be for a > bootstrap, though. > > > There's also an API to obtain the info - but only on 10.15+ and it forces > > one > > to install XCode I suspect to use it, I'm not keen on making new > > dependencies > > on things outside our control - I'd rather make use of OSS equivalents. > > Understood. In particular when Xcode.app can be installed anywhere, not > just in /Applications. Maybe something to talk about with Jeremy > Sequoia, perhaps it can be provided from some stable location? I think it has come up in some other bug...
[Bug fortran/94228] Preprocessor inconsistency for macros when invoked from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 --- Comment #6 from Mark Paris --- (In reply to Steve Kargl from comment #5) > On Thu, Mar 19, 2020 at 10:24:10PM +, markwayne1969 at gmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 > > > > --- Comment #4 from Mark Paris --- > > (In reply to kargl from comment #3) > > > No. Newer C, as opposed to older C, uses // for a comment. > > > Fortran uses // as the concatenation operator. Run this > > > through a cpp pre-processor. > > > > > > character(len=80) :: name = 'john ' // 'Doe' > > > print *, name > > > end > > > > > > ~/work/bin/cpp a.F > > > # 1 "a.F" > > > # 1 "" > > > # 1 "" > > > # 1 "a.F" > > > character(len=80) :: name = 'john ' > > > print *, name > > > end > > > > Thank you for your kind reply. I understand that this is an issue > of disparate use of the same operator, '//' in C and Fortran. > > > > Is it possible to have cpp recognize the different uses of // by, > > say, the file name extension of the source being processed? > > Sure. Anything is possible if someone puts in the time to > write a Fortran specific preprocessor. AFAIK, none of the > current diminishing number of gfortran contributors is > working a new preprocessor. > > > Links to information about gcc development for this specific > > possible feature would be appreciated. > > I don't know of any gfortran preprocessor projects. You are > more then welcomed to clone the git repository and start > such a project. Having new gfortran contributors would be > healthy for gfortran's future. Thank you, again for your reply. It's not exactly the information I was looking for -- perhaps you're not the right person to ask. If not, you might be able to point me to the correct group. I was asking whether you knew of any reason that the existing cpp couldn't be adjusted to handle the '//' disparity with a filename extension dependency. If this is possible, then it seems like a minor revision, as opposed to what you appear to have in mind of writing "a Fortran specific preprocessor," which sounds like a prohibitive undertaking. Thanks again.
[Bug tree-optimization/94266] New: aarch64：ICE during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94266
Bug ID: 94266
Summary: aarch64：ICE during GIMPLE pass: forwprop
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qianchao9 at huawei dot com
Target Milestone: ---
Target: aarch64
hello
I find an ICE when testing GCC10.0 on aarch64 with -march=armv8.2-a+sve
-msve-vector-bits=256 -ftree-loop-vectorize -O2:
Simple test case
---
#include
#define N 16
int out[N];
int a[2*N] =
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31};
/* Outer-loop vectorization. */
__attribute__ ((noinline)) void
foo ()
{
int i, j;
int res;
for (i = 0; i < N; i++)
{
res = 1000;
for (j = 0; j < N; j++)
res = res - a[i+j];
out[i] = res;
}
}
int main ()
{
foo ();
return 0;
}
---
GCC version:
gcc version 10.0.1 20200309 (experimental) (GCC)
Runcommand:
gcc new_test.c -march=armv8.2-a+sve -msve-vector-bits=256 -ftree-loop-vectorize
-O2 -S -o new_test.s
Result:
during GIMPLE pass: forwprop
pr_xxx.c: In function ‘foo’:
pr_xxx.c:10:1: internal compiler error: in maybe_canonicalize_mem_ref_addr, at
gimple-fold.c:4899
10 | foo ()
| ^~~
0x97dd5b maybe_canonicalize_mem_ref_addr
../../gcc/gimple-fold.c:4899
0x988d97 fold_stmt_1
../../gcc/gimple-fold.c:4972
0x98cfa3 fold_stmt_inplace(gimple_stmt_iterator*)
../../gcc/gimple-fold.c:5328
0xde455f forward_propagate_addr_expr_1
../../gcc/tree-ssa-forwprop.c:878
0xde6513 forward_propagate_addr_expr
../../gcc/tree-ssa-forwprop.c:998
0xdea427 execute
../../gcc/tree-ssa-forwprop.c:2715
[Bug tree-optimization/93328] missed optimization opportunity in deserialization code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93328
--- Comment #3 from Paco Arjonilla ---
But this gets optimized indeed!
#include
using type = std::uint32_t;
type foo(type v){
type r = ((v << 24) & 0xFF00)
| ((v << 8) & 0x00FF)
| ((v >> 8) & 0xFF00)
| ((v >> 24) & 0x00FF);
return r;
}
GCC -O2:
foo(unsigned int):
mov eax, edi
bswap eax
ret
