[Bug c/86768] New: gcc wrongly decides that variable is <=1 after "while (x>1 && blah)" construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86768
Bug ID: 86768
Summary: gcc wrongly decides that variable is <=1 after "while
(x>1 && blah)" construct.
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Emmanuel.Thome at inria dot fr
Target Milestone: ---
Created attachment 44477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44477=edit
test program (wrong diagnostic emitted with -m32 -O3 only)
I have a construct of the following form (comes from actual code, test case
attached).
// check argc >= 3
while (argc > 1 && argv[1][0] == '-') {
// do something and then argc--, or maybe call exit()
}
// do code that relies on argc >= 3
As presented, it looks kinda weird, but I could as well make the condition be:
while (argc > 1 && argv[1][0] == '-' && foo(argc))
with foo(argc) being outside the compilation unit. So we could be in a
situation where because of the way foo() acts, the post-condition argc>=3 holds
anyway (and the test argc>1 is pointless).
However, I get the following with -m32 -O3: (note: nr_B2 is argc-2)
localhost $ gcc -m32 -O3 /tmp/t.c -W -Wall -c
/tmp/t.c: In function ‘blah’:
/tmp/t.c:32:10: warning: argument 1 value ‘4294967292’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
B2 = malloc(nr_B2 * sizeof(unsigned long));
^
In file included from /tmp/t.c:2:
/usr/include/stdlib.h:539:14: note: in a call to allocation function ‘malloc’
declared here
extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
^~
Meaning that gcc has decided that the post-condition argc==1 holds after the
while loop. I think that this is an incorrect guess.
[Bug c++/86733] c++17 and #pragma GCC diagnostic warning "-Wall" resurrect pre-c++11 warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86733 --- Comment #4 from Emmanuel Thomé --- (In reply to Jonathan Wakely from comment #3) > (In reply to Emmanuel Thomé from comment #2) > > (In reply to Jonathan Wakely from comment #1) > > > Presumably the handling for the pragma just turns the option on without > > > considering the current cxx_dialect. > > > > It seems to me that it is not consistent with the test case compiling fine > > with g++ -std=c++11 -c foo.cpp , is it ? > > That's why I confirmed it as a bug. If #pragma were just "turning the option on without considering the dialect", then my test case would issue a warning with -std=c++11 too. So there's more stuff that comes into play, it seems.
[Bug c++/86733] c++17 and #pragma GCC diagnostic warning "-Wall" resurrect pre-c++11 warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86733
--- Comment #2 from Emmanuel Thomé ---
(In reply to Jonathan Wakely from comment #1)
> Presumably the handling for the pragma just turns the option on without
> considering the current cxx_dialect.
It seems to me that it is not consistent with the test case compiling fine with
g++ -std=c++11 -c foo.cpp , is it ?
> This should fix it:
>
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -9210,7 +9210,7 @@ cp_parser_binary_expression (cp_parser* parser, bool
> cast_p,
>/* Get an operator token. */
>token = cp_lexer_peek_token (parser->lexer);
>
> - if (warn_cxx11_compat
> + if (warn_cxx11_compat && cxx_dialect < cxx11
>&& token->type == CPP_RSHIFT
>&& !parser->greater_than_is_operator_p)
> {
Yes it does.
However, when reading gcc/c-family/c-opts.c one surmises that there is an
intent to disable warn_cxx11_compat altogether if cxx_dialect >= cxx11 ; this
code path is apparently not walked when warnings are enabled with #pragma,
which (I presume) sets -Wall only based on EnabledBy and LangEnabledBy in
c.opt, unconditionally.
Maybe there are other bugs in the same vein, then (insofar as "warning X is
enabled by -Wall [or -Wextra] in [dialect XYZ]" is often implemented in
c-opts.c, and would then be missed by the #pragma).
[Bug c++/86733] New: c++17 and #pragma GCC diagnostic warning "-Wall" resurrect pre-c++11 warnings.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86733
Bug ID: 86733
Summary: c++17 and #pragma GCC diagnostic warning "-Wall"
resurrect pre-c++11 warnings.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Emmanuel.Thome at inria dot fr
Target Milestone: ---
gcc 8.1.0 here.
The following simple code expectedly fails to compile with -std=c++98 because
of the double angle brackets. (g++ -std=c++98 -c /tmp/foo.cpp)
#pragma GCC diagnostic warning "-Wall"
template class foo { };
template struct bar { struct type { }; };
template struct baz { typedef typename bar>::type type; };
With -std=c++11, this works fine, and no warning is triggered.
With -std=c++17, I get a warning that I had not expected.
localhost $ g++ -std=c++17 -c foo.cpp
foo.cpp:4:56: warning: ‘>>’ operator is treated as two right angle brackets in
C++11 [-Wc++11-compat]
template struct baz { typedef typename bar>::type type; };
^~
foo.cpp:4:56: note: suggest parentheses around ‘>>’ expression
The #pragma plays a role here. The warning is triggered only when the #pragma
is enabled. I haven't been able to trigger it with the #pragma commented out
and a command-line flag (e.g. not with -std=c++17 -Wall, nor with -std=c++17
-Wc++11-compat).
[Bug middle-end/67418] resolution to constant fails between pointer on stack and pointer within argument structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67418 --- Comment #2 from Emmanuel Thomé --- ok thanks. Indeed it's more an enhancement request then.
[Bug c/67418] New: resolution to constant fails between pointer on stack and pointer within argument structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67418
Bug ID: 67418
Summary: resolution to constant fails between pointer on stack
and pointer within argument structure
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Emmanuel.Thome at inria dot fr
Target Milestone: ---
Hi,
In the code below, gcc version 4.8.4, 4.9.3, and 5.2.0 fail to resolve the
expression temp != a->x as being a constant, while all succeed in resolving
temp != b.
It seems to me however that no valid code can reach either temp==b or
temp==a->x. Shouldn't gcc decide then that temp != a->x is constant and equal
to true in this case ? Please correct me if I am wrong.
[I've run into this as being the cause of an unexpected uninitialized warning,
whose root cause is this constant problem]
E.
struct container {
unsigned long * x;
};
int bang() __attribute__((error("should never be called")));
#define MUST_BE_CONSTANT(c) do { \
int n __attribute__((unused)) = __builtin_constant_p((c)) ? 0 : bang(); \
} while (0)
void test(struct container * a, unsigned long * b)
{
unsigned long temp[1];
MUST_BE_CONSTANT(temp != b); // passes ok.
MUST_BE_CONSTANT(temp != a->x);// fails to decide it holds
}
/*
$ ./gcc-5.2.0/bin/gcc -O2 -Wextra /tmp/a.c -c
/tmp/a.c: In function ‘test’:
/tmp/a.c:7:67: error: call to ‘bang’ declared with attribute error: should
never be called
int n __attribute__((unused)) = __builtin_constant_p((c)) ? 0 : bang(); \
^
/tmp/a.c:14:5: note: in expansion of macro ‘MUST_BE_CONSTANT’
MUST_BE_CONSTANT(temp != a->x);// fails to decide it holds
^
$ uname -a
Linux localhost 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64
GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing (stretch)
Release:testing
Codename: stretch
$ ./gcc-5.2.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-5.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.2.0/configure --prefix=/opt/gcc-5.2.0
--enable-languages=c,c++
Thread model: posix
gcc version 5.2.0 (GCC)
*/
[Bug c/62294] [4.9 Regression] Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294 --- Comment #6 from Emmanuel Thomé Emmanuel.Thome at inria dot fr --- Thanks. E.
[Bug c/62294] New: Missing passing argument [...] from incompatible pointer type warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62294
Bug ID: 62294
Summary: Missing passing argument [...] from incompatible
pointer type warning.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Emmanuel.Thome at inria dot fr
Hi.
The following code should cause a warning.
#include gmp.h
void what(mpz_t a, mpz_t p, gmp_randstate_t rstate)
{
mpz_urandomm(a, p, rstate); /* WRONG */
mpz_urandomm(a, rstate, p); /* correct */
}
Alas, gcc-4.9.1 seems happy:
/tmp $ gcc-4.9 -W -Wall -Wextra -c b.c
gcc-4.8 moans appropriately.
/tmp $ gcc-4.8 -W -Wall -Wextra -c b.c
b.c: In function ‘what’:
b.c:5:5: warning: passing argument 2 of ‘__gmpz_urandomm’ from incompatible
pointer type [enabled by default]
mpz_urandomm(a, p, rstate); /* WRONG */
^
In file included from b.c:1:0:
/usr/include/x86_64-linux-gnu/gmp.h:1115:21: note: expected ‘struct
__gmp_randstate_struct *’ but argument is of type ‘struct __mpz_struct *’
__GMP_DECLSPEC void mpz_urandomm (mpz_ptr, gmp_randstate_t, mpz_srcptr);
^
b.c:5:5: warning: passing argument 3 of ‘__gmpz_urandomm’ from incompatible
pointer type [enabled by default]
mpz_urandomm(a, p, rstate); /* WRONG */
^
In file included from b.c:1:0:
/usr/include/x86_64-linux-gnu/gmp.h:1115:21: note: expected ‘mpz_srcptr’ but
argument is of type ‘struct __gmp_randstate_struct *’
__GMP_DECLSPEC void mpz_urandomm (mpz_ptr, gmp_randstate_t, mpz_srcptr);
Here is gcc -v:
/tmp $ gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=gcc-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-4'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-4)
I'm happy to provide any further information.
Regards,
E.
[Bug tree-optimization/53198] [4.7 Regression] gcc wrongly emits array subscript is above array bounds for simple arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53198
Emmanuel Thomé Emmanuel.Thome at inria dot fr changed:
What|Removed |Added
CC||Emmanuel.Thome at inria dot fr
--- Comment #7 from Emmanuel Thomé Emmanuel.Thome at inria dot fr ---
Hi,
Seems to me that the bug is still present in 4.7.3 (stock version,
x86_64-unknown-linux-gnu)
int foo(unsigned long t)/* implicit promise that t != 0 */
{
unsigned long a[2] = {0, t};
int i;
for(i = 1 ; !a[i] ; i++);
return a[i];
}
int bar(unsigned long t)/* implicit promise that t != 0 */
{
unsigned long a[2] = {0, t};
int i;
for(i = 0 ; !a[++i] ; );
return a[i];
}
$ gcc -c -W -Wall -O2 b.c
b.c: In function ‘foo’:
b.c:5:19: warning: array subscript is above array bounds [-Warray-bounds]
Interestingly, the two functions are equivalent as far as I can tell (sorry for
headaches induced by contrived control), and behave differently with 4.7.3.
Both with respect to the fact that only one triggers the warning, and also that
assembly code generated differs slightly.
4.8.1 behaves fine, and optimizes everything away as expected.
