I asked:
> Can this have serious effects (like overlapped or split objects),
> or is .size used only for e.g. debugging?
It seems that .size is used for shared libraries compiled without
-fPIC: linking the same code statically or with -fPIC fixes the wrong
behavior, and -finhibit-size-directive c
gcc-4.1.0-0.20051206r108118 emits wrong .size directives for
statically initialized objects with a flexible array member,
e.g.:
struct {int x; int y[];} obj = {1, {2, 3}};
.globl obj
.data
.align 4
.type obj, @object
.size obj, 4
obj:
.long 1
Andrew Pinski <[EMAIL PROTECTED]> writes:
>> This is gcc-4.2.0-0.20060806r115974
>
> Can you submit a real bug report to http://gcc.gnu.org/bugzilla
> as mentioned on http://gcc.gnu.org/bugs.html?
Done; http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28727
--
__("< Marcin Kowalczyk
\_
This is gcc-4.2.0-0.20060806r115974
Source:
--
typedef struct descr *descr_t;
typedef descr_t *value_t;
struct descr {descr_t descr;};
typedef struct {descr_t descr; value_t fields[2];} object_t_2;
value_t **marked_top, **marked_
I was told in January that the "comparison is always true due to
limited range of data type" warning has been guarded by -Walways-true
in gcc-4.2.0. But it's still issued unconditionally in
gcc-4.2.0-0.20060806r115974.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
There is a missing opportunity for optimization.
int f(void);
void test(int x) {
if (x & 1 ? x == 0 : x > 0) f();
}
This is gcc-4.1.0-0.20051206 with some patches by PLD Linux
Distribution. gcc -S -O2 -fomit-frame-pointer generates the
following code:
test:
movl4(%esp), %eax
Andrew Pinski <[EMAIL PROTECTED]> writes:
> No. This is GCC "extern inline" and not C99 "extern inline".
Does GCC plan to move to the C99 semantics of inline and extern inline
in C?
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Well this warning just found a bug in GCC's code where we had an enum and
> that enum was stored in a bitfield but the bitfield did not span the
> whole enum so we get this warning.
Couldn't this be detected when the enum is stored in the bitfield?
> S
Hello.
There was a discussion about this warning about a year ago, but it
seems to have been forgotten without a resolution.
This warning is issued unconditionally, impossible to disable, hard
to work around, and it depends on integer sizes even when the code
is portable.
I think it should be re
