Re: [PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

2016-09-03 Thread Richard Biener
On September 3, 2016 5:23:35 PM GMT+02:00, Tom de Vries 
 wrote:
>Hi,
>
>this patch fixes a c++ ICE, a p1 6/7 regression.
>
>
>Consider test.C:
>...
>void bar (__builtin_va_list &);
>
>struct c
>{
>   operator const __builtin_va_list &();
>   operator __builtin_va_list &();
>};
>
>void
>foo (void) {
>   struct c c1;
>
>   bar (c1);
>}
>...
>
>The compiler ICEs as follows:
>...
>test.C: In function ‘void foo()’:
>test.C:13:10: internal compiler error: canonical types differ for 
>identical types __va_list_tag [1] and __va_list_tag [1]
>bar (c1);
>   ^
>comptypes(tree_node*, tree_node*, int)
>   src/gcc/cp/typeck.c:1430
>reference_related_p(tree_node*, tree_node*)
>   src/gcc/cp/call.c:1415
>reference_binding
>   src/gcc/cp/call.c:1559
>implicit_conversion
>   src/gcc/cp/call.c:1805
>build_user_type_conversion_1
>   src/gcc/cp/call.c:3776
>reference_binding
>   src/gcc/cp/call.c:1664
>implicit_conversion
>   src/gcc/cp/call.c:1805
>add_function_candidate
>   src/gcc/cp/call.c:2141
>add_candidates
>   src/gcc/cp/call.c:5394
>perform_overload_resolution
>   src/gcc/cp/call.c:4066
>build_new_function_call(tree_node*, vec**,
>   bool, int)
>   src/gcc/cp/call.c:4143
>finish_call_expr(tree_node*, vec**, bool,
>   bool, int)
>   src/gcc/cp/semantics.c:2440
>...
>
>The regression is caused by the commit for PR70955, that adds a 
>"sysv_abi va_list" attribute to the struct in the va_list type (which
>is 
>an array of one of struct).
>
>The ICE in comptypes happens as follows: we're comparing two versions
>of 
>va_list type (with identical array element type), each with the 
>canonical type set to themselves. Since the types are considered 
>identical, they're supposed to have identical canonical types, which is

Did you figure out why they are not assigned the same canonical type?

Richard.

>not the case, and we run into the ICE.
>
>The patch fixes the ICE by setting the canonical type of the va_list 
>struct and array to NULL, forcing structural comparison.
>
>
>This fix causes a regression for test2.C:
>...
>template 
>int
>fn7 (T ap)
>{
>   return __builtin_va_arg(ap, int);
>}
>
>int
>fn8 (__builtin_va_list ap)
>{
>   return fn7<__builtin_va_list> (ap);
>}
>...
>
>It causes this warning to appear:
>...
>test2.C: In function ‘int fn8(__va_list_tag*)’:
>test2.C:11:36: warning: ignoring attributes applied to ‘__va_list_tag’ 
>after definition [-Wattributes]
>return fn7<__builtin_va_list> (ap);
>...
>
>The patch removes the warning by considering the attribute on the 
>va_list struct type as engrained in apply_identity_attributes.
>
>
>Bootstrapped and reg-tested on x86_64.
>
>OK for trunk, 6 branch?
>
>Thanks,
>- Tom




Re: [PATCH, 2/4] Replace error_at with assert in build_va_arg

2016-09-03 Thread Andreas Schwab
http://gcc.gnu.org/ml/gcc-testresults/2016-09/msg00298.html

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [PATCH, 2/4] Replace error_at with assert in build_va_arg

2016-09-03 Thread Tom de Vries

On 03/09/16 17:37, Andreas Schwab wrote:

On Aug 24 2016, Tom de Vries  wrote:


> Replace error_at with assert in build_va_arg
>
> 2016-08-22  Tom de Vries  
>
>* c-common.c (build_va_arg): Replace first argument type error
>with assert.

/daten/gcc/gcc-20160902/gcc/testsuite/c-c++-common/pr70651.c: In function 'void 
fn1()':
/daten/gcc/gcc-20160902/gcc/testsuite/c-c++-common/pr70651.c:8:31: internal 
compiler error: in build_va_arg, at c-family/c-common.c:5837
0x103a856b build_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:5837
0x101c8eaf build_x_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/cp/call.c:6986
0x1028cef3 cp_parser_primary_expression
../../gcc/cp/parser.c:5096
0x1028f6cf cp_parser_postfix_expression
../../gcc/cp/parser.c:6721
0x102981cb cp_parser_unary_expression
../../gcc/cp/parser.c:8019
0x10298ad7 cp_parser_cast_expression
../../gcc/cp/parser.c:8696
0x10299267 cp_parser_binary_expression
../../gcc/cp/parser.c:8797
0x10299acf cp_parser_assignment_expression
../../gcc/cp/parser.c:9084
0x1029c9d7 cp_parser_expression
../../gcc/cp/parser.c:9253
0x1029d477 cp_parser_expression_statement
../../gcc/cp/parser.c:10736
0x1028aeb3 cp_parser_statement
../../gcc/cp/parser.c:10587
0x1028bdcf cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10859
0x1028bed7 cp_parser_compound_statement
../../gcc/cp/parser.c:10813
0x102a9e4f cp_parser_function_body
../../gcc/cp/parser.c:20832
0x102a9e4f cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:20868
0x102aa8eb cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:25565
0x102ab827 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:25477
0x102ab827 cp_parser_init_declarator
../../gcc/cp/parser.c:18603
0x102abaa3 cp_parser_simple_declaration
../../gcc/cp/parser.c:12487
0x102abf23 cp_parser_block_declaration
../../gcc/cp/parser.c:12363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: c-c++-common/pr70651.c  -std=c++11 (internal compiler error)


Sorry, I need more data to reproduce this. Works for me with x86_64 
-m64/-m32 at r239971.


Thanks,
- Tom


[v3, patch, variant] user-defined operator& and std::variant

2016-09-03 Thread Mikhail Strelnikov
Hello,

Following code does not compile,

#include 

namespace n
{
template
void operator&(T) {}
struct s{};
}

int main()
{
std::variant v;
std::get(v);
}

error: include/c++/7.0.0/variant:315:4: error: invalid static_cast

diff -r -u a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant
--- a/libstdc++-v3/include/std/variant 2016-08-26 13:34:30.823029400 +0300
+++ b/libstdc++-v3/include/std/variant 2016-09-03 18:01:26.431299300 +0300
@@ -312,7 +312,7 @@
   _M_storage() const
   {
  return const_cast(
-  static_cast(&_M_first._M_storage));
+  static_cast(std::__addressof(_M_first._M_storage)));
   }

   union


Re: Implement C _FloatN, _FloatNx types [version 6]

2016-09-03 Thread Andreas Schwab
On Aug 17 2016, Joseph Myers  wrote:

> Index: gcc/testsuite/gcc.dg/torture/float32-basic.c
> ===
> --- gcc/testsuite/gcc.dg/torture/float32-basic.c  (nonexistent)
> +++ gcc/testsuite/gcc.dg/torture/float32-basic.c  (working copy)
> @@ -0,0 +1,9 @@
> +/* Test _Float32.  */
> +/* { dg-do run } */
> +/* { dg-options "" } */
> +/* { dg-add-options float32 } */
> +/* { dg-require-effective-target float32_runtime } */
> +
> +#define WIDTH 32
> +#define EXT 0
> +#include "floatn-basic.h"

This fails on powerpc32, in vafn.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: C++ PATCH for c++/77379 (abi_tag on thunk)

2016-09-03 Thread Andreas Schwab
On Aug 29 2016, Jason Merrill  wrote:

> +// { dg-final { scan-assembler "_ZThn16_N7Derived7get_fooEv" } }
>

FAIL: g++.dg/abi/abi-tag23.C  -std=gnu++98  scan-assembler 
_ZThn16_N7Derived7get_fooB3barEv

$ grep _ZThn abi-tag23.s 
.long   _ZThn8_N7Derived7get_fooB3barEv

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [PATCH, 2/4] Replace error_at with assert in build_va_arg

2016-09-03 Thread Andreas Schwab
On Aug 24 2016, Tom de Vries  wrote:

> Replace error_at with assert in build_va_arg
>
> 2016-08-22  Tom de Vries  
>
>   * c-common.c (build_va_arg): Replace first argument type error
>   with assert.

/daten/gcc/gcc-20160902/gcc/testsuite/c-c++-common/pr70651.c: In function 'void 
fn1()':
/daten/gcc/gcc-20160902/gcc/testsuite/c-c++-common/pr70651.c:8:31: internal 
compiler error: in build_va_arg, at c-family/c-common.c:5837
0x103a856b build_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:5837
0x101c8eaf build_x_va_arg(unsigned int, tree_node*, tree_node*)
../../gcc/cp/call.c:6986
0x1028cef3 cp_parser_primary_expression
../../gcc/cp/parser.c:5096
0x1028f6cf cp_parser_postfix_expression
../../gcc/cp/parser.c:6721
0x102981cb cp_parser_unary_expression
../../gcc/cp/parser.c:8019
0x10298ad7 cp_parser_cast_expression
../../gcc/cp/parser.c:8696
0x10299267 cp_parser_binary_expression
../../gcc/cp/parser.c:8797
0x10299acf cp_parser_assignment_expression
../../gcc/cp/parser.c:9084
0x1029c9d7 cp_parser_expression
../../gcc/cp/parser.c:9253
0x1029d477 cp_parser_expression_statement
../../gcc/cp/parser.c:10736
0x1028aeb3 cp_parser_statement
../../gcc/cp/parser.c:10587
0x1028bdcf cp_parser_statement_seq_opt
../../gcc/cp/parser.c:10859
0x1028bed7 cp_parser_compound_statement
../../gcc/cp/parser.c:10813
0x102a9e4f cp_parser_function_body
../../gcc/cp/parser.c:20832
0x102a9e4f cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:20868
0x102aa8eb cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:25565
0x102ab827 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:25477
0x102ab827 cp_parser_init_declarator
../../gcc/cp/parser.c:18603
0x102abaa3 cp_parser_simple_declaration
../../gcc/cp/parser.c:12487
0x102abf23 cp_parser_block_declaration
../../gcc/cp/parser.c:12363
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: c-c++-common/pr70651.c  -std=c++11 (internal compiler error)

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


[PATCH, c++, PR77427 ] Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

2016-09-03 Thread Tom de Vries

Hi,

this patch fixes a c++ ICE, a p1 6/7 regression.


Consider test.C:
...
void bar (__builtin_va_list &);

struct c
{
  operator const __builtin_va_list &();
  operator __builtin_va_list &();
};

void
foo (void) {
  struct c c1;

  bar (c1);
}
...

The compiler ICEs as follows:
...
test.C: In function ‘void foo()’:
test.C:13:10: internal compiler error: canonical types differ for 
identical types __va_list_tag [1] and __va_list_tag [1]

   bar (c1);
  ^
comptypes(tree_node*, tree_node*, int)
src/gcc/cp/typeck.c:1430
reference_related_p(tree_node*, tree_node*)
src/gcc/cp/call.c:1415
reference_binding
src/gcc/cp/call.c:1559
implicit_conversion
src/gcc/cp/call.c:1805
build_user_type_conversion_1
src/gcc/cp/call.c:3776
reference_binding
src/gcc/cp/call.c:1664
implicit_conversion
src/gcc/cp/call.c:1805
add_function_candidate
src/gcc/cp/call.c:2141
add_candidates
src/gcc/cp/call.c:5394
perform_overload_resolution
src/gcc/cp/call.c:4066
build_new_function_call(tree_node*, vec**,
  bool, int)
src/gcc/cp/call.c:4143
finish_call_expr(tree_node*, vec**, bool,
  bool, int)
src/gcc/cp/semantics.c:2440
...

The regression is caused by the commit for PR70955, that adds a 
"sysv_abi va_list" attribute to the struct in the va_list type (which is 
an array of one of struct).


The ICE in comptypes happens as follows: we're comparing two versions of 
va_list type (with identical array element type), each with the 
canonical type set to themselves. Since the types are considered 
identical, they're supposed to have identical canonical types, which is 
not the case, and we run into the ICE.


The patch fixes the ICE by setting the canonical type of the va_list 
struct and array to NULL, forcing structural comparison.



This fix causes a regression for test2.C:
...
template 
int
fn7 (T ap)
{
  return __builtin_va_arg(ap, int);
}

int
fn8 (__builtin_va_list ap)
{
  return fn7<__builtin_va_list> (ap);
}
...

It causes this warning to appear:
...
test2.C: In function ‘int fn8(__va_list_tag*)’:
test2.C:11:36: warning: ignoring attributes applied to ‘__va_list_tag’ 
after definition [-Wattributes]

   return fn7<__builtin_va_list> (ap);
...

The patch removes the warning by considering the attribute on the 
va_list struct type as engrained in apply_identity_attributes.



Bootstrapped and reg-tested on x86_64.

OK for trunk, 6 branch?

Thanks,
- Tom
Set TYPE_STRUCTURAL_EQUALITY for sysv_abi va_list

2016-09-03  Tom de Vries  

	PR c++/77427
	* config/i386/i386.c (ix86_build_builtin_va_list_64): Set
	TYPE_STRUCTURAL_EQUALITY for record and array.

	* tree.c (apply_identity_attributes): Consider attributes ingrained on
	records and unions.

	* g++.dg/pr77427.C: New test.

---
 gcc/config/i386/i386.c |  6 +-
 gcc/cp/tree.c  |  3 ++-
 gcc/testsuite/g++.dg/pr77427.C | 17 +
 3 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 4531647..4e00dee 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10550,9 +10550,13 @@ ix86_build_builtin_va_list_64 (void)
 
   TYPE_ATTRIBUTES (record) = tree_cons (get_identifier ("sysv_abi va_list"),
 	NULL_TREE, TYPE_ATTRIBUTES (record));
+  SET_TYPE_STRUCTURAL_EQUALITY (record);
 
   /* The correct type is an array type of one element.  */
-  return build_array_type (record, build_index_type (size_zero_node));
+  tree res = build_array_type (record, build_index_type (size_zero_node));
+  SET_TYPE_STRUCTURAL_EQUALITY (res);
+
+  return res;
 }
 
 /* Setup the builtin va_list data type and for 64-bit the additional
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 6d254dd..0259bbf 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1244,7 +1244,8 @@ apply_identity_attributes (tree result, tree attribs, bool *remove_attributes)
   tree new_attribs = NULL_TREE;
   tree *p = &new_attribs;
 
-  if (OVERLOAD_TYPE_P (result))
+  if (OVERLOAD_TYPE_P (result)
+  || RECORD_OR_UNION_TYPE_P (result))
 {
   /* On classes and enums all attributes are ingrained.  */
   gcc_assert (attribs == TYPE_ATTRIBUTES (result));
diff --git a/gcc/testsuite/g++.dg/pr77427.C b/gcc/testsuite/g++.dg/pr77427.C
new file mode 100644
index 000..544946d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr77427.C
@@ -0,0 +1,17 @@
+// { dg-do compile }
+
+void bar (__builtin_va_list &);
+
+struct c
+{
+  operator const __builtin_va_list &();
+  operator __builtin_va_list &();
+};
+
+void
+foo (void)
+{
+  struct c c1;
+
+  bar (c1);
+}


Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope

2016-09-03 Thread Jakub Jelinek
On Thu, May 12, 2016 at 04:12:21PM +0200, Martin Liška wrote:
> > Dunno, guess you need to do something in the FE for it already (talk to
> > Jason?).  At least in *.original dump there is already:
> >   < >   save ((const struct IntHolder &) &TARGET_EXPR ) >;
> > int x = (int) saved->val;
> >   return  = x;
> > and the info on where the D.2263 temporary goes out of scope is lost.
> 
> Thanks for sample, I will ask Jason to help me with that.

Actually, I believe this is all available to the gimplifier.
Primarily look at gimplify_target_expr, which if
gimplify_ctxp->in_cleanup_point_expr
emits a D.N ={v} {CLOBBER};
stmt as cleanup to be added at that corresponding CLEANUP_POINT_EXPR.
And also study gimplify_cleanup_point_expr and gimple_push_cleanup.

I bet you want to emit for use-after-scope sanitization in
gimplify_target_expr next to the conditional which adds the clobber also
(for gimplify_ctxp->in_cleanup_point_expr only) also addition of ASAN_MASK
for the poisoning.  And with the same guard also (again, for if (init) case
only, i.e. the first time the TARGET_EXPR is encountered) before the
gimplification of the init the unpoisoning of the temporary.
Maybe initially ignore VLA temporaries, those would be harder to handle,
and probably have to be dealt together with user VLA/alloca address
sanitization.

Jakub


Re: [Fortran, Patch, PR72832, v1] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

2016-09-03 Thread Dominique d'Humières
Hi Andre,

The patch works as expected. As said on IRC, IMO the dejagnu directives in 
gfortran.dg/allocate_with_source_23.f03

+! { dg-do run { xfail *-*-* } }
+! { dg-options "-fcheck=bounds" }
should be replaced with

+! { dg-do run }
+! { dg-options "-fcheck=bounds" }
+! { dg-shouldfail "Array reference out of bounds" }

(see, e.g., gfortran.dg/assumed_rank_3.f90) which is what I have tested.

Thanks for the patch,

Dominique



Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

2016-09-03 Thread Eric Gallager
On 9/3/16, Manuel López-Ibáñez  wrote:
> On 3 September 2016 at 02:11, Eric Gallager  wrote:
>> On 9/2/16, Manuel López-Ibáñez  wrote:
>>> On 3 Sep 2016 12:56 a.m., "Eric Gallager"  wrote:
 I tried that but it doesn't look like it produced any dumpfiles...
>>>
>>> I often use -fdump-tree-all-all-lineno
>>>
>>
>>
>> That produced a lot of files; I'm attaching a tarball of all of them
>> because I don't know which is the correct one...
>
> None of them. Are you sure you were using at least -O2 and -Wall ?
>


Oops, you're right, the warning disappears with optimization; sorry
for the noise...


New Swedish PO file for 'gcc' (version 6.2.0)

2016-09-03 Thread Translation Project Robot
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-6.2.0.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.




Re: [PATCH] Silence some uninitialized variable warnings that appear when bootstrapping

2016-09-03 Thread Manuel López-Ibáñez
On 3 September 2016 at 02:11, Eric Gallager  wrote:
> On 9/2/16, Manuel López-Ibáñez  wrote:
>> On 3 Sep 2016 12:56 a.m., "Eric Gallager"  wrote:
>>> I tried that but it doesn't look like it produced any dumpfiles...
>>
>> I often use -fdump-tree-all-all-lineno
>>
>
>
> That produced a lot of files; I'm attaching a tarball of all of them
> because I don't know which is the correct one...

None of them. Are you sure you were using at least -O2 and -Wall ?

In any case, it is not worth it to waste your time on this further:

* Warnings in stage1 don't matter: https://gcc.gnu.org/wiki/FAQ#stage1warnings
* Wrong (missing or bogus) uninitialized warnings only present in old
compilers will not get fixed. They are rarely a regression nor easy to
fix.
* Large testcases for wrong uninitialized warnings are not worth
investigating except if they show a regression in trunk. Otherwise,
there are so many known issues with Wuninitialized that the analysis
will certainly be closed as a duplicate and not help at all towards a
possible fix.
* If you wish to learn about Wuninitialized, it is better to start
with one of the well-known and already analyzed bug reports than with
a large testcase. Major problems are described here:
https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings#Current_Situation
However, those are likely among the hardest problems to solve in GCC,
so you may want to check for easyhacks.


Cheers,

Manuel.


[committed] Fix up gomp/_Atomic-4.c (PR c/65467)

2016-09-03 Thread Jakub Jelinek
Hi!

On Fri, Sep 02, 2016 at 08:46:21PM +0200, Jakub Jelinek wrote:
>   * gcc.dg/gomp/_Atomic-4.c: New test.

Andreas noted in the PR the test fails on targets other than x86_64/i686.
That is because no other target yet provides the compute_vecsize_and_simdlen
target hook (basically, backend maintainers should agree on some ABI for
simd clones and implement those in the target hook).

So, I've committed following patch as obvious:

2016-09-03  Jakub Jelinek  

PR c/65467
* gcc.dg/gomp/_Atomic-4.c: Require vect_simd_clones effective target.

--- gcc/testsuite/gcc.dg/gomp/_Atomic-4.c.jj2016-09-02 20:36:22.0 
+0200
+++ gcc/testsuite/gcc.dg/gomp/_Atomic-4.c   2016-09-03 10:30:29.708581112 
+0200
@@ -1,6 +1,7 @@
 /* PR c/65467 */
 /* { dg-do compile } */
 /* { dg-additional-options "-std=c11" } */
+/* { dg-require-effective-target vect_simd_clones } */
 
 #pragma omp declare simd
 int


Jakub


Re: [PATCH] Move class substring_loc from c-family into gcc

2016-09-03 Thread Manuel López-Ibáñez

On 02/09/16 23:55, Martin Sebor wrote:

diff --git a/gcc/substring-locations.h b/gcc/substring-locations.h
index f839c74..bb0de4f 100644
--- a/gcc/substring-locations.h
+++ b/gcc/substring-locations.h
@@ -20,6 +20,73 @@ along with GCC; see the file COPYING3.  If not see
  #ifndef GCC_SUBSTRING_LOCATIONS_H
  #define GCC_SUBSTRING_LOCATIONS_H

+#include 
+


Is this header file going to be used in the middle-end? If so, then it is 
suspicious that it includes cpplib.h. Otherwise, perhaps it should live in 
c-family/


I'm not complaining about substring-locations.c because libcpp is already 
linked with everything else even for other non-C languages, like Ada, but the 
above is leaking all cpplib.h into the rest of the compiler, which defeats the 
purpose of this in coretypes.h


/* Provide forward struct declaration so that we don't have to include
   all of cpplib.h whenever a random prototype includes a pointer.
   Note that the cpp_reader and cpp_token typedefs remain part of
   cpplib.h.  */

struct cpp_reader;
struct cpp_token;


Cheers,
Manuel.