[Bug target/38203] New: attribute `noreturn' isn't effective when -mthumb param is active
A small testcase:
#include
extern unsigned int whatever(unsigned char *);
__attribute__((noreturn)) int main(void)
{
whatever(NULL);
for(;;);
}
If you compile this code without -mthumb, gcc asm output is as such:
.file "pqp.c"
.text
.align 2
.global main
.type main, %function
main:
@ Volatile: function does not return.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, #0
bl whatever
.L2:
b .L2
.size main, .-main
.ident "GCC: (GNU) 4.3.2"
... Or, in other words, it correctly avoids to preserve the link register.
With -mthumb, it pushes lr to the stack, which is the same behaviour as
removing the noreturn attribute.
The thing becomes relevant when main is a complex function that does not
return: it pushes not only lr, but several otherwise clobbered registers to the
stack which it won't pull back in, thus wasting stack space forever. As you can
imagined, in embedded targets every byte counts. when compiling to arm mode
(not thumb), it avoids preserving these since it has nowhere to return them to.
--
Summary: attribute `noreturn' isn't effective when -mthumb param
is active
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-11-20 16:52 --- Created an attachment (id=16728) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16728&action=view) A more involved testcase. This testcase shows the preserving behaviour on multiple call-clobbered registers, in spite of noreturn attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38203
[Bug tree-optimization/26850] unused function not eliminated with -fwhole-program --combine
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-11-25 20:01 --- Still fails as of gcc 4.3.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #1 from alexandre dot nunes at gmail dot com 2007-10-20 01:49 --- Created an attachment (id=14374) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14374&action=view) A complete testcase. I compiled with gcc -ggdb3 file.c -o file, no optimization flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/33823] New: bitfields on packed struct aligns by a few bits if the types differ
I have two structs (the unions are there for the sake of testing, it still
behaves the same without them):
#define ATTRIBUTE_PACKED_STRUCT __attribute__((gcc_struct,packed))
#include
#include
typedef union ATTRIBUTE_PACKED_STRUCT
{
struct ATTRIBUTE_PACKED_STRUCT {
uint8_t a:1,
b:7,
c:7;
uint16_t d:16;
uint8_t e:7;
uint8_t f:7;
uint16_t g:10;
uint16_t h:10;
uint16_t i:12;
uint8_t j:7;
uint8_t k:8;
uint16_t l:15;
};
unsigned char values[14];
} test_struct;
typedef union ATTRIBUTE_PACKED_STRUCT
{
struct ATTRIBUTE_PACKED_STRUCT {
uint32_t a:1,
b:7,
c:7;
uint32_t d:16;
uint32_t e:7;
uint32_t f:7;
uint32_t g:10;
uint32_t h:10;
uint32_t i:12;
uint32_t j:7;
uint32_t k:8;
uint32_t l:15;
};
unsigned char values[14];
} test_struct2;
These structs have the same effective size, i.e., removing them from the
unions, and having sizeof() applied to them yelds the 14 bytes size, but the
members dispostion differs, i.e. the 'e' member is a bit ahead in the first
struct (test_struct) than in the second.
I didn't expect the type change to force an alignment. It that's standard
behaviour, then I would like to propose a documentation request; The ms_struct
alignment is described quite well on gcc's page, but gcc's default one isn't.
If that's not expected behaviour, then what would be? In case it is, could
someone please point me to a documentation source, i.e. an ISO C pointer or
whatever reasoning is behind this, if any?
Thanks.
--
Summary: bitfields on packed struct aligns by a few bits if the
types differ
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #3 from alexandre dot nunes at gmail dot com 2007-10-20 12:20 --- (In reply to comment #2) > The standard puts all the burden on the implementation (See 6.7.2.1/10). > The GCC manual in turn says the behavior is specified by the ABI (4.9 > Structures, unions, enumerations, and bit-fields), which would be the sysv ABI > which I > don't have handy right now. > Does the ABI dictates the case of how gcc should *pack* the structures? I've seem that gcc packs structures in a very similar (if not identical) fashion on some targets (ix86-linux-gnu, arm-elf, mingw without -mms-bitfields, at least), are they covered by sysv ABI too? Is it a default on gcc whenever the target has no particular semantics (as arm-elf, which I suppose does not derive from the ARM published ABIs at all)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #4 from alexandre dot nunes at gmail dot com 2007-10-20 12:55 --- (In reply to comment #2) > The standard puts all the burden on the implementation (See 6.7.2.1/10). > The GCC manual in turn says the behavior is specified by the ABI (4.9 > Structures, unions, enumerations, and bit-fields), which would be the sysv ABI > which I > don't have handy right now. > http://www.sco.com/developers/devspecs/abi386-4.pdf Would that be it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #5 from alexandre dot nunes at gmail dot com 2007-10-20 13:35 --- (In reply to comment #4) > (In reply to comment #2) > > The standard puts all the burden on the implementation (See 6.7.2.1/10). > > The GCC manual in turn says the behavior is specified by the ABI (4.9 > > Structures, unions, enumerations, and bit-fields), which would be the sysv > > ABI > > which I > > don't have handy right now. > > > > http://www.sco.com/developers/devspecs/abi386-4.pdf > > Would that be it? > I couldn't find (ok, I didn't try hard enough) the generic abi, but the 386 abi only tells about the case of bitfields on regular structures, i.e. those without the packed attribute. I do believe that ABI-conformant structures are always padded (aligned), and the packed structures are outside of the ABI scope... I'll try and see if I find the generic sysv abi docs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/37642] New: GCC applies signed strict-overflow rules to unsigned short type
I'll submit a testcase that apparently demonstrates that gcc is trying to apply
signed strict overflow rules to an unsigned short type, at least on 32 bit
machines when short is 16 bit.
Here is the output:
arm-elf-gcc -O2 -W -Wall -Wstrict-overflow=5 -c testcase.c
testcase.c: In function incr_counter:
testcase.c:13: warning: assuming signed overflow does not occur when assuming
that (X + c) < X is always false
this is from gcc 4.3.1; my native build also has the same semantics, and I've
tested with 4.2.4 also.
The thing is that the type is unsigned (even if it is smaller than the target
machine register), so that it can overflow and it can be detected (costly
perhaps, but can).
--
Summary: GCC applies signed strict-overflow rules to unsigned
short type
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-09-24 17:29 --- Created an attachment (id=16403) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16403&action=view) This is the first testcase. compile with gcc -O2 -W -Wall -Wstrict-overflow=5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug c/37642] GCC applies signed strict-overflow rules to unsigned short type
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-09-24 20:42 --- (In reply to comment #2) > Subject: Re: New: GCC applies signed strict-overflow rules to unsigned short > type > > When doing addition unsigned short is promoted to an signed int. So > this is not a bug. That is unsigned short + 1 is a signed int since 1 > is a signed int. > > Sent from my iPhone > Hah, living and learning. That actually makes sense, thanks, I'll refine the test. -- alexandre dot nunes at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37642
[Bug c++/3187] gcc lays down two copies of constructors
--- Comment #32 from alexandre dot nunes at gmail dot com 2008-10-21 18:37 --- I was considering using C++ for an arm-elf target, but I'm dropping that in favour of plain C because of this silly thing. This sucks, because other than that g++ does a pretty decent job when generating small, optimized code: I've got no abstraction penalty at all, but a few duplicated constructors here and there lead to about 23% code increase, and that wasn't acceptable. The other funny thing is that if this is fixed, it'll be by 4.4 or something, and so far I can't consider using gcc versions newer than 4.2.x, at least because of PR31849. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187
[Bug rtl-optimization/11826] [ARM] Minor register allocation problem before function return
--- Comment #4 from alexandre dot nunes at gmail dot com 2008-02-08 16:51 --- I suggest closing this unless reproductible on gcc 4.3.x, since at least vanilla arm-elf-gcc 4.2.2 is correct: foo: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. cmn r1, r0 rsbeq r0, r1, r0 rsbne r0, r0, r1 @ lr needed for prologue bx lr .size foo, .-foo .ident "GCC: (GNU) 4.2.2" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11826
[Bug c/35141] New: ARM: Constant generation inside a loop: Missed optimization opportunity
On ARM, the following C code:
void whatever(const char *pqp)
{
volatile unsigned int *uart_thr = (typeof(uart_thr))0xE000C000;
unsigned int ch;
while((ch = *pqp++))
*uart_thr = ch;
}
Generates this assembler output (by means of -mcpu=arm7tdmi -O2):
whatever:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr2, [r0, #0]@ zero_extendqisi2
cmp r2, #0
@ lr needed for prologue
bxeqlr
.L4:
mov r3, #-536870912
add r3, r3, #49152
str r2, [r3, #0]
ldrbr2, [r0, #1]! @ zero_extendqisi2
cmp r2, #0
bne .L4
bx lr
The relevant part is the bne .L4 ; since r3 is preserved across the loop, it
could optimize for speed without space penality by generating this instead:
.L4:
mov r3, #-536870912
add r3, r3, #49152
.L5:
str r2, [r3, #0]
ldrbr2, [r0, #1]! @ zero_extendqisi2
cmp r2, #0
bne .L5
bx lr
... or, in other words, generating the constant only once, which saves at least
two cycles per iteration.
--
Summary: ARM: Constant generation inside a loop: Missed
optimization opportunity
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC host triplet: i686-unknow-linux
GCC target triplet: arm-*-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-08 20:48 --- (In reply to comment #2) > Also using a volatile pointer may prevent optimization, so don't use it if > not strictly needed (or at least don't expect optimized code). > Sorry for lefting it in there: Tought the above code snippet was from real code that writes to a hardware register, the compiler generates exactly the same output with or without the volatile, thus that's irrelevant for this bug report. I hope I don't confuse testing on future compiler versions, where it may end up making any difference. > Can you try 4.3 as suggested? > Yes, if/when I can get it to compile. I'll post back in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #4 from alexandre dot nunes at gmail dot com 2008-02-11 21:10 --- (In reply to comment #2) > Also using a volatile pointer may prevent optimization, so don't use it if > not strictly needed (or at least don't expect optimized code). > > Can you try 4.3 as suggested? > Ok, PR35071 was the only blocker. I did a bad thing in order to bypass it (it only affected a non-default [for me] target on my multilib config) and get the whole thing to compile, and the result is: whatever: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldrbr3, [r0, #0]@ zero_extendqisi2 cmp r3, #0 bxeqlr mov r2, #-536870912 add r2, r2, #49152 .L3: str r3, [r2, #0] ldrbr3, [r0, #1]! @ zero_extendqisi2 cmp r3, #0 bne .L3 bx lr ... which seems correct to me. (my build was from svn trunk, current date 20080211, unknow revision number [my build system got rid of .svn subdirs]). No chance of a 4.2.x backport ? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-02-11 21:34 --- (In reply to comment #2) > (In reply to comment #1) > > I've seem the same error building for arm-elf. Perhaps I need a newer > > (experimental) binutils? > > Just a wild guess, could this be a typo? > > [EMAIL PROTECTED] arm]$ grep do_itt * > ieee754-df.S: do_itt eq > ieee754-sf.S: do_itt eq > I guessed the same and changed it, allowing it to compile. Whether or not that's good, I don't know, but I'll keep the tree alive in the case I need to recompile it :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-02-11 21:31 --- I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older than the one I tried at arm), and it seems to misbehave there. I'm not sure tought of the implications, since that's a superscalar cpu and these things are too complicated to my mind, perhaps it's faster that way because of an eventual alignment, etc... But it seems buggy to me :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
--- Comment #33 from alexandre dot nunes at gmail dot com 2008-02-12 00:32 --- I compiled gcc 4.3 for arm-unknown-elf (today's trunk, not sure about the rev). Compiling three in three firmware images gave me size regressions with -Os; with -O2, gcc 4.3 produces smaller code than 4.2.3: # Increased about 3.1% #nam gcc v fl code size img1 4.2.3 -Os 4786 img1 4.3.- -Os 4936 # Increased about 1.3% img2 4.2.3 -Os 3372 img2 4.3.- -Os 3416 # Decreased (!) about 3,3% img3 4.2.3 -O2 13892 img3 4.3.- -O2 13436 # Increased about 4,4% img3 4.2.3 -Os 12348 img3 4.3.0 -Os 12892 -- alexandre dot nunes at gmail dot com changed: What|Removed |Added CC||alexandre dot nunes at gmail | |dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #1 from alexandre dot nunes at gmail dot com 2008-02-11 20:12 --- I've seem the same error building for arm-elf. Perhaps I need a newer (experimental) binutils? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-02-12 00:45 --- > It is not what you think it is. ;) > > movl%edx, -536821760 > > means: > > (set (mem:SI (const_int -536821760 [0xe000c000]))(reg/v:SI 1 dx)) > > IOW, put %edx to constant address. > It actually makes sense, this arch has no spare registers to play with :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #36 from alexandre dot nunes at gmail dot com 2008-02-12 13:13 --- I think it's worth to note here the implications of the fix to PR31849. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #8 from alexandre dot nunes at gmail dot com 2008-02-14 22:06 --- (In reply to comment #7) > Yes, so for packed structs (which are a GCCism), GCC sets the rule. Better > documentation is certainly appreciated, but - what is the bug here? Did > the behavior change (I think it did for some 3.x releases) recently? > I'm not sure if it's a bug, call it a clarification request, that may or may not involve a bug: It's stated somewhere in gcc docs that gcc tries to do things uniformly, only diverging between targets where there's a compelling reason to do so. So what I'm asking is: - Is the attribute((packed)) behaviour consistent between gcc ports regarding bitfield alignments? If not, why? - If attribute((packed)) is not consistent between gcc ports, could it be made so? At least sysv abi (as far as I've read) does not mandate anything about the bitfields within a word. I've not pointed to any ABI that does, however, that was the explanation I've got. That's where I said the abi could change (for several arches). You may say it's not worthy, and I would agree, but here is where the "bug" would (or would not) lie. - If not and there's no point changing it, could there be another attribute, or anything, that would have that effect (uniformity between ABIs)? I understand perfectly that using structures like that is meant to be non-portable, but it's quite handy to have something like that without too much worry about platforms, since altough I develop for several arches, almost all of them today have a gcc port, and I know there are others with similar issues. If this revert to be a non-bug and I can still hold a feature request on it, I would be satisfied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #10 from alexandre dot nunes at gmail dot com 2008-02-14 23:15 --- (In reply to comment #9) > We can't change the current behavior/ABI obviously. But the request for > better > documentation is correct. > Would it be feasibly to have a non-fatal testcase for this, so that it would be easy to catch (and document) which (if any) targets deviates from this pattern? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug rtl-optimization/31360] [4.2 Regression] RTL loop invariant is not aggressive enough
--- Comment #37 from alexandre dot nunes at gmail dot com 2008-03-03 14:30 --- If PR31849 is right, shouldn't this be reopened or marked as something other than fixed ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
[Bug tree-optimization/31849] [4.3/4.4 Regression] Code size increased with PR 31360 (IV-opts not understanding autoincrement)
--- Comment #47 from alexandre dot nunes at gmail dot com 2009-03-06 15:29 --- Any news on the subject? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #4 from alexandre dot nunes at gmail dot com 2009-04-14 20:04 --- Created an attachment (id=17638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17638&action=view) Testcase for gcc 4.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #5 from alexandre dot nunes at gmail dot com 2009-04-14 20:07
---
See the attached pqp.c file.
With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
sum:
ldr r2, .L3
ldmia r2, {r1, r3}@ phole ldm
add r3, r0, r3
add r0, r0, r1
stmia r2, {r0, r3}@ phole stm
bx lr
With gcc 4.4.0 branch, built on 20090413, it fails:
sum:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldr r2, [r3, #0]
ldr r1, [r3, #4]
add r2, r0, r2
add r1, r0, r1
str r1, [r3, #4]
str r2, [r3, #0]
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #6 from alexandre dot nunes at gmail dot com 2009-04-14 20:11
---
(In reply to comment #5)
> See the attached pqp.c file.
>
> [cut]
>
> With gcc 4.4.0 branch, built on 20090413, it fails:
>
This seems to be caused by the register order allocation. If I replace the
source code lines to operate in the reverse order:
hehe.y += pqp;
hehe.x += pqp;
Then 4.4.0 20090413 generates optimized code:
ldr r3, .L3
ldmia r3, {r1, r2}@ phole ldm
add r2, r0, r2
add r1, r0, r1
stmia r3, {r1, r2}@ phole stm
bx lr
While gcc 4.3.3 does not :-) Funny thing isn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug c/33823] bitfields on packed struct aligns by a few bits if the types differ
--- Comment #6 from alexandre dot nunes at gmail dot com 2007-11-02 16:58 --- >From the gcc internals (http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html): Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (tree record_type) This target hook returns true if bit-fields in the given record_type are to be laid out following the rules of Microsoft Visual C/C++, namely: (i) a bit-field won't share the same storage unit with the previous bit-field if their underlying types have different sizes, and the bit-field will be aligned to the highest alignment of the underlying types of itself and of the previous bit-field; (ii) a zero-sized bit-field will affect the alignment of the whole enclosing structure, even if it is unnamed; except that (iii) a zero-sized bit-field will be disregarded unless it follows another bit-field of nonzero size. If this hook returns true, other macros that control bit-field layout are ignored. When a bit-field is inserted into a packed record, the whole size of the underlying type is used by one or more same-size adjacent bit-fields (that is, if its long:3, 32 bits is used in the record, and any additional adjacent long bit-fields are packed into the same chunk of 32 bits. However, if the size changes, a new field of that size is allocated). In an unpacked record, this is the same as using alignment, but not equivalent when packing. If both MS bit-fields and `__attribute__((packed))' are used, the latter will take precedence. If `__attribute__((packed))' is used on a single field when MS bit-fields are in use, it will take precedence for that field, but the alignment of the rest of the structure may affect its placement. ... it seems like that the packed attribute has the power of nulify the ms_struct attribute, but not the gcc_struct one, regarding a rather non-uniform behaviour if the underlying ABIs are different. It also means that I could use ms_struct,packed in a portable way (even on architetures where the ms_struct isn't even an alternative), but gcc_struct,packed is less portable. Right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33823
[Bug c/34076] New: inline attribute seems to mess with const qualifier.
On the following code:
#ifndef NOINLINES
#define EINLINE __inline__
#else
#define EINLINE
#endif
EINLINE int a(void *value)
{
return *(char *)value;
}
int b(const char *val)
{
return a((char *)val);
}
int c(void)
{
return b("whatever");
}
... compiling it with these flags: -W -Wall -Winline -Wshadow -Werror -O
... gives this warning (treated as an error as requested):
pqp.c: In function b:
pqp.c:16: warning: passing argument 1 of a discards qualifiers from pointer
target type
if you pass -DNOINLINES on the command line, i.e. take away the inline
attribute, this goes away, except if I compile with -O3 (which tries to inline
it anyway). Please note the explicit cast to (char *) at a; without that cast
gcc should (and it does) warn both with and without attribute inline, but I
couldn't find a way to make the explicit cast respected when gcc is inlining
functions.
I couldn't reproduce this on gcc 4.1.x, i.e. it behaves ok.
--
Summary: inline attribute seems to mess with const qualifier.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34076
[Bug c/34076] inline attribute seems to mess with const qualifier.
--- Comment #1 from alexandre dot nunes at gmail dot com 2007-11-12 19:46 --- Created an attachment (id=14532) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14532&action=view) the original file from the bug report. gcc -DNOINLINES -W -Wall -Winline -Wshadow -Werror -O -c pqp.c gcc -W -Wall -Winline -Wshadow -Werror -O -c pqp.c cc1: warnings being treated as errors pqp.c: In function b: pqp.c:16: warning: passing argument 1 of a discards qualifiers from pointer target type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34076
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #23 from alexandre dot nunes at gmail dot com 2007-11-12 20:11 --- (In reply to comment #20) > Change target milestone to 4.2.3, as 4.2.2 has been released. > Does this means it'll get fixed by 4.2.3, or the 4.2.x series will stay bugged indefinitely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #26 from alexandre dot nunes at gmail dot com 2007-11-12 20:40 --- (In reply to comment #25) > > ... but the audit trail suggests otherwise. :S > Ok, now I'm confused :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug middle-end/29478] [4.2 Regression] optimization generates warning for casts
--- Comment #29 from alexandre dot nunes at gmail dot com 2007-11-13 17:35 --- (In reply to comment #28) > (In reply to comment #26) > > (In reply to comment #25) > [cut] > > Mark does not actually read the full list of messages when changing the target > milestone. I think this should be closed as WONTFIX since there is no easy way > to fix this for 4.2 but it is fixed in 4.3. As a workaround, you should be > able > to use -Wno-cast-qual to avoid the warning. > > I don't remember if 4.2 supports -Wno-error=cast-qual. If it does, you can > still get the warning as a warning even when using -Werror. > It does, thanks for the tip. I added this to my makefile: check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi ;) # Work-around for stupid gcc 4.2 bug ifneq ($(findstring Werror,$(WARN)),) WARN += $(call check_gcc,-Wno-error=cast-qual,) endif ... now it compiles fine with -Werror both on gcc 4.1 and 4.2. It would be nice if this bug would get somehow documented on gcc manual or the main site before gcc 4.2.3 release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29478
[Bug c/28706] [4.1 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #6 from alexandre dot nunes at gmail dot com 2008-01-15 17:40 --- This seems to work as of gcc 4.2.2 (vanilla), using the original commands to reproduce. Anyone denies/confirms this? -- alexandre dot nunes at gmail dot com changed: What|Removed |Added CC||alexandre dot nunes at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
[Bug c/34800] New: Compile failure with --combine and a union with an anonymous struct
$ cat pqp.c
typedef union {
struct
{
unsigned char d;
};
unsigned char a, b;
} test_type;
extern test_type whatever;
$ gcc -c pqp.c
$ gcc --combine -c pqp.c pqp.c
pqp.c:9: error: conflicting types for whatever
pqp.c:9: error: previous declaration of whatever was here
This seems like a more strict case of bug 28706 or something.
--
Summary: Compile failure with --combine and a union with an
anonymous struct
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandre dot nunes at gmail dot com
GCC host triplet: i686-unknow-linux
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34800
[Bug c/28706] [4.1 Regression] Compile failure with --combine and explicitly aligned structures
--- Comment #7 from alexandre dot nunes at gmail dot com 2008-01-15 17:55 --- (In reply to comment #6) > This seems to work as of gcc 4.2.2 (vanilla), using the original commands to > reproduce. Anyone denies/confirms this? > ... and please see bug 34800 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28706
[Bug c/28712] [4.0/4.1 Regression] Compile failure with --combine and packed structures.
--- Comment #5 from alexandre dot nunes at gmail dot com 2008-01-15 17:58 --- (In reply to comment #4) > won't fix in GCC-4.0.x. Adjusting milestone. > For anyone interested, I think this is fixed for at least gcc 4.2.2; I couldn't reproduce it. -- alexandre dot nunes at gmail dot com changed: What|Removed |Added CC| |alexandre dot nunes at gmail | |dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28712
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
--- Comment #16 from alexandre dot nunes at gmail dot com 2008-01-15 18:03 --- vanilla gcc 4.2.2 seems to compile this testcase ok (all five symbols are emmited and externally visible, no warnings) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug middle-end/28755] [4.0/4.1/4.2 Regression] duplicate members of arrays
--- Comment #9 from alexandre dot nunes at gmail dot com 2008-01-15 18:12 --- (In reply to comment #8) > Fixed on the trunk. > For anyone else wondering, this is still reproductible on vanilla gcc 4.2.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28755
[Bug c/34800] Compile failure with --combine and a union with an anonymous struct
--- Comment #2 from alexandre dot nunes at gmail dot com 2008-06-19 13:21 --- (In reply to comment #1) > Works for me with > GNU C (Debian 4.3.1-2) version 4.3.1 (i486-linux-gnu) > and current trunk. > Yes, 4.3.x is not affected, even pre-releases of 4.3.0 worked fine for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34800
