iority: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #1 from Max TenEyck Woodbury ---
Created attachment 31080
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31080&action=edit
test case
Comment out the '#line' directives and it compiles without error...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Max TenEyck Woodbury changed:
What|Removed |Added
CC||mtewoodbury at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #3 from Max TenEyck Woodbury ---
Turn off the special case immediatly after getting the number to
eliminate side effects...
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 u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Max TenEyck Woodbury changed:
What|Removed |Added
Severity|normal |major
--- Comment #4 from Max TenE
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #2 from Max TenEyck Woodbury ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #6 from Max TenEyck Woodbury ---
(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 so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #4 from Max TenEyck Woodbury ---
(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 spiri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #5 from Max TenEyck Woodbury ---
(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 spiri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #6 from Max TenEyck Woodbury ---
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 starte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #9 from Max TenEyck Woodbury ---
(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 re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #7 from Max TenEyck Woodbury ---
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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #9 from Max TenEyck Woodbury ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #11 from Max TenEyck Woodbury ---
(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 invol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #11 from Max TenEyck Woodbury ---
(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/Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58887
--- Comment #13 from Max TenEyck Woodbury ---
(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 plen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #13 from Max TenEyck Woodbury ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #14 from Max TenEyck Woodbury ---
Created attachment 31125
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31125&action=edit
Patch to postpone __LINE__ evaluation to the end of a # line directive.
Patch includes changes to 2 sourc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #15 from Max TenEyck Woodbury ---
Could you all give me some idea on how soon this might be applied?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #17 from Max TenEyck Woodbury ---
It might be better to put the CUR__LINE__ definition in 'internal.h' instead of
in 'cpplib.h'.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #18 from Max TenEyck Woodbury ---
(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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #21 from Max TenEyck Woodbury ---
(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
> wo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #23 from Max TenEyck Woodbury ---
(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 '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #25 from Max TenEyck Woodbury ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVAL
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
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 specific
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 pr
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
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
pos
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
situat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
39 matches
Mail list logo
