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

[doug at cs dot dartmouth.edu]

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

Bug ID: 94859
   Summary: zero-length bit fields conflict with standard
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug at cs dot dartmouth.edu
  Target Milestone: ---

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

[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 specifiers, paragraph #4:

"The expression that specifies the width of a bit-field shall be an integer
constant expression with a nonnegative value that does not exceed the width of
an object of the type that would be specified were the colon and expression
omitted. If the value is zero, the declaration shall have no declarator."

See also Section 3.14 memory location, paragraph #4 EXAMPLE.

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

[doug at cs dot dartmouth.edu]

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

Bug ID: 93278
   Summary: huge almost empty array takes huge time to compile and
produces huge object file
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  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 accordingly. Compile time varies by a factor of a
hundred on my 4GB desktop.

ELF allows sections to be incompletely initialized. Can't gcc exploit that?

I suspect this is not a new complaint, but the search terms I tried didn't find
it.

And I was amused to find that replacing "x"  with "\0" causes the inefficiency
to be optimized away.

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

[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] huge almost empty array takes huge time to compile and produces huge object file

[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
char a[1000] = "x";
int main(){ return 0; }

$ bin/gcc --version
bin/gcc (GCC) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ time /bin/gcc junk.c

real0m3.864s
user0m2.919s
sys 0m0.326s

$ ls -l a.exe
-rwxr-xr-x 1 DOUG DOUG 10158440 Jan 17 14:43 a.exe

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

[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
char a[1000] = "x";
int main(){ return 0; }

$ bin/gcc --version
bin/gcc (GCC) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ time /bin/gcc junk.c

real0m3.864s
user0m2.919s
sys 0m0.326s

$ ls -l a.exe
-rwxr-xr-x 1 DOUG DOUG 10158440 Jan 17 14:43 a.exe

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

[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(){ return 0; }
It even does so for a string of 1000 \0's. But not for one x.

--

It's  lamentable that a common feature--partially initialized arrays--can lead
to stratospheric compile time.

Apologies for wishfully misreading partial sections into the EPL spec.

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

[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 took a full minute to get to
that point.

If indeed there is nothing gcc can tell the assembler to fix this, I suggest
gcc file a bug report asking as to pass suitable instructions to the linker.
That will carry much more weight (and be better informed) than a ticket from
me.

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

[doug at cs dot dartmouth.edu]

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

Bug ID: 93474
   Summary: no warning for nonstandard bit field
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  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 int and unsigned int declarators.

gcc -Wall -Wpedantic -Wextra  does not report this
nonstandard usage.

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

[doug at cs dot dartmouth.edu]

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

Bug ID: 93476
   Summary: int bit fields waste space
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: 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 and not portable.

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

[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

[doug at cs dot dartmouth.edu]

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

--- Comment #56 from doug mcilroy  ---
(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 character. GCC's
convention of including in the end-of-line indicator any white space that is
preceded by a backslash conforms, though it may be a surprise.

The surprise is perversely out of sympathy with the raison d'etre of the
standard--maximal portability. It is incompatible with the most direct (and
historically prior) implementations, wherein the end-of-line indicator is
simply a new-line character.

A suitable fix is to warn when white space occurs in an end-of-line indicator.
This will break no code that GCC currently compiles, yet draw attention to the
nonportable construct.

Here is what the C11 standard says about the end-of-line indicator:

5.1.1.2
Physical source file multibyte characters are mapped, in an implementation
defined manner, to the source character set (introducing new-line characters
for end-of-line indicators) if necessary.

5.2.1 paragraph 3
In source files, there shall be some way of indicating the end of each line of
text; this International Standard treats such an end-of-line indicator as if it
were a single new-line character.