https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #15 from Bogdan ---
People can still comment, it's part of the process. But in a case like this I
would say that it is safe to assume this proposal will stick. It literally just
allows to optionally add flags, which current already i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #14 from Jonathan Wakely ---
Isn't there a 30 day period for comments?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #13 from Bogdan ---
(In reply to Jonathan Wakely from comment #12)
> Suspending while OP's posix submission is processed:
> https://www.austingroupbugs.net/bug_view_page.php?bug_id=1925
I forgot to report back here after opening tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #11 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #8)
> IMNSHO it is POSIX that should be fixed. Clearly they've added a
> requirement there that doesn't match what the compilers actually do (GCC,
> clang, ICC (bo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #10 from Bogdan ---
Actually, EDG seems to have a GCC compatibility mode on godbolt where it
doesn't use the #line format. I haven't tested to see whether it prints flags
or not, just wanted wanted to correct that bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #9 from Bogdan ---
MSVC and ICC do not follow POSIX whatsoever. Everything from default paths to
command-line options is different there so I don't think these count. As for
EDG, that's true but there is no common ground between its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #7 from Bogdan ---
I came back to this and noticed it's still marked as unconfirmed. I could
potentially submit a patch. I am curious whether it's because you are unsure of
the direction you wish to take, in which case I won't need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #5 from Jonathan Wakely ---
Ah no, it looks like GCC only emits a line in that format for the main source
file, not for the included headers. So maybe GCC could just emit one extra
line, and not remove anything from the current outpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #6 from Bogdan ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Bogdan from comment #2)
> > GCC does use the options specified in the standard.
>
> I think it would be more accurate to say that the standard specifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #4 from Jonathan Wakely ---
(In reply to Bogdan from comment #2)
> GCC does use the options specified in the standard.
I think it would be more accurate to say that the standard specifies the
options that GCC (and traditional UNIX c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #1 from Jonathan Wakely ---
POSIX is talking about the 'c17' utility, not a command called 'gcc'. I don't
think GCC claims to be equivalent to 'c17'.
Any 'c99' or 'c17' utility you have is not part of upstream GCC but is
installed b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #3 from Jonathan Wakely ---
(In reply to Bogdan from comment #0)
> 1. If those numbers at the end are unimportant, maybe just strip them from
> the output. I'm not even sure what they represent.
See the documentation:
https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753
--- Comment #2 from Bogdan ---
Yes, distributions often use an alias where c99 or c17 will actually be GCC
using the appropriate --std option. But it seems reasonable to try to keep
close to the standard whenever there is a good technical reason
15 matches
Mail list logo
