[Bug c/68994] New: GCC doesn't issue any diagnostic for missing end-of-line marker

[pponnuvel at gmail dot com]

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

Bug ID: 68994
   Summary: GCC doesn't issue any diagnostic for missing
end-of-line marker
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pponnuvel at gmail dot com
  Target Milestone: ---

Considering a source file created like this

$ printf "int main(void) {return 0;}" > test.c
$ wc test.c
 0  4 26 test.c
$ gcc -Wall -Wextra -pedantic-errors -std=c11 test.c
$ echo $?
0

(wc command reports 0 newlines)

C11 standard, §5.1.1.2, says

[..] A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character before any
such
splicing takes place.

The above code violates this constraint. But gcc doesn't issue any diagnostic
about it.

Compiled using gcc 5.1.1/glibc 2.21 on Debian.

[Bug c/68966] atomic_fetch_* on atomic_bool not diagnosed

[pponnuvel at gmail dot com]

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

Pon  changed:

   What|Removed |Added

 CC||pponnuvel at gmail dot com

--- Comment #7 from Pon  ---
Clarification needed about this change.

C standard says:

> None of these operations is applicable to atomic_bool.

I understand the "not applicable" as "because it's already an atomic type". But
does it also applicable to "plain" bool (_Bool) type too? GCC 6.1.1 with
-std=gnu99, GCC fails to compile and reports:

> error: operand type ‘_Bool *’ is incompatible with argument 1 of 
> ‘__sync_fetch_and_or’

for code that used to work with GCC 5.3.1. 

Comments from the testsuite:

> This is necessary because GCC expects that all initialized _Bool
> objects have a specific representation and allowing 
> atomic operations to change it would break the invariant.

and code:
> Those are not valid to call with a pointer to _Bool (or C++ bool)
> and so must be rejected.

suggest the change is deliberate for "plain" bool type (_Bool) too.
Does it mean the existing code that uses of these atomic intrinsics 
on plain bool type is buggy?

Obviously I can fix it by using an int/unsigned int instead
of _Bool or use atomic_bool in new code.
But my question is about GCC 6.1.1 breaking older code compiled
 using gnu99. I would appreciate a clarification on this.

Thanks.