[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.

[mtewoodbury at gmail dot com]

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

--- Comment #4 from Max TenEyck Woodbury  ---
I think there is a misunderstanding here...

These patches, when I submit them, will add a new warning option.  It is not
appropriate to add this to the normal "unused-value" warning because the
situation being diagnosed has a side effect that is important.  In fact you do
not want to see this warning in almost all circumstances.  It becomes important
only when enforcing -very- pedantic stylistic rules and when abusing the
definition of the prefix and postfix operators in C++.  I repeat -- this is a
warning option you do -not- want to turn on under normal circumstances.  It is
also inappropriate to conflate this diagnostic with the usual 'unused value'
diagnostic; they are -not- equivalent.  On the other hand, under rare
circumstances, this option could provide vital information.

The patches, again when submitted, document the problem in several places.  The
most important is in the gimplify module where the postix operator is converted
to a prefix operator under certain specific conditions.  This transformation is
-not- under the control of any optimization option; it is -always- done. 
Situations where you could change this so that you -can- control this
optimization, which I am -not- recommending, need to be identified first and
would stress the optimization system in ways it has not been stressed before. 
The patches, when submitted, would add that identification capability.  Before
actually changing the code generator, there should be an investigation of what
impact the change would have.  These patches, when submitted, would provide
that information.  All the other places where this situation can be identified
simply ignore the problem.  Part of the patch set, when submitted, will include
adding diagnostics in those places.

That brings us back to comment 2.  This is a new option and it adds at least
one and possibly more than one diagnostic messages that will need translation. 
While I can figure out what the English text of these messages should be, I am
aware that changes to the message translation infrastructure should be made
when the new messages are added.  I am -not- conversant with that procedure.  I
am looking for directions on how to add new messages into the translation
infrastructure.  I want to provide the information needed to start the
translation process as part of the patch submission.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #35 from Max TenEyck Woodbury  ---
True, none of the specifically listed maintainers have commented on
this version of the patch.  There are three people listed and a
general reference to all C and C++ front end maintainers.  It is
possible that they are not even aware of this discussion.

You are -not- listed specifically as a libcpp maintainer, only as a
general C front end maintainer specializing in soft-fp, i18n,
documentation and option handling.  On the other hand your name does
appear in the libcpp ChangeLog and I presume jsm28 is your committer
ID.  Your code looks good in general.

I do appreciate your helping me clarify my arguments.  I have indeed
been sloppy in my phrasing on more than one occasion.  On the other
hand, you have -not- addressed the main reason for adding this change:
this alternate implementation of #line __LINE__ is useful while the
current implementation is not.  As noted in an earlier comment, it
could -help- address at least two other issues currently being
discussed in other reports.

On 10/26/17, joseph at codesourcery dot com  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
>
> --- Comment #34 from joseph at codesourcery dot com  dot com> ---
> None of the other preprocessor maintainers have commented on this bug in
> the past four years to disagree with my view of the natural identification
> of the current line for this __LINE__ token.  Unless any comment soon I
> think we can take there to be consensus on my interpretation, i.e. that
> this is INVALID and the existing interpretation is the most appropriate
> one.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #33 from Max TenEyck Woodbury  ---
The way it is currently implemented by GCC makes #line __LINE__ a
useless construct.  The form where subsequent line numbers remain
unchanged is very useful.  From the literature, that was the way it
was expected to work.  In THAT sense it is more portable.

I have had occasion to write C like pre-processors more than once.
When coded to collect the entire directive and then dispatch on the
directive keyword, the natural outcome for #line __LINE__ was to leave
the subsequent line numbers unchanged.
That falls out naturally if you code the specifiction for identifying
directives following the standards as a separate step.  It is only
when you merge the directive collection, tokenization  and
interpretation steps that you get an interpretation of #line __LINE__
that changes subsequent line numbers.

On 10/25/17, joseph at codesourcery dot com  wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
>
> --- Comment #32 from joseph at codesourcery dot com  dot com> ---
> The evidence from the DR discussion is that it's the *less* portable
> interpretation - that none of the implementations tested behaved as you
> suggest.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #31 from Max TenEyck Woodbury  ---
The request in 82176 would remove all file components except the
filename itself.  It also puts control of the option on the comand
line which would usually mandate its use for all modules in a project.
It is a strong departure from the standard's requirement.  The request
in 70268 seems to be fairly similar if less draconian and a bit more
complex in its implementation.  Both could be resolved by consistantly
including #line ... "" directives near the
begining of the modules.  That is a good practice since it also
provides a natural internal source code identification of the modules.
The main objection to doing that would be the problem of maintaining
the value of '...'.

And that brings us to this request.  This is not that much of a
strain on the interpretation of what counts as the line number.  The
interpretation of __LINE__ is actually unchanged in the more recent
patch.  This simply changes -when- the substitution takes effect.  The
updated standard enumerates two times the expansion can be done.  This
change specifies that the more portable interpretation be used.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

--- Comment #29 from Max TenEyck Woodbury  ---
While #line is indeed most commonly used by code generators, it can be used in
other contexts.  The most common other use is to remove sensitive and useless
file name components from the file specification.  Since there are bad actors
who might be able to abuse that sensitive information, that use is becoming
more critical.  While it is possible to hide that information without using
#line __LINE__, doing so introduces potential code maintenance issues. 

If you look at the old programming literature, you can find places where the
use of #line __LINE__ is assumed to not change subsequent line numbers.  I
think allowing #line __LINE__ to change subsequent line numbers makes this
construction unusable for normal purposes.  If #line __LINE__ preserves
subsequent line numbering, I find it is much easier to write safe portable
code.  If you look at the question from a portability point of view, the
natural choice is to have #line __LINE__ leave subsequent line numbers
unchanged.

When I said 'not robust' I meant that it was fairly easy to frustrate the check
as implemented.  This might be considered a good thing if you want the
alternate behavior; you can still get the alternate behavior by hiding the use
of __LINE__ behind another macro, but then you would be back in the unspecified
behavior realm.  While it is possible to change the implementation to detect
hidden __LINE__ references, I found that that requires adding a communication
path between the macro.c module and the directives.c module.  I played around
and found that to be unnecessarily complicated.  It is almost always better to
leave the coder a choice of behaviors, so being able to hide the use of
__LINE__ if the user wants to should be considered a 'good thing'.

Joseph: Do you know of any existing cases where this change would cause user's
problems?  The existing behavior has caused me enough trouble that I now use a
patched version of GCC in place of any of the usual binary distributions.

[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury  changed:

   What|Removed |Added

  Component|tree-optimization   |c

--- Comment #1 from Max TenEyck Woodbury  ---
I found the relevant code in the "gimplify" modules.  I could submit patches
for this now but it adds messages that will need translation and I am not
certain on the way that should be handled.

It turns out the problem described gets fixed very early and never gets to the
optimizer, but could have an impact when certain c++ features are abused...

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #27 from Max TenEyck Woodbury  ---
The existence of examples in older programming literature indicates that the
proposed interpretation where #line __LINE__ did not change subsequent line
numbers was considered useful.  I have found this very useful myself.

The conclusion that this is not a "BUG" is correct, but it it is a useful
feature and it would make GCC easier to use.  GCC specifies the unspecified in
many places and it could do so here.  It is actually fairly easy to implement
as the patch I submitted to patches-gcc shows.

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #12 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Just because the compiler is ALLOWED to discard the r-value as part of the
OPTIMIZATION process, does NOT mean that a program that calls for an EXTRANEOUS
temporary is without defect.  Such a program IS trivially defective and
removing that kind of defect should be allowed without comment.  Such changes
may want to cite an open bug report as their justification.

While you are arguing about what the compiler does, the issue here is about
what the source code calls for.  The compiler can and should clean up such
defects, but it should not be called upon to do so.  THAT i the issue and you
are NOT addressing it.

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #10 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
There is no VARIABLE, just a TEMPORARY r-value like  all the others that hold
intermediate results.

Also, the LANGUAGE semantics has the operator produce a result, an r-value,
that
has to be represented in some manner, that is, it has a store of some kind.
The machine code generated without optimization is required to put that result
into the store before incrementing the specified l-value. (sub-clause 6.2.5.4)
Optimization is allowed to, but not required to, remove such operations as long
as the change produces no detectable change in the program's results.

Now, stop misrepresenting the standard.  It makes your other pronouncements
less credible.

To go over this again, if a piece of code specifies a postfix operation
conceptually, the original value is stored somewhere.  That stored value is
then
discarded.   Those steps are extraneous and the code would be conceptually
cleaner without them.  As such, their present is a defect, a trivial defect,
but
still a defect.  Using the prefix operator in its place improves to code, again
trivially, but it does improve it.  Such changes may want to cite something as
justification for the change.  This report is such a justification.  Until all
such defects have been removed, it should stay open.

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---
   Severity|minor   |trivial

--- Comment #8 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Re: Manuel López-Ibáñez

Yes, as soon as I feel that my efforts will not be ignored, as they have been
so far...

Re:  Jakub Jelinek

You admit that different 'tree codes' are generated, so there is a difference
between the two sequences.  You further admit that -O0 does do some
optimization, otherwise the machine code emitted would store and discard
the temporary value because that is what the language standard says should
happen.  While this is quite trivial in practice, it shows that you place
your opinion over the exact semantics called for by the standard and lack
the ability to see that.  That is distinctly disturbing.

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #4 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
There is another semantic element to the a++ operator; the temporary where the
original value of the variable is stored until used.  You are either unaware of
this aspect of the language or are deliberately ignoring it.

This has NOTHING to do with overloading the postfix operators.  This is part of 
the basic definition of the C language.  In fact, C does NOT have operator
overloading and the majority of GCC is written in C, not C++.

Without optimization, this temporary store is allocated and set even if the
value is never used.  The fact that to value is not used and need never be set
is detected during optimization.  The fact that the temporary store is then
never
used and can be eliminated requires further optimization.  All this extra work
is unnecessary in well written code.  That makes the use of a++ where ++a will
do a minor coding defect.  This bug report provides a referent for changes that
improve that kind of defective code.

Since there are hundreds, if not thousands of instances of this defect in the
GCC code and there is no urgency in correcting these defects, this bug will
only
get resolved slowly.  Closing it for invalid reasons does the community a
disservice.

[Bug c/59193] Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
The practice is very common in C (and the GCC code) and is NOT peculiar to C++.

The creation of temporary values that are never used is a waste of resources
and, even when removed by the optimizer, represent an, admittedly minor,
defect.
This may be a minor point but it is NOT controversial.  Also, it is not really
a
matter of style.  Your lack of insight on this is somewhat disturbing.  Marking
the argument as INVALID is just plain wrong.  It should be left open to provide
a reference for patches that address this problem.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #23 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #22)
 On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote:
 
  The elaborate description of the different forms of the '#line' (and other) 
  directives makes it clear that pp-token expansion is not to take place 
  until after the end-of-line for the directive has been seen.  
 
 The question is not when it takes place, it's what the current token is 
 when it takes place, because line number is defined in terms of the 
 current token rather than the time of expansion.

If that is what they meant, they would have said something like the line 
number when the __LINE__ token is seen', but they say 'current line' and 
define 'current line' elsewhere.

 I think the current token is clearly __LINE__ on the #line directive.  

But the standard says 'current line'.  It says nothing about 'current 
token' in this context.

 Consider the case where 
 there are no more tokens after that directive, just the newline at the end 
 of the directive (you can easily construct cases where the value of 
 __LINE__ in such a context affects the validity of the program, by 
 concatenating it with something else to form what might or might not be a 
 macro name) - it's not possible the the current token to be anything on a 
 subsequent line, because there aren't any subsequent tokens.  So the 
 current token has got to be __LINE__ (or maybe, in the more complicated 
 cases I referred to, something else on the #line line).  That's different 
 from
 
 macro
 (
 __LINE__
 )
 
 where all of the tokens from macro to ) are involved in expansion at 
 the same time and you can argue for any of macro, __LINE__ and ) as 
 being the current token.  (It's also different from the cases where 
 backslash-newline appears in the middle of __LINE__ so the question is 
 whether to the current token means to the start of end of that token.)
 
You are arguing about macro expansion again.  Macro expansion is an 
immediate process and, as you pointed out, somewhat ambiguous.  The case 
being argued here is the expansion of pp-tokens in directives where their 
expansion is delayed until after the form of the directive has been 
established.

  Accepted usage is for '#line __LINE__' to leave the line numbering 
  unchanged.  
 
 It's quite possible there's a common bug among multiple other 
 implementations where it does leave the line number unchanged, but I'm now 
 tending to that actually being a bug in those implementations rather than 
 an ambiguity in the standard.  That is, there is no way in the standard to 
 leave the line number unchanged, and no defect, and it might be better to 
 wait until a revision process for a new major C standard version is 
 underway them submit a proposal for e.g. #line with just a filename and no 
 line number (or a #file directive - either would be a reasonable way of 
 achieving that goal).

So everyone else is wrong?

Realty, you should consider what the users of the language need to be able 
to do.  There is need for an easy way to change __FILE__ without messing 
up the line number sequence.  '#line __LINE__ ...' is fairly obviously that 
mechanism and the extra verbiage in the standard is a fairly obvious 
attempt to accommodate that need.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #25 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #24)
 ...
 
 I don't believe the standard makes any such attempt to accommodate such a 
 (marginal) need;

GAG! Without this, a number of problems associated with externally developed 
development environments are very difficult, if not impossible, to manage.  
It is ultimately a portability problem; there must be a way to identify the 
source for the code that is independent of the particulars of the build 
environment and at the same time not change the line sequencing without forcing 
the code maintainers to maintain a count of code lines.  That puts this problem 
squarely in the middle of the domain of problems that language standards were 
developed to address!

  the wording is simply the most natural way to describe 
 the possible forms of #line directive within the style used by the 
 standard.  Note there are no examples in the standard to indicate any 
 particular intent regarding corner cases of #line or __LINE__.

The 'natural' way to say this would be much closer to the way it was expressed 
in KR.  Someone went to a great deal of trouble to rephrase it for some 
reason and, at least in my opinion, that reason included the interaction of 
__LINE__ and directives.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #21 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to Joseph S. Myers from comment #20)
 Suspending pending a DR since I think the present code is correct and while
 the standard is ambiguous I think the interpretation here strains the
 wording of the standard.  I'd proposed to close this if a DR (or other WG14
 document) isn't under consideration at the Parma meeting of WG14.

A 'DR' is not necessary and is unlikely to be submitted.  The ambiguity
referred 
to is in the expansion of macros, not in the processing of directives.  

The elaborate description of the different forms of the '#line' (and other) 
directives makes it clear that pp-token expansion is not to take place until 
after the end-of-line for the directive has been seen.  

Accepted usage is for '#line __LINE__' to leave the line numbering unchanged.  
Any other interpretation would require some form of expression evaluation in 
order to leave line numbering unchanged; a possibility that has been rejected.

[Bug c/59193] New: Unused postfix operator temporaries

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193

Bug ID: 59193
   Summary: Unused postfix operator temporaries
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

The use of postfix operators without using the value in their inherent
temporary store is a mild abuse of languages that provide those operators. 
Compilers convert them to prefix operators as part of their optimization
process, but they waste space in automatic storage when the optimization is
insufficiently deep to detect them.

Reading the code in this project turns up hundreds of instances of this poor
practice.  Please convert these to the proper prefix operator form.

(More to the point, please accept patches that fix these problems without
abuse!  I have several sets that I will submit if there are no strong
objections.)

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #18 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #16)
 On Mon, 4 Nov 2013, mtewoodbury at gmail dot com wrote:
 
  Could you all give me some idea on how soon this might be applied?
 
 At some time after seeing this on gcc-patches, I or another preprocessor 
 reviewer will review the patch (after checking that the FSF copyright.list 
 file reflects receipt of the assignment, if the patch seems big enough to 
 need it).

it's been a couple weeks.  Any progress?

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #17 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
It might be better to put the CUR__LINE__ definition in 'internal.h' instead of
in 'cpplib.h'.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #15 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Could you all give me some idea on how soon this might be applied?

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #14 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Created attachment 31125
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31125action=edit
Patch to postpone __LINE__ evaluation to the end of a # line directive.

Patch includes changes to 2 source code files, a header and the line4.c test
case.

make bootstrap OK.

make -k check of patched and un-patched code matches except for time stamps.

Formal release of changes copyright to FSF granted.

Max TenEyck Woodbury

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #9 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #8)
 Thanks for working on this bug.  http://gcc.gnu.org/contribute.html 
 describes how to submit changes (including testcases etc.).

Thank you for the pointer.

As I said, I have a patch.  The patch includes an addition to the line4.c test
case.

What is delaying this is my testing of the change.  Specifically, I am
configuring, building bootstrap and building check for both the patched and
un-patched code then comparing the results.  The comparison was throwing up
many spurious differences due entirely to the slightly different directory
names I was using in the configuration process.  I think I now have those
details worked out, but there are still spurious differences due to temporary
file names, but I think that I can get past that.  It just takes hours for the
builds to complete...

Argh! -- someone put in a patch that I didn't track properly.  More details to
account for and another round of delays.  It'll be done when it's properly
tested.

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #11 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #10)
 On Mon, 28 Oct 2013, mtewoodbury at gmail dot com wrote:
 
 (Stop the 'we'!  Name or enumerate the group involved please.)
 
 Well-established consensus among the GCC maintainers about what sorts of 
 features are appropriate to add and what sorts of features cause problems.  
 It's not as if the preprocessor has lots of active development with 
 disagreement among its developers about what should go in; it's rightly 
 pretty stable in terms of features with only occasional bug fixes or new 
 features (mainly coming from WG21) needed.

I think I understand consensus, but I only hear your voice here, not the voice
of a multitude.  You may be part of the consensus you speak of, but you are not
its entirety.  In that, you overstate your case.  If you had said 'As an old
hand at this' instead of 'We', I would not have objected.

 But that bug was filed on the wrong component and has languished for YEARS
 as a result of that miss-filing.  It looks like no one has looked at its
 problem seriously...
 
 That maintainers wouldn't necessarily object to the addition of a feature 
 doesn't mean any maintainer has any interest in implementing it.  There 
 are lots of bugs filed suggesting some vaguely reasonable new feature 
 that was of interest to the submitter but not of sufficient interest to 
 anyone wanting to implement it (but not rejected either, because the 
 feature might well be accepted if implemented).

I have worked for companies where there was a formal definition of roles, and
what you describe is something from that world.  On the other hand, I believe
open-source projects like GCC have less authoritarian structures and that such
decisions are much less formal.  In other words, membership in 'maintainers' is
consensus based on merit, not the open and shut rule of corporate structure.

On the other hand, 'unconfirmed' is really not a status that applies to
requests for enhancements.

 (In reply to jos...@codesourcery.com from comment #8)
 (And for recursion, even specification at the level of standard text might 
 leave something to be desired; I'd think specification at the level of 
 X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
 name generated in macro expansion can itself be expanded, would be desired 
 as well.  Not that I think recursion is appropriate to include in GCC's 
 preprocessor unless it's standardized.)
 
 Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?
 
 Yes.
 
 If so, I'll need to go over it fairly carefully.  A quick review left me with
 the impression that determining when to allow additional expansion involved a
 bit of hand-waving.
 
 The point is it defines, through the pseudocode functions, exactly how 
 hide sets (the sets of macros for which expansion is currently suppressed 
 because it would be recursive) are determined - it's the pseudocode that 
 you need to study more than the surrounding text.  And it's this algorithm 
 that GCC is intended to follow.  So anything allowing new forms of 
 recursion needs to explain how this algorithm is affected.

As I said, I need to go over it carefully.  It is obviously pseudo-code and
both the code and the explanation deserve careful study.  Where it has built in
the no-recursion rule was not quite obvious at first glance, thus the remark
about hand waving.  Again, I need to study it carefully, and I have not done
that yet...

On the other hand, your summary adds vary little to what the pdf contains...

 
 possible.  With the proper hedges in place it would have the same kind of
 power that variadic functions posses.  As things currently stand, variadic
 macros have apparently arbitrary limitations that reduces their usefulness.
 With an intelligent design, this would be where the language aught to be
 going.
 
 I suggest that the language ought not to be going in the direction of 
 adding much power to the preprocessor at all - that expressive power 
 belongs in the language, not the preprocessor (and that it's fine to use 
 programs to generate C program text if neither is convenient for what you 
 want to do).

That is a very old argument and fallacious on its face.  The preprocessor is
part of the language.

External code generators create new languages.  Those new languages will never
get the level of acceptance that 'C' has.  Each generator represents an
additional layer in a project's development and requires an investment that has
to be justified.  Further, that kind of development calls for skills that many
projects simply can not justify.  Adding an external code generator to an
implementation can also preclude that implementation from consideration for
legal reasons while extending 'C' by using macros would not run into the same
bar.  Po-poing the preprocessor this way just isn't

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #11 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to Manuel López-Ibáñez from comment #10)
 
 If you are planning to do sporadic GCC development, it may be worthwhile to
 ask for an account in the Compile Farm http://gcc.gnu.org/wiki/CompileFarm
 
 (I could have never done any GCC development without it.)
 
 For building GCC and testing patches there are several scripts in contrib/.
 I also have my own:
 http://gcc.gnu.org/wiki/
 ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFiledo=viewtarget=gccfarming

Thank you, I will look info all of that.  My own resources have limits; when it
comes to testing generated code on many architectures, I will definitely need
such resources.

I will also look at the scripts after I have a bit better handle on exactly
what kinds of problems testing raise.  I was mildly surprised that changing
line numbers in headers produced differences in what is obviously generated
code.  Without having seen that buried deep in the build directory tree, I am
sure I would not appreciate any scripts that interact with that aspect of the
build process.

I am at the base of the learning curve here.  I have some climbing to do before
I will be able to make significant contributions...

'make check' on the un-patched sources in progress.  Later...

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #13 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #12)
 
 I was agreeing with Andrew.  Jason, the other maintainer likely to review 
 libcpp patches, hasn't commented on this issue.  (There are plenty of 
 others who *can* review such patches but are unlikely to do so in 
 practice.)

Ahh. so 'We' is you and Andrew...  OK.

 That someone doesn't reply to some point (if they read it) only indicates, 
 at most, that they do not have anything to add that has not already been 
 said adequately somewhere in the totality of the discussion, rather than 
 whether they agree or disagree.

Yes, but it would be very helpful if there is some indication that the
appropriate people have at least looked at the submission.  Something far short
of a commitment to do anything, but at least an acknowledgment that the ideas
have not been rejected out-of-hand.  'CONFIRMED' would do nicely.

 But that bug was filed on the wrong component and has languished for YEARS
 as a result of that miss-filing.  It looks like no one has looked at its
 problem seriously...
 
 That maintainers wouldn't necessarily object to the addition of a feature 
 doesn't mean any maintainer has any interest in implementing it.  There 
 are lots of bugs filed suggesting some vaguely reasonable new feature 
 that was of interest to the submitter but not of sufficient interest to 
 anyone wanting to implement it (but not rejected either, because the 
 feature might well be accepted if implemented).
 
 I have worked for companies where there was a formal definition of roles, and
 what you describe is something from that world.  On the other hand, I believe
 open-source projects like GCC have less authoritarian structures and that
 such decisions are much less formal.  In other words, membership in
 'maintainers' is consensus based on merit, not the open and shut rule of
 corporate structure.
 
 Bugs languish because the maintainers - and other developers who might fix 
 them - are individuals, there is indeed no formal structure as regards 
 reviewing bugs or assigning people to fix them, and each individual who 
 looked at it was not interested in implementing the feature / fixing the 
 bug.  Misfiling is only a minor part - it could be relevant, if someone 
 had gone through all the preprocessor bugs, implementing lots of things, 
 and missed that one because it wasn't a preprocessor bug - but it so 
 happens no-one has been active in that way with preprocessor bugs lately.
 
 Maintainers are appointed by the Steering Committee (based on merit) (but 
 someone's views on a patch or feature can be relevant and useful without 
 them being a maintainer who can approve the patch).

That matches what I understand most open-source projects do.  Again, what is
missing is some indication that the submission has not fallen into oblivion.

 As I said, I need to go over it carefully.  It is obviously pseudo-code and
 both the code and the explanation deserve careful study.  Where it has
 built in the no-recursion rule was not quite obvious at first glance, thus
 the remark about hand waving.  Again, I need to study it carefully, and I
 have not done that yet...
 
 No-recursion is built in through hide sets - that is, each token has at 
 each time an associated set of names of macros that cannot be expanded if 
 encountered when expanding that token.  Thus, when expanding a macro M, 
 the name M is added to the hide sets of the tokens in the expansion before 
 they, and the rest of the input, are considered for reexpansion (for 
 details see the pseudocode).
 
 Some discussions of C macro expansion use the term blue paint when 
 discussing the rules for recursion.
 
 Your proposal is apparently something that means a macro is no longer in 
 or out of a hide set, but in a state meaning whether it can be expanded 
 depends on the number of parameters.  Maybe the hide sets will need to 
 contain pairs (macro, number of arguments), or something like that, 
 instead of just macro names.

Yes, paint the number of parameters as well as the spelling.  It was precisely
the lack of specificity of what put something in the 'hide set' that I was
going to have to study.  A demonstration that the resulting expansion is
bounded if the definition is extended would need to be added to that report.  I
could probably do it but it would take me a little while and quite a bit of
effort to get back into the mental mode to do it right.  Step 7.

Yes, it would be pairs, or triples.  Spelling, variadic flag and parameter
count with all spellings of a variadic macro hidden if its parameter count
matched or exceeded the current limit.  Additional expansions would temporarily
lower the limit.  Looks doable, even a bit fun...  Late undergrad or masters
level problem, not PhD, definitely not novice.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #13 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #12)
 On Wed, 30 Oct 2013, mtewoodbury at gmail dot com wrote:
 
 Thank you, I will look info all of that.  My own resources have limits; when
 it comes to testing generated code on many architectures, I will definitely
 need such resources.
 
 A fix for this particular bug should only need testing on one 
 architecture.  It's not like changes to the register allocator that are 
 likely to have architecture-specific issues.

Yes.  'make -w -k check' on the base configuration is still in progress. 
There's enough stuff wrong with the base that I need a log to check against. 
Using the compile farm here would add a queuing delay, slowing the process
further.

Oh, and could you mark this bug as either 'confirmed' or 'in-progress'?

I do have another bug (58884) that will need those resources if I am the one
that tackles fixing it...

Later...

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #6 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
I have checked the code in libcpp.  The __VA_ARG_COUNT__/__VA_ARGC__
implementation looks quite feasible.  The heaviest impact looks to be new and
revised error messages and their translation.

I started to look at the possibility of doing actual recursion but ran out of
steam temporarily.  It might be necessary to copy hashnodes or, worse yet, add
a field to the hashnode structure.  Later...

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #9 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #7)
 On Sun, 27 Oct 2013, mtewoodbury at gmail dot com wrote:
 
 That has not always stopped you all in the past, but that is really neither
 
 We have plenty of experience dealing with the consequent problems of the 
 old habit of adding extensions because they seemed like a good idea at the 
 time (or because a feature was supported in some language other than C, 
 and there used to be an idea that GNU C should support all features of 
 GCC's internal representation that could be accessed from any language 
 supported by GCC) without any real effort in designing them at the level 
 of precise proposed standard text to specify the feature.  Based on that 
 experience, the bar for new extensions is much higher now.
 
 Unlike recursion, __VA_ARGC__ seems like something reasonably well-defined 
 and in accordance with the spirit of the preprocessor and unlikely to be 
 problematic as an extension - but as you note, there's already a separate 
 bug for it.

(Stop the 'we'!  Name or enumerate the group involved please.)

But that bug was filed on the wrong component and has languished for YEARS as a
result of that miss-filing.  It looks like no one has looked at its problem
seriously...

(In reply to jos...@codesourcery.com from comment #8)
 (And for recursion, even specification at the level of standard text might 
 leave something to be desired; I'd think specification at the level of 
 X3J11/86-196, the algorithm GCC tries to follow regarding when a macro 
 name generated in macro expansion can itself be expanded, would be desired 
 as well.  Not that I think recursion is appropriate to include in GCC's 
 preprocessor unless it's standardized.)

Hmm.  Is X3J11/86-196 the pdf that shows up at the top of a Google search?
If so, I'll need to go over it fairly carefully.  A quick review left me with
the impression that determining when to allow additional expansion involved a
bit of hand-waving.

So, the description of what should expanded has to be carefully worked out
before any implementation is released.  Indirect recursion would be part of the
package.

I am trying to look at the reasons behind the specifications in the standard. 
In the case of 'no recursion' it was obvious that simple recursion was a snake
eating its own tail and as originally specified could not be anything else. 
With the addition of variadic macros, a self limiting form of recursion becomes
possible.  With the proper hedges in place it would have the same kind of power
that variadic functions posses.  As things currently stand, variadic macros
have apparently arbitrary limitations that reduces their usefulness.  With an
intelligent design, this would be where the language aught to be going.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #7 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
I have a patch written and I am testing it now.

What steps (other than posting it here when the tests are done) need to be done
to get it applied?

[Bug preprocessor/58887] Allow recursion in varadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #2 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Eventually, that is where this will go, but the committee is MUCH more
receptive of suggestions that have an implementation that people have had a
chance to play with.  GCC is one of the platforms where new ideas get tested. 
So, I believe it needs to be considered here.  

While I have not had news group access in recent years, I did watch and made
comments on the committee's action for more than a decade and it is implemented
extensions that get taken most seriously.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #6 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to Andrew Pinski from comment #5)
  Simply to make identification host independent.  The fact that my
 projects are stored on '/VOL10' on one of my machines and '/DATA0.2'
 
 This sounds like a bug in how you are compiling the sources.  Also there are
 options inside GDB to transpose paths to the path on your machine.

It is precisely because the identification varies with the way to file name is
passed to the compiler that makes setting __FILE__ desirable.  The compiler
invocation details are not always under the developer's control.  Tools like
'make', 'autoconf' and 'automake' dictate the forms.  So, I have fairly strong
objections to calling it an external procedural BUG.  The issue REALLY is that
__LINE__ gets messed up; leave discussions of how the compiler is invoked out
of it.

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #4 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #3)
 We take the view that the preprocessor is deliberately meant to be limited 
 and overly complicated features in it would be contrary to the spirit of 
 C.  Of course if they are introduced in the standard we need to implement 
 them, but otherwise this proposed feature seems inappropriate.

That has not always stopped you all in the past, but that is really neither
here nor there and you use the royal 'we' to boot...  Speak for yourself. 
(ignore that; I'm in a sour mood and you just pushed one of my hot buttons.)

Where option 1 may be a little complicated to implement, option 2, while less
effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe
__VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__.

See also Bug 33877.

[Bug preprocessor/58887] Allow recursion in variadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

--- Comment #5 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
(In reply to jos...@codesourcery.com from comment #3)
 We take the view that the preprocessor is deliberately meant to be limited 
 and overly complicated features in it would be contrary to the spirit of 
 C.  Of course if they are introduced in the standard we need to implement 
 them, but otherwise this proposed feature seems inappropriate.

That has not always stopped you all in the past, but that is really neither
here nor there and you use the royal 'we' to boot...  Speak for yourself. 
(ignore that; I'm in a sour mood and you just pushed one of my hot buttons.)

Where option 1 may be a little complicated to implement, option 2, while less
effective, is a real simple addition: define __VA_ARG_COUNT__ (or maybe
__VA_ARGC__) with the same kind of restrictions that apply to __VA_ARGS__.

See also Bug 33877.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |major

--- Comment #4 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Why is this important?

1)  There must be a way to modify the '__FILE__' value without messing
up the '__LINE__' value.  A 'Google' shows that the expected way to
do this is:

# line __LINE__ new-__FILE__-value

but with this bug, the __LINE__ value gets messed up and all 
subsequent diagnostics are off by at least one.  It also makes
debugging more difficult if not impossible.

Now, why change the '__FILE__' value?

Simply to make identification host independent.  The fact that my
projects are stored on '/VOL10' on one of my machines and '/DATA0.2'
on another only confuses any trouble reports.  What is important is
that the file is 'myproject/configure.c' (or whatever).

2)  Similarly, adding multi-line comments to the '# line __LINE__ ...'
directive should NOT mess with the line numbering.

3)  Why not use a specific value in place of '__LINE__'?

Because that embeds a maintenance problem that should not be there
into the source.  If something gets added before the '# line n ...'
directive, then n has to be updated.  If the source is 'generated'
by some tool, this is reasonable, but it is NOT reasonable for base
level source files.  Similarly, there should be a freedom to edit
the comment without having to play with the line number.

[Bug preprocessor/58887] New: Allow recursion in varadic macros?

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887

Bug ID: 58887
   Summary: Allow recursion in varadic macros?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

With good reason, recursion in macro definitions is suppressed -- it leads to
infinite expansion loops and subsequent software failure, HOWEVER

Recursion of varadic macros where the number of arguments in the argument list
decreases would necessarily stop expanding when the argument list became empty.

It would be nice if this could be handled easily, but doing it requires an
extension -- something beyond what the standard calls for/allows.

I can see two ways to do this -- there may be other ways as well:

1)  Allow recursion as long as the new invocation has fewer arguments
than the current invocation.

This is the general solution, but should only be allowed if some
special mode is set, such as a command line switch or 'pragma'

2)  Make the number of arguments easily available.

There is a way to write a varadic macro that return a count of
its arguments, but it has severe limitations -- it will necessarily
have an upper bound on the number of arguments it can count and
that limit will be half the implementation limit the preprocessor
puts on the number of arguments that can be passed to varadic
macros.

It would help if there were a predefined macro that did this
counting and did not have the upper bound limitation.

Once the argument count is available, it is possible to construct
the name of a macro for the correct number of arguments and have
those macros chain their expansion.

This solution is sub-optimal:  macros for each argument count have
to be defined, which means there will be an arbitrary upper bound
on the number of arguments handled and puts a strain on preprocessor
resources.

For this reason, solution 1 is preferable.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Max TenEyck Woodbury mtewoodbury at gmail dot com changed:

   What|Removed |Added

 CC||mtewoodbury at gmail dot com

--- Comment #2 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Grumble!

Modified testsuite/gcc.dg/cpp/line4.c to test __LINE__ use.  I think I
saw a stronger set of tests while 'googling' the problem.  I was a bit
short on understanding when I saw it, so I didn't mark it for study...

I've looked at the code that handles this.  It's in the libcpp tree.

Thw indentation is messed up.  '\t' used in many places WITHOUT consistant
tab widths.  I see spots with '\t' stops at 4 and at 8.  Indent width is
mostly 2.  Style is a bit mixed.  FOR MY OWN USE, I've cleaned this up.
The result is much more readable.

I tried a simple look-ahead hack, but no go.

Going the mild KLUGE route:  Use a special value to indicate the bad
value and emit it under special circumstances.

- define the special value CUR__LINE__ in include/libcpp.h (-1)
- modify state.in_directive to have a special value (2) when in the #line
  directive (in do_line).
- check for the CUR__LINE__ value at the end of do_line after flushing the
  tokens and use replace the special value with the current line number
  before doing the state change.
- in macro.c, __LINE__ processing, look for the special stat.in_directive
  value and return CUR__LINE__ if it has the special value.

Potential problem if someone uses __LINE__ to construct the file name.

Intrest?

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #3 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Turn off the special case immediatly after getting the number to
eliminate side effects...

[Bug tree-optimization/58884] New: OPTIONAL warning when a temprary value is created and not used.

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58884

Bug ID: 58884
   Summary: OPTIONAL warning when a temprary value is created and
not used.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

Please add the capability to warn when the temporary value created by postfix 
operators '++' and '--' are not used.  This should be OPTIONAL and disabled by 
default.

This is only an issue when NO optimization AT ALL is used, but does use a
little 
time and storage during optimization that could be better used improving the 
working code instead of coddling lazy programmers.

[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

--- Comment #1 from Max TenEyck Woodbury mtewoodbury at gmail dot com ---
Created attachment 31080
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31080action=edit
test case

Comment out the '#line' directives and it compiles without error...

[Bug preprocessor/58687] New: #line __LINE__ ... changes subsequent line numbers

[mtewoodbury at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687

Bug ID: 58687
   Summary: #line __LINE__ ... changes subsequent line numbers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mtewoodbury at gmail dot com

A preprocessor directive of the form '#line __LINE__ ... should NOT change the
line number.  That is '__LINE__' should evaluate to the number of the NEXT line
in this context.

If you read the standards carefully, __LINE__ should have a value equal to the
number of 'new line' characters seen by the phaee 1 translation plus one WHEN
THE SUBSTITUTION OCCURS (unless modified by previous #line directives).

When the subsituyion occurs is controlled by the parsing done in phase 4 of
translation.  Specifically, subsitution in preprocessing directives occure when
the specific form of the directive has been  formally identified AND that form
calls for pp_token aubstitution.  The form in this case is:

'#' 'line' pp_token+ new_line

Note that the terminating new line token has to have been seen BEFORE the
form is identifiad.  That means __LINE__ will normally have the line number of
the NEXT line in the file when the substitution occurs.  FURTHER NOTE that any
new line tokens in comments will also have been counted when the substiturion
occurs.

What is apparently happening instead is that the substitution is being made
BEFORE the particular form of the '#line' directive has been completely and
formally identified.  In other wordds you have folded the translation phases
togeather and botched up the carefully structured procedure with its
intentional delays in substitution set forth in the standard.