[Bug lto/86651] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 U.Mutlu changed: What|Removed |Added CC||um at mutluit dot com --- Comment #1 from U.Mutlu --- Do you get the same error if you leave out the --disable-plugin ?
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 --- Comment #5 from U.Mutlu --- I have to correct myself in #2 and #3. The code is correct, and should return n=6.
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 --- Comment #4 from U.Mutlu --- gcc version 4.9.2 (Debian 4.9.2-10+deb8u1) gives the same result as v9: p=123456 n=6
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622
--- Comment #3 from U.Mutlu ---
I just tested it with v9:
#include
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
const char* p = *([1] + i);
int n = __builtin_strlen (p);
printf("p=%s n=%d\n", p, n);// p=123456 n=6
if (n != 6)
__builtin_abort ();
}
Hmm. I would have expected something different, along the lines of
p=[1][1]...
The question is, which result is correct?
[Bug tree-optimization/86622] [9 Regression] incorrect strlen of array of array plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86622 U.Mutlu changed: What|Removed |Added CC||um at mutluit dot com --- Comment #2 from U.Mutlu --- I think there's no error. IMO the call is wrong as it tests the strlen of a single char (a[1][1], ie. '2'), which of course is bogus.
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #6 from U.Mutlu --- Another difference is: the passing normal compiler was built with itself (so to say, ie. built with v9), whereas the failing cross compiler was built with the default system compiler: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10+deb8u1)
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #5 from U.Mutlu --- I just see a difference: Target: x86_64-linux-gnu Target: x86_64-linux The pr68264 fails in the latter case (built as a crosscompiler).
[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #4 from U.Mutlu --- (In reply to Eric Gallager from comment #3) > (In reply to Oleg Endo from comment #2) > > (In reply to Kazumoto Kojima from comment #1) > > > (In reply to Oleg Endo from comment #0) > > > > Kaz, do you know what's going wrong there? Some silent wrong code > > > > related > > > > to fenv maybe? > > > > > > Maybe, though I have no idea for what is going on. > > > You can see that those tests fail on several other targets: > > > > > > powerpc-ibm-aix7.1.0.0 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00925.html > > > x86_64-unknown-freebsd9.3 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00932.html > > > i386-unknown-freebsd10.3 > > > https://gcc.gnu.org/ml/gcc-testresults/2016-05/msg00919.html > > > > Oh, good to know. Thanks for checking. Probably we can close this PR as > > "invalid" after a while... > > U.Mutlu says it still fails here: > https://gcc.gnu.org/ml/gcc-help/2018-07/msg00179.html Today I discovered that with a gcc that was built normally on x86_64 it does not fail! So, we have 2 cases: gcc built as crosscompiler: pr68264 fails gcc built as non-crosscompiler: pr68264 passes The test command was: cd build-gcc rm -fr *.sum make check-gcc-c RUNTESTFLAGS="-a -v -v dg-torture.exp=pr68264.c" 2>&1 | tee /tmp/test_one.t And here are the compiler settings: 1.) normal build (with suffix "-latest", was built with many optimization flags): Executing on host: /data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/xgcc -v (timeout = 300) pid is 4079 -4079 waitres is 4079 exp8 0 0 output is Using built-in specs. COLLECT_GCC=/data/sw/src/gcc_dev/my_build_dir_for_gcc/gcc/xgcc COLLECT_LTO_WRAPPER=/usr/local/MY_gcc/gcc-latest_34_base_31__bootstrap0_strip1__binutils-latest1/libexec/gcc/x86_64-linux-gnu/9.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc_trunk/configure -v --prefix=/usr/local/MY_gcc/gcc-latest_34_base_31__bootstrap0_strip1__binutils-latest1 --program-suffix=-latest --build=x86_64-linux-gnu --host=x86_64-linux-gnu --disable-multilib --enable-checking=release --enable-languages=c,c++ --enable-threads=posix --enable-lto --enable-plugin --enable-shared --with-build-config=bootstrap-lto --with-system-zlib --disable-nls --enable-libstdcxx-time=yes --enable-link-mutex --disable-bootstrap CC=gcc-latest GCC=gcc-latest CXX=g++-latest CC_FOR_BUILD=gcc-latest GCC_FOR_BUILD=gcc-latest CXX_FOR_BUILD=g++-latest CC_FOR_TARGET=gcc-latest GCC_FOR_TARGET=gcc-latest CXX_FOR_TARGET=g++-latest 'CXXFLAGS_FOR_BUILD= -fopt-info -pipe -Ofast-DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include ' 'CXXFLAGS_FOR_TARGET= -fopt-info -pipe -Ofast -DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include ' LDFLAGS=' -fopt-info -pipe -Ofast-DCLS=64 -fpic -floop-nest-optimize --param simultaneous-prefetches=16 -fprefetch-loop-arrays -msse4.2 -mrecip=all -funroll-loops -fdelete-null-pointer-checks --param prefetch-latency=32 -ffast-math -ftree-vectorize -funsafe-math-optimizations -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Wno-pedantic -Wno-error -I/usr/include -flto' --without-target-libbacktrace --disable-vtable-verify --enable-clocale=gnu --enable-default-pie --enable-gnu-unique-object --with-abi=m64 --with-default-libstdcxx-abi=new --with-tune=generic --with-gcc-arch=x86_64 --with-gnu-as --with-gnu-ld --enable-gnu-indirect-function CFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' CPPFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' CXXFLAGS='-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' 'CFLAGS_FOR_BUILD=-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' 'CFLAGS_FOR_TARGET=-fopt-info -pipe -Wall -Wextra -Werror -Wpedantic -pedantic -g0 -DNDEBUG -Ofast -Wno-pedantic -Wno-error -I/usr/include ' Thread model: posix gcc version 9.0.0 20180701 (experimental) [trunk revision 262287] (GCC) status 0
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #8 from U.Mutlu --- If one activates -Werror then it won't build as it then treats the warnings as error. And there are many warnings currently suppressed. That means -Werror is deactivated by default, and IMO never activated by any of the configure scripts. It is possible to fix all the warnings and then use -Werror. That means then that if there were a warning, then it wouldn't build. But if the warnings are fixed, then it will build even with -Werror. I just have managed to fix all warnings in libiberty (a tedious work as one has to start a clean-build after each fix done; but is manageable). For C & C++ there are in total 7 such configure scripts (like libiberty) needing such fixes: ../gcc_trunk/libiberty/configure ../gcc_trunk/fixincludes/configure ../gcc_trunk/libcpp/configure ../gcc_trunk/libdecnumber/configure ../gcc_trunk/mpfr-3.1.4/configure ../gcc_trunk/mpc-1.0.3/configure ../gcc_trunk/intl/configure If one can use the following, then the fixes can be done easily: #pragma GCC diagnostic push #pragma GCC diagnostic warning "-Wunused-value" ... #pragma GCC diagnostic pop But I'm not sure if that can be used if the building compiler is not gcc... So, currently just playing with it to broaden by experience...
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #6 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:
Example for the libiberty subdir: once w/o -Werror and once with -Werror:
< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no
And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...
So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> | /* Ultrix mips cc rejects this. */
> | typedef int charset[2];
> | const charset cs;
> | /* SunOS 4.1.1 cc rejects this. */
> | char const *const *pcpcc;
> | char **ppc;
> | /* NEC SVR4.0.2 mips cc rejects this. */
> | struct point {int x, y;};
> | static struct point const zero = {0,0};
> | /* AIX XL C 1.02.0.0 rejects this.
> | It does not let you subtract one const X* pointer from another in
> | an arm of an if-expression whose if-part is not a constant
> | expression */
> | const char *g = "string";
> | pcpcc = + (g ? g-g : 0);
> | /* HPUX 7.0 cc rejects these. */
> | ++pcpcc;
> | ppc = (char**) pcpcc;
> | pcpcc = (char const *const *) ppc;
> | { /* SCO 3.2v4 cc rejects this. */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> |
> | *t++ = 0;
> | if (s) return 0;
> | }
> | { /* Someone thinks the Sun supposedly-ANSI compiler will reject this. */
> | int x[] = {25, 17};
> | const int *foo = [0];
> | ++foo;
> | }
> | { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> | }
> | { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue.
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> | }
> | { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> | }
> | return !cs[0] && !zero.x;
> | #endif
> |
> | ;
> | return 0;
> | }
As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.
I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
--- Comment #5 from U.Mutlu ---
The configure scripts in the subdirs/libs (like libiberty) do compile some test
codes to populate the config.h of the subdir.
And there the difference happens if -Wuninitialized is treated as error,
ie. if user sets -Werror=uninitialized either explicitly or implicitly thru
-Werror or a similar option:
Example for the libiberty subdir: once w/o -Werror and once with -Werror:
< conftest.c:53:7: warning: 't' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:53:7: error: 't' is used uninitialized in this function
> [-Werror=uninitialized]
361c361
< conftest.c:75:13: warning: 'cs[0]' is used uninitialized in this function
[-Wuninitialized]
---
> conftest.c:75:13: error: 'cs[0]' is used uninitialized in this function
> [-Werror=uninitialized]
364,365c364,447
< configure:4686: $? = 0
< configure:4693: result: yes
...
> configure:4693: result: no
And in the 2nd case (>) from there on this causes many things in the config.h's
to be set differently, incl. the said NEED_DECLARATION_ERRNO ...
So, I think if the warnings in the stanza-codes could be eliminated then the
compilation would go further. It is the following code that generates the above
warnings: the variables t and cs should be initialized:
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> | /* FIXME: Include the comments suggested by Paul. */
> | #ifndef __cplusplus
> | /* Ultrix mips cc rejects this. */
> | typedef int charset[2];
> | const charset cs;
> | /* SunOS 4.1.1 cc rejects this. */
> | char const *const *pcpcc;
> | char **ppc;
> | /* NEC SVR4.0.2 mips cc rejects this. */
> | struct point {int x, y;};
> | static struct point const zero = {0,0};
> | /* AIX XL C 1.02.0.0 rejects this.
> | It does not let you subtract one const X* pointer from another in
> | an arm of an if-expression whose if-part is not a constant
> | expression */
> | const char *g = "string";
> | pcpcc = + (g ? g-g : 0);
> | /* HPUX 7.0 cc rejects these. */
> | ++pcpcc;
> | ppc = (char**) pcpcc;
> | pcpcc = (char const *const *) ppc;
> | { /* SCO 3.2v4 cc rejects this. */
> | char *t;
> | char const *s = 0 ? (char *) 0 : (char const *) 0;
> |
> | *t++ = 0;
> | if (s) return 0;
> | }
> | { /* Someone thinks the Sun supposedly-ANSI compiler will reject this. */
> | int x[] = {25, 17};
> | const int *foo = [0];
> | ++foo;
> | }
> | { /* Sun SC1.0 ANSI compiler rejects this -- but not the above. */
> | typedef const int *iptr;
> | iptr p = 0;
> | ++p;
> | }
> | { /* AIX XL C 1.02.0.0 rejects this saying
> |"k.c", line 2.27: 1506-025 (S) Operand must be a modifiable lvalue.
> */
> | struct s { int j; const int *ap[3]; };
> | struct s *b; b->j = 5;
> | }
> | { /* ULTRIX-32 V3.1 (Rev 9) vcc rejects this */
> | const int foo = 10;
> | if (!foo) return 0;
> | }
> | return !cs[0] && !zero.x;
> | #endif
> |
> | ;
> | return 0;
> | }
As this code is just for test-compilation by the configure script, then it
makes sense to fix the warnings.
I will try this for all occurrences of that code and similar ones, and if the
result is satisfactory, then post a patch to the mailing list for review.
[Bug c/86377] extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377 --- Comment #3 from U.Mutlu --- As said in the Remarks, the bug originally was triggered in this file in the trunk: ../gcc_trunk/libiberty/pex-common.c:28 #include #ifdef NEED_DECLARATION_ERRNO extern int errno; #endif
[Bug c/86377] New: extern int errno; is treated as buggy function declaration [-Werror=strict-prototypes]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86377
Bug ID: 86377
Summary: extern int errno; is treated as buggy function
declaration [-Werror=strict-prototypes]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
Created attachment 44344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44344=edit
The output file of -save-temps (ie. the "file.i" file)
test file extern_var_bug.c:
-
#include
extern int errno;
int main(int argc, char* argv[])
{
return errno;
}
Output:
---
extern_var_bug.c:2:16: error: function declaration isn't a prototype
[-Werror=strict-prototypes]
extern int errno;
^
extern_var_bug.c: In function 'main':
extern_var_bug.c:4:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char* argv[])
^~~~
extern_var_bug.c:4:26: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char* argv[])
~~^~
cc1: all warnings being treated as errors
Compiler and compile command:
-
# gcc-latest is v9 from svn trunk on x86_64
$ gcc-latest --version
gcc-latest (GCC) 9.0.0 20180701 (experimental) [trunk revision 262287]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
gcc-latest -c -DHAVE_CONFIG_H -fopt-info -Wall -Wextra -Werror -Wpedantic
-pedantic -g0 -DNDEBUG -Ofast \
-I. -I../../gcc_trunk/libiberty/../include -W -Wall -Wwrite-strings \
-Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic -D_GNU_SOURCE
-fpic \
\
-Wno-error=stringop-truncation -Wno-error=unused-parameter \
\
-x c \
-fno-strict-aliasing -fwrapv \
-save-temps \
\
extern_var_bug.c \
Remarks:
- The compile error happens only if was included, and only if
compiled as C.
- The same error originally happened in
../../gcc_trunk/libiberty/pex-common.c:28:1: error: function declaration isn't
a prototype [-Werror=strict-prototypes]
extern int errno;
^~
when building with nearly almost all warnings enabled and -g0 -DNDEBUG.
[Bug libitm/86294] New: comparison is always true due to limited range of data type [-Werror=type-limits]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86294
Bug ID: 86294
Summary: comparison is always true due to limited range of data
type [-Werror=type-limits]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: um at mutluit dot com
Target Milestone: ---
If warnings are treated as error (I think that's the default, or gets
implicitly activated if -Wall -Wextra has been given), then if
-Wno-error=type-limits has not been defined, then the following error gets
reported and the build aborts:
../../../gcc_trunk/libitm/method-ml.cc: In member function 'virtual bool
{anonymous}::ml_wt_dispatch::supports(unsigned int)':
../../../gcc_trunk/libitm/method-ml.cc:650:35: error: comparison is always true
due to limited range of data type [-Werror=type-limits]
return (number_of_threads * 2 <= ml_mg::OVERFLOW_RESERVE);
~~^~~~
[Bug libitm/86293] New: unused variable left over (used in assert) when building with -g0 -DNDEBUG [-Werror=unused-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86293 Bug ID: 86293 Summary: unused variable left over (used in assert) when building with -g0 -DNDEBUG [-Werror=unused-variable] Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: um at mutluit dot com Target Milestone: --- when building the languages=c,c++ with "-g0 -DNDEBUG", then the following error happens: ../../../gcc_trunk/libitm/method-serial.cc: In member function 'void GTM::gtm_thread::serialirr_mode()': ../../../gcc_trunk/libitm/method-serial.cc:309:12: error: unused variable 'ok' [-Werror=unused-variable] bool ok = disp->trycommit (priv_time); ^~ Of course one can get rid of it by giving also -Wno-error=unused-variable. Hints for fixing: As the variable gets used only in an assert statement, then the variable definition should have "__attribute__((unused))" added: bool ok __attribute__((unused)) = disp->trycommit (priv_time);
