CC’ing gcc alias as well.
Hi, Yeoul,
I think the key for when to use the forward declaration syntax is:
When there is only one single identifier as the argument of counted_by
attribute,
There will be no possibility of scope conflict between different identifiers
inside
the counted_by
tency, but I don't care that much. The
> > > point
> > > to put it into start_enum was that we don't really care about the location
> > > of the forward declaration after that.
> > >
> > > That said, there is one thing I'm wondering abou
t we don't really care about the location
> > of the forward declaration after that.
> >
> > That said, there is one thing I'm wondering about:
> >
> > if (name != NULL_TREE)
> > enumtype = lookup_tag (ENUMERAL_TYPE, name, true, &enuml
ches/2009-09/msg01161.html
> > > the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
> > > forward declaration. If we e.g. have a variable that is first declared
> > > extern and then defined, we emit DW_TAG_variable with the location of th
enumeral_type if there is a
> > forward declaration. If we e.g. have a variable that is first declared
> > extern and then defined, we emit DW_TAG_variable with the location of the
> > first declaration and then another DW_TAG_variable with DW_AT_specification
> > pointing to the
On Thu, Mar 09, 2017 at 10:24:43AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
> the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
> forward declaration. If we e.g. have a variable that is
Hi!
Similarly to https://gcc.gnu.org/ml/gcc-patches/2009-09/msg01161.html
the C FE gets wrong the location of DW_TAG_enumeral_type if there is a
forward declaration. If we e.g. have a variable that is first declared
extern and then defined, we emit DW_TAG_variable with the location of the
first
On 05/02/2016 12:27 PM, Marek Polacek wrote:
Here, the problem was that we weren't diagnosing invalid code when an array
dimension was of incomplete enum type. That led to an ICE in gimplifier.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2016-05-02 Marek Polacek
PR c/70
"size of unnamed array has non-integer type");
+ "size of unnamed array has non-integer type");
+ size = integer_one_node;
+ }
+ /* This can happen with enum forward declaration. */
+
OK.
Jason
On Sun, Jul 12, 2015 at 7:31 PM, Patrick Palka wrote:
> This patch attempts resolve the mentioned PR by fixing two underlying
> issues:
I should note that there is some overlap between the fixes.
Technically fix #2 is sufficient to resolve the PR, whereas fix #1 can
only resolve the first test ca
This patch attempts resolve the mentioned PR by fixing two underlying
issues:
1.
When a template is first declared we currently take care to set
the DECL_CONTEXT of each of its template template parms to point to it (line
5119 in pt.c:push_template_decl_real). However, we currently don't do
this
Committed r222177 after testing on aarch64-none-linux-gnu and aarch64-none-elf.
gcc/ChangeLog:
config/aarch64/arm_neon.h (vdup_n_f32): Remove forward declaration
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 71ef027..e9cc825 100644
--- a/gcc/config
On Sun, May 20, 2012 at 9:57 PM, Alan Modra wrote:
> This removes rather a lot of forward declarations in rs6000.c, most of
> which existed to satisfy an early TARGET_INITIALIZER. Now that the
> TARGET_INITIALIZER has been moved to the end of rs6000.c, they become
> unnecessary and wrongly give t
This removes rather a lot of forward declarations in rs6000.c, most of
which existed to satisfy an early TARGET_INITIALIZER. Now that the
TARGET_INITIALIZER has been moved to the end of rs6000.c, they become
unnecessary and wrongly give the impression that rs6000.c style is to
declare functions at
15 matches
Mail list logo
