[Bug c/94859] zero-length bit fields conflict with standard

2020-04-29 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94859 --- Comment #1 from doug mcilroy --- gcc accepts struct X {int a; int :0;} x; and rejects struct Y {int a; :0;} y; in conflict with the final sentence in this quote from the C standard, Section 6.7.2.1, Structure and union

[Bug c/94859] New: zero-length bit fields conflict with standard

2020-04-29 Thread doug at cs dot dartmouth.edu
Assignee: unassigned at gcc dot gnu.org Reporter: doug at cs dot dartmouth.edu Target Milestone: ---

[Bug c/93476] New: int bit fields waste space

2020-01-27 Thread doug at cs dot dartmouth.edu
: unassigned at gcc dot gnu.org Reporter: doug at cs dot dartmouth.edu Target Milestone: --- sizeof(struct{ unsigned int a:2; }) is 4. 3 out of the 4 bytes are gratuitously wasted. A workaround is struct{ unsigned char a:2; }, whose size is 1, but this is implementation-defined syntax

[Bug c/93474] New: no warning for nonstandard bit field

2020-01-27 Thread doug at cs dot dartmouth.edu
Assignee: unassigned at gcc dot gnu.org Reporter: doug at cs dot dartmouth.edu Target Milestone: --- struct { char x:1; } is implementation-defined syntax per www.open-std.org/jtc1/sc22/wg14/www/docs/n2433.pdf, Section 6.7.2.1, Constraint 5, which requires support of only _Bool, signed

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

2020-01-22 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278 --- Comment #11 from doug mcilroy --- When I ran it on Linux, I did get catastrophe: "No space left on device". I do not know what device; ~ and /tmp live in different file systems. It's been decades since I last saw that diagnostic. It also

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

2020-01-18 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278 --- Comment #9 from doug mcilroy --- If I can play with the assembler to accomplish the desired result, why can't gcc? I notice that gcc is smart enough already to produce uninitialized space for char a[1000] = "\0"; int main(){

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

2020-01-17 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278 --- Comment #6 from doug mcilroy --- The waste of time and space happens in the assembler, but the assembler only does what it is told to do. There must be a way for gcc to tell it to put array a in a partially filled ELF section. $ cat junk.c

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

2020-01-17 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278 --- Comment #5 from doug mcilroy --- The waste of time and space happens in the assembler, but the assembler only does what it is told to do. There must be a way for gcc to tell it to put array a in a partially filled ELF section. $ cat junk.c

[Bug c/93278] huge almost empty array takes huge time to compile and produces huge object file

2020-01-16 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278 --- Comment #2 from doug mcilroy --- My error. I omitted half the program. The bad behavior is exhibited by char a{HUGE] = "x"; int main(){ return 0; }

[Bug c/93278] New: huge almost empty array takes huge time to compile and produces huge object file

2020-01-15 Thread doug at cs dot dartmouth.edu
Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: doug at cs dot dartmouth.edu Target Milestone: --- Example, with HUGE varying from a million to a billion. char a[HUGE] = "x"; Object file size varies a

[Bug preprocessor/8270] [6/7/8 Regression] back-slash white space newline with comments, no warning

2017-11-03 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #61 from doug mcilroy --- Contrary to comment #57, the GCC convention does affect the interpretation of C-style comments. GCC rejects this Christmas tree with trailing spaces. /* /\ /**\ /\ */

[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning

2015-03-21 Thread doug at cs dot dartmouth.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270 --- Comment #56 from doug mcilroy doug at cs dot dartmouth.edu --- (In reply to Kai Tietz from comment #55) Comment #55 overlooks the Standard's translation phase 1, which replaces an implementation-defined end-of-line indicator with a new-line