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
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
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 #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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Max TenEyck Woodbury changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
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
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
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
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
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
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'.
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?
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
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
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
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/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
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
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
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
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?
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
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
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
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
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
: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
Max TenEyck Woodbury mtewoodbury at gmail dot com changed:
What|Removed |Added
CC
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...
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
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...
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
39 matches
Mail list logo
