[Bug libgomp/28468] New: OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
Versions:
* gcc: gcc (GCC) 4.2.0 20060715 (experimental)
* cpu: AMD-K7 (i686)
* kernel: Linux 2.4.21-99 (SuSE 9.0)
* glibc: glibc-2.3.6 built with LinuxThreads, _not_ NPTL
Test program:
== omp-test1.c ===
#include
#include
/* A computational task whose duration depends on x. */
int job (int x)
{
int j = rand() % (100 + 10 * x);
int i;
for (i = j - 1; i > 0; i--)
if (j % i == 0)
break;
return i;
}
int main (int argc, char *argv[])
{
int n = 1;
int *mem = malloc (n * sizeof (int));
int i;
/* Because the tasks don't have all the same duration, a dynamic
schedule is best. */
#pragma omp parallel for schedule(dynamic)
for (i = 0; i < n; i++)
mem[i] = job (i);
for (i = 0; i < n; i++)
printf ("mem[%d] = %d\n", i, mem[i]);
return 0;
}
=
$ gcc -fopenmp -Wall -O omp-test1.c
The single-threaded program runs fine:
$ unset OMP_NUM_THREADS; ./a.out
or
$ export OMP_NUM_THREADS=1; ./a.out
But with more than one thread it crashes:
$ export OMP_NUM_THREADS=2; ./a.out
Segmentation fault (core dumped)
$ gdb a.out core.26661
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from
/gfs/ibook/Volumes/ExtData/bin.x86-linux/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1...done.
Loaded symbols for
/packages/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/iter.c:189
189 start = ws->next;
(gdb) where
#0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/iter.c:189
#1 0x4001c8e8 in gomp_loop_dynamic_next (istart=0xbfffe9c4, iend=0xbfffe9c8)
at ../../../gcc-4.2-20060715/libgomp/loop.c:248
#2 0x080486ed in main.omp_fn.0 ()
#3 0x0804861e in main ()
(gdb) print ws
$1 = (struct gomp_work_share *) 0x0
--
Summary: OpenMP-parallelized program crashes when OMP_NUM_THREADS
> 1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-suse-linux-gnu
GCC host triplet: i686-suse-linux-gnu
GCC target triplet: i686-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug c++/35708] jump to label enters catch block
--- Comment #3 from bruno at clisp dot org 2008-03-28 22:46 --- > you are entering a scope that has objects constructed. Can you point out the sections in the ISO C++ standard that say that an 'if' statement can create the scope for some objects? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #4 from bruno at clisp dot org 2008-03-28 22:48 --- The bug also occurs with g++ 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #7 from bruno at clisp dot org 2009-03-29 16:55 --- (In reply to comment #4) > The Fortran front-end diagnostic strings have a specific format, that is an > extension of the C printf format. It is not the same as the > gcc-internal-format. Thus, if you want it to be supported, it first needs to > be > recognized by the tools (xgettext), Support for this type of format has now been added to xgettext. The support will be contained in gettext 0.18. > then we'll modify the front-end headers to mark it appropriately. The xgettext options that need to be passed to "xgettext --language=GCC-source" are: --keyword=gfc_error:1:gfc-internal-format \ --keyword=gfc_error_now:1:gfc-internal-format \ --keyword=gfc_fatal_error:1:gfc-internal-format \ --keyword=gfc_internal_error:1:gfc-internal-format \ --keyword=gfc_notify_std:2:gfc-internal-format \ --keyword=gfc_warning:1:gfc-internal-format \ --keyword=gfc_warning_now:1:gfc-internal-format If you want to generate these options automatically, you'll need to modify the 'po/exgettext' script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug c/78155] missing warning on invalid isalpha et al.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #6 from Bruno Haible --- Created attachment 48440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48440&action=edit Test case Another test case is the attached program, alpha.c. When run on glibc systems on x86, x86_64, and other CPUs (not powerpc), it sign-extends the 'char' argument; so the character 'ÿ' (in ISO-8859-1 encoding) becomes EOF, and the function returns 0. $ LC_ALL=de_DE.ISO-8859-1 xterm $ ./a.out ÿ not alphabetic The corrected program (with a cast to 'unsigned char' in the isalpha() argument) behaves as expected: $ LC_ALL=de_DE.ISO-8859-1 xterm $ ./a.out ÿ alphabetic
[Bug c/96527] New: __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527 Bug ID: 96527 Summary: __builtin_va_arg_pack_len produces error in documented sample code Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 49024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49024&action=edit Test case The only documented example of __builtin_va_arg_pack_len, in https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Constructing-Calls.html , produces an error "invalid use of '__builtin_va_arg_pack_len ()'" when actually used. Test case foo.c is attached. GCC 5.5.0, 6.5.0, 7.5.0, 8.4.0, 9.3.0, 10.2.0 all produce an error: $ gcc -O2 -Wall -S foo.c foo.c: In function 'myopen': foo.c:7:7: error: invalid use of '__builtin_va_arg_pack_len ()' 7 | if (__builtin_va_arg_pack_len () > 1) | ^~~~
[Bug c/96527] __builtin_va_arg_pack_len produces error in documented sample code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527 --- Comment #2 from Bruno Haible --- Created attachment 49026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49026&action=edit Corrected test case I see. A corrected test case is attached. I wanted to avoid __gnu_inline__ because that's an attribute that is known to have caused trouble with GCC 4.2.x / 4.3.x. Nowadays, the preferred attribute is 'inline' from ISO C11. And I got in trouble with the 'extern' modifier while doing that... How about changing the example in the documentation to use static inline __attribute__((__always_inline__)) instead of extern inline __attribute__((__gnu_inline__)) ?
[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #9 from Bruno Haible --- We now have a generic workaround to this bug: If the bug occurs in a function foo: 1. Rename foo to foo_internal, mark it as '__attribute__ ((__noinline__)) static' and add a 'char stack_buf[1024]' parameter. 2. In the function foo_internal, drop the stack-allocated buffer and use the new parameter instead. 3. Create a new function foo, with the same signature as before, that merely allocates a 'char stack_buf[1024]' on the stack and passes it to foo_internal. For an example, see https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2a3468c9f263596815a3383c0157ba9a81cf2d24
[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #7 from Bruno Haible --- There is more discussion on this issue in bug #36166.
[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #8 from Bruno Haible ---
(In reply to Andrew Pinski from comment #6)
> a?-1:0 is transformed into -1 before we figure out that a is always true; an
> ordering difference.
Fortunately the GCC optimization affects only the return value of null_ptr().
It does not cause side effects to occur that shouldn't occur.
Test case:
=
extern char *canonicalize_file_name (const char *__name)
__attribute__ ((__nonnull__ (1)));
extern int rand (void);
extern void brick_the_hard_disk (void);
/* Return NULL. */
static void *
null_ptr (void)
{
unsigned int x = rand ();
unsigned int y = x * x;
/* The following statement is equivalent to if (false),
since a square is always congruent to 0 or 1 mod 4. */
if (y & 2) {
brick_the_hard_disk ();
return (void *) -1;
} else
return (void *) 0;
}
int
main (void)
{
return !!canonicalize_file_name (null_ptr ());
}
=
Compiled with gcc -O6 -S foo.c from a recent GCC 10 snapshot:
=
.file "foo.c"
.text
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callrand
imull %eax, %eax
testb $2, %al
je .L2
callbrick_the_hard_disk
.L2:
movq$-1, %rdi
callcanonicalize_file_name
testq %rax, %rax
setne %al
addq$8, %rsp
.cfi_def_cfa_offset 8
movzbl %al, %eax
ret
.cfi_endproc
.LFE1:
.size main, .-main
.ident "GCC: (GNU) 10.0.0 20191229 (experimental)"
.section.note.GNU-stack,"",@progbits
=
As you can see, it still performs the (y & 2) and will thus never execute
brick_the_hard_disk().
[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #10 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #9)
> So the only thing we should take from the above for the compiler is optimize
> in ccp that x*x has the second least significant bit clear.
If a compiler understands this, I'll change the function as follows:
=
/* Return NULL. */
static void *
null_ptr (void)
{
unsigned int x = rand ();
unsigned long long y = (unsigned long long) x * (unsigned long long) x;
/* The following statement is equivalent to if (false),
since a square is always congruent to 0 or 1 mod 3. */
if ((y % 3) == 2) {
brick_the_hard_disk ();
return (void *) -1;
} else
return (void *) 0;
}
=
Now, if you change GCC to handle that, by exploiting Gauss' quadratic
reciprocity law https://en.wikipedia.org/wiki/Quadratic_reciprocity ,
then I'll make y a polynomial of degree 3 and use some theorem about
Frobenius automorphisms ;-)
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 bruno at clisp dot org changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #17 from bruno at clisp dot org 2010-12-26 18:06:15 UTC --- Note that the use of values-xpg6.o leads to unexpected behaviour when considering shared libraries: 1) The behaviour of a shared library also depends on whether the executable is linked with or without values-xpg6.o. The author of the shared library may not expect this and may not have tested in this situation. 2) The behaviour of an executable also depends on whether some of the shared libraries was built with values-xpg6.o. The author of the program may not expect this. This leads to real bugs: <http://lists.gnu.org/archive/html/autoconf/2010-02/msg00013.html> More details in <http://lists.gnu.org/archive/html/autoconf/2010-12/msg00059.html> For this reason, I would find it bad if "gcc -std=c99" or "gcc -std=gnu99" would cause values-xpg6.o to be included in the link. Please close this issue as "Won't fix". Programs which wish to have POSIX compliant behaviour of system functions can use GNU gnulib; it doesn't rely on values-xpg6.o.
[Bug c/50154] New: attribute printf and scanf should imply attribute nonnull
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154 Bug #: 50154 Summary: attribute printf and scanf should imply attribute nonnull Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: br...@clisp.org Created attachment 25076 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25076 test case When a function is declared as taking a printf or scanf format string, gcc gives a warning when a format string with invalid syntax is passed. It should also give a warning when a NULL format string is passed. How to reproduce: Save the test case file as foo.c. $ gcc -Wformat=2 -c foo.c [no warning] $ gcc -Wformat=2 -c foo.c -DDECLARE_NONNULL foo.c: In function 'foo': foo.c:10:3: warning: null argument where non-null required (argument 3) [-Wnonnull] Rationale: 1) ISO C 99 specifies that the printf and scanf format strings must be "multibyte character sequences"; that excludes NULL. See ISO C 99 sections 7.19.6.1 paragraph 3 and 7.19.6.2 paragraph 3. 2) Passing NULL as first argument to printf crashes the program on FreeBSD, Solaris, and other platforms.
[Bug c/50154] attribute printf and scanf should imply attribute nonnull
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154 bruno at clisp dot org changed: What|Removed |Added Attachment #25076|0 |1 is obsolete|| --- Comment #1 from bruno at clisp dot org 2011-08-22 16:29:26 UTC --- Created attachment 25077 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25077 test case (corrected)
[Bug tree-optimization/50021] -Wsuggest-attribute=pure makes obviously-incorrect suggestion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50021 bruno at clisp dot org changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #4 from bruno at clisp dot org 2012-03-25 01:06:41 UTC --- Apparently fixed in GCC 4.7.0.gcc -Wsuggest-attribute=pure -O2 -S v.i
[Bug target/51793] New: pragma GCC optimize wrapv leads to invalid code on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Bug #: 51793
Summary: pragma GCC optimize wrapv leads to invalid code on
Solaris
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: br...@clisp.org
Created attachment 26274
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26274
Test case
The use of
#pragma GCC optimize ("wrapv")
with optimization level -O2 turns the ".p2align 4,,15" to ".p2align 4,,-1".
This can be observed on both i386-pc-solaris2.11 and i386-pc-linux-gnu systems.
On i386-pc-solaris2.11 it causes a compilation failure, because the assembler
does not understand this syntax.
How to reproduce:
== foo.c ==
#pragma GCC optimize ("wrapv")
int foo () { return 17; }
int bar () { return 42; }
===
$ gcc -O2 -c foo.c
Assembler: foo.c
"/var/tmp//ccwQaWQO.s", line 3 : .align test amount has negative value
"/var/tmp//ccwQaWQO.s", line 10 : .align test amount has negative value
$ gcc -O2 -S foo.c
$ cat foo.s
.file"foo.c"
.text
.p2align 4,,-1
.globl foo
.typefoo, @function
foo:
movl$17, %eax
ret
.sizefoo, .-foo
.p2align 4,,-1
.globl bar
.typebar, @function
bar:
movl$42, %eax
ret
.sizebar, .-bar
.ident"GCC: (GNU) 4.5.2"
$ gcc --version
gcc (GCC) 4.5.2
Copyright (C) 2010 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 -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/lto-wrapper
Target: i386-pc-solaris2.11
Configured with:
/builds/hudson/workspace/nightly/build/i386/components/gcc45/gcc-4.5.2/configure
CC=/ws/onnv-tools/SUNWspro/sunstudio12.1/bin/cc
CXX=/ws/onnv-tools/SUNWspro/sunstudio12.1/bin/CC --prefix=/usr/gcc/4.5
--mandir=/usr/gcc/4.5/share/man --bindir=/usr/gcc/4.5/bin
--libdir=/usr/gcc/4.5/lib --sbindir=/usr/gcc/4.5/sbin
--enable-languages=c,c++,fortran,objc --enable-shared
--with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr
--prefix=/usr/gcc/4.5 --mandir=/usr/gcc/4.5/share/man
--infodir=/usr/gcc/4.5/share/info --libexecdir=/usr/gcc/4.5/lib CFLAGS='-g -O2
'
Thread model: posix
gcc version 4.5.2 (GCC)
$ type as
as is hashed (/usr/bin/as)
$ as -V
as: Sun Compiler Common 12 SunOS_i386 snv_174 08/25/2011
Usage: as [-V] [-Q{y,n}] [-s]
[-S[aAbBcClL]] [-K {pic,PIC}] [-o objfile] [-L] [-T]
[-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
[-m [-Ym,path]] [-n] [-xF] [-F] [-b] [-i] file.s ...
[Bug target/52023] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
bruno at clisp dot org changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #2 from bruno at clisp dot org 2012-01-27 21:01:11 UTC ---
I can reproduce the bug with gcc version 4.7-20120121 (snapshot) for x86.
Test program:
===
#include
#include
#include
#include
int main ()
{
typedef struct { char slot1; int64_t slot2; } int64_t_helper;
typedef struct { char slot1; double slot2; } double_helper;
printf ("%d %d %d\n",
alignof (int64_t),
offsetof (int64_t_helper, slot2),
alignof (int64_t) == offsetof (int64_t_helper, slot2));
printf ("%d %d %d\n",
alignof (double),
offsetof (double_helper, slot2),
alignof (double) == offsetof (double_helper, slot2));
}
===
Actual output:
8 4 0
8 4 0
Expected output:
4 4 1
4 4 1
(In reply to comment #1)
> I don't think this is a bug, the alignment requirements in a struct can be
> different from outside of a struct.
You could argue like this for __alignof__ which is a GCC invention.
But since ISO C11 and since is included, we have to look what
ISO C11 says about it. Citing the latest draft of it (n1570.pdf):
6.5.3.4.(3)
"The _Alignof operator yields the alignment requirement of its operand type.
The
operand is not evaluated and the result is an integer constant. When applied
to
an array type, the result is the alignment requirement of the element type."
3.2 alignment
"requirement that objects of a particular type be located on storage
boundaries
with addresses that are particular multiples of a byte address"
3.15 object
"region of data storage in the execution environment, the contents of which
can represent values"
As a consequence of these definitions, the alignment of a type inside a struct
could be a multiple of _Alignof(type), but the alignment of a type inside a
struct
cannot be less than _Alignof(type).
In other words, if
alignof (double) == 8
then every 'double' object in memory must be on an address that is a multiple
of 8.
Then objects inside the 'double_helper' type must also always be at addresses
that
are a multiple of 8. Which by the rules for structs means that
alignof (double_helper)
and
offsetof (double_helper, slot2)
must both be multiples of 8.
More about structs in ISO C11:
6.7.2.1.(6)
"a structure is a type consisting of a sequence of members, whose
storage is allocated in an ordered sequence"
6.7.2.1.(14)
"Each non-bit-field member of a structure or union object is aligned in an
implementation-defined manner appropriate to its type."
Note the last part of the last sentence: "appropriate to its type". The
implementation does not have the freedom to ignore the type's alignment
when deciding about offsetof of a member in a struct.
Please reopen this bug. (I cannot find how to do this witin the bugzilla GUI.)
[Bug target/52023] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 --- Comment #9 from bruno at clisp dot org 2012-01-27 22:39:01 UTC --- (In reply to comment #7) > What happens if you have the attribute packed on the structure? Attribute 'packed' is outside the scope of ISO C11. We're discussing ISO C11 compliant programs here. ISO C11 has the _Alignas keyword, with which a stricter alignment can be requested (ISO C11 6.2.8.(1), 6.7.5.(4)), but not a less strict alignment. GCC's __alignof__ that returns the *preferred* alignment of an object of the given type has its uses (in memory allocators for example). But the semantics imposed by ISO C11 on the 'alignof' and '_Alignof' operators defined through is address boundary requirement for all "objects" of that type, not the preferred alignment.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #37 from Bruno Haible --- (In reply to Rainer Orth from comment #35) > Fixed for GCC 8.1. Please consider comment 17: The behaviour of a shared library also depends on whether the executable is linked with or without values-xpg6.o. The author of the shared library may not expect this and may not have tested in this situation. Can you please address this through documentation? As a shared library author, I find it extremely nasty to become aware of this tricky issue only after the fact. It could be some text such as "Note about Solaris: If you develop a shared library that makes use of functionality that is specified differently in C99 than in C90, you need to make sure that the library works fine either way. Whether C99 compliant definitions or C90 compliant definitions are in effect, depends whether the executable(!) is created with "gcc -std=c99" versus "gcc -std=c90"."
[Bug c/84190] New: [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 Bug ID: 84190 Summary: [7 Regression] double arithmetic on x86 no longer rounds to nearest Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 43331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43331&action=edit test program The attached program foo.c tests whether simple 'double' arithmetic does round-to-nearest. It uses 'volatile double' types to make sure that on x86, x86_64, and ia64, only 53 bits of precision are used instead of the "extended" doubles that have 64 bits of precision. With gcc versions 4.2.4 to 6.4.0: $ gcc -m32 -O -Wall foo.c && ./a.out 1 1 1 1 With gcc versions 7.1.0 to 7.3.0: $ gcc -m32 -O -Wall foo.c && ./a.out 0 0 0 0 This occurs even with -frounding-math: $ gcc -m32 -O -frounding-math -Wall foo.c && ./a.out 0 0 0 0 It does not occur when inlining is disabled: $ gcc -m32 -O -fno-inline -Wall foo.c && ./a.out 1 1 1 1
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #1 from Bruno Haible --- It works when I declare ys1, ys2, zs1, zs2 as 'volatile double' instead of 'double'. But I should not be needing to do this, because the only uses of these 4 variables is as arguments to equalfn, which takes 'volatile double *' arguments, which ought to already do the truncation from extended-double format to double format.
[Bug other/84193] New: Document the limitations of -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84193 Bug ID: 84193 Summary: Document the limitations of -fcheck-pointer-bounds Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- The documentation of -fcheck-pointer-bounds in https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Instrumentation-Options.html says - what the option does, - what are the prerequisites from other tools, - how it can be fine-tuned. However, it does not say what are the limitations. === Quoting the article "Design of Intel MPX" from Intel <https://intel-mpx.github.io/design/>: "At the application level, the MPX-protected program may require manual changes due to troublesome C coding patterns, multithreading issues, or potential problems with other ISA extensions. (In some cases, it is inadvisable to use MPX at all.)" "the protected application will have worse cache locality" "Intel MPX can cause issues when used together with other ISA extensions, e.g., Intel TSX and Intel SGX. Intel MPX may cause transactional aborts in some corner cases when used inside an Intel TSX hardware transaction ..." "our evaluation reveals that narrowing of bounds breaks many programs (see Usability)..." (The entire section "Not supported C idioms" is relevant.) === Quoting Florian Weimer, a glibc co-maintainer <https://lists.gnu.org/archive/html/bug-gnulib/2018-02/msg00015.html>: "-fcheck-pointer-bounds in GCC doesn't really work. The existing implementation is barely a research prototype (for example, most string functions are not protected by it), and I don't think anyone knows how to make it thread-safe." Really, as a user of GCC, I would like to be made aware of these limitations through the GCC documentation, so that I don't waste my time attempting to use a technology that will not work with my application.
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #5 from Bruno Haible --- (In reply to jos...@codesourcery.com from comment #4) > You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for > predictable results from double arithmetic on 32-bit x86. If you do that, > do you still see such a problem? If I pass -fexcess-precision=standard or -mfpmath=sse (no need for -msse2 in this case), the test passes. However, something has evidently changed (regressed) in the inliner: 'volatile double', put in sufficiently many places, has the same effect as -fexcess-precision=standard (before gcc 7 and in gcc 7). What has changed, is that if I have 'volatile double' only in the signature of the 'equalfn' function that gets inlined, since gcc 7 this information that the values should be passed as IEEE doubles (discarding excess precision) gets lost.
[Bug tree-optimization/91029] New: missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Bug ID: 91029
Summary: missed optimization regarding value of modulo
operation
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
GCC's optimizers apparently don't know that, for b an integer >= 0, a % b > 0
implies that a >= 0 and a % b < 0 implies that a <= 0.
Test case:
= foo.c =
int xx;
void f (int i)
{
if ((i % 7) == 3)
xx = (i < 0);
}
=
$ gcc -O2 -m32 -S foo.c && fgrep -v .cfi foo.s
.file "foo.c"
.text
.p2align 4
.globl f
.type f, @function
f:
.LFB0:
movl4(%esp), %ecx
movl$-1840700269, %edx
movl%ecx, %eax
imull %edx
movl%ecx, %eax
sarl$31, %eax
addl%ecx, %edx
sarl$2, %edx
subl%eax, %edx
leal0(,%edx,8), %eax
subl%edx, %eax
movl%ecx, %edx
subl%eax, %edx
cmpl$3, %edx
je .L4
ret
.p2align 4,,10
.p2align 3
.L4:
shrl$31, %ecx
movl%ecx, xx
ret
.LFE0:
.size f, .-f
.comm xx,4,4
.ident "GCC: (GNU) 9.1.0"
.section.note.GNU-stack,"",@progbits
The two instructions after .L4 could be optimized to
movl$0, xx
by observing that for i < 0, i % 7 is <= 0 and therefore never == 3.
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 Bruno Haible changed: What|Removed |Added Target||x86_64-pc-linux-gnu Host||x86_64-pc-linux-gnu Known to fail||9.1.0 Build||x86_64-pc-linux-gnu --- Comment #1 from Bruno Haible --- Related to bug 66552.
[Bug middle-end/21161] [6/7/8 Regression] "clobbered by longjmp" warning ignores the data flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161 --- Comment #15 from Bruno Haible --- > I think the following test case does show what Bruno was trying to prove. Yes, the test case from comment 14 much better reflects what this bug report is about, than the one from comment 13.
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #3 from Bruno Haible --- (In reply to Jakub Jelinek from comment #2) > You need to read the documentation, which would tell you you need to use > -fmain=HelloWorld option. It is true that -fmain=HelloWorld was missing in the reporter's command line. But if that had been the only problem, the error message would have been (.text+0x18): undefined reference to `main' not Exception in thread "main" java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain The error message "java.lang.NoClassDefFoundError: org.eclipse.jdt.internal.compiler.batch.GCCMain" means that the ecj1 program cannot find the org.eclipse.jdt.internal.compiler.batch.GCCMain class, which it expects to find in the jar file specified through the --with-ecj-jar option. So, the reporter's real problem was that he configured GCC with a --with-ecj-jar option without argument.
[Bug java/45433] Can't find GCCMain in org.eclipse.jdt.internal.compiler.batch.GCCMain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
--- Comment #4 from Bruno Haible ---
I am having the same error, even with option -C (which does not need a
-fmain=... option):
$ gcj -v -C HelloWorld.java
Using built-in specs.
COLLECT_GCC=/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/gcj
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.3/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/arch/x86-linux/gnu-inst-gcc/4.7.3 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32
--with-gmp=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-mpc=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-libelf=/arch/x86-linux/gnu-inst-gcc/4.7.3
--with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar
Thread model: posix
gcc version 4.7.3 (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-B'
'/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-gnu/4.7.3'
'-v' '-C'
'-fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../lib/gcc/../../share/java/libgcj-4.7.3.jar'
'-g1' '-fsyntax-only' '-femit-class-files' '-S' '-o' 'NONE' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/libexec/gcc/i686-pc-linux-gnu/4.7.3/ecj1
HelloWorld.java -g1
-fbootclasspath=./:/media/nas/pub/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/../lib/gcc/../../share/java/libgcj-4.7.3.jar
-g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccrzqP4M.zip
Exception in thread "main" java.lang.NoClassDefFoundError:
org.eclipse.jdt.internal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(MainThread.java:100)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.batch.GCCMain not found in
gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java)
at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:27)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
at gnu.java.lang.MainThread.run(MainThread.java)
The problem is that the file that I specified as --with-ecj-jar value when
configuring GCC no longer exists. The GCC installation has not copied the file
to the GCC installation directory! But the ecj1 program still references it.
I cannot find an option to tell ecj1 about the new file name of ecj-latest.jar.
So I ended up creating a symlink so that the old file name still works.
[Bug driver/81653] New: gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653 Bug ID: 81653 Summary: gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 41884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41884&action=edit Test case program, part 1 GCC, configured with --enable-default-pie on SPARC, miscompiles hand-written .s files that happen to access global variables. The cause is that it passes the option "-K PIC" to the assembler; the assembler then interprets the .s file differently (by putting different relocations into the .o file). The resulting executable does not work. Test case: Find attached main.c and getter.s. With a GCC not configured with --enable-default-pie: $ gcc -m32 main.c getter.s $ ./a.out $ echo $? 42 With a GCC configured with --enable-default-pie: $ gcc -m32 main.c getter.s $ ./a.out Segmentation fault $ gdb a.out (gdb) run Starting program: /home/haible/a.out Program received signal SIGSEGV, Segmentation fault. 0x76c8 in getter () (gdb) disassemble getter Dump of assembler code for function getter: 0x76c0 <+0>: sethi %hi(0), %g1 0x76c4 <+4>: or %g1, 0x10, %g1 ! 0x10 => 0x76c8 <+8>: ld [ %g1 ], %o0 0x76cc <+12>:retl 0x76d0 <+16>:nop End of assembler dump. (gdb) print $g1 $1 = 16 Details about this GCC version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper Target: sparc64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-2' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=sparc64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-sparc64 --with-arch-directory=sparc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-multiarch --enable-targets=all --with-cpu-32=ultrasparc --with-long-double-128 --enable-multilib --enable-checking=release --build=sparc64-linux-gnu --host=sparc64-linux-gnu --target=sparc64-linux-gnu Thread model: posix gcc version 6.4.0 20170724 (Debian 6.4.0-2) Analysis of the difference between that and this GCC: 1) The "as" invocation was as -v -s -Av9a -32 -relax -o /tmp/cci9hbn2.o getter.s and in this GCC version is as -v -s -K PIC -Av9a -32 -relax -o /tmp/ccYeBhLa.o getter.s 2) The relocations in the object file: That GCC: $ gcc -m32 -c getter.s -o getter.o $ objdump --disassemble --reloc getter.o getter.o: file format elf32-sparc Disassembly of section .text: : 0: 03 00 00 00 sethi %hi(0), %g1 0: R_SPARC_HI22 variable 4: 82 10 60 00 mov %g1, %g1 ! 0 4: R_SPARC_LO10 variable 8: d0 00 40 00 ld [ %g1 ], %o0 c: 81 c3 e0 08 retl 10: 01 00 00 00 nop This GCC: $ gcc -m32 -c getter.s -o getter.o $ objdump --disassemble --reloc getter.o getter.o: file format elf32-sparc Disassembly of section .text: : 0: 03 00 00 00 sethi %hi(0), %g1 0: R_SPARC_GOT22variable 4: 82 10 60 00 mov %g1, %g1 ! 0 4: R_SPARC_GOT10variable 8: d0 00 40 00 ld [ %g1 ], %o0 c: 81 c3 e0 08 retl 10: 01 00 00 00 nop As you can see, the assembler has inserted different relocations with "-K PIC" than without. 3) The instructions in the linked a.out file: That GCC: $ objdump --disassemble a.out 00010480 : 10480: 9d e3 bf a0 save %sp, -96, %sp 10484: 03 00 00 88 sethi %hi(0x22000), %g1 10488: 82 10 60 68 or %g1, 0x68, %g1 ! 22068 1048c: 84 10 20 2a mov 0x2a, %g2 10490: c4 20 40 00 st %g2, [ %g1 ] 10494: 40 00 00 06 call 104ac 10498: 01 00 00 00 nop 1049c: 82 10 00 08 mov %o0, %g1 104a0: b0 10 00 01 m
[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653 --- Comment #1 from Bruno Haible --- Created attachment 41885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41885&action=edit Test case program, part 2
[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653 Bruno Haible changed: What|Removed |Added Target||sparc64-linux-gnu --- Comment #2 from Bruno Haible --- Apparently, on SPARC, there are two ways of referring to global variables from within .s files. The non-PIC way is sethi %hi(variable), %g1 or %g1, %lo(variable), %g1 The PIC way is sethi %hi(_GLOBAL_OFFSET_TABLE_-8), %l7 add %l7, %lo(_GLOBAL_OFFSET_TABLE_-4), %l7 call__sparc_get_pc_thunk.l7 nop sethi %gdop_hix22(variable), %g1 xor %g1, %gdop_lox10(variable), %g1 ld [%l7 + %g1], %g1, %gdop(variable) The ugly thing is that * the non-PIC way, compiled by "gcc -fPIC", crashes, * the PIC way, compiled by "gcc" without -fPIC and without --enable-default-pie, crashes as well. So in order to write hand-written assembly that accesses global variables, one has to write a .S file (that gets preprocessed!) #ifdef __PIC__ sethi %hi(_GLOBAL_OFFSET_TABLE_-8), %l7 add %l7, %lo(_GLOBAL_OFFSET_TABLE_-4), %l7 call__sparc_get_pc_thunk.l7 nop sethi %gdop_hix22(variable), %g1 xor %g1, %gdop_lox10(variable), %g1 ld [%l7 + %g1], %g1, %gdop(variable) #else sethi %hi(variable), %g1 or %g1, %lo(variable), %g1 #endif Is this the only workaround to a silent change of behaviour of commands such as "gcc -c getter.s" ?
[Bug driver/81658] New: gcc configured with --enable-default-pie on SPARC produces buggy executable from working .o files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81658 Bug ID: 81658 Summary: gcc configured with --enable-default-pie on SPARC produces buggy executable from working .o files Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 41886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41886&action=edit tarball of object files GCC, configured with --enable-default-pie on SPARC, links object files that happen to access global variables in such a way that the resulting executable is broken: it crashes when attempting to access the global variable. Test case: Find attached a tarball with 4 object files. They were produced from https://haible.de/bruno/gnu/libffcall-2.0-20170731.tar.gz on a Linux/sparc machine with gcc 6.3.0 (that is NOT configured with --enable-default-pie). On that machine: $ gcc -m32 vacall-libapi.o vacall.o vacall-structcpy.o minitests.o $ ./a.out Unpack the same tarball and link the same object files on a machine with a GCC configured with --enable-default-pie: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper Target: sparc64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-2' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=sparc64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-sparc64 --with-arch-directory=sparc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc=auto --enable-multiarch --enable-targets=all --with-cpu-32=ultrasparc --with-long-double-128 --enable-multilib --enable-checking=release --build=sparc64-linux-gnu --host=sparc64-linux-gnu --target=sparc64-linux-gnu Thread model: posix gcc version 6.4.0 20170724 (Debian 6.4.0-2) $ gcc -m32 vacall-libapi.o vacall.o vacall-structcpy.o minitests.o $ ./a.out void f(void): Segmentation fault Using "gcc -v", I see that the link command is essentially /usr/lib/gcc/sparc64-linux-gnu/6/collect2 --sysroot=/ --build-id --eh-frame-hdr -m elf32_sparc -dynamic-linker /lib/ld-linux.so.2 -relax -pie -o a.out /usr/lib32/Scrt1.o /usr/lib32/crti.o /usr/lib/gcc/sparc64-linux-gnu/6/32/crtbeginS.o -L/usr/lib/gcc/sparc64-linux-gnu/6/32 -L/usr/lib32 -L/lib32 -L/usr/lib32 -L/usr/lib/gcc/sparc64-linux-gnu/6 -L/usr/lib vacall-libapi.o vacall.o vacall-structcpy.o minitests.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/sparc64-linux-gnu/6/32/crtend.o /usr/lib32/crtn.o If I execute it manually, the resulting a.out file crashes: $ ./a.out void f(void): Segmentation fault But if I execute it manually without the "-pie" option, the resulting a.out file works. $ ./a.out The difference between the two is at the beginning of function vacall_receiver. 0x5b48 :save %sp, -144, %sp 0x5b4c : sethi %hi(0), %o0 0x5b50 : sethi %hi(0x1c400), %l7 0x5b54 : call 0x5b40 0x5b58 : add %l7, 0xac, %l7 ! 0x1c4ac 0x5b5c : or %o0, 0x180, %o0 0x5b60 : ld [ %l7 + %o0 ], %o1 At the instruction ld [ %l7 + %o0 ], %o1 the values are: In the case that works: %l7 + %o0 = 0x32180 => loads the word 0x32b58 into %o1 &vacall_function = 0x32b58 In the case that does not work: %l7 + %o0 = 0x70022180 => loads the word 0x700456b0 into %o1 &vacall_function = 0x70022b58 The value in memory is wrong! 0x700456b0 is too high by 0x22b58 (strange coincidence of numbers - looks like a relocation has been applied twice instead of just once) When I set a watchpoint at that location, I see that it's modified only once: (gdb) watch *(void**)0x70022180 Hardware watchpoint 1: *(void**)0x70022180 (gdb) run Starting program: /home/haible/vacall/a.out Watchpoint 1: *(void**)0x70022180 Old value = (void *) 0x22b58 New value = (void *) 0x700456b0 elf_dynamic_do_Rela (skip_ifunc=, lazy=0, nrelative=, relsize=, reladdr=, map=0xf7ffaa10) at do-rel.h:112 112 do-rel.h: No such file or directory. I'm reporting this as a bug in GCC, because it&
[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653 --- Comment #6 from Bruno Haible --- > passing -fno-pie seems to be the agreed upon way out here. My assembly code is located in a library (think at libffcall, libffi, gmp, ...). Therefore I don't control the final linker options. So, the only available option the '#ifdef __PIC__' solution from comment 2.
[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653 --- Comment #7 from Bruno Haible --- And what do you think about the fact that it produces crashing code without any warning? Is there a chance that 'as' could emit a warning when it produces R_SPARC_GOT22/R_SPARC_GOT10 relocations instead of the intended R_SPARC_HI22/R_SPARC_LO10 relocations?
[Bug c++/80495] New: attribute [[noreturn]] is accepted in function pointer declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80495
Bug ID: 80495
Summary: attribute [[noreturn]] is accepted in function pointer
declarations
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
g++ does not flag an error for use of attribute [[noreturn]] on a function
pointer declaration.
C++11 [dcl.attr.noreturn] says "The attribute may be applied to a declarator-id
in a function declaration."
$ cat noreturn1.cc
void func1 (void) { for (;;); }
[[ noreturn ]] void func2 (void) { for (;;); }
__attribute__ ((__noreturn__)) void func3 (void) { for (;;); }
void (*fptr11) (void) = func1;
void (*fptr12) (void) = func2;
void (*fptr13) (void) = func3;
[[ noreturn ]] void (*fptr21) (void) = func1; /* expected: error */
[[ noreturn ]] void (*fptr22) (void) = func2; /* expected: error */
[[ noreturn ]] void (*fptr23) (void) = func3; /* expected: error */
$ g++ --version | head -n 1
g++ (GCC) 6.3.0
$ g++ -std=c++11 -pedantic -c noreturn1.cc
[Bug c++/80496] New: missing diagnostic regarding noreturn mismatch in function pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80496
Bug ID: 80496
Summary: missing diagnostic regarding noreturn mismatch in
function pointer initialization
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
A mismatch regarding __attribute__((__noreturn__)) in a function pointer
initialization generates a warning in C mode, but not in C++ mode.
$ cat noreturn2.cc
void func1 (void) { for (;;); }
[[ noreturn ]] void func2 (void) { for (;;); }
__attribute__ ((__noreturn__)) void func3 (void) { for (;;); }
void (*fptr11) (void) = func1;
void (*fptr12) (void) = func2;
void (*fptr13) (void) = func3;
__attribute__ ((__noreturn__)) void (*fptr31) (void) = func1; /* expected:
warning */
__attribute__ ((__noreturn__)) void (*fptr32) (void) = func2;
__attribute__ ((__noreturn__)) void (*fptr33) (void) = func3;
$ g++ --version | head -n 1
g++ (GCC) 6.3.0
$ g++ -std=c++11 -Wall -c noreturn2.cc
I would have expected a warning in the declaration of fptr31.
[Bug bootstrap/78984] New: [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 Bug ID: 78984 Summary: [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- The following bootstrap procedure, to build x86 (32-bit) executables of GCC on a 64-bit (x86_64-linux-gnu) machine, succeeded with version 4.8.5 and earlier, but fails with versions 4.9.0, 4.9.4, 5.1.0, 6.1.0: version=4.9.0 export CC="gcc -m32" CXX="g++ -m32" LDFLAGS="-m32" ../gcc-$version/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu-inst-gcc/$version --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32 --with-gmp=/arch/x86-linux/gnu-inst-gcc/$version --with-mpfr=/arch/x86-linux/gnu-inst-gcc/$version --with-mpc=/arch/x86-linux/gnu-inst-gcc/$version --with-libelf=/arch/x86-linux/gnu-inst-gcc/$version --with-isl=/arch/x86-linux/gnu-inst-gcc/$version --with-cloog=/arch/x86-linux/gnu-inst-gcc/$version --with-ecj-jar=/downloads/sourceware.org-ecj/ecj-latest.jar make It fails like this: /home/bruno/build/gcc-4.9.0-build/./gcc/xgcc -B/home/bruno/build/gcc-4.9.0-build/./gcc/ -B/arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/bin/ -B/arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/lib/ -isystem /arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/include -isystem /arch/x86-linux/gnu-inst-gcc/4.9.0/i686-pc-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so /usr/bin/ld: /home/bruno/build/gcc-4.9.0-build/./gcc/liblto_plugin.so: error in plugin cleanup (ignored) /usr/bin/ld: /home/bruno/build/gcc-4.9.0-build/./gcc/liblto_plugin.so: error loading plugin collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.so] error 1 make[3]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] error 2 make[2]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build' make[1]: *** [stage1-bubble] error 2 make[1]: Verlasse Verzeichnis '/home/bruno/build/gcc-4.9.0-build' make: *** [all] error 2 $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: i686-pc-linux-gnu Configured with: ../gcc-4.9.0/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu-inst-gcc/4.9.0 --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32 --with-gmp=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.9.0 --with-mpc=/arch/x86-linux/gnu-in
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #1 from bruno at clisp dot org --- The error is similar to the one in bug #63507. The differences are: - I'm not using the '--with-build-config=bootstrap-asan' option. - It fails building the "," directory of libgcc, not the "32" directory of libgcc.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #5 from bruno at clisp dot org --- Thanks Jakub. The ld --version and "-m elf_i386 -L /usr/lib/" trick solves it! (I was already using the "as --32" trick.) Another way is to define a simpler ld32 script == ld32 = #!/bin/sh exec ld -m elf_i386 -L /usr/lib/ "$@" = specify this script through the --with-ld option, AND use the --disable-lto option.
[Bug bootstrap/78984] [4.9 regression] bootstrap fails while creating 32-bit libgcc on 64-bit x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984 --- Comment #7 from bruno at clisp dot org --- (In reply to Andreas Schwab from comment #6) > Note that if you use --with-ld, -B no longer works. Thanks Andreas. In fact, I've never used the -B option (except during gcc bootstrap). Some 20 years ago I used the options -V and -b, but over time I found it more reliable to not share anything between installed GCC binaries of different versions or targets, i.e. use a different --prefix each time.
[Bug other/32415] libgcc_s not found in library search path with --enable-version-specific-runtime-libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415 bruno at clisp dot org changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #14 from bruno at clisp dot org --- I'm seeing this also, with gcc 4.9.0. Configured on x86_64 Linux with ../gcc-4.9.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --prefix=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86_64-linux-gnu/gnu/bin/as --with-gmp=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-mpfr=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-mpc=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-libelf=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-isl=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-cloog=/arch/x86_64-linux-gnu/gnu-inst-gcc/4.9.0 --with-ecj-jar=/downloads/sourceware.org-ecj/ecj-latest.jar The build with --enable-version-specific-runtime-libs fails to find libgcc_s when linking programs. The build without this option works fine. Analyzing the difference: * Location of installed libraries other than libgcc_s: Most 32-bit libraries get installed in - PREFIX/lib32 for the working build, - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32 for the build with --enable-version-specific-runtime-libs. Most 64-bit libraries get installed in - PREFIX/lib64 for the working build, - PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0 for the build with --enable-version-specific-runtime-libs. * Location of installed libgcc_s (.so symlink and .so.1): 32-bit libgcc_s gets installed in - PREFIX/lib32 for the working build, - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32 for the build with --enable-version-specific-runtime-libs. 64-bit libgcc_s gets installed in - PREFIX/lib64 for the working build, - PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64 for the build with --enable-version-specific-runtime-libs. * The library path (set of -L options) that collect2 passes to ld, however, is the same in both cases (without and with --enable-version-specific-runtime-libs). Namely: When creating 32-bit binaries: PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32 PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib32 /lib/i386-linux-gnu /lib/../lib32 /usr/lib/i386-linux-gnu /usr/lib/../lib32 PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0 PREFIX/lib/gcc PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../.. /lib/i386-linux-gnu /usr/lib/i386-linux-gnu When creating 64-bit binaries: PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0 PREFIX/lib/gcc PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../lib64 /lib/x86_64-linux-gnu /lib/../lib64 /usr/lib/x86_64-linux-gnu PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../.. This library path contains the location of all installed libraries except libgcc_s. Conclusion: So it looks really like a bug in the installation rules for libgcc_s. - The 32-bit libgcc_s ought to be installed in PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0/32, not PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib32. - The 64-bit libgcc_s ought to be installed in PREFIX/lib/gcc/x86_64-pc-linux-gnu/4.9.0, not PREFIX/lib/gcc/x86_64-pc-linux-gnu/lib64.
[Bug c/79479] -Woverflow false alarm in unreachable expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #3 from Bruno Haible ---
(In reply to Marek Polacek from comment #2)
> int
> fn1 (long x)
> {
> if (0)
> return __INT_MAX__ + 1;
>
> if (x || 0)
> return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
>
> if (1 || 0)
> return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
The rest of fn1 is dead code (at least a good dataflow analysis would detect
it). How about splitting fn1 into several functions?
int
fn11 (long x)
{
if (0)
return __INT_MAX__ + 1;
return 0;
}
int
fn12 (long x)
{
if (x || 0)
return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
return 0;
}
int
fn13 (long x)
{
if (1 || 0)
return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
return 0;
}
int
fn14 (long x)
{
if (0 && 0)
return __INT_MAX__ + 1;
return 0;
}
int
fn15 (long x)
{
if (0)
return __INT_MAX__ + 1;
else
return 0;
}
int
fn16 (long x)
{
if (0)
return 0;
else
return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
}
etc.
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300 --- Comment #10 from Bruno Haible --- I confirm. I cannot reproduce the bug (neither with -O nor -O2) in GCC versions 4.2.3 4.2.4 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 4.4.0 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.5.0 4.5.1 4.5.2 4.5.3 4.5.4 4.6.0 4.6.1 4.6.2 4.6.3 4.6.4 4.7.0 4.7.1 4.7.2 4.7.3 4.8.0 4.8.1 4.8.5 4.9.0 4.9.4 5.1.0
[Bug c++/43116] New: ICE when using attributes in a function alias declaration
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.4.2/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/arch/x86-linux/gnu-inst-gcc/4.4.2 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32
--with-gmp=/arch/x86-linux/gnu-inst-gcc/4.4.2
--with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.4.2
--with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar
Thread model: posix
gcc version 4.4.2 (GCC)
$ g++ -S bug.cc
bug.cc:5: internal compiler error: in start_decl, at cp/decl.c:4231
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Here is the contents of bug.cc (also attached):
= bug.cc =
extern "C" int rpl_open (const char *filename, int flags, ...) __attribute__
((__nonnull__ (1)));
namespace gnulib
{
int (*const open) (const char *filename, int flags, ...) __attribute__
((__nonnull__ (1))) = rpl_open;
}
==
--
Summary: ICE when using attributes in a function alias
declaration
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug c++/43116] ICE when using attributes in a function alias declaration
--- Comment #1 from bruno at clisp dot org 2010-02-18 23:21 --- Created an attachment (id=19918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19918&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
[Bug c++/43454] New: warning with -Wall despite __attribute__ ((__unused__))
The attached program gives a warning about 'check_moo' being unused,
despite the variable being declared with __attribute__ ((__unused__)).
= bug.cc ==
extern "C" int c_foo (void);
namespace gnulib { static int (*foo) (void) = ::c_foo; }
static int (* __attribute__ ((__unused__)) check_foo) (void) = gnulib::foo;
extern "C" int c_moo (void);
namespace gnulib { static int (*const moo) (void) = ::c_moo; }
static int (* __attribute__ ((__unused__)) check_moo) (void) = gnulib::moo;
===
$ g++ -Wall -S bug.cc
bug.cc:7: warning: 'check_moo' defined but not used
The warning is present in all g++ version of 3.x and 4.x that I tested,
except in g++ 4.0.2. I.e. "Known to work" = 4.0.2, "Known to fail" =
4.0.4, 4.1.2, 4.2.4, 4.3.4, 4.4.3.
The only difference between check_foo (which does not elicit a warning)
and check_moo is the 'const'ness of the initializer.
--
Summary: warning with -Wall despite __attribute__ ((__unused__))
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454
[Bug c++/43454] warning with -Wall despite __attribute__ ((__unused__))
--- Comment #1 from bruno at clisp dot org 2010-03-20 13:39 --- Created an attachment (id=20145) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20145&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454
[Bug c++/43881] New: warning attached to a function is emitted even though the function is not being called
The gcc documentation, section "Declaring Attributes of Functions", states
about the __attribute__ ((__warning__ ("..."))) of a function:
"If this attribute is used on a function declaration and a call to
such a function is not eliminated through dead code elimination or
other optimizations, a warning which will include MESSAGE will be
diagnosed."
Here is a case where the warning is diagnosed although the program contains
no direct call to the function:
=== main.cc ===
extern "C" int close(int);
static int (*safe_close) (int fd) = close;
extern __typeof__ (close) close __attribute__ ((__warning__ ("The symbol close
refers to the system function. Use safe_close instead.")));
int fd;
int main()
{
safe_close(fd);
}
===
$ g++ -S -O main.cc
main.cc: In function 'int main()':
main.cc:7:17: warning: call to 'close' declared with attribute warning: The
symbol close refers to the system function. Use safe_close instead.
The warning is not justified, because its only use is as initializer
of the variable 'safe_close', and at that moment, the warning is not yet
attached to it.
Notes:
- The warning occurs only with optimization, not with -O0.
- The warning occurs only if the variable 'safe_close' is 'static', not
when it is changed to a global variable.
- The behaviour of GCC 4.3.4 and GCC 4.4.3 is the same as the one of GCC
4.5.0.
--
Summary: warning attached to a function is emitted even though
the function is not being called
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug c++/43881] warning attached to a function is emitted even though the function is not being called
--- Comment #1 from bruno at clisp dot org 2010-04-24 22:49 --- Created an attachment (id=20479) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20479&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug c++/43881] warning attached to a function is emitted even though the function is not being called
--- Comment #3 from bruno at clisp dot org 2010-04-24 23:54 --- When the line static int (*safe_close) (int fd) = close; is changed to static int (*safe_close) (int fd) = ((void)0, close); the warning also disappears, but then the generate code is suboptimal: the variable safe_close is not eliminated from the 'data' section. Therefore I cannot use this as a workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug c++/43881] warning attached to a function is emitted even though the function is not being called
--- Comment #4 from bruno at clisp dot org 2010-04-24 23:58 --- (In reply to comment #2) > It is called directly because safe_close's value is replaced in the > indirect call. Since safe_close is static and not changed in the code > at all, it is marked as read only and the initialized value can be > used directly. This is an explanation why gcc behaves like this, but not a justification. 1) GCC should try to make warnings independent of optimization settings. 2) GCC warns about a line of code that calls 'safe_close', which it should not warn about. Only calls of 'close' should be warned about, and there are no such calls in the source program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug rtl-optimization/6585] Redundant store/load instruction pairs on ix86
--- Additional Comments From bruno at clisp dot org 2005-06-27 11:50 --- Indeed, the result is much better now, nearly optimal. As you say, the only further optimization possible is that a better register allocation could get rid of the movl%edx, %esi and movl%ebx, %edi instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585
[Bug driver/22544] New: gcc ignores input file given on the command line
gcc-3.4 introduced a syntax for compilation with inter-module analysis:
$ gcc -c foo1.c foo2.c -o foo.o
gcc-4.0 performs the same with the command-line option -combine:
$ gcc -combine -c foo1.c foo2.c -o foo.o
But Makefiles that have already switched to using the gcc-3.4 invocation
convention are trapped: gcc-4.0, when invoked without -combine, ignores
all input files except the last one.
$ cat foo1.c
int foo1 (int x) { return 17 * x; }
$ cat foo2.c
int foo2 (int x) { return 42 * x; }
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure
--prefix=/home/haible/gnu/arch/linuxgcc40
--enable-shared --enable-threads --enable-__cxa_atexit
--enable-languages=c,c++,java,objc --enable-nls
Thread model: posix
gcc version 4.0.0
$ gcc -c foo1.c foo2.c -o foo.o && nm foo.o
T foo2
Expected result: An error, as with gcc-3.3:
$ gcc -c foo1.c foo2.c -o foo.o && nm foo.o
gcc: cannot specify -o with -c or -S and multiple compilations
--
Summary: gcc ignores input file given on the command line
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22544
[Bug c/23058] New: visibility attribute does not work for aliased symbols
When a function or variable has its assembler name given through an
__asm__, the __attribute__((__visibility__("default"))) present on the
same declaration is ignored.
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /freebsd/gnu/linuxarchive/gcc-4.0.1/configure
--prefix=/packages/gnu-inst-gcc/4.0.1 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/packages/gnu/bin/as
--with-ld=/packages/gnu/bin/ld
Thread model: posix
gcc version 4.0.1
$ cat bug.c
extern
int hidden_var
__asm__("my_hidden_var");
extern __attribute__((__visibility__("default")))
int exported_var
__asm__("my_exported_var");
extern
int hidden_func (void)
__asm__("my_hidden_func");
extern __attribute__((__visibility__("default")))
int exported_func (void)
__asm__("my_exported_func");
int my_hidden_var = 0;
int my_exported_var = 0;
int my_hidden_func (void) { return 0; }
int my_exported_func (void) { return 0; }
$ gcc -c -fvisibility=hidden bug.c
$ readelf --syms bug.o
Symbol table '.symtab' contains 11 entries:
Num:Value Size TypeBind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 FILELOCAL DEFAULT ABS bug.c
2: 0 SECTION LOCAL DEFAULT1
3: 0 SECTION LOCAL DEFAULT2
4: 0 SECTION LOCAL DEFAULT3
5: 0 SECTION LOCAL DEFAULT5
6: 0 SECTION LOCAL DEFAULT4
7: 4 OBJECT GLOBAL HIDDEN3 my_hidden_var
8: 0004 4 OBJECT GLOBAL HIDDEN3 my_exported_var
9: 10 FUNCGLOBAL HIDDEN1 my_hidden_func
10: 000a10 FUNCGLOBAL HIDDEN1 my_exported_func
$ gcc -shared -o bug.so bug.o && nm bug.so | grep my_
0476 t my_exported_func
15e4 b my_exported_var
046c t my_hidden_func
15e0 b my_hidden_var
As you can see, the symbols my_exported_func, my_exported_var are not
exported from bug.so, because their visibility was "HIDDEN" in bug.o.
Known workaround: If I write "int exported_var = 0;" instead of
"int my_exported_var = 0;", and "int exported_func (void) { return 0; }"
instead of ""int my_exported_func (void) { return 0; }", the problem
disappears.
--
Summary: visibility attribute does not work for aliased symbols
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23058
[Bug c/49283] New: pointless warning with -Wstrict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49283 Summary: pointless warning with -Wstrict-overflow Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: br...@clisp.org Created attachment 24429 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24429 test case When -Wstrict-overflow is used, gcc reports a warning "assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2" on a location where 1) gcc ought to be able to infer that there is no wraparound. 2) gcc emits this warning only when a certain other function is present in the same compilation unit. How to reproduce: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/data/arch/x86-linux/gnu-inst-gcc/4.6.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6.0/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/arch/x86-linux/gnu-inst-gcc/4.6.0 --enable-shared --enable-version-specific-runtime-libs --enable-nls --enable-threads=posix --enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32 --with-gmp=/arch/x86-linux/gnu-inst-gcc/4.6.0 --with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.6.0 --with-mpc=/arch/x86-linux/gnu-inst-gcc/4.6.0 --with-libelf=/arch/x86-linux/gnu-inst-gcc/4.6.0 --with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar Thread model: posix gcc version 4.6.0 (GCC) $ gcc -Wstrict-overflow -O2 -S foo.c foo.c: In function 'yylex': foo.c:2026:18: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c: In function 'yyparse': foo.c:1442:6: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:1442:6: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:2026:18: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:1407:1: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:2026:18: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:2026:18: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:1442:6: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] foo.c:2026:18: warning: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Wstrict-overflow] 1) Line 2026 contains the expression (p < buff + sizeof buff - 1) but buff is an array of constant size, sizeof buff is 20. gcc ought to be able to infer that (buff + 19) does not wrap around. 2) If the function yyparse is removed from foo.c, the warning disappears. So apparently the warning is generated when inlining yylex into yyparse. It makes no sense to have no warning in yylex by itself but have a warning when it gets inlined.
[Bug middle-end/49283] pointless warning with -Wstrict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49283 --- Comment #3 from bruno at clisp dot org 2011-06-06 20:33:07 UTC --- (In reply to comment #2) > [GCC] optimizes [...] > moving the + 3 from the LHS and combining it with the constant offset > on the RHS. That is only valid if p + 3 does not get outside of buff > which GCC doesn't see Rather than performing an invalid optimization (that is, produce wrong-code) with a warning, I would prefer if GCC would simply only do valid optimizations. Code ought to be written to be maintainable. If code has to be changed, so as to avoid invalid optimizations from a compiler, then 1. it becomes a lot of work to change the code so that all compilers on all supported platforms are pleased, 2. the maintainability of the code suffers. I did not enable particular, dangerous optimization options. Just "-O2", which is the default setting in every package that uses autoconf.
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
--- Comment #1 from bruno at clisp dot org 2007-11-30 10:46 --- Created an attachment (id=14671) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14671&action=view) source code exhibiting the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug middle-end/34300] New: gcc 4.2.2 miscompiles code that uses global register variables
If assuming that newinsert() does not change the STACK, the value cached
in %edi should be the value of STACK at the beginning of the loop
(since there is one increment of STACK before the newinsert call and
one decrement of STACK after it.
Here's an annotated listing of the rehash_symtab function produced:
== gcc -O -S bug.c
...
rehash_symtab:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
subl$16, %esp
movl8(%ebp), %eax ; %eax := symtab
movl%eax, (%ebx); STACK[0] = symtab
leal4(%ebx), %ecx ; STACK += 1
subl$2, %eax
movl4(%eax), %edx
andl$536870911, %edx
movl%edx, %edi
shrl$5, %edi; %edi := oldsize
movl8(%eax), %eax ; Get
((Svector)((oint)(symtab)-2))->data[1]
movl%eax, (%ecx); STACK[0] = ...
addl$4, %ecx; STACK += 1
movl$symbol_tab_data+2, (%ecx) ; STACK[0] =
(object)((UBYTE*)(&symbol_tab_data.S_nil)+2)
leal4(%ecx), %esi ; STACK += 1
movl%esi, %ebx
imull $205, %edi, %edx; prod = oldsize * 205UL
movl$16777215, %eax
testl %edx, %edx
js .L10
movl%edx, %eax
shrl$7, %eax
.L10: ; newsize in %eax
subl$1, %eax
orl $1, %eax; newsize = (newsize - 1) | 1
movl%eax, -12(%ebp)
movl%eax, (%esp)
callallocate_vector ; newtable =
allocate_vector(newsize)
movl%eax, (%esi); STACK[0] = newtable
addl$4, %ebx; STACK += 1
movl%edi, %esi
movl$0, -16(%ebp) ; offset = 0
.L11:
movl-12(%ebx), %eax
movl-16(%ebp), %ecx
movl2(%ecx,%eax), %edx ; %edx := oldentry
movl%edx, %eax
andl$3, %eax
cmpl$2, %eax
jne .L12; (((oint)(oldentry) & 3) == 2)
leal-4(%ebx), %edi ; HERE! %edi := STACK - 1
.L19: ; BEGINNING OF INNER LOOP
movl-2(%edx), %eax
movl%eax, (%ebx); STACK[0] =
((Cons)((oint)(oldentry)-2))->cdr
leal4(%ebx), %eax
movl%eax, %ebx ; STACK += 1
movl-12(%eax), %eax
movl%eax, -2(%edx) ;
((Cons)((oint)(oldentry)-2))->cdr = STACK[-3]
movl%edx, -12(%ebx) ; STACK[-3] = oldentry
movl-12(%ebp), %eax ; newsize
movl%eax, 4(%esp)
movl2(%edx), %eax
movl%eax, (%esp)
callnewinsert ;
newinsert(((Cons)((oint)(oldentry)-2))->car,newsize)
movl%edi, %ebx ; HERE! BUG! WRONG VALUE FOR
STACK!
movl(%edi), %edx; oldentry = STACK[0]
movl%edx, %eax
andl$3, %eax
cmpl$2, %eax
je .L19; (((oint)(oldentry) & 3) == 2)
.L12: ; END OF INNER LOOP
subl$1, %esi
je .L14; while(!(--count==0))
addl$4, -16(%ebp) ; offset++
jmp .L11
.L14:
cmpl$stackspace+216, %ebx ; (STACK != &stackspace[54])
.p2align 4,,2
je .L16
callabort
.L16:
movlstackspace+212, %esi
movl$stackspace+200, %ebx
movlstackspace+200, %eax
leal-2(%eax), %ecx
movl-12(%ebp), %edx
sall$5, %edx
subl$1073741824, %edx ; %edx := size
movl%edx, 4(%ecx)
movl%esi, 8(%ecx)
addl$16, %esp
popl%esi
popl%edi
popl%ebp
ret
...
--
Summary: gcc 4.2.2 miscompiles code that uses global register
variables
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
[Bug c/21159] New: "no effect" warning despite cast to void*
The gcc-4.0 manual says * An expression-statement or the left-hand side of a comma expression contains no side effects. To suppress the warning, cast the unused expression to void. For example, an expression such as `x[i,j]' will cause a warning, but `x[(void)i,j]' will not. This worked for earlier releases of gcc, but in gcc-4.0 the cast to void doesn't avoid the warning. $ gcc -v Using built-in specs. Target: powerpc-apple-darwin7.8.0 Configured with: /Users/bruno/data/work/gcc-4.0.0-20050410/configure --prefix=/Volumes/UserData/experimental-macos --enable-shared --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: posix gcc version 4.0.0 20050410 (prerelease) $ gcc -W -c foo.c foo.c: In function 'foo': foo.c:4: warning: left-hand operand of comma expression has no effect $ gcc -W -c bug.c bug.c: In function 'copy_string': bug.c:169: warning: left-hand operand of comma expression has no effect -- Summary: "no effect" warning despite cast to void* Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruno at clisp dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.8.0 GCC host triplet: powerpc-apple-darwin7.8.0 GCC target triplet: powerpc-apple-darwin7.8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug c/21159] "no effect" warning despite cast to void*
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:01 --- Created an attachment (id=8706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8706&action=view) source file foo.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug c/21159] "no effect" warning despite cast to void*
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:01 --- Created an attachment (id=8707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8707&action=view) source file bug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
[Bug c/21160] New: how to force a variable into the stack?
When a function contains a call to longjmp(), some variables give the
warning
variable 'ptr' might be clobbered by 'longjmp' or 'vfork'
How to avoid this warning? In earlier versions of gcc, it was possible to
write
(void)&ptr;
in order to force ptr on the stack, where it would be unaffected by strange
behaviour of longjmp(). This doesn't work any more with gcc-4.0.
$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.8.0
Configured with: /Users/bruno/data/work/gcc-4.0.0-20050410/configure
--prefix=/Volumes/UserData/experimental-macos --enable-shared
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20050410 (prerelease)
$ gcc -W -O -c bug.c
bug.c: In function 'lisp_completion':
bug.c:261: warning: variable 'array' might be clobbered by 'longjmp' or 'vfork'
bug.c:270: warning: variable 'ptr' might be clobbered by 'longjmp' or 'vfork'
bug.c:291: warning: variable 'ptr1' might be clobbered by 'longjmp' or 'vfork'
Expected:
$ gcc -W -O -c bug.c
bug.c: In function 'lisp_completion':
bug.c:291: warning: variable 'ptr1' might be clobbered by 'longjmp' or 'vfork'
--
Summary: how to force a variable into the stack?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
[Bug c/21160] how to force a variable into the stack?
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:04 --- Created an attachment (id=8708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8708&action=view) source file bug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
[Bug c/21161] New: "clobbered by longjmp" warning ignores the data flow
The warning
argument 'obj' might be clobbered by 'longjmp' or 'vfork'
does not take into account the facts that
1) When longjmp() is called, setjmp() returns a non-null value,
2) In this case, when setjmp() returns a non-null value, 'obj' is
reset before being used.
$ gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.8.0
Configured with: /Users/bruno/data/work/gcc-4.0.0-20050410/configure
--prefix=/Volumes/UserData/experimental-macos --enable-shared
--enable-version-specific-runtime-libs --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0 20050410 (prerelease)
$ gcc -W -O -c bug.c
bug.c: In function 'update_instance':
bug.c:220: warning: argument 'obj' might be clobbered by 'longjmp' or 'vfork'
Expected: no warning.
--
Summary: "clobbered by longjmp" warning ignores the data flow
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
[Bug c/21161] "clobbered by longjmp" warning ignores the data flow
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:08 --- Created an attachment (id=8709) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8709&action=view) source file bug.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
[Bug c/21160] how to force a variable into the stack?
--- Additional Comments From bruno at clisp dot org 2005-04-22 14:14 --- I don't understand your resolution. How can I guarantee that gcc will not put 'ptr' and 'array' into registers where, on SPARC, longjmp() will clobber them? The semantics of 'volatile' are quite different than 'non register'. It has negative effect on performance. GCC should add a 'nonregister' qualifier or attribute that would allow to force variables into the stack without making their access slower than other stack allocated variables. The GCC 4.0 documentation says "These warnings occur only for variables that are candidates for register allocation. Therefore, they do not occur for a variable that is declared `volatile', or whose address is taken, or whose size is other than 1, 2, 4 or 8 bytes." I have taken the address of 'ptr' and despite that, it was not excluded from the candidates for register allocation - or the warning occurred despite of the variable being stack allocated. In either case, it's a GCC bug. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
[Bug c/21160] [4.0/4.1 Regression] documentation for -Wuninitialized out of date
--- Additional Comments From bruno at clisp dot org 2005-04-22 17:10 --- Thanks Joseph for the hint to ISO C 7.13.2.1.(3). Indeed, in the name of portability, I'll have to use 'volatile'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
[Bug c/19881] strange warning about alloca
--- Additional Comments From bruno at clisp dot org 2005-02-10 21:43 --- The warning is not correct because 1) The code snippet uses alloca() and variable-size arrays for their respective purpose: alloca() for storage that persists until the end of the function, and variable-size arrays for storage that persists until the end of the block. 2) In the above sample, all 2 alloca() blocks and 2 variable-size arrays terminate their lifetime at the same instruction. There are no instructions after the bar(...) function call return; therefore a warning about a possible accidental use of the type_temp memory after this point is pointless: the compiler could determine that there are no instructions any more. We are asking for an easy way to turn off this warning, so that we can look at other, useful, warnings. This is not duplicate of PR 14236, but rather a complaint about the implementation of the fix of PR 14236. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19881
[Bug c/19881] strange warning about alloca
--- Additional Comments From bruno at clisp dot org 2005-02-11 13:13
---
> the warning is not the FSF's gcc, you two should have filed it with Redhat
> instead.
You're right: Current gcc CVS ("gcc version 4.0.0 20050211 (experimental)")
doesn't
show the warning. So it appears to be a RedHat-only problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19881
[Bug rtl-optimization/6585] Redundant store/load instruction pairs on ix86
--- Additional Comments From bruno at clisp dot org 2004-10-11 11:55 --- This result is even better: shorter than the previous ones, and there are no useless moves between registers any more. However, there are more useless moves from register to stack slot and back from stack slot to register. They could be eliminated. Commented listing: mul: subl$20, %esp movl32(%esp), %ecx b0 movl24(%esp), %eax a0 movl%ebx, 8(%esp) ; save %ebx movl36(%esp), %ebx b1 movl%edi, 12(%esp) ; save %edi movl24(%esp), %edi a0 movl%ebp, 16(%esp) ; save %ebp mull%ecx%edx:%eax := a0*b0 imull 28(%esp), %ecx a1*b0 imull %ebx, %edi a0*b1 movl8(%esp), %ebx ; restore %ebx movl%edx, %ebp hi movl%eax, (%esp)USELESS! addl%edi, %ebp hi+a0*b1 movl(%esp), %eaxUSELESS! leal(%ebp,%ecx), %ecx hi+a0*b1+a1*b0 COULD GO INTO %edx DIRECTLY movl12(%esp), %edi ; restore %edi movl%ecx, 4(%esp) USELESS! movl16(%esp), %ebp ; restore %ebp movl4(%esp), %edx USELESS! addl$20, %esp ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6585
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
--- Comment #1 from bruno at clisp dot org 2006-11-07 14:36 --- It's still reproducible with gcc-4.2-20061031: $ export OMP_NUM_THREADS=2 $ gdb a.out GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /dev/shm/a.out [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4983)] [New Thread 32769 (LWP 4984)] [New Thread 16386 (LWP 4985)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 4985)] gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/iter.c:189 189 start = ws->next; (gdb) where #0 gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/iter.c:189 #1 0x4001ca78 in gomp_loop_dynamic_next (istart=0xbf7ffa94, iend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/loop.c:248 #2 0x080486ed in main.omp_fn.0 () #3 0x4001de5d in gomp_thread_start (xdata=0xbfffe580) at ../../../gcc-4.2-20061031/libgomp/team.c:108 #4 0x4003bfe6 in pthread_start_thread (arg=0xbf7ffbe0) at manager.c:310 #5 0x4003c07f in pthread_start_thread_event (arg=0xbf7ffbe0) at manager.c:334 #6 0x4014e0aa in clone () from /lib/libc.so.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug libgomp/28468] OpenMP-parallelized program crashes when OMP_NUM_THREADS > 1
--- Comment #3 from bruno at clisp dot org 2006-11-15 13:38 --- > Was LinuxThreads built at least --with-tls support or without? The glibc was built with LinuxThreads without TLS. (I gave --without-tls explicitly to the glibc build.) > If without and libgomp has been built without --disable-tls and your > assembler/linker support TLS, libgomp might be using __thread eventhough > glibc doesn't support that. Yes, this is exactly the problem; see the analysis and patch in http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html > There have been some patches added recently to improve gcc configure checks > for the runtime support of TLS. The only patch that has been committed is this one from Daniel Jacobowitz http://gcc.gnu.org/viewcvs/trunk/config/tls.m4?r1=117049&r2=118777 It has no effect on this bug, since it applies only to the cross-compiling case. For the native compile, I posted a patch that is known to fix this bug: http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html It has been approved by Richard Henderson: http://gcc.gnu.org/ml/gcc/2006-11/msg00255.html But noone has committed it to the GCC SVN. Could someone please commit this patch on the HEAD and possibly on the 4.2 branch? (It is not a regression, if you argue that libgomp and -fopenmp is a new feature. But it is a regression if you argue that there are packages out there, such as GNU gettext 0.16, which use -fopenmp if available, and this bug turns a program that would run unparallelized but correctly with gcc-4.1 into a program that runs parallelized but crashes with gcc-4.2.) -- bruno at clisp dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28468
[Bug c/29994] New: __STRICT_ANSI__ meaning incorrectly documented
What does __STRICT_ANSI__ mean in C (not C++) mode? The doc says: "The macro `__STRICT_ANSI__' is predefined when the `-ansi' option is used." I.e. when the compiler is implementing strict ISO C90. But it is also defined when the compiler is implementing strict ISO C99. $ touch empty.c $ gcc -std=c99 -E -dM empty.c | grep '\(__STRICT\|__STDC_V\)' #define __STRICT_ANSI__ 1 #define __STDC_VERSION__ 199901L And -ansi is not implied in this mode: -std=c99 -ansi apparently means strict ISO C90: $ gcc -std=c99 -ansi -E -dM empty.c | grep '\(__STRICT\|__STDC_V\)' #define __STRICT_ANSI__ 1 Possible resolutions: A) Document that __STRICT_ANSI__ can also mean strict ISO C99. B) Change "gcc -std=c99" to define __STRICT_C99__ instead of __STRICT_ANSI__. -- Summary: __STRICT_ANSI__ meaning incorrectly documented Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruno at clisp dot org GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
[Bug c/29994] __STRICT_ANSI__ meaning incorrectly documented
--- Comment #2 from bruno at clisp dot org 2006-11-27 16:50 --- You're right, it's well documented in cpp.info. I looked only in gcc.info. -- bruno at clisp dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
[Bug c/29999] New: preprocessor documentation is missing from gcc.info
A user that uses "info gcc" to look for details about the preprocessor doesn't find them. Example: [Bug c/29994]. The user did "info gcc", was looking for a section that explains all the predefined preprocessor macros, but didn't find it. The reason was that they are in a separate manual. Nowadays the preprocessor is rarely used on its own. To the user, it appears as part of the compiler. Suggestion: Integrate the parts of cpp.info that don't apply to other C/C++ implementations (such as "Predefined Macros" and "Invocation", and possibly others) into the gcc.info manual. -- Summary: preprocessor documentation is missing from gcc.info Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruno at clisp dot org GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug c/30267] New: missed optimization due to bad range propagation without -fwrapv
This program shows that some range propagation became worse between
gcc 4.0.2 and gcc 4.1.1.
=== foo.c
int notneg (int x)
{
return (~ -x) >= (-2147483647-1);
}
int negnot (int x)
{
return (- ~x) <= 2147483647;
}
==
# With gcc 4.0.2 on i686-pc-linux-gnu the code is fully optimized:
$ gcc -O2 -fomit-frame-pointer -S foo.c && cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl notneg
.type notneg, @function
notneg:
movl$1, %eax
ret
.size notneg, .-notneg
.p2align 4,,15
.globl negnot
.type negnot, @function
negnot:
movl$1, %eax
ret
.size negnot, .-negnot
.ident "GCC: (GNU) 4.0.2"
.section.note.GNU-stack,"",@progbits
# With gcc 4.1.1 on i686-pc-linux-gnu the code is fully optimized with -fwrapv
# but not without -fwrapv:
$ gcc -O2 -fomit-frame-pointer -S foo.c && cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl notneg
.type notneg, @function
notneg:
xorl%eax, %eax
cmpl$-2147483648, 4(%esp)
setne %al
ret
.size notneg, .-notneg
.p2align 4,,15
.globl negnot
.type negnot, @function
negnot:
xorl%eax, %eax
cmpl$2147483647, 4(%esp)
setne %al
ret
.size negnot, .-negnot
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
$ gcc -O2 -fomit-frame-pointer -fwrapv -S foo.c && cat foo.s
.file "foo.c"
.text
.p2align 4,,15
.globl notneg
.type notneg, @function
notneg:
movl$1, %eax
ret
.size notneg, .-notneg
.p2align 4,,15
.globl negnot
.type negnot, @function
negnot:
movl$1, %eax
ret
.size negnot, .-negnot
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
So somehow this seems to be linked to flag_wrapv. But regardless which
value is the result after signed overflow, any int >= INT_MIN and
any int <= INT_MAX should evaluate to 1 unconditionally.
--
Summary: missed optimization due to bad range propagation without
-fwrapv
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #87 from bruno at clisp dot org 2006-12-21 15:08 ---
The option -ffloat-store, recommended by Richard Henderson, has the effect of
decreasing the performance of floating-point operations for the entire
compilation unit. If you want a minimal fix that does not affect other
functions in the same compilation unit, you can use 'volatile double'
instead of 'double'. It's like a one-shot -ffloat-store. Example:
#include
void test(double x, double y)
{
const volatile double y2 = x + 1.0;
if (y != y2) printf("error\n");
}
void main()
{
const double x = .012;
const double y = x + 1.0;
test(x, y);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 --- Comment #5 from Bruno Haible --- Nice! Thank you.
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 --- Comment #8 from Bruno Haible --- > what is the reason to require that b >= 0 in all of this? In the 1990ies there were portability problems with a%b, b < 0. ANSI C said that the result was machine-dependent if a < 0 or b < 0. Fortunately the result is formally specified now, since ISO C 99. You're right: Since GCC emits the instructions for the % operation, and supposedly in compliance with ISO C and ISO C++, it can assume that negative operands behave as specified. > So, shouldn't the rules be Yes, these 4 rules look correct.
[Bug driver/98162] New: Documentation mentions non-existent option -mcet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98162 Bug ID: 98162 Summary: Documentation mentions non-existent option -mcet Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- The documentation page https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html mentions "The following built-in functions are available when -mcet or -mshstk option is used." But an option '-mcet' is not documented (see https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html) and not implemented either: $ gcc -S -O2 a.c -mcet -fcf-protection gcc: error: unrecognized command-line option '-mcet'
[Bug sanitizer/98165] New: Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 Bug ID: 98165 Summary: Use of the UB sanitizer links the the program with libstdc++ Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I would like to use the 'signed-integer-overflow' sanitizer (part of the undefined behaviour sanitizer) for all my C programs, as a security measure. However, doing so with GCC causes a link dependency towards libstdc++: $ gcc -Wall -fsanitize=signed-integer-overflow foo.c $ ldd ./a.out linux-vdso.so.1 (0x7ffc73977000) libubsan.so.1 => /lib/x86_64-linux-gnu/libubsan.so.1 (0x7fbec9aa) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fbec98b6000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fbec98b) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbec988e000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fbec96ad000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fbec9692000) /lib64/ld-linux-x86-64.so.2 (0x7fbeca42a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fbec9541000) I don't want this, because libstdc++ increases the startup time of programs (from ca. 2 ms to ca. 7 ms). This is with gcc 10.2.0. With clang 11.0.0, I don't have this problem: $ clang -fsanitize=signed-integer-overflow foo.c $ ldd ./a.out linux-vdso.so.1 => (0x7fffc25e3000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5fc1486000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5fc127e000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5fc0f75000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5fc0d71000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f5fc0b5b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5fc0791000) /lib64/ld-linux-x86-64.so.2 (0x7f5fc16a3000)
[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 --- Comment #1 from Bruno Haible --- Created attachment 49691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49691&action=edit Test case
[Bug sanitizer/98165] Use of the UB sanitizer links the the program with libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165 Bruno Haible changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Bruno Haible --- Thank you. The option '-static-libubsan' indeed has the effect I was looking for.
[Bug c/98396] New: gcc wrongly assumes that free preserves errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396 Bug ID: 98396 Summary: gcc wrongly assumes that free preserves errno Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 49808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49808&action=edit Test case On POSIX systems, free() can clobber the value of errno. This is implied by 1) https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html which says: "The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." and 2) https://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html which does not mention errno. A future version of POSIX will specify that a valid call to free() preserves errno: https://www.austingroupbugs.net/view.php?id=385 . But this is not yet standard. In particular, on Linux/glibc systems, the glibc bug https://sourceware.org/bugzilla/show_bug.cgi?id=17924 is still open, because glibc does not guarantee that free() preserves errno — neither through the code nor through the documentation. This glibc bug even has a test case of a successful free() that sets errno to ENOMEM (via a call to munmap). But GCC, when optimizing, eliminates tests of errno or assignments to errno after 'free (ptr);' where ptr was the result of a malloc(...) call in the same function. How to reproduce: $ gcc -O2 -S foo.c Inspect the resulting foo.s. You see that - In function 'check_errno_unmodified', GCC has eliminated the lines if (errno != 1789) abort (); - In function 'ensure_errno_unmodified', GCC has eliminated the lines int saved_errno = errno; and errno = saved_errno; So, while the programmer knew that free() can clobber errno and added statements to ensure that errno gets preserved, GCC optimized these statements away!
[Bug c/98396] gcc wrongly assumes that free preserves errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396 Bruno Haible changed: What|Removed |Added Known to work||4.0.4, 4.1.2, 4.2.4, 4.3.6, ||4.4.7, 4.5.4, 4.6.4, 4.7.3, ||4.8.5 Known to fail||10.2.0, 4.9.4, 5.5.0, ||6.5.0, 7.5.0, 8.4.0, 9.3.0 Target||x86_64-pc-linux-gnu Build||x86_64-pc-linux-gnu Host||x86_64-pc-linux-gnu --- Comment #1 from Bruno Haible --- Related: bug 88576, bug 98070.
[Bug middle-end/98396] gcc wrongly assumes that free preserves errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396 --- Comment #4 from Bruno Haible --- (In reply to Richard Biener from comment #3) > But note that while free() may clobber errno the state after it is undefined > (it's not documented to set it to any specific value). So I'd argue the > check_errno_unmodified testcase is not really relevant. The state of errno after calling free() is not "undefined", it is "unspecified". See the POSIX citation in the description. See also the definition of "undefined behavior" and "unspecified behavior" in ISO C 2018 § 3.4.3 and § 3.4.4. The test case 'check_errno_unmodified' is therefore perfectly valid with glibc versions newer than 2020-12-29 (where https://sourceware.org/bugzilla/show_bug.cgi?id=17924 is fixed). In these glibc versions glibc gives the guarantee that free() does not clobber errno. If you (the GCC people) don't want to make this test case work unconditionally, you at least need to tell in which way the free() declaration in glibc's needs to be modified, so that the test case will work in these newer versions of glibc.
[Bug target/51793] pragma GCC optimize wrapv leads to invalid code on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793 Bruno Haible changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.5.4, 4.6.4, 4.7.3, 4.8.5, ||4.9.4 Known to work||10.3.0, 11.1.0, 5.5.0, ||6.5.0, 7.5.0, 8.4.0, 9.3.0 Resolution|--- |FIXED --- Comment #3 from Bruno Haible --- It works fine on - Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15' - Solaris 11 OpenIndiana (gcc 7.2.0): likewise - Solaris 11 OmniOS (gcc 9.3.0): foo.s does not contain .p2align directives any more More details by testing various versions on i386-pc-linux-gnu: 4.5.4 -> .p2align 4,,-1 4.6.4 -> .p2align 4,,-1 4.7.3 -> .p2align 4,,-1 4.8.5 -> .p2align 4,,-1 4.9.4 -> .p2align 4,,-1 5.5.0 -> no .p2align any more 6.5.0 -> .p2align 4,,15 7.5.0 -> .p2align 4,,15 8.4.0 -> .p2align 4,,15 9.3.0 -> .p2align 4 10.3.0 -> .p2align 4 11.1.0 -> .p2align 4 In summary, it appears to be fixed since GCC version 5.x.
[Bug target/51793] pragma GCC optimize wrapv leads to invalid code on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793 --- Comment #4 from Bruno Haible --- Correction to comment #3: It works fine on - Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15' - Solaris 11 OpenIndiana (gcc 7.2.0): likewise - Solaris 11 OmniOS (gcc 9.3.0): foo.s contains '.p2align 4' Consistently with what we see on Linux.
[Bug other/100735] -fno-trampolines doc wrongly implies it affects C, C++ etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #1 from Bruno Haible --- (In reply to Paul Eggert from comment #0) > it is silently ignored for these languages, and I assume for any language > other than Ada. Confirmed: flag_trampolines matters only for calls with the ECF_BY_DESCRIPTOR bit set or CALL_EXPR_BY_DESCRIPTOR being true. Other than from the Ada backend, such calls are generated only from gimple nodes with subcode bit GF_CALL_BY_DESCRIPTOR set. GF_CALL_BY_DESCRIPTOR gets set through gimple_call_set_by_descriptor with argument true, and such calls exist only as consequence of tree nodes with CALL_EXPR_BY_DESCRIPTOR being true.
[Bug middle-end/30267] folding (~ -x) >= (-2147483647-1) to x != -2147483648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267 Bruno Haible changed: What|Removed |Added Known to work||10.3.0, 11.1.0, 6.5.0, ||7.5.0, 8.4.0, 9.3.0 Known to fail||4.9.4, 5.5.0 --- Comment #4 from Bruno Haible --- (In reply to Andrew Pinski from comment #3) > Fixed with at least GCC 7. > It was still broken in GCC 4.8.5 though. Indeed. Here's the status with GCC versions since 4.0.x: 4.0.4 optimized 4.1.2 missed 4.2.4 missed 4.3.6 missed 4.4.7 missed 4.5.4 missed 4.6.4 missed 4.7.3 missed 4.8.5 missed 4.9.4 missed 5.5.0 missed 6.5.0 optimized 7.5.0 optimized 8.4.0 optimized 9.3.0 optimized 10.3.0 optimized 11.1.0 optimized
[Bug c/108694] New: need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
Bug ID: 108694
Summary: need a new warning option for preparing migration to
ISO C 23
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The use of () to denote an unknown or varargs parameter list in function
declarations and function types, a language feature from K&R C, is finally
disallowed in ISO C 23. Instead, () as a parameter list denotes a list of zero
arguments, the same as (void), in ISO C 23.
The set of warnings that were added to GCC over the years, regarding function
prototypes, were designed at a time when the migration target was still
unknown. Now that the migration target, ISO C 23, is known, some projects want
to have the following programming style, for code that compiles OK both in C99
and C23:
- (1) In function definitions, use () to denote argument lists with zero
arguments.
- (2) In function declarations and function types, use (void) to denote
argument lists with zero arguments.
See https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00055.html and
https://lists.gnu.org/archive/html/bug-gnulib/2023-02/msg00062.html for details
of the rationale.
As a programmer, I would like to have an easy way to get warnings when this
programming style is not followed.
There are two ways such a warning could be added to GCC:
(A) A warning that applies when compiling for a language standard older than
C23 (e.g. -std=gnu99).
In which situations would this warning be emitted?
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators will
have a different meaning in ISO C23 */
void func4 (void); /* No warning */
=
Looking through the existing warning options of GCC and clang:
Warning options from https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Option Not adequate because ...
---
-Wall Does not warn for func3.
-Wstrict-prototypes Warns for func1 as well.
-Wold-style-declaration Does not warn for func3.
-Wold-style-definition Does not warn for func3. Warns for func1.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wmissing-declarations Does not warn for func3. Warns for func1 and func2.
-Wpedantic Does not warn for func3.
Warning options from https://clang.llvm.org/docs/DiagnosticsReference.html
Option Not adequate because ...
---
-Wall Does not warn for func3.
-Wdeprecated-declarations Does not warn for func3.
-Wdeprecated-non-prototype Does not warn for func3.
-Wmissing-prototypesDoes not warn for func3. Warns for func1 and func2.
-Wpedantic Warns for func1 as well.
So, none of these existing warning options fits the need. A new warning option
is needed.
(B) A warning that applies when compiling for C23 (e.g. -std=gnu23).
The situations would be the same as above. Only the diagnostic's message would
refer to *older* standard versions, such as:
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* warning: an empty parameter list in function declarators
denotes a varargs parameter list in ISO C17 and older; use (void) to
disambiguate */
void func4 (void); /* No warning */
=
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #2 from Bruno Haible ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to warn in those cases. It distracts from the real issue.
OK. So let's see what we get with this approach where 'void func3 ();' doesn't
warn and only the wrong uses of func3 produce diagnostics. Here's a test case,
annotated with 'error' in those places where 'clang15 -std=c2x' produces an
error:
=
/* Function definitions: */
void func1 () {}
void func2 (void) {}
/* Function declarations: */
void func3 ();
void func4 (void);
void code ()
{
void (*fp) (void);
void (*fp1) (int);
fp = func1;
fp = func2;
fp = func3;
fp = func4;
fp1 = func3;
func1 (1); /* error */
func2 (2); /* error */
func3 (3); /* error */
func4 (4); /* error */
(void) fp;
(void) fp1;
}
void func3 (int x, int y) {} /* error */
=
When compiling this in -std=c17 or older mode, we would like to get a warning
- in those places where we get an error in C23 mode, and
- in those places where there are unsafe conversions or parameter passing going
on in C23 or in C17 or older.
In detail, the desired behaviour in -std=c17 or older mode is:
=
/* Function definitions: */
void func1 () {} /* No warning */
void func2 (void) {} /* No warning */
/* Function declarations: */
void func3 (); /* No warning */
void func4 (void); /* No warning */
void code ()
{
void (*fp) (void);
void (*fp1) (int);
fp = func1; /* No warning */
fp = func2; /* No warning */
fp = func3; /* No warning */
fp = func4; /* No warning */
fp1 = func3; /* warning */
func1 (1); /* warning (if -std=c17) or error (if -std=c23) */
func2 (2); /* error */
func3 (3); /* warning (if -std=c17) or error (if -std=c23) */
func4 (4); /* error */
(void) fp;
(void) fp1;
}
void func3 (int x, int y) {} /* warning (if -std=c17) or error (if -std=c23) */
=
In the line 'fp1 = func3;' a warning should be shown because it's an unsafe
function pointer conversion in C23. (Even though in C17 it is not dangerous
code and even though in C23 it's not an error!) 'clang15 -std=c2x
-Wincompatible-function-pointer-types' does show a "warning: incompatible
function pointer types" there.
> Clang now has -Wdeprecated-non-prototype apparently
But '-Wdeprecated-non-prototype' does not exactly have the behaviour you want:
while it warns for 'func1 (1);' and 'func3 (3);' (good!), it warns also for
'void func3 ();', that is, where you don't want to see a warning.
So, no existing GCC or clang warning option has the desired behaviour. What we
need (and even independently of programming style) is
* a part of -Wdeprecated-non-prototype: do warn in function call positions,
don't warn in function declaration/type positions,
* combined with a kind of -Wfuture-incompatible-function-pointer-types, that
considers the interpretation according to C23 instead of the interpretation
according to the currently chosen standard.
[Bug c/108694] need a new warning option for preparing migration to ISO C 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694 --- Comment #4 from Bruno Haible --- (In reply to Aaron Ballman from comment #3) OK. So, except for this unlucky (*) choice of attribution in case of a conflict between function declaration and function definition, the '-Wdeprecated-non-prototype' warning is actually usable. What we need is thus: * -Wdeprecated-non-prototype, * combined with a kind of -Wfuture-incompatible-function-pointer-types, that considers the interpretation according to C23 instead of the interpretation according to the currently chosen standard. (*) Reported as a clang bug at https://github.com/llvm/llvm-project/issues/60592 .
[Bug c++/108231] New: g++ mistakenly reports ambiguity between equivalent function declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108231 Bug ID: 108231 Summary: g++ mistakenly reports ambiguity between equivalent function declarations Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 54156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54156&action=edit test case The attached code, i1.cc, contains two equivalent function declarations for the function 'free'. They are equivalent because they have the same signature and both have "C" linkage. In lines 9, 10, 12, 13, referencing the function 'free' works fine. However, referencing it in line 17, as part of a __attribute__ ((__malloc__ (free, 1))) attribute, leads to an error "‘malloc’ attribute argument 1 is ambiguous". I would expect no error, no warning. How to reproduce: $ g++ -S i1.cc i1.cc:17:67: error: ‘malloc’ attribute argument 1 is ambiguous 17 | __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (free, 1))); | ^ i1.cc:17:67: note: use a cast to the expected type to disambiguate
[Bug other/105527] New: configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 Bug ID: 105527 Summary: configure option --with-zstd is not documented Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- A GCC 12.1.0 build of mine is failing with the error messages /usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: /build-loongarch64-linux/gcc-12.1.0/gcc/../../../../sources/gcc-12.1.0/gcc/lto-compress.cc:170: undefined reference to `ZSTD_isError' /usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld: /build-loongarch64-linux/gcc-12.1.0/gcc/../../../../sources/gcc-12.1.0/gcc/lto-compress.cc:171: undefined reference to `ZSTD_getErrorName' collect2: error: ld returned 1 exit status make: *** [/sources/gcc-12.1.0/gcc/c/Make-lang.in:87: cc1] error 1 Obviously, the ZStd prerequisite is missing. The documentation (in gcc-12.1.0/gcc/doc/gccinstall.info and in https://gcc.gnu.org/install/prerequisites.html) merely says "Alternatively, the --with-zstd configure option should be used." But what is its argument? I would expect to see this documented 1. in gcc-12.1.0/gcc/doc/gccinstall.info node "Configuration", 2. also in https://gcc.gnu.org/install/configure.html. The only hint I can get is by running "gcc-12.1.0/gcc/configure --help", which prints --with-zstd=PATHspecify prefix directory for installed zstd library. Equivalent to --with-zstd-include=PATH/include plus --with-zstd-lib=PATH/lib --with-zstd-include=PATH specify directory for installed zstd include files --with-zstd-lib=PATHspecify directory for the installed zstd library This text gives the answer. It should be added to the .texi documentation.
[Bug other/105527] configure option --with-zstd is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527 --- Comment #3 from Bruno Haible --- Created attachment 52955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52955&action=edit Patch to document also --with-zstd-include and --with-zstd-lib Hi Martin, The patch you added is pretty minimal: it refers to undocumented options --with-zstd-include and --with-zstd-lib; it suggests that --with-zstd can be used without an argument; and it does not clarify how this option applies to cross-compilation. How about adding the same details as for the --with-isl, --with-isl-include, --with-isl-lib options, mutatis mutandis? Find attached a patch that does that.
[Bug tree-optimization/101494] -Wmaybe-uninitialized false alarm with memrchr of size 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #1 from Bruno Haible --- It's a regression, since GCC 10.3.0 does not produce a warning here.
[Bug analyzer/111289] [13 Regression] Unwarranted -Wanalyzer-va-arg-type-mismatch warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289 --- Comment #6 from Bruno Haible --- (In reply to John David Anglin from comment #5) > Don't include on hpux to avoid conflicting type declarations > for mode_t. This fixes test on houx. Why not entirely remove the '#include '? There is nothing in this file that needs it.
[Bug other/111287] New: doc: "strict ISO mode" definition is not up-to-date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287 Bug ID: 111287 Summary: doc: "strict ISO mode" definition is not up-to-date Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html we read: "Outside strict ISO C mode (-ansi, -std=c90, -std=c99 or -std=c11) ..." Nowadays, the options -std=c17 and -std=c2x also put gcc in "strict ISO C mode", as can be seen from the __STRICT_ANSI__ preprocessor macro: $ : | gcc -std=c90 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c99 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c11 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c17 -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 $ : | gcc -std=c2x -E -dM - | grep __STRICT_ANSI__ #define __STRICT_ANSI__ 1 Could this sentence in the manual be updated to include these new -std options?
[Bug other/111288] New: formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 Bug ID: 111288 Summary: formatting mistake in HTML documentation Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bruno at clisp dot org Target Milestone: --- Created attachment 55839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55839&action=edit proposed fix In https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html the declarations of the last 6 functions are not well formatted: the highlighted token is "int" or "long", not the name of the built-in. The attached patch fixes it. I'm also attaching the rendering before and after the patch is applied.
