Jason Merrill ja...@redhat.com writes:
So then this change would make
_Complex c;
OK, but not
static _Complex c;
because the first declspec is not from a macro, right?
Yes.
I believe you noted this at some point and
agreed with me that ideally each declspec should come with its
Jason Merrill ja...@redhat.com writes:
On 10/03/2011 06:49 PM, Dodji Seketeli wrote:
Good question. Is the below better?
+ if (linemap_location_from_macro_expansion_p (set, pre))
+pre = linemap_resolve_location (set, pre,
+ LRK_MACRO_EXPANSION_POINT
Jason Merrill ja...@redhat.com writes:
I was thinking that you could walk the macro expansions to see if the
two locations have an expansion in common, and if so compare the
indices. I guess you could do this only if the locations have the same
expansion location but are not themselves equal.
Jason Merrill ja...@redhat.com writes:
On 10/13/2011 01:12 PM, Dodji Seketeli wrote:
+ while (true)
+{
+ if (!linemap_macro_expansion_map_p (map0)
+ || !linemap_macro_expansion_map_p (map1)
+ || map0 == map1)
+ break;
I'd put the test in the condition
This set of patches to track locations of tokens access macro
expansion was reviewed and accepted at
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01346.html.
I have bootstrapped and tested it on x86_64-unknown-linux-gnu against
trunk and I am checking it in now.
Thanks.
...@redhat.com
Dodji Seketeli do...@redhat.com
* doc/cppopts.texi: Document -fdebug-cpp.
* doc/invoke.texi: Add -fdebug-cpp to the list of preprocessor
options.
gcc/c-family/ChangeLog
2011-10-15 Tom Tromey tro...@redhat.com
Dodji Seketeli do
it actually uses from the allocated memory region. In the
'none' allocator implementation (that uses xmalloc) the
ggc_round_alloc_size just returns the requested allocation size.
gcc/ChangeLog
2011-10-15 Tom Tromey tro...@redhat.com
Dodji Seketeli do...@redhat.com
* ggc.h
This patch adds statistics about line maps' memory consumption and
macro expansion to the output of -fmem-report. It has been useful in
trying to reduce the memory consumption of the macro maps support.
gcc/ChangeLog
2011-10-15 Tom Tromey tro...@redhat.com
Dodji Seketeli do
GCC_VERSION = 2007.
I am bootstrapping and testing the obvious patch below with
--disable-bootstrap and I am planning to check it in if it passes, under
the obvious rule.
Sorry for the inconvenience.
commit e957242a9a8ec8f297e05ca0dae1d63bf543fad8
Author: Dodji Seketeli do...@redhat.com
Date: Mon
c1cd2be336ceec75cf40ac5f32cc4f72b8fc5da3
Author: Dodji Seketeli do...@redhat.com
Date: Mon Oct 17 13:33:41 2011 +0200
Fix bootstrapping with --disable-checking
libcpp/ChangeLog
* line-map.c (linemap_macro_map_loc_to_exp_point): Avoid setting a
variable without using it if ENABLE_CHECKING
Gerald Pfeifer ger...@pfeifer.com writes:
Hi Dodji,
On Mon, 17 Oct 2011, Dodji Seketeli wrote:
This is the first instalment of a set which goal is to track locations
of tokens across macro expansions. Tom Tromey did the original work
and attached the patch to PR preprocessor/7263
x86_64 host and the bootstrap is
underway. It's taking time, sorry.
I ran a full bootstrap of the changes which went up to the comparison
failure we are currently having on trunk.
OK if this appears to fix the raised issues and passes bootstraps on the
i686 target?
Author: Dodji Seketeli do
Jason Merrill ja...@redhat.com writes:
If you have a patch like this that fixes a major regression, go ahead
and check it in without waiting for approval; we can adjust it as
necessary after build is working again.
OK.
size_t num_expanded_macros;
- fprintf (stderr, Number of expanded
Gerald Pfeifer ger...@pfeifer.com writes:
On Mon, 17 Oct 2011, Dodji Seketeli wrote:
this looks like it's causing the following bootstrap failure for me
on i386-unknown-freebsd9.0?
Yes this is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50760, and I am
testing the patch attached to the bug
David Edelsohn dje@gmail.com writes:
Your patch broke bootstrap on AIX because of the typedef loc_t
introduced in tree-diagnostics.c. The typedef conflicts with a
typedef in an AIX 5.3 header file for locales. AIX should not be
using that namespace, but the failure occurs before
Dodji Seketeli do...@redhat.com writes:
David Edelsohn dje@gmail.com writes:
Your patch broke bootstrap on AIX because of the typedef loc_t
introduced in tree-diagnostics.c.
I have committed the patch below. Tested on x86_64-unknown-linux-gnu
only, unfortunately. I hope it fixes
This is probably going to take some back and forth as I don't have any
SPU target at hand to debug, so I have filed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 to track this issue,
along with a candidate fix. Could you please test it and reply to the
bug with your results?
Thank you for
it on
x86_64-unknown-linux-gnu. One person confirmed in the audit trail of
the PR that it fixes the issue for him on PPC, so I am proposing the
patch even if I don't know if it bootstraps on SPU or PPC in general.
OK for trunk?
From: Dodji Seketeli do...@redhat.com
Date: Thu, 20 Oct 2011 09:43:49 +0200
Ulrich Weigand uweig...@de.ibm.com writes:
I can confirm that the patch does fix the newlib build failure I was
seeing on SPU.
Pheew, thank you.
Below is a better patch that I am bootstrapping at the moment.
From: Dodji Seketeli do...@redhat.com
Date: Thu, 20 Oct 2011 09:43:49 +0200
Subject
Ulrich Weigand uweig...@de.ibm.com writes:
B.t.w. isn't the same thinko also present in the else if path:
Right. Jakub spotted it as well. Hence the followup patch in the other
subthread.
Thanks for watching.
--
Dodji
Dodji Seketeli do...@redhat.com writes:
libcpp/
* lex.c (_cpp_remaining_tokens_num_in_context): Fix computation of
number of tokens.
Jakub OKed the patch on IRC, so I went ahead and committed to trunk
Thanks.
--
Dodji
as per the
obvious rule.
Sorry for the inconvenience.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eeed56d..83da507 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -10,6 +10,10 @@
2011-10-20 Dodji Seketeli do...@redhat.com
+ * ggc-zone.c (ggc_internal_alloc_zone_stat): Rename
Hello,
cpp_peek_token can fail to peek tokens sometimes because
_cpp_remaining_tokens_num_in_context counts tokens only from the current
context; worse, _cpp_token_from_context_at also get tokens only from the
context context. They should both operate on the context given by
cpp_peek_token. I
Hello,
The following two patches fixes virtual locations handling to progress
toward bootstrapping the compiler with CFLAGS=-ftrack-macro-expansion
CXXFLAGS=-ftrack-macro-expansion
After these two patches I'll still need to update many c++ test cases
and probably exercise some dg-prune-fu to
Hello,
A virtual location can now wrap a reserved location. By reserved
location, I mean a location that is less than RESERVED_LOCATION_COUNT
(i.e UNKNOWN_LOCATION or BUILTINS_LOCATION).
When such a virtual location is passed to linemap_resolve_location,
that function returns the bare reserved
Hello,
I noticed that linemap_macro_map_lookup can yield the wrong map when
at the end of the lookup, we end up with a pair of maps whose indexes
are (mn,mx) with mx-mn == 1. In that case, if the map we want is mn,
we'd wrongly yield mx.
Fixed thus, bootstrapped and tested on
This is the right patch that I bootstrapped and tested.
* line-map.c (linemap_macro_map_lookup): Make sure to always pick
the map with the highest MAP_START_LOCATION.
---
libcpp/line-map.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git
Jason Merrill ja...@redhat.com writes:
OK.
Thanks. The bootstrap on powerpc-darwin completed successfully. I have
just checked the patch in.
--
Dodji
Jason Merrill ja...@redhat.com writes:
On 10/21/2011 07:37 PM, Dodji Seketeli wrote:
It also makes linemap_expand_location_full to return the location it
resolved to.
I think I'd prefer to have expand_location call
linemap_resolve_location and then linemap_expand_location, and perhaps
and tested on
x86_64-unknown-linux-gnu against trunk.
From: Dodji Seketeli do...@redhat.com
Date: Fri, 21 Oct 2011 16:47:07 +0200
Subject: [PATCH 2/2] Fix lookup of macro maps
* line-map.c (linemap_macro_map_lookup): Fix logic.
---
libcpp/line-map.c |6 +++---
1 files changed, 3
Hello,
I have committed the obvious cleanup below for a typo on a comment, into
trunk.
gcc/cp/
* cp-tree.h (DECL_DECLARES_TYPE_P): Fix comment.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index cc12d15..7ff1491 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -3625,7
Hello,
This patch adds support for the alias-declaration feature of the c++11
specification, introduced by the paper N2258[1] and voted into in the
standard. It's a derivative work of a preliminary patch attached by
Jason Merrill to PR C++/45114[2].
alias-declaration introduces a new syntax for
Hello,
I am proposing a series of patches which is supposed to address the
remaining issues (I am aware of) preventing us from enabling the
-ftrack-macro-expansion by default.
The idea is to address each issue I notice in the course of trying to
bootstrap the compiler and running the tests with
Hello,
cpp_sys_macro_p crashes when -ftrack-macro-expansion is on. The issue
can be reproduced by running the tests:
runtest --tool gcc --tool_opts=-ftrack-macro-expansion cpp.exp=sysmac1.c
runtest --tool gcc --tool_opts=-ftrack-macro-expansion cpp.exp=sysmac2.c
This is because it just
This patch makes token pasting work with -ftrack-macro-expansion
turned on. It improves some pasting related tests of the gcc.dg/cpp
sub-directory.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate
Disclaimer: I am sorry for the length of this message.
In essence, it's just a one liner fix in gengtype.c. I felt the need to
explain extensively what I think I understood because it didn't seem
obvious to me.
So, when -ftrack-macro-expansion is activated, the PCH generation
machinery can
Consider the test case gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c.
Its interesting part is:
#define A(x) vari x /* line 7. */
#define vari(x)
#define B , varj
int A(B) ; /* line 10. */
In its initial version, this test was being pre-processed as:
# 1
Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a header
somewhere. Turning on
Now that diagnostics for tokens coming from macro expansions point to
the spelling location of the relevant token (and then displays the
context of the expansion), some ugly (not so seldom) corner cases can
happen.
When the relevant token is a built-in token (which means the location
of that
Besides the warning emitted by warn_uninit, this function wants
to hint the user at where the uninitialized variable was declared, for
cases where the declaration location is outside the current function.
Now that expand_location expands to the location that is in the main
source file (even for
Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location that is recorded for
some_type is not correct. We wrongly record a location
There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null). NULL is defined as a
macro in a system header, so calling warning or warning_at on a virtual
location of NULL yields no diagnostic. So the test accompanying this
patch (as well as
Jason Merrill ja...@redhat.com writes:
On 04/10/2012 10:55 AM, Dodji Seketeli wrote:
+ if (CPP_OPTION (pfile, track_macro_expansion))
I think this should check context-tokens_kind rather than the
compiler flag.
OK.
Below is the updated patch that does that.
Tested and bootstrapped
Jason Merrill ja...@redhat.com writes:
On 04/10/2012 03:42 PM, Dodji Seketeli wrote:
In that case, besides returning NULL, enter_macro_context sets
pfile-context-c.macro to NULL, making cpp_get_token_1 forget to set
the location of the vari to the expansion point of A.
This seems like a bug
On 04/10/2012 03:49 PM, Dodji Seketeli wrote:
Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Wed, Apr 11, 2012 at 3:46 AM, Dodji Seketeli do...@redhat.com wrote:
There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null). NULL is defined as a
macro in a system header, so
Consider the test case g++.dg/other/offsetof5.C:
#include stddef.h
struct A
{
char c;
int i;
};
int j = offsetof (A, i);// { dg-warning invalid
access|offsetof }
template typename T
struct S
{
T h;
T i;
static const int
In gcc/testsuite/gcc.dg/pr30457.c, the first warning was not being
emitted because the relevant location was inside the var_start macro
defined in a system header. It can even point to a token for a
builtin macro there. This patch unwinds to the first token in real
source code in that case.
Even after all the patches I have already submitted for this
-ftrack-macro-expansion business, some test cases where errors happens
on tokens that are defined in macros see their output change in an
incompatible way, when you run them with or without
-ftrack-macro-expansion.
I think this is
Hopefully closing the series, this patch switches the compiler to
-ftrack-macro-expansion=2 by default.
Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk.
libcpp/
* init.c (cpp_create_reader): Switch -ftrack-macro-expansion=2 on
by default. Add comments.
Gabriel Dos Reis g...@integrable-solutions.net writes:
Thanks. But a point of the suggestion was that we won't need the
same comment/explanation duplicated over at least 3 places. Just
one. All those three places deal exactly with one instance: null
pointer constant. That deserves a
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Wed, Apr 25, 2012 at 9:04 AM, Dodji Seketeli do...@redhat.com wrote:
In gcc/testsuite/gcc.dg/pr30457.c, the first warning was not being
emitted because the relevant location was inside the var_start macro
defined in a system header
I have re-based my tree on top of a recent tree that incorporates the
changes for caret diagnostics and I had to update this patch
accordingly. Here is its new version on trunk of today. It basically
updates the new diagnostic_show_locus function to point to spelling
locations.
The patch does
Manuel López-Ibáñez lopeziba...@gmail.com writes:
Hi Dodji,
Hello Manuel,
Sorry for my late reply, I was on the road.
I was going to commit this as obvious, but I want to make sure that it
doesn't conflict with your new track-macro-expansion patches. It can
also wait until you commit all
Jason Merrill ja...@redhat.com a écrit:
It seems like we'll do this for every line in the header, which could
lead to a lot of leaked memory. Instead, we should canonicalize when
setting ORDINARY_MAP_FILE_NAME.
[...]
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
On 21 April 2012
Hello all, and sorry for getting into this a bit late. I have a
question concerning this patch:
+++ cp/call.c (working copy)
[...]
+static const char *
+op_error_string (const char *err_msg, int ntypes, bool match)
+{
+ const char *msg;
+
+ const char *msgt = concat (match ?
Diego Novillo dnovi...@google.com a écrit:
On Mon, Apr 16, 2012 at 10:23, Richard Guenther rguent...@suse.de wrote:
[...]
I'm not sure PPH will replace PCH - will it?
[...]
In theory, it may. But it's not in the immediate plans.
The big thing that PCH has going for it is load speed.
Diego Novillo dnovi...@google.com a écrit:
On Thu, Apr 26, 2012 at 06:43, Dodji Seketeli do...@seketeli.org wrote:
I guess it's also worth noting one limitation of PPHs that is, if I
believe the wiki:
In essence, the only headers that can be pre-parsed are those that
produce the same
Jonathan Wakely jwakely@gmail.com a écrit:
On 26 April 2012 11:12, Dodji Seketeli wrote:
So maybe it'd be better to canonicalize the _cpp_file::path when it's
first build? One drawback of that approach would be that
_cpp_file::path will then permanently loose the information about
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Why not remove this comment and free file here with XDELETEVEC (file) ?
+ canonical_path = maybe_shorter_path (path);
+ if (canonical_path != NULL canonical_path != path)
+ {
+ /* The canonical path was newly allocated. Let's
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Wed, Apr 25, 2012 at 10:20 AM, Dodji Seketeli do...@redhat.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Wed, Apr 25, 2012 at 9:04 AM, Dodji Seketeli do...@redhat.com wrote:
In gcc/testsuite/gcc.dg/pr30457.c
Hello Gabriel,
Following your request[1], please find below the implementation for the
-Wvarargs option, as well as its introductory text. It applies on top
the changes to enable -ftrack-macro-expansion by default[2].
[1]: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01604.html
[2]:
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
Another drawback I didn't realize until now is that in this way the
canonicalize every path, instead of only touching those that belong to
system headers.
Ah. Good catch.
I guess file-dir-sysp should tell us if we are in a system directory,
Dodji Seketeli do...@redhat.com writes:
Tested on x86_64-unknown-linux-gnu against trunk. Bootstrap is still
running ...
* builtins.c (fold_builtin_next_arg): Unwinds to the first
location in real source code.
---
gcc/builtins.c | 23 +++
1 files
Dodji Seketeli do...@redhat.com writes:
Tested on x86_64-unknown-linux-gnu against trunk. Bootstrap for all
languages is still underway.
gcc/c-family/
* c.opt (Wvarargs): Define new option.
gcc/
builtins.c (fold_builtin_next_arg): Use OPT_Wvarargs as an
argument
comments.
(lex_string): Likewise.
diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index f7c330c..4b66c84 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,9 @@
+2012-04-29 Dodji Seketeli do...@redhat.com
+
+ * lex.c (lex_raw_string): Change C++ style comments into C style
Jason Merrill ja...@redhat.com writes:
On 04/25/2012 05:07 AM, Dodji Seketeli wrote:
+ /* If the first token we got was a padding token, let's put
+ it back into the stream so that cpp_get_token will get it
+ first; and if we are currently expanding a macro, don't
Jason Merrill ja...@redhat.com writes:
On 04/25/2012 11:31 AM, Dodji Seketeli wrote:
+#define EXPANSION_POINT_LOCATION_FILE(LOC) \
+ ((expand_location_to_expansion_point (LOC)).file)
+#define EXPANSION_POINT_LOCATION_LINE(LOC) \
+ ((expand_location_to_expansion_point (LOC
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
PR 5297
* libcpp/files.c (maybe_shorter_path): New.
(find_file_in_dir): Use it.
I can't approve or deny this patch, but for what it's worth, I find it
fine.
Thanks.
--
Dodji
Gabriel Dos Reis g...@integrable-solutions.net writes:
OK.
Thank you.
While bootstrapping the tree again, it appeared that an output
regression of the objc test objc.dg/foreach-7.m flew below my radar.
It's one of those typical cases where the first location pointed to by
the diagnostics
Dodji Seketeli do...@redhat.com writes:
Gabriel Dos Reis g...@integrable-solutions.net writes:
OK.
Thank you.
While bootstrapping the tree again, it appeared that an output
regression of the objc test objc.dg/foreach-7.m flew below my radar.
It's one of those typical cases where
Dodji Seketeli do...@redhat.com writes:
I am proposing a series of patches which is supposed to address the
remaining issues (I am aware of) preventing us from enabling the
-ftrack-macro-expansion by default.
The idea is to address each issue I notice in the course of trying to
bootstrap
on
alphaev68-pc-linux-gnu?
Here is the patch, with its introductory text. Thanks.
From 3e8a8ff118d6fbf038802348bac51ce1dbd26647 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli do...@redhat.com
Date: Tue, 1 May 2012 11:14:45 +0200
Subject: [PATCH] Properly initialize cpp_context
Dodji Seketeli do...@redhat.com writes:
Tested on x86_64-unknown-linux-gnu against trunk by running the
test gcc.dg/gomp/macro-4.c under Valgrind. Bootstrap is still
underway.
For what it's worth, the patch passes bootstrap on
x86_64-unknown-linux-gnu.
libcpp/
* directives.c
Jason Merrill ja...@redhat.com writes:
On 05/01/2012 05:36 AM, Dodji Seketeli wrote:
pfile-context = XNEW (cpp_context);
+ memset (pfile-context, 0, sizeof (cpp_context));
You can use XCNEW instead of XNEW + memset.
OK with that change.
Thank you.
Here is the patch I will commit
Uros Bizjak ubiz...@gmail.com writes:
On Tue, May 1, 2012 at 6:04 PM, Dodji Seketeli do...@redhat.com wrote:
pfile-context = XNEW (cpp_context);
+ memset (pfile-context, 0, sizeof (cpp_context));
You can use XCNEW instead of XNEW + memset.
OK with that change.
Thank you.
Here
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This patch enables caret diagnostics for macro expansions. So now we will get:
/home/manuel/macro-clang.c:2:91: error: invalid operands to binary
(have ‘struct mystruct’ and ‘float’)
#define MYMAX(A,B) __extension__ ({ __typeof__(A) __a =
Tristan Gingold ging...@adacore.com a écrit:
the function libcpp/expr.c:interpret_float_suffix allows its argument
LEN to be 0, but in this case it tries to read before the buffer S.
It is not a real issue, except in case of overflow: on VMS with 64bit
pointers but 32bit size_t, the following
Jason Merrill ja...@redhat.com writes:
+ decl_specs-locations[cpdw_builtin_type_spec] = location;
if (!decl_specs-type)
{
decl_specs-type = type_spec;
decl_specs-type_definition_p = false;
- decl_specs-type_location = location;
+
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2012-05-04 Dodji Seketeli do...@redhat.com
+
+ Enable -Wunused-local-typedefs when -Wall or -Wunused is on
+ * opts.c (finish_options): Activate -Wunused-local-typedefs if
+ -Wunused is activated.
+ * doc/invoke.texi: Update blurb
Alexandre Oliva aol...@redhat.com a écrit:
[...]
Anyway, the problem is that, for some unsuitable candidate template
specializations, tsubst returns error_mark_node, which tsubst_decl
stores in argvec, and later on register_specialization gets this
error_mark_node and tries to access it as a
Sorry for my late reply.
Manuel López-Ibáñez lopeziba...@gmail.com writes:
This patch fixes almost all false positives in PR43772. The case not fixed is:
intmax_t i = (whatever);
if (INT_MAX i i = LONG_MAX)
print (i is in 'long' but not 'int' ran)
where we warn if INT_MAX =
Hello,
As discussed previously, the unwinder for macro expansion is quite
verbose [1]. This patch proposes to address that shortcoming.
Consider this test case:
$ cat -n test.c
1 #define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); \
2 __typeof__(B) __b
Hello,
As stated in the audit trail of this problem report, consider this
test case:
$ cat test.c
1 struct x {
2int i;
3 };
4 struct x x;
5
6 #define TEST(X) x.##X
7
8 void foo (void)
Jason Merrill ja...@redhat.com writes:
On 05/15/2012 07:18 AM, Dodji Seketeli wrote:
+paste_tokens (cpp_reader *pfile, source_location lhs_location,
If in the long run we want the location passed in to be the ##
location, let's drop the lhs from the parameter name.
Dropped.
- const
Hello,
As the audit trail of this shows, -Wunused-local-typedefs is not
turned on by -Wunused after all. Sigh.
Now that we have the EnabledBy construct for the *.opt files, it's
more precise and concise to use that to make -Wunused-local-typedefs
be triggered by -Wunused.
I have changed the
Hello,
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile
Jason Merrill ja...@redhat.com writes:
On 05/15/2012 10:17 AM, Dodji Seketeli wrote:
It fixes the test case gcc.dg/cpp/paste12.c because that test case runs
with -ftrack-macro-expansion turned off. Otherwise, you are right that
the issue exists only when we aren't tracking virtual locations
Tom Tromey tro...@redhat.com writes:
Dodji == Dodji Seketeli do...@redhat.com writes:
Dodji To properly fix this, I think libcpp should keep the token of the
Dodji pasting operator '##', instead of representing it with flag on the LHS
Dodji operand's token. That way, it could use its
Manuel López-Ibáñez lopeziba...@gmail.com a écrit:
This seems a chicken and egg dilemma. Current full-time contributors
don't have interest or time for this kind of infrastructure work. And
potential contributors who have interest in using (and perhaps
improving) this infrastructure prefer to
Jason Merrill ja...@redhat.com writes:
On 05/21/2012 10:07 AM, Dodji Seketeli wrote:
Jason Merrillja...@redhat.com writes:
When do we not want to set invocation_location if we're beginning to
expand a macro?
If M itself involves expanding another macro M', we are supposed to call
Jason Merrill ja...@redhat.com writes:
What if the built-in macro appears in a macro defined in a system
header but used in user code? This would resolve the location all the
way to the user code, and warn. I think we only want to step out
until we reach a non-built-in macro, not all the
Jason Merrill ja...@redhat.com writes:
On 05/22/2012 05:04 AM, Dodji Seketeli wrote:
The problem is that cpp_get_token_1 can be called when we are at the
beginning of a macro expansion (inside enter_macro_expansion, called
from cpp_get_token_1), *before* context-c.macro is set. This happens
PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01003.html
Dodji Seketeli do...@redhat.com writes:
Hello,
As discussed previously, the unwinder for macro expansion is quite
verbose [1]. This patch proposes to address that shortcoming.
Consider this test case:
$ cat -n test.c
Jason Merrill ja...@redhat.com writes:
On 05/24/2012 12:03 PM, Dodji Seketeli wrote:
+ if (macro != NULL)
+pfile-about_to_expand_macro_p = false;
The approach sounds good, but why do this in the push_token_context
functions rather than in enter_macro_context?
Because, it's not only
Jason Merrill ja...@redhat.com writes:
On 05/24/2012 01:41 PM, Dodji Seketeli wrote:
[...]
Another way of seeing it is to say that, from the beginning of
enter_macro_context, we are in a state of about to expand a macro
until we actually push the macro context. So it seems to make sense
Gabriel Dos Reis g...@integrable-solutions.net writes:
On Thu, May 24, 2012 at 11:07 AM, Dodji Seketeli do...@redhat.com wrote:
PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01003.html
Sorry, this slipped under my radar.
No problem.
Patch is OK.
Thank you. Applied to trunk, revision
Dodji Seketeli do...@redhat.com writes:
Jason Merrill ja...@redhat.com writes:
On 05/24/2012 01:41 PM, Dodji Seketeli wrote:
[...]
Another way of seeing it is to say that, from the beginning of
enter_macro_context, we are in a state of about to expand a macro
until we actually push
Tom Tromey tro...@redhat.com writes:
Dodji == Dodji Seketeli do...@redhat.com writes:
I didn't see a gcc-patches CC...?
Woops, indeed. Sorry. I have just bounced the original messages to the
list now.
Dodji When building the compiler on altivec, it appears that an unused local
Dodji
I initially forgot to add the gcc-patches list in CC, and tried
unsuccessfully to bounce the message to the list. I am thus forwarding
it now.
---BeginMessage---
Hello,
When building the compiler on altivec, it appears that an unused local
typedef is lurking in a function of libcpp, breaking
101 - 200 of 546 matches
Mail list logo
