[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[ajax at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582

Adam Jackson  changed:

   What|Removed |Added

 CC||ajax at redhat dot com

--- Comment #5 from Adam Jackson  ---
(In reply to Martin Sebor from comment #4)
> It seems like the reporter might be conflating the forming of a past-the-end
> pointer (what the GRABEXT macro does) with dereferencing that pointer (the
> use of the -> operator with the result).

I'm not conflating it, I'm pretty sure the whole point of computing that
address
is to dereference it because that's where the data I want is. The caller is
doing somemthing of the form:

struct image {
int w, h, bpp;
// unsigned char pixels[];
};

struct image *i = malloc(sizeof(*i) + w * h * bpp);

This is not uncommon in code older than zero-length arrays.

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[ajax at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582

--- Comment #7 from Adam Jackson  ---
(In reply to Marek Polacek from comment #6)

> Well, zero-length arrays are a GNU C extension, but pre-C99 you could use
> pixels[1] and post-C99 you can use pixels[].  Is non of that an option?

The code could be changed, sure. We hit this _only_ on s390x when rebuilding
libXt. If the code is invalid then why the inconsistency?

[Bug c/41624] New: RFE: -fno-nested-functions

[ajax at redhat dot com]

Nested functions in C are a serious misfeature, for any number of reasons (some
of which are even in the manual).  They should be something a project should be
able to ban the use of at the language level, without forcing a switch to
strict non-gnu mode.

Also, unlike most g89 language features, they seriously impede the ability of
the parser to tell you where syntax errors occur.  As it is, a missing }
doesn't get noticed until the end of the compilation unit; non-nested-function
dialects of C can fail at exactly the nested function declaration.


-- 
   Summary: RFE: -fno-nested-functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajax at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41624

[Bug c++/51427] New: Less-than-useful error message when union/struct tags conflict

[ajax at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51427

 Bug #: 51427
   Summary: Less-than-useful error message when union/struct tags
conflict
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@redhat.com
CC: do...@gcc.gnu.org


[ajax@f17 tmp]$ cat test.c
#ifdef __cplusplus
extern "C" {
#endif
typedef struct _GMutex GMutex;
typedef union _GMutex GMutex;
#ifdef __cplusplus
};
#endif

[ajax@f17 tmp]$ g++ -Wall -c -o test.o test.c
test.c:5:19: error: ‘union’ tag used in naming ‘struct _GMutex’ [-fpermissive]

This message is unhelpful.  At the very least it should say where the
conflicting typedef came from, since it could easily be in a different file. 
The text itself is a bit unclear as well, something more like "GMutex already
defined as 'struct _GMutex' at ..." might be better.

Note that the C frontend gets this right already:

[ajax@f17 tmp]$ gcc -Wall -c -o test.o test.c
test.c:5:19: error: ‘_GMutex’ defined as wrong kind of tag
test.c:5:27: error: conflicting types for ‘GMutex’
test.c:4:28: note: previous declaration of ‘GMutex’ was here

[Bug c/85182] New: _Static_assert is less than useful in a static inline

[ajax at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182

Bug ID: 85182
   Summary: _Static_assert is less than useful in a static inline
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajax at redhat dot com
  Target Milestone: ---

Consider:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  static inline void bar(void)
 2  {
 3  _Static_assert(0, "called bar()");
 4  }
desoxy:~/git/junkdrawer% cat -n static-assert.c
 1  #include "static-assert.h"
 2  void foo(void) { bar(); }
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c 
In file included from static-assert.c:1:
static-assert.h: In function ‘bar’:
static-assert.h:3:5: error: static assertion failed: "called bar()"
 _Static_assert(0, "called bar()");
 ^~
desoxy:~/git/junkdrawer% gcc --version | head -1
gcc (GCC) 8.0.1 20180317 (Red Hat 8.0.1-0.19)
---

Note that the report locates the definition, not the call site. Effectively I'm
being punished for avoiding the preprocessor, which seems wrong:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  #define bar() do { \
 2  _Static_assert(0, "called bar()"); \
 3  } while (0)
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c
In file included from static-assert.c:1:
static-assert.c: In function ‘foo’:
static-assert.h:2:9: error: static assertion failed: "called bar()"
 _Static_assert(0, "called bar()"); \
 ^~
static-assert.c:2:18: note: in expansion of macro ‘bar’
 void foo(void) { bar(); }
  ^~~
---

[Bug c/85182] _Static_assert is less than useful in a static inline

[ajax at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85182

Adam Jackson  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Adam Jackson  ---
(In reply to jos...@codesourcery.com from comment #1)
> This is how static assertions are defined in C11, not a bug in GCC: it's a 
> constraint violation if the constant expression compares equal to 0, 
> regardless of the context in which the declaration appears (thus, a 
> constraint violation in a function that is never called, for example).

You missed my point. The diagnostic points me to the site of the declaration of
the static inline, not of the call site. Let's make this more explicit:

---
desoxy:~/git/junkdrawer% cat -n static-assert.h
 1  static inline void bar(void)
 2  {
 3  const int y = 0;
 4  _Static_assert(y, "called bar()");
 5  }
desoxy:~/git/junkdrawer% cat -n static-assert.c
 1  #include "static-assert.h"
 2  void foo(void) { bar(); }
desoxy:~/git/junkdrawer% gcc -O2 -c static-assert.c
In file included from static-assert.c:1:
static-assert.h: In function ‘bar’:
static-assert.h:4:5: error: static assertion failed: "called bar()"
 _Static_assert(y, "called bar()");
 ^~
---

Don't tell me "in file A included from this spot in B, you hit a static
assert". Tell me "At this spot in A, this function defined in B hit a static
assert". Because otherwise, with a less trivial assertion, I am going to have
_no idea_ where the constraint was violated.

[Bug c/82520] New: Missing warning when stack addresses escape the current scope

[ajax at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82520

Bug ID: 82520
   Summary: Missing warning when stack addresses escape the
current scope
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ajax at redhat dot com
  Target Milestone: ---

Testcase:

-
#include 

struct foo { void *v; };

struct foo *bar(void)
{
int a[10];
struct foo *ret = malloc(sizeof(struct foo));

ret->v = &a;

return ret;
}
-

The address of 'a' is just somewhere on the stack. There might be rare cases
where you'd want to do this, but usually this would be a bug.

Bug 63181 is perhaps a C++ variation of the same kind of problem, but clang
doesn't warn for this one.

[Bug c/30075] New: Missed optimizations with -fwhole-program -combine

[ajax at redhat dot com]

---
atropine:~/combine-bug% cat foo.c
int foo(void) {
return 0;
}

atropine:~/combine-bug% cat bar.c 
extern int foo(void);

void *array[] = {
foo
};

atropine:~/combine-bug% gcc -shared -fPIC -combine -fwhole-program -o libfoo.so
foo.c bar.c
atropine:~/combine-bug% nm libfoo.so | egrep '(foo)|(array)'
048c t foo
atropine:~/combine-bug% rpm -q gcc
gcc-4.1.1-30
---

foo is still emitted, when you'd think you could garbage-collect it, since the
array that references it has fallen out of existance.  If you use
-fvisibility=hidden instead of -fwhole-program the result is even worse, both
foo and array are emitted even though the resulting DSO does not give any
access to them.


-- 
   Summary: Missed optimizations with -fwhole-program -combine
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: ajax at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30075

[Bug c/30075] Missed optimizations with -fwhole-program -combine

[ajax at redhat dot com]

--- Comment #2 from ajax at redhat dot com  2006-12-05 19:37 ---
Just to clarify, I neglected to use -O in the example above, but this behaviour
is still seen even with -O.


-- 

ajax at redhat dot com changed:

   What|Removed |Added

  Component|middle-end  |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30075