On 7/21/23 10:57, Ben Boeckel wrote:
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote:
On 7/19/23 20:47, Ben Boeckel wrote:
But it is inhibiting distributed builds because the distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper
On 7/19/23 20:47, Ben Boeckel wrote:
On Wed, Jul 19, 2023 at 17:11:08 -0400, Nathan Sidwell wrote:
GCC is neither of these descriptions. a CMI does not contain the transitive
closure of its imports. It contains an import table. That table lists the
transitive closure of its imports (it needs
On 7/18/23 20:01, Ben Boeckel wrote:
On Tue, Jul 18, 2023 at 16:52:44 -0400, Jason Merrill wrote:
On 6/25/23 12:36, Ben Boeckel wrote:
On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
On 6/22/23 22:45, Ben Boeckel wrote:
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill
On 7/18/23 16:52, Jason Merrill wrote:
On 6/25/23 12:36, Ben Boeckel wrote:
On Fri, Jun 23, 2023 at 08:12:41 -0400, Nathan Sidwell wrote:
On 6/22/23 22:45, Ben Boeckel wrote:
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the
Not commenting on the semantics, but the name seems unfortunate (hello
bikeshed). The documentation starts with 'attribute causes @var{name} to be
emitted as an alias to the definition'. So not emitting a 'reverse alias',
whatever that might be. It doesn;t seem to mention how reverse alias
On 7/14/23 11:56, Richard Sandiford wrote:
Summary: We'd like to be able to specify some attributes using
keywords, rather than the traditional __attribute__ or [[...]]
syntax. Would that be OK?
In more detail:
We'd like to add some new target-specific attributes for Arm SME.
These attributes
On 6/22/23 22:45, Ben Boeckel wrote:
On Thu, Jun 22, 2023 at 17:21:42 -0400, Jason Merrill wrote:
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is
I came across this when working on the conversion operator deduction fix. We'd
successfully demangle an instantiation of 'template operator X &
()', but fail for 'template operator X ()'. The demangle printer
was trying to specially handle the instantiation in the latter case -- seeing
the
DR 976 affects conversion operator deduction, swapping reference stripping and
cv-qual removal. This allows 'Y::operator P const & ()' to deduce T against a
call wanting plain A (previously that would fail as 'P const' cannot be deduced
from 'A').
It also affects deductions for array- or
PR 99451 is about the inability to name tree and rtl dumps by plugin name. And
includes a patch. But then I worked around the problem and forgot about it.
Here it is again, retested against trunk.
ok?
nathan
--
Nathan SidwellFrom e54518bc5e59ef5cdc21c652ceac41bd0c0f436c Mon Sep 17 00:00:00
On 4/25/23 11:04, Jan Beulich wrote:
On 28.06.2022 16:06, Jan Beulich wrote:
The pathname underneath gcm.cache/ is determined from the effective name
used for the main input file of a particular module. When modules are
built, no canonicalization occurs for the main input file. Hence the
module
On 4/25/23 11:00, Jan Beulich wrote:
When IPv6 is disabled in the kernel, the error message coming back from
Cody::OpenInet6() is different from the sole so far expected one.
ok -- i couldn't find such a system :)
---
v2: Re-base.
--- a/gcc/testsuite/g++.dg/modules/bad-mapper-3.C
+++
Jakub,
for avoidance of doubt, your version is fine.
nathan
On 4/11/23 18:06, Nathan Sidwell wrote:
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap
On 4/11/23 04:12, Jakub Jelinek wrote:
Hi!
When working on the PR109040 fix, I wanted to test it on some
WORD_REGISTER_OPERATIONS target and tried sparc-solaris on GCC Farm.
My bootstrap failed in comparison failure on cp/module.o, because
Solaris date doesn't support the -r option and one
On 2/21/23 11:31, Richard Earnshaw wrote:
I started looking at this a few weeks back, but I was a bit confused by the
testcase and then never got around to following up.
The Arm C++ binding rules normally exclude using an inline function definition
from being chosen as the key function
That might be sufficient for this case, but temploid friends violate an
assumption of the implementation -- namely that module A cannot create an entity
that belongs in module B's symbol table. This causes a bunch of excitement,
particularly around handling (well formed) duplicatd instantions.
On 1/7/23 14:12, John David Anglin wrote:
Tested on trunk and gcc-12 with hppa64-hp-hpux11.11.
ah, I see that is the use that was unprotected, ok.
Okay?
Dave
---
Fix compilation of server.cc on hpux.
Select and FD_ISSET are declared in sys/time.h on most versions
of hpux. As a result,
On 12/7/22 16:50, Patrick Palka wrote:
We currently declare __builtin_source_location with a const void* return
type instead of the true type (const std::source_location::__impl*), and
later when folding this builtin we just obtain the true type via name
lookup.
But the below testcase
On 11/25/22 14:03, Torbjorn SVENSSON wrote:
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html
ok, thanks!
Kind regards,
Torbjörn
On 2022-11-17 14:20, Torbjörn SVENSSON wrote:
v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on
Templated lambdas have a template-head, which is part of their
signature. GCC ABI 18 mangles that into the lambda name. This adds
support to the demangler. We have to introduce artificial template
parameter names, as we need to refer to them from later components of
the lambda signature. We
On 11/8/22 05:18, Torbjorn SVENSSON wrote:
Hi Nathan,
On 2022-11-08 00:03, Nathan Sidwell wrote:
Yes, something like the above, but I think you're missing "/bob' in the
DOS_BASED case? shouldn't that also be a pathname?
if (IS_DIR_SEPARATOR (ptr[ptr[0] == '.']) // ./FOO or /FOO
#if
On 11/3/22 11:06, Torbjorn SVENSSON wrote:
On 2022-11-03 15:17, Nathan Sidwell wrote:
On 10/28/22 05:15, Torbjörn SVENSSON wrote:
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows,
I found some additional cases when working on the demangler. May as
well check their mangling. Since I managed to confuse myself.
nathan
--
Nathan SidwellFrom 51d567d4d15e78b42d2ca83f229c98fff2aec9fa Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 7 Nov 2022 11:08:21 -0500
Subject:
On 10/28/22 05:15, Torbjörn SVENSSON wrote:
On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the module loader and is likely not found.
On 11/3/22 09:48, Torbjorn SVENSSON wrote:
Hello Nathan,
On 2022-11-03 14:13, Nathan Sidwell wrote:
On 11/3/22 05:37, Torbjörn SVENSSON wrote:
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
On 11/3/22 05:37, Torbjörn SVENSSON wrote:
v1 -> v2:
Updated expression in bad-mapper-3.C
Ok for trunk?
---
Without the patch, the output for bad-mapper-3.C would be:
/src/gcc/gcc/testsuite/g++.dg/modules/bad-mapper-3.C:2:1: error: unknown
Compiled Module Interface: no such module
As this
This implements ABI-compliant lambda discriminators. Not only do we
have per-scope counters, but we also distinguish by lambda signature.
Only lambdas with the same signature will need non-zero
discriminators. As the discriminator is signature-dependent, we have
to process the lambda
We currently use a per-extra-scope counter to discriminate multiple
lambdas in a particular such scope. This is not ABI compliant. This
patch merely refactors the existing code to make it easier to drop in
a conformant mangling -- there's no functional change here. I rename
the
(Explicitly) Templated lambdas have a different signature to
implicitly templated lambdas -- '[] (T) {}' is not the
same as '[](auto) {}'. This should be reflected in the mangling. The
ABI captures this as
https://github.com/itanium-cxx-abi/cxx-abi/issues/31, and clang has
implemented such
On 10/27/22 04:17, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, apparently my r13-2887 P1467R9 changes
regressed these tests on powerpc64le-linux with IEEE quad by default.
I believe my changes just uncovered a latent bug.
The problem is that push_namespace calls find_namespace_slot,
which
We intend to mark synthetic template parameters (coming from use of auto
parms), as DECL_VIRTUAL_P. The API of process_template_parm is
awkwardly confusing, and we were marking the previous template parm
(unless this was the first parm). process_template_parm returns the list
of parms, when
On 10/21/22 09:11, Patrick Palka wrote:
On Fri, 21 Oct 2022, Nathan Sidwell wrote:
Thanks for the explanation, it's a situation I didn;t anticipate and your fix
is good. Could you add a comment about why you need to propagate the values
though?
Thanks a lot, will do. Just to make sure
On 10/19/22 09:55, Patrick Palka wrote:
On Wed, 19 Oct 2022, Richard Biener wrote:
On Tue, Oct 18, 2022 at 8:26 PM Patrick Palka wrote:
On Fri, 14 Oct 2022, Richard Biener wrote:
On Thu, Oct 13, 2022 at 5:40 PM Patrick Palka via Gcc-patches
wrote:
Here during stream in we end up having
On 10/20/22 10:07, Patrick Palka wrote:
Here node_template_info is overlooking that CONCEPT_DECL has TEMPLATE_INFO
too, which makes get_originating_module_decl for the CONCEPT_DECL fail to
return the corresponding TEMPLATE_DECL, which leads to an ICE from
import_entity_index while pretty
On 10/18/22 10:13, Patrick Palka wrote:
This fixes the below testcase in which we neglect to stream the default
argument for T only because the subsequent parameter U doesn't also have
a default argument.
ok
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR c++/105045
On 10/14/22 13:00, Patrick Palka wrote:
IIUC we currently avoid streaming the RESULT_DECL and PARM_DECLs
of a constexpr_fundef entry under the assumption that they're just
copies of the DECL_RESULT and DECL_ARGUMENTS of the FUNCTION_DECL.
Thus we can just make new copies of DECL_RESULT and
On 10/13/22 11:27, Jason Merrill wrote:
On 10/11/22 13:40, Nathan Sidwell wrote:
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the
On 10/13/22 15:04, Patrick Palka wrote:
The FUNCTION_DECL we build for __dynamic_cast has an empty DECL_CONTEXT,
but trees_out::tree_node expects all FUNCTION_DECLs to have non-empty
DECL_CONTEXT thus we crash when streaming out the dynamic_cast in the
below testcase.
This patch naively fixes
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
On 10/11/22 10:58, Patrick Palka wrote:
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
On 10/4/22 13:36, Patrick Palka wrote:
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from
The grammar for a lambda context can include 'M', and we
were adding the component that generated to the substitution table
twice. Just ignore the 'M' completely -- we'll already have done the
checks we need when we saw its predecessor. A prefix cannot be the
last component of a nested name,
On 10/4/22 13:36, Patrick Palka wrote:
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from module_state::read_cluster has no effect,
and we never push f onto deferred_fns and end up never
On 10/7/22 11:09, Patrick Palka wrote:
According to grokbitfield, DECL_BITFIELD_REPRESENTATIVE may "temporarily"
contain the width of the bitfield until we layout the class type (after
which it'll contain a FIELD_DECL). But for a class template, it'll always
be the width since we don't/can't
Now we have templated lambdas, we can have variadic template lambdas,
and this leads to lambda signatures containing parameter packs. But
just like 'auto' inside such a signature, we don't have a containing
template, and thus fail. The fix is to check is_lambda_arg, just as
for a template
VAR and FIELD decls can become part of a lambda context, when the
lambda is 'attached' to that entity (It's a C++20 ODR thing that was
discovered with modules, but is actually separate.) We were not
marking those decls as substitution candidates, leading to demangling
failures and compiler
On 10/6/22 12:19, Patrick Palka wrote:
The below testcase fails to link with the error
undefined reference to `f()::y'
ultimately because during stream out for the static VAR_DECL y we
override DECL_EXTERNAL to true, which later during IPA confuses
symbol_table::remove_unreachable_nodes
On 9/30/22 09:43, Nathan Sidwell wrote:
Hi,
I've discovered some mangling problems with lambdas. (a) divergence
from clang and (b) manglings that incorrectly demangle. With #a I'm not
yet sure who is correct. for #b g++ is definitely wrong.
From the docs, it doesn't appear to have been
Hi,
I've discovered some mangling problems with lambdas. (a) divergence
from clang and (b) manglings that incorrectly demangle. With #a I'm not
yet sure who is correct. for #b g++ is definitely wrong.
From the docs, it doesn't appear to have been bumped this cycle. Is
that correct, and I
On 9/30/22 04:18, Torbjörn SVENSSON wrote:
The ':' is reserved in filenames on Windows.
Can't find any specification for this, but when there is no filename
defined in the map file, GCC will replace the ':' with a '-' in the
generated filename for the module.
Correct (and the specification is
This adds smarts to the module machinery to handle NTTP object
VAR_DECLs. Like typeinfo objects, these must be ignored in the symbol
table, streamed specially and recreated on stream in.
Patrick, thanks for the testcase, I don't know how to attribute that to
you in the changelog anymore.
On 9/28/22 10:42, Patrick Palka wrote:
On Tue, 27 Sep 2022, Nathan Sidwell wrote:
On 9/26/22 15:05, Patrick Palka wrote:
On Mon, 26 Sep 2022, Patrick Palka wrote:
On Mon, 26 Sep 2022, Nathan Sidwell wrote:
return decl;
@@ -29150,9 +29151,10 @@ finish_concept_definition (cp_expr
VAR_DECLs for NTTPs need to be handled specially by module streaming,
in the same manner to type info decls. This reworks their handling to
allow that work to drop in. We use DECL_LANG_FLAG_5 to indicate such
decls (I didn't notice template_parm_object_p, which looks at the
mangled name --
On 9/26/22 15:05, Patrick Palka wrote:
On Mon, 26 Sep 2022, Patrick Palka wrote:
On Mon, 26 Sep 2022, Nathan Sidwell wrote:
On 9/26/22 10:08, Nathan Sidwell wrote:
On 9/23/22 09:32, Patrick Palka wrote:
Judging by the two commits that introduced/modified this part of
On 9/26/22 10:36, Patrick Palka wrote:
In r13-2775-g32d8123cd6ce87 I overlooked that we need to adjust the
call to add_mergeable_specialization in the MK_partial case to correctly
handle variable template partial specializations (it currently assumes
we're always dealing with one for a class
On 9/26/22 10:08, Nathan Sidwell wrote:
On 9/23/22 09:32, Patrick Palka wrote:
Judging by the two commits that introduced/modified this part of
maybe_register_incomplete_var, r196852 and r214333, ISTM the code
is really only concerned with constexpr static data members (whose
initializer may
On 9/23/22 09:32, Patrick Palka wrote:
Judging by the two commits that introduced/modified this part of
maybe_register_incomplete_var, r196852 and r214333, ISTM the code
is really only concerned with constexpr static data members (whose
initializer may contain a pointer-to-member for a
On 9/22/22 14:25, Patrick Palka wrote:
index 80467c19254..722b64793ed 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -18235,9 +18235,11 @@ maybe_register_incomplete_var (tree var)
{
/* When the outermost open class is complete we can resolve any
On 9/21/22 12:16, Patrick Palka wrote:
With partial variable template specializations, it looks like we
stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding
TEMPLATE_DECL) since process_partial_specialization adds it to the
specializations table, but end up never streaming the
On 9/20/22 15:54, Patrick Palka wrote:
This adds some recently implemented C++20/23 library headers to the
xtreme-header tests as appropriate. Also, it looks like we can safely
re-add and remove the NO_ASSOCIATED_LAMBDA workaround.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
On 9/20/22 15:54, Patrick Palka wrote:
The modules streaming code seems to rely on the invariant that a
TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE.
It does indeed.
But for a templated VAR_DECL with deduced non-dependent type, the two
TREE_TYPEs end up diverging:
On 9/20/22 10:08, Patrick Palka wrote:
On Tue, 20 Sep 2022, Nathan Sidwell wrote:
On 9/19/22 09:52, Patrick Palka wrote:
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream
On 9/19/22 09:52, Patrick Palka wrote:
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false equivalences
of different partial instantiations of
On 9/16/22 11:54, Patrick Palka wrote:
On Fri, 16 Sep 2022, Nathan Sidwell wrote:
Thanks, this looks right. Sigh templates can mess up ones mental invariants!
The test case should really be a foo_[ab].C kind, to test both sides of the
streaming. Bonus points for using the template after
Thanks, this looks right. Sigh templates can mess up ones mental invariants!
The test case should really be a foo_[ab].C kind, to test both sides of the
streaming. Bonus points for using the template after importing. And you
need the dg-module-cmi annotation to check /and then delete/ the gcm
On 8/22/22 13:39, Paul Hollinsky wrote:
On Mon, Aug 22, 2022 at 09:19:29AM -0400, Nathan Sidwell wrote:
On 8/19/22 16:27, Paul Hollinsky wrote:
Hi all,
Would love some feedback on this patch!
Thanks,
Paul
On Mon, Aug 01, 2022 at 05:18:40AM +, Paul Hollinsky wrote:
Rather than
On 8/19/22 16:27, Paul Hollinsky wrote:
Hi all,
Would love some feedback on this patch!
Thanks,
Paul
On Mon, Aug 01, 2022 at 05:18:40AM +, Paul Hollinsky wrote:
Rather than traversing the all_files linked list for every include,
this factors out the quick idempotency checks (modification
On 8/15/22 10:03, Richard Biener wrote:
On Mon, Aug 15, 2022 at 3:29 PM Nathan Sidwell via Gcc-patches
wrote:
On 8/2/22 10:44, Qing Zhao wrote:
Hi, Nathan,
I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common”
(gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays
Not all systems have the same injected headers, leading to line
location table differences that are immaterial to the test. Fix the
regexp more robustly.
nathan
--
Nathan SidwellFrom af088b32def1c56538f0f3aaea16f013e9292d64 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 15 Aug 2022
On 8/2/22 10:44, Qing Zhao wrote:
Hi, Nathan,
I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common”
(gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays.
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index ea9f281f1cc..458c6e6ceea 100644
--- a/gcc/tree-core.h
Inspired by a user question. Jason, thoughts?
Since C++ is such a moving target, Microsoft have /std:c++latest
(AFAICT clang does not), to select the currently implemented version
of the working paper. But the use of 'std:latest' is somewhat
ambiguous -- the current std is C++20 -- that's the
Like macro locations, we only need to emit ordinary location
information for locations emitted into the CMI. This adds a hash table
noting which ordinary lines are needed. These are then sorted and
(sufficiently) adjacent lines are coalesced to a single map. There is
a tradeoff here, allowing
In order to prune ordinary locations, we need to note the locations of
macros we'll be writing out. This reaaranges the macro processing to
achieve that. Also drop an unneeded parameter from macro reading & writing.
Fix some it's/its errors.
nathan
--
Nathan SidwellFrom
The macro location tables should really mention they are about
locations. So rename them. Also, add a missing free of the remapping
table, and remove some now-unneeded macro checking.
nathan
--
Nathan SidwellFrom b0f25e1fdc6199725e69023a3dc49021f311ba66 Mon Sep 17 00:00:00 2001
From: Nathan
This implements garbage collection on locations within macro
expansions, when streaming out a CMI. When doing the reachability
walks, we now note which macro locations we need and then only write
those locations. The complication here is that every macro expansion
location has an independently
The only reason I chose to use DECL_UID on this hash table was to make
it stable against ASLR and perturbations due to other allocations.
It's not required for correctness, as the comment mentions the
equality fn uses pointer identity.
nathan
--
Nathan SidwellFrom
I missed we documented this as unimplemented, when I implemented it.
--
Nathan SidwellFrom f1fcd6e3ad911945bc3c24a3a5c7ea99b910121e Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Tue, 21 Jun 2022 06:23:11 -0700
Subject: [PATCH] doc: Document module language-linkage supported
I missed we
There's no point adding no-op initializer fns (that a module might
have) to the static initializer list. Also, we can add any objc
initializer call to a partial initializer function and simplify some
control flow.
nathan
--
Nathan SidwellFrom c970d0072e3f962afa278e28f918fdcd1b3e755c Mon Sep
It turns out that 'implementation partition' is not a term used in the
std, and is confusing to users. Let's use the better term 'internal
partition'. While there, adjust header unit naming.
nathan
--
Nathan SidwellFrom 052d89537a4c09e1e1437042e2d1ea215656325f Mon Sep 17 00:00:00 2001
From:
This implements NOP module initializer elision. Each CMI gains a new
flag informing importers whether its initializer actually does something
(initializers its own globals, and/or calls initializers of its
imports). This allows an importer to determine whether to call it.
nathan
--
Nathan
This moves some module writing into a newly added write_end function,
which is called after writing initializers.
Thus paving the way to eliminate calls to NOP initializer fns.
nathan
--
Nathan SidwellFrom 6303eee4b92e8509409503a3abebde8bd50f0f05 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
To add a module initializer optimization, we need to defer finishing
writing out the module file until the end of determining the dynamic
initializers. This is achieved by passing some saved-state from the main
module writing to a new function that completes it.
This patch merely adds the
We special-case emitting the calls of module initializer functions.
It's simpler to just emit a static fn do do that, and add it onto the
front of the global init fn chain. We can also move the calculation of
the set of initializers to call to the point of use.
nathan
--
Nathan
A couple of paths in duplicate decls dealing with templates and
builtins were overly complicated. Fixing thusly.
gcc/cp/
* decl.c (duplicate_decls): Refactor some template & builtin
handling.
applying to trunk
nathan
--
Nathan Sidwell : Facebook
diff --git
I found the linemap logic dealing with running out of column numbers
confusing. There's no need for completely separate code blocks there,
as we can rely on the masking operations working all the way down to
zero bits. The two binary searches for linemap lookups could do with
modernization
I discovered I'd missed applying a testcase when fixing up the EOF token
location a while back.
gcc/testsuite/
* c-c++-common/cpp/pragma-eof.c: New
--
Nathan Sidwell : Facebook
diff --git c/gcc/testsuite/c-c++-common/cpp/pragma-eof.c
85 matches
Mail list logo
