Re: [Bug other/86890] New: GCC 8.2.0 fails to build with isl 0.20
isl 0.18 is the supported version for gcc 8 branch. Original message From: freddie_chopin at op dot pl Date: 08/08/2018 16:04 (GMT+00:00) To: gcc-bugs@gcc.gnu.org Subject: [Bug other/86890] New: GCC 8.2.0 fails to build with isl 0.20 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86890 Bug ID: 86890 Summary: GCC 8.2.0 fails to build with isl 0.20 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: freddie_chopin at op dot pl Target Milestone: --- When trying to build GCC 8.2.0 with isl 0.20, I see a lot (at least a few dozens) of errors about undeclared functions, like: -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/. -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../include -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libcpp/include -I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/gmp-6.1.2/include -I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/mpfr-4.0.1/include -I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/mpc-1.1.0/include -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libdecnumber -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/../libbacktrace -I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/isl-0.20/include -I/home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/zlib-1.2.11/include -pipe -o graphite-isl-ast-to-gimple.o -MT graphite-isl-ast-to-gimple.o -MMD -MP -MF ./.deps/graphite-isl-ast-to-gimple.TPo /home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c /home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c: In function ‘void ivs_params_clear(ivs_params&)’: /home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c:83:7: error: ‘isl_id_free’ was not declared in this scope isl_id_free (it->first); ^~~ /home/freddie/bleeding-edge-toolchain/sources/gcc-8.2.0/gcc/graphite-isl-ast-to-gimple.c:83:7: note: suggested alternative: ‘isl_aff_free’ isl_id_free (it->first); ^~~ isl_aff_free -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- This seems like some header include problems or something like that, as there definitely is a isl_id_free() function in /home/freddie/bleeding-edge-toolchain/buildNative/prerequisites/isl-0.20/include/isl/id.h, which is available in the search path.
ada no longer boootraps
I resent change causes ada no longer to bootstrap multiple definition of ada_demangle /usr/local/src/gcc4.3/src/libiberty/cplus-dem.c:895: multiple definition of `ada_demangle' ada/adadecode.o:/usr/local/src/gcc4.3/src/gcc/ada/adadecode.c:374: first defined here graham
Makefile.in missing a definition of c-family-warn
All, I noticed that files in the c-family directory compiled during stage3 arn't using -Werror along with many other Warning flags usually applied during stage3 This to me appears to be because nothing is definng c-family-warn = $(STRICT_WARN) so any warnings specified as parrt of STRICT_WARN arn't being applied when compiling any fille within gcc/c-family Graham
Re: [Bug target/41246] should sorry when regparm=3 and nested functions are encountered
All, nested functions get passed a hidden argumment akin to static link/display so that nested function can access the locals of its enclosing function. Passing a nested function as parameter to another function isn't going to work correctly when the function is eventually called the hidden argument isn't going to be setup correctly. I think the code is thus invalid and GCC should reject it. Regards Graham --- On Thu, 3/9/09, bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org wrote: From: bonzini at gnu dot org gcc-bugzi...@gcc.gnu.org Subject: [Bug target/41246] should sorry when regparm=3 and nested functions are encountered To: gcc-bugs@gcc.gnu.org Date: Thursday, 3 September, 2009, 6:11 PM --- Comment #5 from bonzini at gnu dot org 2009-09-03 17:11 --- Yes, if you use nested functions you can just use -mregparm=2 globally, that's a much better solution. -- bonzini at gnu dot org changed: What |Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-03 17:11:30 date| | Summary|%ecx corruption when |should sorry when |combining -regparm=3 with |regparm=3 and nested |nested functions |functions are encountered http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
Re: [Bug tree-optimization/38180] CCP does not propagate through constant initializers
Richard, const volatile is a perfectly valid combination. What is says is it's read only but may change value in ways unknown to the compiler think of a memory mapped hardware register which is read only such as some kind of counter . Cheers Graham
Re: [Bug tree-optimization/38180] CCP does not propagate through constant initializers
Hi Richard,
Does this patch work for objects which are both const and volatile
get_symbol_constant_value only looks at TREE_READONLY should it not
also look at TREE_VOLATILE ?
I don't have a upto date tree to hand to try the following testcase on
static const volatile int value = 42;
int foo(void)
{
return value;
}
Here it's not valid to ccp value into the return value and return 42
Graham
--- On Wed, 26/11/08, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote:
From: rguenth at gcc dot gnu dot org [EMAIL PROTECTED]
Subject: [Bug tree-optimization/38180] CCP does not propagate through
constant initializers
To: gcc-bugs@gcc.gnu.org
Date: Wednesday, 26 November, 2008, 12:28 PM
--- Comment #3 from rguenth at gcc dot gnu dot org
2008-11-26 12:28 ---
Subject: Bug 38180
Author: rguenth
Date: Wed Nov 26 12:27:33 2008
New Revision: 142217
URL:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=142217
Log:
2008-11-26 Richard Guenther [EMAIL PROTECTED]
PR tree-optimization/38180
* tree-ssa-ccp.c (get_default_value): Simplify.
(likely_value): Likewise.
(surely_varying_stmt_p): Properly handle VOP case.
(ccp_initialize): Likewise.
(ccp_fold): Handle propagating through *.
(fold_const_aggregate_ref): Also handle decls.
* gcc.dg/tree-ssa/ssa-ccp-24.c: New testcase.
Added:
branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-24.c
Modified:
branches/alias-improvements/gcc/ChangeLog.alias
branches/alias-improvements/gcc/tree-ssa-ccp.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38180
Re: [Bug rtl-optimization/37296] Bootstrap failure due to __muldi3
All, From the backtrace I very doubt this is a IRA issue. I looks to be related to the recent IPA/CGRAPG changes so it's one for Honza to look at Cheers Graham
Re: GCC has problems with 64-bit multiplication
All,
Not a bug in GCC the result is correct as you've only asked for a 32-bit
multiply.
--- Hans Petter Selasky [EMAIL PROTECTED] wrote:
Test program:
#include stdio.h
#include sys/types.h
int main() {
int32_t a = 0x4000;
int16_t b = 0x4000;
int64_t c = a * b;
^ this is a 32-bit multiply with the result widened
to 64-bit,
printf(0x%016llx\n, c);
return 0;
}
Re: [Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham
Re: [Bug c++/27045] c++ is generating incorrect optimized code for xor operations on long long
All, Not a bug, this is yet another case of type pruning. Use -fno-strict-aliasing or fix your code. Graham
Re: [Bug bootstrap/26679] boostrap failure due to warning in gcc/varasm.c
All, If the warning isn't bogus then we probably need to do the shift in two steps (i.e. hwi = (hwi (shift - 1)) 1) as done elsewhere to avoid the potential warning. --- joseph at codesourcery dot com [EMAIL PROTECTED] wrote: --- Comment #4 from joseph at codesourcery dot com 2006-03-14 15:11 --- Subject: Re: boostrap failure due to warning in gcc/varasm.c On Tue, 14 Mar 2006, pinskia at gcc dot gnu dot org wrote: What compiler are you using to get that warning? There should be no warning as shift is a variable and n is a variable and should be zero. shift is a const variable initialized with a constant, so when building with optimization (this is the stage1 compiler building the stage2 compiler) it gets replaced by its value. Because the warning is given before dead code elimination, the fact that n is also a constant and the code is unreachable is irrelevant. Why this error is newly appeared I'm not sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26679
Re: [Bug middle-end/25568] New: [4.2 regression] RTL checking bootstrap failure on i686-unknown-linux-gnu
ghazi at gcc dot gnu dot org wrote:
I'm getting an RTL checking bootstrap failure on i686-unknown-linux-gnu. The
bootstrap dies in stage2 like so:
/home/ghazi/tmpdisk/gcc-testing/42/build/./prev-gcc/xgcc
-B/home/ghazi/tmpdisk/gcc-testing/42/build/./prev-gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\
-DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\
-DPACKAGE=\zlib\ -DVERSION=\1.1.4\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1
-DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 -I.
-I../../egcc-SVN20051225/zlib -O2 -g -fomit-frame-pointer -c -o
libz_a-deflate.o `test -f 'deflate.c' || echo
'../../egcc-SVN20051225/zlib/'`deflate.c
../../egcc-SVN20051225/zlib/deflate.c: In function 'deflateInit2_':
../../egcc-SVN20051225/zlib/deflate.c:312: internal compiler error: RTL check:
expected code 'const_int', have 'const_double' in simplify_shift_const_1, at
combine.c:8923
This is a regression.
The follow patch should fixit
Index: combine.c
===
--- combine.c (revision 109050)
+++ combine.c (working copy)
@@ -8919,6 +8919,7 @@
(new = simplify_const_binary_operation (ASHIFT, result_mode,
XEXP (varop, 1),
GEN_INT (count))) != 0
+ GET_CODE (new) == CONST_INT
merge_outer_ops (outer_op, outer_const, PLUS,
INTVAL (new), result_mode, complement_p))
{
@@ -8937,6 +8938,7 @@
(new = simplify_const_binary_operation (code, result_mode,
XEXP (varop, 1),
GEN_INT (count))) != 0
+ GET_CODE (new) == CONST_INT
merge_outer_ops (outer_op, outer_const, XOR,
INTVAL (new), result_mode, complement_p))
{
Re: [Bug middle-end/25568] [4.2 regression] RTL checking bootstrap failure on i686-unknown-linux-gnu
ghazi at gcc dot gnu dot org wrote: --- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-26 16:04 --- I did a successful rtl bootstrap (--enable-checking=yes,rtl) as recently as: http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00388.html So this is at most a few weeks old. It came in with Fridays update
Re: [Bug target/22112] Another fallout from alias warning patch
nathan at gcc dot gnu dot org wrote: --- Additional Comments From nathan at gcc dot gnu dot org 2005-06-18 13:04 --- can someone send me the .i file and/or sys/ucontext.h, I don't have an x86-64 system available. It also happens on i686-pc-linux-gnu
Re: [Bug fortran/17590] Standard conformance should take intrinsics into account.
All,
FWIW here's a quick patch which fixes bootstrap problem for me on i686-pc-linux-gnu.
I've got to go out the door in 5 mins do with as you see fit.
Graham
Index: intrinsic.c
===
RCS file: /cvs/gcc/gcc/gcc/fortran/intrinsic.c,v
retrieving revision 1.27
diff -c -p -r1.27 intrinsic.c
*** intrinsic.c 31 Oct 2004 01:24:29 - 1.27
--- intrinsic.c 31 Oct 2004 14:46:19 -
*** gfc_init_expr_extensions (gfc_intrinsic_
*** 2672,2687
static void
check_intrinsic_standard (const char *name, int standard)
{
! int name_len;
! char msgstr[name_len + 53];
!
! if (!gfc_option.warn_nonstd_intrinsics)
! return;
!
! name_len = strlen (name);
! strncpy (msgstr, name, name_len + 1);
! strncat (msgstr, intrinsic is not included in the selected standard., 53);
! gfc_notify_std (standard, msgstr);
}
--- 2671,2688
static void
check_intrinsic_standard (const char *name, int standard)
{
! if (gfc_option.warn_nonstd_intrinsics)
! {
! static const char err[] = intrinsic is not included in the selected standard.;
! size_t err_len = sizeof (err);
! size_t name_len = strlen (name);
! char *msgstr = gfc_getmem (name_len + err_len);
!
! memcpy (msgstr, name, name_len);
! memcpy (msgstr[name_len], err, err_len);
! gfc_notify_std (standard, msgstr);
! gfc_free (msgstr);
! }
}
