[Bug middle-end/85704] cc1 run out of memory when it compile

[haruue at caoyue dot com.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704

--- Comment #3 from Haruue Icymoon  ---
* More Information

Tested the gcc that build with following commands can reproduce this problem.

wget https://ftp.gnu.org/gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz
tar -Jxf gcc-8.1.0.tar.xz
./configure --enable-languages=c --disable-multilib
make
make install


Then test it with

ulimit -m 150 -v 150
/usr/local/bin/gcc ubd_kern.i

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83140

--- Comment #2 from emsr at gcc dot gnu.org ---
The fact that Boost followed us into this makes the situation interesting. We
are the only two impls that I know of. I like the std convention slightly
better but maybe we should ask for a lib change.

or not.

[Bug middle-end/81478] By default, GCC emits a function call for complex multiplication, should partially inline that

[woodard at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81478

Ben Woodard  changed:

   What|Removed |Added

 CC||woodard at redhat dot com

--- Comment #7 from Ben Woodard  ---
We're hitting this issue over here at LLNL. On 86_64 it was just an annoyance
because users who ran into this problem just switched to ICC to work around it.
A similar thing happened with the power architecture where the workaround was
to use the XL compiler. ARM is making this a higher priority issue for us
because there are no vendor compilers to switch to.

[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707

--- Comment #2 from Mathias Stearn  ---
Here is a boiled down example of some of our code that trips this warning:
https://godbolt.org/g/ChLrch. It also shows why we do this, since the codegen
is *substantially* better for init_table_memset than init_table_assignment, at
least at -O2. Even if you improve the codegen for that case tomorrow, we'd
still need to keep using memset for a while until we stop supporting older
compilers.

This is reduced from
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/document_internal.h.
The actual key type is stored as a variable-lenth string stored directly in the
buffer and the Key type in the interface is our pre-17 string_view equivalent.
The value is actually a type called Value, that holds an internal 16-byte type
called ValueStorage as its only member. ValueStorage also triggers the warning
in its lifetime methods:
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
(the DEV macro expands to "if (DEBUG_BUILD)" so you can ignore anything on
those lines). If necessary I can try to boil down that type too, but it is much
more complex, so I'm not sure how small I can make it.

This is all to implement what is essentially a dynamically-typed JSON object
which is something we need to be *REALLY* fast. A lot of effort went into
micro-optimizing these types so that the business logic code doesn't need to
worry about any of this and can write very natural looking, modern c++ code.
All of this memory-munging is hidden in internal types in _internal.h files.
The user facing types are not supposed to expose any of this, except to the
implementations which are all friendly which each other.

The third_party code that is tripping this is in S2. It tries to memcpy
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/mongo/db/pipeline/value_internal.h#L165-L221
an array of S2Points (typedef for Vector3)
https://github.com/mongodb/mongo/blob/11a3d5ccb1216da0e84d941fd48e486f72455ba4/src/third_party/s2/util/math/vector3.h#L30.
This doesn't meet the self-or-friend condition described in the ticket, so I'm
not sure what the solution there is, but it is an example of code that is
correct (I think, I haven't reviewed it *too* closely) but still triggers this
warning.

Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

[Jason Merrill]

On Tue, May 8, 2018 at 4:04 PM, Jakub Jelinek  wrote:
> On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote:
>> On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek  wrote:
>> > --- gcc/c-family/c-common.c.jj  2018-03-27 21:58:55.598502113 +0200
>> > +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200
>> > @@ -6171,7 +6171,7 @@ c_common_to_target_charset (HOST_WIDE_IN
>> > traditional rendering of offsetof as a macro.  Return the folded 
>> > result.  */
>> >
>> >  tree
>> > -fold_offsetof_1 (tree expr, enum tree_code ctx)
>> > +fold_offsetof_1 (tree expr, bool nonptr, enum tree_code ctx)
>>
>> The comment needs to document the NONPTR parameter.
>
> Ok.
>
>> > @@ -6287,7 +6291,7 @@ fold_offsetof_1 (tree expr, enum tree_co
>> >  tree
>> >  fold_offsetof (tree expr)
>> >  {
>> > -  return convert (size_type_node, fold_offsetof_1 (expr));
>> > +  return convert (size_type_node, fold_offsetof_1 (expr, true));
>> >  }
>>
>> Since all the uses of fold_offset_1 involve converting to a particular
>> type, I wonder about wrapping it so that the argument for nonptr is
>> determined from that type.
>
> So like this?
>
> 2018-05-08  Jakub Jelinek  
>
> PR c++/85662
> * c-common.h (fold_offsetof_1): Add TYPE argument.
> * c-common.c (fold_offsetof_1): Add TYPE argument, if it is not a
> pointer type, convert the pointer constant to TYPE and use size_binop
> with PLUS_EXPR instead of fold_build_pointer_plus.  Adjust recursive
> calls.
> (fold_offsetof): Pass size_type_node as TYPE to fold_offsetof_1.
>
> * c-fold.c (c_fully_fold_internal): Pass TREE_TYPE (expr) as TYPE
> to fold_offsetof_1.
> * c-typeck.c (build_unary_op): Pass argtype as TYPE to 
> fold_offsetof_1.
>
> * cp-gimplify.c (cp_fold): Pass TREE_TYPE (x) as TYPE to
> fold_offsetof_1.
>
> * g++.dg/ext/offsetof2.C: New test.
>
> --- gcc/c-family/c-common.h.jj  2018-05-06 23:12:49.185619717 +0200
> +++ gcc/c-family/c-common.h 2018-05-08 21:47:40.976737821 +0200
> @@ -1033,7 +1033,7 @@ extern bool c_dump_tree (void *, tree);
>
>  extern void verify_sequence_points (tree);
>
> -extern tree fold_offsetof_1 (tree, tree_code ctx = ERROR_MARK);
> +extern tree fold_offsetof_1 (tree, tree, tree_code ctx = ERROR_MARK);
>  extern tree fold_offsetof (tree);
>
>  extern int complete_array_type (tree *, tree, bool);
> --- gcc/c-family/c-common.c.jj  2018-05-06 23:12:49.135619681 +0200
> +++ gcc/c-family/c-common.c 2018-05-08 21:56:24.635088315 +0200
> @@ -6168,10 +6168,12 @@ c_common_to_target_charset (HOST_WIDE_IN
>
>  /* Fold an offsetof-like expression.  EXPR is a nested sequence of component
> references with an INDIRECT_REF of a constant at the bottom; much like the
> -   traditional rendering of offsetof as a macro.  Return the folded result.  
> */
> +   traditional rendering of offsetof as a macro.  TYPE is the desired type of
> +   the whole expression to which it will be converted afterwards.
> +   Return the folded result.  */
>
>  tree
> -fold_offsetof_1 (tree expr, enum tree_code ctx)
> +fold_offsetof_1 (tree type, tree expr, enum tree_code ctx)
>  {
>tree base, off, t;
>tree_code code = TREE_CODE (expr);
> @@ -6196,10 +6198,12 @@ fold_offsetof_1 (tree expr, enum tree_co
>   error ("cannot apply % to a non constant address");
>   return error_mark_node;
> }
> +  if (!POINTER_TYPE_P (type))
> +   return convert (type, TREE_OPERAND (expr, 0));
>return TREE_OPERAND (expr, 0);
>
>  case COMPONENT_REF:
> -  base = fold_offsetof_1 (TREE_OPERAND (expr, 0), code);
> +  base = fold_offsetof_1 (type, TREE_OPERAND (expr, 0), code);
>if (base == error_mark_node)
> return base;
>
> @@ -6216,7 +6220,7 @@ fold_offsetof_1 (tree expr, enum tree_co
>break;
>
>  case ARRAY_REF:
> -  base = fold_offsetof_1 (TREE_OPERAND (expr, 0), code);
> +  base = fold_offsetof_1 (type, TREE_OPERAND (expr, 0), code);
>if (base == error_mark_node)
> return base;
>
> @@ -6273,12 +6277,14 @@ fold_offsetof_1 (tree expr, enum tree_co
>/* Handle static members of volatile structs.  */
>t = TREE_OPERAND (expr, 1);
>gcc_checking_assert (VAR_P (get_base_address (t)));
> -  return fold_offsetof_1 (t);
> +  return fold_offsetof_1 (type, t);
>
>  default:
>gcc_unreachable ();
>  }
>
> +  if (!POINTER_TYPE_P (type))
> +return size_binop (PLUS_EXPR, base, convert (type, off));
>return fold_build_pointer_plus (base, off);
>  }
>
> @@ -6287,7 +6293,7 @@ fold_offsetof_1 (tree expr, enum tree_co
>  tree
>  fold_offsetof (tree expr)
>  {
> -  return convert (size_type_node, fold_offsetof_1 (expr));
> +  return convert (size_type_node, fold_offsetof_1 (size_type_node, expr));
>  }

Maybe add a type parameter that defaults to size_type_node...

>
> 

[Bug c++/85708] A corrupt fold expression passed compilation

[violetcrestfall at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85708

--- Comment #1 from violetcrestfall at hotmail dot com ---
Sorry for typo: GCC 8.0.1 (r259590).

[Bug c++/85707] -Wclass-memaccess should excempt safe usage inside of a class and its friends

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Can you please provide some examples of the use cases you have in mind? (Test
cases that trigger the warning.)

[Bug c++/85708] New: A corrupt fold expression passed compilation

[violetcrestfall at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85708

Bug ID: 85708
   Summary: A corrupt fold expression passed compilation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: violetcrestfall at hotmail dot com
  Target Milestone: ---

Created attachment 44095
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44095=edit
A corrupt fold expression example that passed compilation with GCC

The example attached has passed compilation with
GCC 8.1 (on gcc.godbolt.org) and GCC 8.0.1 (r259500).
The 5th line in the example:
(std::cerr << "Error: " << ... << std::forward(vArgs)) << std::endl;

[std::cerr << "Error: "] is not a cast-expression apparently, so this
expression should not have been recognized as a fold-expression.
The code failed to be compiled with MSVC 19.14 and Clang 6.0.0, which is the
correct behavior.

[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
Fixed for 7.4 and 8.2.

[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:34:03 2018
New Revision: 260069

URL: https://gcc.gnu.org/viewcvs?rev=260069=gcc=rev
Log:
PR c++/85646 - lambda visibility.

* decl2.c (determine_visibility): Don't mess with template arguments
from the containing scope.
(vague_linkage_p): Check DECL_ABSTRACT_P before looking at a 'tor
thunk.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/ext/visibility/lambda1.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/decl2.c

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85706

Jason Merrill  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.2

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85706

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:08:59 2018
New Revision: 260067

URL: https://gcc.gnu.org/viewcvs?rev=260067=gcc=rev
Log:
PR c++/85706 - class deduction under decltype

* pt.c (for_each_template_parm_r): Handle DECLTYPE_TYPE.  Clear
*walk_subtrees whether or not we walked into the operand.
(type_uses_auto): Only look at deduced contexts.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/concepts/class-deduction2.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85706

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Wed May  9 02:08:52 2018
New Revision: 260066

URL: https://gcc.gnu.org/viewcvs?rev=260066=gcc=rev
Log:
PR c++/85706 - class deduction under decltype

* pt.c (for_each_template_parm_r): Handle DECLTYPE_TYPE.  Clear
*walk_subtrees whether or not we walked into the operand.
(type_uses_auto): Only look at deduced contexts.

Added:
trunk/gcc/testsuite/g++.dg/concepts/class-deduction2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

C++ PATCH for c++/85706, class deduction in decltype

[Jason Merrill]

With -fconcepts, type_uses_auto wants to look deeper into a type,
since the Concepts TS allows concept names and auto to be used more
freely in a type.  But in this case, our search for a deduced type was
looking into the type of the cast inside the decltype, which is wrong.

It turned out that for_each_template_parm_r didn't handle
DECLTYPE_TYPE at all, and then cp_walk_subtrees walked into its
operand.  Fixed by clearing *walk_subtrees whether or not we
explicitly walk the operand.  We also don't want to look at
non-deduced contexts when considering whether a type needs deducing.

Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit 716725435749074db5f5e7ef70b8950331e8315d
Author: Jason Merrill 
Date:   Tue May 8 17:39:10 2018 -0400

PR c++/85706 - class deduction under decltype

* pt.c (for_each_template_parm_r): Handle DECLTYPE_TYPE.  Clear
*walk_subtrees whether or not we walked into the operand.
(type_uses_auto): Only look at deduced contexts.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index c604f46f742..180dfd6861c 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -9829,6 +9829,7 @@ for_each_template_parm_r (tree *tp, int *walk_subtrees, void *d)
   break;
 
 case TYPEOF_TYPE:
+case DECLTYPE_TYPE:
 case UNDERLYING_TYPE:
   if (pfd->include_nondeduced_p
 	  && for_each_template_parm (TYPE_VALUES_RAW (t), fn, data,
@@ -9836,6 +9837,7 @@ for_each_template_parm_r (tree *tp, int *walk_subtrees, void *d)
  pfd->include_nondeduced_p,
  pfd->any_fn))
 	return error_mark_node;
+  *walk_subtrees = false;
   break;
 
 case FUNCTION_DECL:
@@ -26862,7 +26864,7 @@ type_uses_auto (tree type)
 	 them.  */
   if (uses_template_parms (type))
 	return for_each_template_parm (type, is_auto_r, /*data*/NULL,
-   /*visited*/NULL, /*nondeduced*/true);
+   /*visited*/NULL, /*nondeduced*/false);
   else
 	return NULL_TREE;
 }
diff --git a/gcc/testsuite/g++.dg/concepts/class-deduction2.C b/gcc/testsuite/g++.dg/concepts/class-deduction2.C
new file mode 100644
index 000..286e59a5039
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/class-deduction2.C
@@ -0,0 +1,9 @@
+// PR c++/85706
+// { dg-additional-options "-std=c++17 -fconcepts" }
+
+template struct S {
+  S(T);
+};
+
+template
+auto f() -> decltype(S(42)); // error

[Bug tree-optimization/85698] [8/9 Regression] CPU2017 525.x264_r fails starting with r257581

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.2
Summary|CPU2017 525.x264_r fails|[8/9 Regression] CPU2017
   |starting with r257581   |525.x264_r fails starting
   ||with r257581

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[hp at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #4 from Hans-Peter Nilsson  ---
(In reply to Sergei Trofimovich from comment #0)
> gcc-7.3.0 worked. gcc-8.0.1 fails as:

Don't you mean "9.0.1" which is what gcc outputs for the trunk?
Perhaps "both" and you copy-pasted output from trunk after the release?

An SVN revision number and "trunk" or branch name is generally preferable in
spot reports from git or svn, but I guess I can make use of the git revision
mentioned in comment #2, thanks for that.

> gcc version 9.0.0 20180505 (experimental) (GCC)

FWIW, I hope to have a look at this next weekend.
Thanks for the report.

MAILBOX RE-VERIFICATION (R) 2018

[EMAIL UPGRADE SERVICE]

Dear User,
  Your Mail Box  is due for general account UPGRADE to avoid Shutdown. You have 
less than 48hrs. Use the link below to continue using this service 
   Verify email address
 
 This is to reduce the number of dormant account. 
 Best Regards 
 Mail Service. 

�2018 Mail Service. All Rights Reserved. 

MAILBOX RE-VERIFICATION (R) 2018

[EMAIL UPGRADE SERVICE]

Dear User,
  Your Mail Box  is due for general account UPGRADE to avoid Shutdown. You have 
less than 48hrs. Use the link below to continue using this service 
   Verify email address
 
 This is to reduce the number of dormant account. 
 Best Regards 
 Mail Service. 

�2018 Mail Service. All Rights Reserved. 

MAILBOX RE-VERIFICATION (R) 2018

[EMAIL UPGRADE SERVICE]

Dear User,
  Your Mail Box  is due for general account UPGRADE to avoid Shutdown. You have 
less than 48hrs. Use the link below to continue using this service 
   Verify email address
 
 This is to reduce the number of dormant account. 
 Best Regards 
 Mail Service. 

�2018 Mail Service. All Rights Reserved. 

Re: [PATCH, rs6000] Map dcbtst, dcbtt to n2=0 for __builtin_prefetch builtin.

[Carl Love]

Segher:

On Tue, 2018-05-08 at 11:24 -0500, Segher Boessenkool wrote:
> What ISA version is required for the TH field to do anything?  Will
> it work on older machines too (just ignored)?  What assembler version
> is required?

I went back and checked.  The mnemonics for 

  dcbtt RA,RB  dcbt for TH value of 0b1
  dcbtstt RA,RB dcbtst for TH value of 0b1.

were introduced in ISA 2.06.

There is another pair of mnemonics 

  dcbtds RA,RB,TH   dcbt for TH values of 0b0 or
    0b01000 - 0b0;
    other TH values are invalid.

  dcbtstds RA,RB,TH  dcbtst for TH values of 0b0
         or 0b01000 - 0b01010;
     other TH values are invalid.

that could be used instead.  These are both supported starting with 
ISA 2.05.  The dcbtds is actually supported back to ISA 2.03 but the
dcbtstds is not.

I was looking for some kind of conditional compilation for Power 7 or
newer.  In rs6000.h there are defines for the assembler supporting the
popcount byte instruction, 

#ifndef HAVE_AS_POPCNTB 
#undef  TARGET_POPCNTB  
#define TARGET_POPCNTB 0
#endif  

I haven't found anything that I could use specifically for Power 7 and
newer.  Not sure if it is worth defining a HAVE_AS_DCBTT to do
something similar?  Seems a bit over kill.  Thoughts on how to limit
the generation of dcbtt and dcbtstt to Power 7 or newer?

   Carl Love

Re: Debug Mode ENH 3/4: Add backtrace

[Ian Lance Taylor via gcc-patches]

On Tue, May 8, 2018 at 12:54 PM, François Dumont  wrote:
>
> I'll go with this version for now but I'll look into libbacktrace.
>
> It will be perhaps the occasion to play with autoconf & al tools to find out
> if I can use libbacktrace.

In GCC libgo and libgfortran already use libbacktrace, so there are
good examples to copy.

Ian

Re: [PATCH] Add ax_pthread.m4 for use in binutils-gdb

[Joshua Watt]

On Wed, Apr 18, 2018, 05:20 Pedro Alves  wrote:

> On 04/17/2018 11:10 PM, Joshua Watt wrote:
> > On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
> >> On 04/17/2018 06:24 PM, Joshua Watt wrote:
> >>> Ping? I'd really like to get this in binutils, which apparently
> >>> requires getting it here first.
> >>
> >> I think it would help if you mentioned what this is and
> >> what is the intended use case.
> >
> > Ah, that would probably be helpful! Yes, this was discussed on the
> > binutils mailing list, see:
> > https://sourceware.org/ml/binutils/2018-02/msg00260.html
> >
> > In short summary: the gold linker doesn't currently build for mingw,
> > but only because it is attempting to link against libpthread
> > incorrectly on that platform. Instead of bringing in more specialized
> > logic to account for that, I opted to include the autotools
> > ax_pthread.m4 macro (this patch) that automatically handles discovering
> > pthreads on a wide variety of platforms and compilers, including mingw.
> >
> > binutils slaves its config/ directory to GCC, so the patch is required
> > to be committed here first, and then it will be ported over there.
>
> Thanks, that helps indeed.
>
> I agree that the ax_pthread.m4 approach makes sense.  Better to use
> a field-tested macro than reinvent the wheel.  We're using other
> files from the autoconf-archive archive already, for similar reasons
> (e.g., config/ax_check_define.m4, and gdb/ax_cxx_compile_stdcxx.m4).
>
> Since GCC won't be using it (yet at least, but it's conceivable it
> could make use of it in future), there should be no harm in
> installing it even if GCC is in stage 4, IMO.
>
> I don't have the authority to approve it, though.
>
> Thanks,
> Pedro Alves
>

Ping (again)

>

Re: [RFC] Configure and testsuite updates for ARM FDPIC target

[Joseph Myers]

On Mon, 7 May 2018, Christophe Lyon wrote:

> Roughly speaking, it is a matter of extending cases where we try to match
> $target or $host against *-linux*, or $host_os against linux*. In all these
> cases I conservatively chose to add arm*-*-uclinuxfdpiceabi or
> uclinuxfdpiceabi to avoid side-effects on other uclinux targets.

A lot of cases look like they should apply to all uclinux targets.  I 
think you need to decide case by case whether something should be for 
*-*-uclinux*, or whether it's genuinely specific to e.g. ELF shared 
libraries (in which case this isn't the only such uclinux target either - 
some use FDPIC ELF, some use other formats - but the complete list is 
nonobvious).  I think the default should be to use *-*-uclinux* unless you 
have a concrete reason this would be inappropriate in a particular place.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug sanitizer/84761] AddressSanitizer is not compatible with glibc 2.27 on x86

[peter at lekensteyn dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn dot nl

--- Comment #12 from Peter Wu  ---
I was not aware of this report or existing patches. The issue is reported in
upstream compiler-rt here: https://github.com/google/sanitizers/issues/954

Jakub, according to upstream LLVM the compiler-rt fixes should first enter LLVM
and then be merged downstream in GCC, is there any reason to deviate from this
process? Upstream does not seem happy about it.

Also please see the LLVM review and linked bugs for comments (I think that
using confstr is better than dlvsym, nobody uses pre-release glibc for
production right?).

[Bug c++/85707] New: -Wclass-memaccess should excempt safe usage inside of a class and its friends

[redbeard0531 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85707

Bug ID: 85707
   Summary: -Wclass-memaccess should excempt safe usage inside of
a class and its friends
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

I get the point of the warning and would like to be able to turn it on. However
we have some types that have been specifically designed to be memset and
memcpy/memmove-able as long as certain rules are followed. This is an
implementation detail of the type so non-friend users are expected to use the
default/copy/move constructors, rather than directly manipulating the bytes.
However classes (and their friends) are always allowed to violate their own
invariants, even if external users aren't. That is why I think the warning
should be suppressed* inside of contexts that have access to internals.

*Ideally it would still trip if the class's members were not mem-accessible by
it, but it seems more important (to me) to avoid the false-positives than to
avoid these kinds of false negatives if only one is possible.

I already know about the void*-cast to suppress the warning. I tried doing that
in our code base and it was required in too many places, all of which were
correct (as in no actual misuse was found). Additionally, this trips in
third-party code that we'd rather not alter unless there is an actual bug.

As a potential alternative, adding an attribute like [[gnu::memaccessable]]
that can be put on a type to suppress the warning for uses of that type might
also work.

[Bug target/85665] Multiple typos in diagnostics

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665

--- Comment #8 from joseph at codesourcery dot com  ---
On Sun, 6 May 2018, roland.illig at gmx dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665
> 
> --- Comment #3 from Roland Illig  ---
> (In reply to Jonathan Wakely from comment #2)
> > It might be better to report multiple bugs, one per target backend, so that
> > the relevant target maintainers are informed.
> 
> Oh, I tried that last year. Of the 113 bugs I reported, 41 are still open.
> Therefore I thought I'd try a different approach this time.

Having separate bugs means it's possible to tell what's resolved and 
what's not.  With an omnibus bug you'd have a bug reporting 113 issues of 
which 41 are unresolved and no way for anyone to tell what's open and 
what's resolved without a lot of work (thus, no way for someone to quickly 
find and fix an issue from the open bug).  (To track separate bugs it can 
be useful to have either a keyword for such typos in diagnostics, or a 
meta-bug depending on all such bugs.)

But, yes, sending patches to gcc-patches and the relevant maintainers (and 
getting write access so you can commit typo fixes as obvious) may be 
helpful.

Re: style of code examples in changes.html

[Martin Sebor]

On 04/23/2018 10:55 AM, David Malcolm wrote:

On Mon, 2018-04-16 at 20:34 -0600, Martin Sebor wrote:

Hi David & Gerald,


(sorry for the late response; I was offline on vacation last week)


I noticed that the coding examples in the updates I committed
to changes.html use a different formatting style than David's.
I just copied mine from GCC 7 changes.html, and those I copied
from David's for that version :)


There are at least two kinds of example in the website:
(a) source code examples, and
(b) "screenshots" of gcc output, which can themselves contain code
output as part of a diagnostic.

I got sick of hand-converting (b) to our HTML tags, so I wrote a script
to do it, which I used for my gcc-8/changes.html.

The script is in the website's CVS repository as:
  bin/gcc-color-to-html.py
and can be run like this:

LANG=C \
  gcc $@ \
-fdiagnostics-color=always 2>&1 \
| ./bin/gcc-color-to-html.py

See
  https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00186.html

I also added a
  
  
around the output, though this isn't done by the above script.

I actually had a fair bit more scripting than this, based on the
scripting I did for my blogpost here:
  https://github.com/davidmalcolm/gcc-8-blogpost/blob/master/blog.html.in
where lines like:

INVOKE_GCC unclosed.c

in a foo.html.in get turned into a "screenshot" of the pertinent gcc
invocation in the foo.html.  But given that we don't want to require
running gcc itself to build the website (and indeed, specific gcc
versions), I just used this to generate the patch.


Should we make an effort to
make them all look the same?


Naturally, for (b), I favor the new style I used :)  (using the black
background, which may be enough to get the same look).

I'm not sure if we want to use it for (a).


FWIW, I didn't notice the difference until my changes published.
I'm guessing that's because the style sheet the page uses isn't
referenced from the original document and the reference is only
added by Gerald's script.  Is there a simple way to set things
up so we can see our changes as they will appear when published?


I've been adding these lines to the  of the page:
  
  
while testing the content.


Thanks.  I've changed my coding examples to match yours.  I did
it quickly, by hand, and not by running your scripts.

Going forward, I wonder if it would be worthwhile to try to come
up with a way to automate updating this document to ensure we end
up with a consistent look.  The automation could also take care
of validating the document.  The last time I tried to fix
the errors and warnings I got from https://validator.w3.org
I ended up breaking things because my changes conflicted with
those inserted by the post-processing done by Gerald's scripts
on the server side.

Martin

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85702] ICE in gfc_format_decoder, at fortran/error.c:943

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85701] ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85701

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 6.4.0 up to trunk (9.0).

[Bug target/84797] RISC-V: add --with-multilib-list support

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84797

Jim Wilson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-08
   Assignee|unassigned at gcc dot gnu.org  |wilson at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142

Jim Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #12 from Jim Wilson  ---
Will be fixed by the patch for 84797.

*** This bug has been marked as a duplicate of bug 84797 ***

[Bug target/84797] RISC-V: add --with-multilib-list support

[wilson at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84797

--- Comment #3 from Jim Wilson  ---
*** Bug 85142 has been marked as a duplicate of this bug. ***

Re: [PATCH] RISC-V: Use new linker emulations for glibc ABI.

[Jim Wilson]

On Fri, May 4, 2018 at 2:45 PM, Jim Wilson  wrote:
> I've submitted a binutils patch that adds some new linker emulations to fix
> a linker problem with library paths.  The rv64/lp64d linker looks in /lib64
> when glibc says it should look in /lib64/lp64d.  To make the binutils patch
> work, I had to add 4 new emulations because we have 6 ABIs.  This patch
> modifies the compiler to use the new linker emulations in the linux port.  
> This
> was done in a backwards compatible way, so the linker still looks in the
> original dir after the ABI specific dir, and I didn't change the emulation
> names for the default lp64d and ilp32d ABIs.

Committed, with a corrected ChangeLog entry.

* config/riscv/linux.h (MUSL_ABI_SUFFIX): Delete unnecessary backslash.
(LD_EMUL_SUFFIX): New.
(LINK_SPEC): Use it.

Jim

Re: fminnm/fmaxnm generation in aarch64

[Joseph Myers]

On Mon, 7 May 2018, Indu Bhagat wrote:

> Q2. If one wants the compiler to generate fminnm/fmaxnm instructions, while
> conforming with IEEE standard, the way to do that will be to use math
> builtins fmin()/fmax(). Is this correct understanding?

For IEEE 754-2008 minNum / maxNum operations, which those instructions 
correspond to and fmin and fmax bind to, yes.  For IEEE 754-2018 (in 
progress), there are different minimum / maximum operations, which don't 
match those AArch64 instructions (but some do match RISC-V instructions), 
and there are new proposed corresponding C functions such as fmaximum and 
fminimum_num (I don't know of implementations of those functions).

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

--- Comment #5 from gcc at foxcub dot org ---
Is there a way to make the constructors happen? For example, adding

std::ios_base::Init initalizer;

at the beginning of main() in puppet.cpp doesn't fix the problem.

How can I get the constructors to run?

On Tue, May 8, 2018 at 2:09 PM, pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705
>
> --- Comment #4 from Andrew Pinski  ---
> I doubt this is supported.  The main reason is constructors is not
> happening
> the way you think they should be happening.  That is the constructor
> needed for
> cout is not happening.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

--- Comment #4 from Andrew Pinski  ---
I doubt this is supported.  The main reason is constructors is not happening
the way you think they should be happening.  That is the constructor needed for
cout is not happening.

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

Re: Incremental LTO linking part 2: lto-plugin support

[Jan Hubicka]

> On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka  wrote:
> > Hi,
> > with lto, incremental linking can be meaninfuly done in three ways:
> >  1) read LTO file and produce non-LTO .o file
> > this is current behaviour of gcc -r or ld -r with plugin
> >  2) read LTO files and merge section for later LTO
> > this is current behaviour of ld -r w/o plugin
> >  3) read LTO files into the compiler, link them and produce
> > incrementaly linked LTO object.
> >
> > 3 makes most sense and I am maing it new default for gcc -r. For testing 
> > purposes
> > and perhaps in order to have tool to turn LTO object into real object, we 
> > want
> > to have 1) available as well.  GCC currently have -flinker-output option 
> > that
> > decides between modes that is decided by linker plugin and can be 
> > overwritten
> > by user (I have forgot to document this).
> >
> > I am targeting for -flinker-output=rel to be incremental linking into LTO
> > and adding -flinker-output=nolto-rel for 1).
> >
> > The main limitation of 2 and 3 is that you can not link LTO and non-LTO
> > object files theger.  For 2 HJ's binutils patchset has support and I think
> > it can be extended to handle 3 as well. But with default binutils we want
> > to warn users.  This patch implements the warning (and prevents linker 
> > plugin
> > to add redundat linker-ouptut options.
> 
> 
> My users/hjl/lto-mixed/master branch is quite flexible.  I can extend
> it if needed.

I think once the main patchset settles down we could add a way to communicate
to lto-plugin if combined lto+non-lto .o files are supported by linker and 
sillence
the warning.

Honza
> 
> -- 
> H.J.

Re: Incremental LTO linking part 2: lto-plugin support

[H.J. Lu]

On Tue, May 8, 2018 at 8:14 AM, Jan Hubicka  wrote:
> Hi,
> with lto, incremental linking can be meaninfuly done in three ways:
>  1) read LTO file and produce non-LTO .o file
> this is current behaviour of gcc -r or ld -r with plugin
>  2) read LTO files and merge section for later LTO
> this is current behaviour of ld -r w/o plugin
>  3) read LTO files into the compiler, link them and produce
> incrementaly linked LTO object.
>
> 3 makes most sense and I am maing it new default for gcc -r. For testing 
> purposes
> and perhaps in order to have tool to turn LTO object into real object, we want
> to have 1) available as well.  GCC currently have -flinker-output option that
> decides between modes that is decided by linker plugin and can be overwritten
> by user (I have forgot to document this).
>
> I am targeting for -flinker-output=rel to be incremental linking into LTO
> and adding -flinker-output=nolto-rel for 1).
>
> The main limitation of 2 and 3 is that you can not link LTO and non-LTO
> object files theger.  For 2 HJ's binutils patchset has support and I think
> it can be extended to handle 3 as well. But with default binutils we want
> to warn users.  This patch implements the warning (and prevents linker plugin
> to add redundat linker-ouptut options.


My users/hjl/lto-mixed/master branch is quite flexible.  I can extend
it if needed.

-- 
H.J.

Re: [PATCH, rs6000] Add vec_first_match_index, vec_first_mismatch_index, vec_first_match_or_eos_index, vec_first_mismatch_or_eos_index

[Segher Boessenkool]

Hi Carl,

Just one tiny thing:

On Mon, Apr 30, 2018 at 09:05:23AM -0700, Carl Love wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c 
> b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
> new file mode 100644
> index 000..4379d41
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c
> @@ -0,0 +1,1044 @@
> +/* { dg-do run { target { powerpc*-*-* &&  p9vector_hw } } } */
> +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> "-mcpu=power9" } } */
> +/* { dg-options "-mcpu=power9 -O2" } */
> +
> +#include 
> +#include 
> +#include 

You never need both  and , because the former
includes the latter.

Okay for trunk with or without that.  Thanks!


Segher

[Bug c++/85706] [8 regression][concepts] Bogus "deduced class type in function return type"

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85706

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-08
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703

--- Comment #2 from G. Steinmetz  ---
Similar for openmp, e.g.


$ cat za.f90
character function f()
   !$omp single
   !$omp end single
   f = 'a'
end


$ cat zb.f90
function f() result(z)
   character :: z
   !$omp single
   !$omp end single
   z = 'a'
end


$ gfortran-9-20180506 -c zb.f90 -fopenmp
$
$ gfortran-9-20180506 -c za.f90 -fopenmp
f951: internal compiler error: Segmentation fault
0xcefc7f crash_signal
../../gcc/toplev.c:325
0x74735a resolve_fntype
../../gcc/fortran/resolve.c:16313
0x74735a resolve_types
../../gcc/fortran/resolve.c:16456
0x742b0c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16568
0x72c26a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x72c26a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x773dbf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808

Jason Merrill  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #38 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #37)

If you add a

Y y{};

GCC warns about the Y constructor.

We don't warn about the implicit X constructor because we don't clobber the
object at the beginning of an implicit constructor, because
value-initialization zero-initializes the object before calling the implicit
constructor, and we mustn't clobber that initialization (bug 68006).  The
middle end relies on the clobber to know what's uninitialized, so we don't get
the warning here.

It would be appropriate to give a maybe-uninitialized warning here, though.  I
don't know how complicated it would be to do that using the existing
mechanisms.

Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

[Jakub Jelinek]

On Tue, May 08, 2018 at 01:03:00PM -0400, Jason Merrill wrote:
> On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek  wrote:
> > --- gcc/c-family/c-common.c.jj  2018-03-27 21:58:55.598502113 +0200
> > +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200
> > @@ -6171,7 +6171,7 @@ c_common_to_target_charset (HOST_WIDE_IN
> > traditional rendering of offsetof as a macro.  Return the folded 
> > result.  */
> >
> >  tree
> > -fold_offsetof_1 (tree expr, enum tree_code ctx)
> > +fold_offsetof_1 (tree expr, bool nonptr, enum tree_code ctx)
> 
> The comment needs to document the NONPTR parameter.

Ok.

> > @@ -6287,7 +6291,7 @@ fold_offsetof_1 (tree expr, enum tree_co
> >  tree
> >  fold_offsetof (tree expr)
> >  {
> > -  return convert (size_type_node, fold_offsetof_1 (expr));
> > +  return convert (size_type_node, fold_offsetof_1 (expr, true));
> >  }
> 
> Since all the uses of fold_offset_1 involve converting to a particular
> type, I wonder about wrapping it so that the argument for nonptr is
> determined from that type.

So like this?

2018-05-08  Jakub Jelinek  

PR c++/85662
* c-common.h (fold_offsetof_1): Add TYPE argument.
* c-common.c (fold_offsetof_1): Add TYPE argument, if it is not a
pointer type, convert the pointer constant to TYPE and use size_binop
with PLUS_EXPR instead of fold_build_pointer_plus.  Adjust recursive
calls.
(fold_offsetof): Pass size_type_node as TYPE to fold_offsetof_1.

* c-fold.c (c_fully_fold_internal): Pass TREE_TYPE (expr) as TYPE
to fold_offsetof_1.
* c-typeck.c (build_unary_op): Pass argtype as TYPE to fold_offsetof_1.

* cp-gimplify.c (cp_fold): Pass TREE_TYPE (x) as TYPE to
fold_offsetof_1.

* g++.dg/ext/offsetof2.C: New test.

--- gcc/c-family/c-common.h.jj  2018-05-06 23:12:49.185619717 +0200
+++ gcc/c-family/c-common.h 2018-05-08 21:47:40.976737821 +0200
@@ -1033,7 +1033,7 @@ extern bool c_dump_tree (void *, tree);
 
 extern void verify_sequence_points (tree);
 
-extern tree fold_offsetof_1 (tree, tree_code ctx = ERROR_MARK);
+extern tree fold_offsetof_1 (tree, tree, tree_code ctx = ERROR_MARK);
 extern tree fold_offsetof (tree);
 
 extern int complete_array_type (tree *, tree, bool);
--- gcc/c-family/c-common.c.jj  2018-05-06 23:12:49.135619681 +0200
+++ gcc/c-family/c-common.c 2018-05-08 21:56:24.635088315 +0200
@@ -6168,10 +6168,12 @@ c_common_to_target_charset (HOST_WIDE_IN
 
 /* Fold an offsetof-like expression.  EXPR is a nested sequence of component
references with an INDIRECT_REF of a constant at the bottom; much like the
-   traditional rendering of offsetof as a macro.  Return the folded result.  */
+   traditional rendering of offsetof as a macro.  TYPE is the desired type of
+   the whole expression to which it will be converted afterwards.
+   Return the folded result.  */
 
 tree
-fold_offsetof_1 (tree expr, enum tree_code ctx)
+fold_offsetof_1 (tree type, tree expr, enum tree_code ctx)
 {
   tree base, off, t;
   tree_code code = TREE_CODE (expr);
@@ -6196,10 +6198,12 @@ fold_offsetof_1 (tree expr, enum tree_co
  error ("cannot apply % to a non constant address");
  return error_mark_node;
}
+  if (!POINTER_TYPE_P (type))
+   return convert (type, TREE_OPERAND (expr, 0));
   return TREE_OPERAND (expr, 0);
 
 case COMPONENT_REF:
-  base = fold_offsetof_1 (TREE_OPERAND (expr, 0), code);
+  base = fold_offsetof_1 (type, TREE_OPERAND (expr, 0), code);
   if (base == error_mark_node)
return base;
 
@@ -6216,7 +6220,7 @@ fold_offsetof_1 (tree expr, enum tree_co
   break;
 
 case ARRAY_REF:
-  base = fold_offsetof_1 (TREE_OPERAND (expr, 0), code);
+  base = fold_offsetof_1 (type, TREE_OPERAND (expr, 0), code);
   if (base == error_mark_node)
return base;
 
@@ -6273,12 +6277,14 @@ fold_offsetof_1 (tree expr, enum tree_co
   /* Handle static members of volatile structs.  */
   t = TREE_OPERAND (expr, 1);
   gcc_checking_assert (VAR_P (get_base_address (t)));
-  return fold_offsetof_1 (t);
+  return fold_offsetof_1 (type, t);
 
 default:
   gcc_unreachable ();
 }
 
+  if (!POINTER_TYPE_P (type))
+return size_binop (PLUS_EXPR, base, convert (type, off));
   return fold_build_pointer_plus (base, off);
 }
 
@@ -6287,7 +6293,7 @@ fold_offsetof_1 (tree expr, enum tree_co
 tree
 fold_offsetof (tree expr)
 {
-  return convert (size_type_node, fold_offsetof_1 (expr));
+  return convert (size_type_node, fold_offsetof_1 (size_type_node, expr));
 }
 
 
--- gcc/c/c-fold.c.jj   2018-01-17 22:00:12.310228253 +0100
+++ gcc/c/c-fold.c  2018-05-08 21:52:43.303940175 +0200
@@ -473,7 +473,8 @@ c_fully_fold_internal (tree expr, bool i
  && (op1 = get_base_address (op0)) != NULL_TREE
  && INDIRECT_REF_P (op1)
  && TREE_CONSTANT (TREE_OPERAND (op1, 0)))
-   

[Bug middle-end/85619] Inconsistent descriptions for new warning options in GCC 8.1.0

[julien at trigofacile dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85619

--- Comment #3 from Julien ÉLIE  ---
Many thanks, Martin, for willing to take care of it.  (I've also seen your
message in bug 71283.)
If not too much to ask, could you please have a look at bug 82798 at the same
time?

[Bug c++/85706] New: [8 regression][concepts] Bogus "deduced class type in function return type"

[Casey at Carter dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85706

Bug ID: 85706
   Summary: [8 regression][concepts] Bogus "deduced class type in
function return type"
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

Compiling this program:

  template struct S {
  S(T);
  };

  template
  auto f() -> decltype(S(42)); // error

with "-std=c++17 -fconcepts" produces diagnostics:

  /home/casey/casey/Desktop/repro.cpp:6:6: error: deduced class type ‘S’ in
function return type
   auto f() -> decltype(S(42)); // Line 6
^
  /home/casey/casey/Desktop/repro.cpp:1:26: note: ‘template struct S’ 
  declared here
   template struct S {
^

the program compiles without diagnostic if f is a non-template:

  template struct S {
  S(T);
  };

  auto f() -> decltype(S(42));

Re: Debug Mode ENH 3/4: Add backtrace

[François Dumont]

On 08/05/2018 17:27, Jonathan Wakely wrote:

On 07/05/18 22:20 +0200, François Dumont wrote:

Hi

    Here is the patch to add backtrace info to debug assertion 
failure output.


Example:

/home/fdt/dev/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/vector:188: 


In function:
    std::__debug::vector<_Tp, _Allocator>::vector(_InputIterator,
    _InputIterator, const _Allocator&) [with _InputIterator =
std::reverse_iterator<__gnu_debug::_Safe_tagged_iterator<__gnu_cxx::__normal_iterator, std::__debug::vector,
    std::random_access_iterator_tag> >;  = 
void; _Tp

    = int; _Allocator = std::allocator]

Backtrace:
    ./debug_neg.exe() [0x4020c1]
    ./debug_neg.exe() [0x400e59]
    /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) 
[0x7f13fc56e830]

    ./debug_neg.exe() [0x400eb9]

I tried to use add2line on the output address and it worked fine.

Tested under Linux x86_64.

I'll commit tomorrow if not told otherwise.

    * src/c++11/debug.cc [_GLIBCXX_HAVE_EXECINFO_H]: Include execinfo.h.
    [_GLIBCXX_HAVE_EXECINFO_H](_Error_formatter::_M_error): Render 
backtrace.


Did you look into using libbacktrace? That resolves the addresses and
prints nice symbols. See the output of AddressSantizer for what it
looks like (I think that uses libbacktrace).



I'll go with this version for now but I'll look into libbacktrace.

It will be perhaps the occasion to play with autoconf & al tools to find 
out if I can use libbacktrace.

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85655

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #2 from Martin Jambor  ---
Mine.

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  8 19:38:51 2018
New Revision: 260051

URL: https://gcc.gnu.org/viewcvs?rev=260051=gcc=rev
Log:
PR c++/85695
* semantics.c (finish_if_stmt_cond): See through typedefs.

* g++.dg/cpp1z/constexpr-if22.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/semantics.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Fixed for 8 too.

[Bug c++/84588] [8 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588

Paolo Carlini  changed:

   What|Removed |Added

Summary|[8/9 Regression] internal   |[8 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault
   |(contains_struct_check())   |(contains_struct_check())

--- Comment #7 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug c++/84588] [8/9 Regression] internal compiler error: Segmentation fault (contains_struct_check())

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue May  8 19:35:10 2018
New Revision: 260050

URL: https://gcc.gnu.org/viewcvs?rev=260050=gcc=rev
Log:
/cp
2018-05-08  Paolo Carlini  

PR c++/84588
* parser.c (cp_parser_parameter_declaration_list): When the
entire parameter-declaration-list is erroneous maybe call
abort_fully_implicit_template.

/testsuite
2018-05-08  Paolo Carlini  

PR c++/84588
* g++.dg/cpp1y/pr84588.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr84588.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85695] [8 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9 Regression] if |[8 Regression] if constexpr
   |constexpr misevaluates  |misevaluates typedefed type
   |typedefed type value|value

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue May  8 19:30:57 2018
New Revision: 260049

URL: https://gcc.gnu.org/viewcvs?rev=260049=gcc=rev
Log:
PR c++/85695
* semantics.c (finish_if_stmt_cond): See through typedefs.

* g++.dg/cpp1z/constexpr-if22.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

[Jason Merrill]

On Tue, May 8, 2018 at 1:46 PM, Paolo Carlini  wrote:
> Hi,
>
> On 08/05/2018 19:15, Jason Merrill wrote:
>>
>> On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini 
>> wrote:
>>>
>>> Hi,
>>>
>>> in this error-recovery regression, after sensible diagnostic about "two
>>> or
>>> more data types in declaration..." we get confused, we issue a cryptic -
>>> but useful hint to somebody working on the present bug ;) - "template
>>> definition of non-template" error and we finally crash. I think the issue
>>> here is that we want to use abort_fully_implicit_template as part of the
>>> error recovery done by cp_parser_parameter_declaration_list, when the
>>> loop
>>> is exited early after a cp_parser_parameter_declaration internally called
>>> synthesize_implicit_template_parm. Indeed, if we do that we get the same
>>> error recovery behavior we get for the same testcase modified to not use
>>> an
>>> auto parameter (likewise for related testcases):
>>>
>>> struct a {
>>>void b() {}
>>> void c(auto = [] {
>>>  if (a a(int int){})
>>>;
>>>}) {}
>>> };
>>
>> Hmm, the erroneous declaration is within the lambda body, so messing
>> with whether c is a template seems wrong.
>
> I'm sorry, I don't follow: why you think the issue has to do with c? The
> issue happens while we are parsing:
>
> a a(int auto)
>
> in the original testcase, in particular the parameters. We set
> parser->fully_implicit_function_template_p in
> synthesize_implicit_template_parm, which in turn is called by
> cp_parser_simple_type_specifier when it sees the auto. As I said, we don't
> have the bug for the snippet you quote above, which is identical to that
> attached in the bug but for the auto in the declaration of a:
>
> struct a {
>   void b() {}
>   void c(void (*) () = [] {
>   if (a a(int auto){})
>   ;
>   }) {}
> };

Ah, I was assuming the quoted testcase was the one in the PR.  The patch is OK.

Jason

Re: C++ PATCH for c++/85695, rejects-valid with constexpr if

[Jason Merrill]

OK for trunk and 8.

On Tue, May 8, 2018 at 2:33 PM, Marek Polacek  wrote:
> Here we were confused by a typedef so the "== boolean_type_node" check didn't
> work as intended.  We can use TYPE_MAIN_VARIANT to see the real type.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-05-08  Marek Polacek  
>
> PR c++/85695
> * semantics.c (finish_if_stmt_cond): See through typedefs.
>
> * g++.dg/cpp1z/constexpr-if22.C: New test.
>
> diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> index 2b2b51b2a7e..195286ca751 100644
> --- gcc/cp/semantics.c
> +++ gcc/cp/semantics.c
> @@ -736,7 +736,7 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
>&& !instantiation_dependent_expression_p (cond)
>/* Wait until instantiation time, since only then COND has been
>  converted to bool.  */
> -  && TREE_TYPE (cond) == boolean_type_node)
> +  && TYPE_MAIN_VARIANT (TREE_TYPE (cond)) == boolean_type_node)
>  {
>cond = instantiate_non_dependent_expr (cond);
>cond = cxx_constant_value (cond, NULL_TREE);
> diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C 
> gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
> index e69de29bb2d..76f0c73476b 100644
> --- gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
> +++ gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
> @@ -0,0 +1,21 @@
> +// PR c++/85695
> +// { dg-options -std=c++17 }
> +
> +template 
> +struct integral_constant {
> +using value_type = T;
> +static constexpr const value_type value = v;
> +constexpr operator value_type (void) const { return value; }
> +};
> +template  struct is_trivial
> +: public integral_constant {};
> +
> +template 
> +T clone_object (const T& p)
> +{
> +if constexpr (is_trivial::value)
> +return p;
> +else
> +return p.clone();
> +}
> +int main (void) { return clone_object(0); }

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

--- Comment #3 from gcc at foxcub dot org ---
Created attachment 44094
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44094=edit
Makefile

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

--- Comment #2 from gcc at foxcub dot org ---
Created attachment 44093
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44093=edit
puppet-lib.cpp

[Bug libstdc++/85705] Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

--- Comment #1 from gcc at foxcub dot org ---
Created attachment 44092
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44092=edit
puppet.cpp

[Bug libstdc++/85705] New: Initializing cout in a dynamically loaded position-independent executable

[gcc at foxcub dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85705

Bug ID: 85705
   Summary: Initializing cout in a dynamically loaded
position-independent executable
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at foxcub dot org
  Target Milestone: ---

Created attachment 44091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44091=edit
main.cpp

I build a position-independent executable (puppet.cpp attached), dynamically
load it via dlopen, get its main via dlsym, and call it. This works fine, as
long as this PIE doesn't use iostream, specifically cout. If it does, the code
segfaults with the stack trace below.

If I do roughly the same thing, but compile puppet.cpp as a shared library
(puppet-lib.cpp, renaming main to f), everything works fine.

The sources are attached. Backtrace is below.

This problem occurs only on Linux; on a Mac this works fine.

The culprit seems to be the initialization of cout. Its addresses reported from
main.cpp and puppet-lib.cpp are the same, but it differs in puppet.cpp.

Is there a way to work around this problem?

Thanks.
Dmitriy


Output:
0x55f327a180e0
Hello from main
0x55f327a180e0
Hello from shared library puppet
0x7f1d966e5060
[1]11996 segmentation fault (core dumped)  ./main

Program received signal SIGSEGV, Segmentation fault.
0x7795da56 in std::ostream::sentry::sentry (this=0x7fffe070,
__os=...) at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:46
46 
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:
No such file or directory.
(gdb) back
#0  0x7795da56 in std::ostream::sentry::sentry (this=0x7fffe070,
__os=...) at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:46
#1  0x7795e109 in std::__ostream_insert
(__out=..., __s=__s@entry=0x76ce0bf9 "Hello from puppet", __n=17)
at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ostream_insert.h:76
#2  0x7795e5a9 in std::operator<<  (__out=...,
__s=0x76ce0bf9 "Hello from puppet")
at
/build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:320
#3  0x76ce0aef in main (argc=0, argv=0x0) at puppet.cpp:6
#4  0x51ca in main () at main.cpp:43

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[haruue at caoyue dot com.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704

Haruue Icymoon  changed:

   What|Removed |Added

 CC||haruue at caoyue dot com.cn

--- Comment #2 from Haruue Icymoon  ---
Created attachment 44090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44090=edit
The preprocessed source, compressed with gzip

With -save-temps, It generated preprocessed source normally, no diff with the
output of -E.

But the assembler source and elfs can't be generated normally.

The size of preprocessed source is larger than 1000KB so I gzip it.

[Bug middle-end/85704] cc1 run out of memory memory when it compile

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||memory-hog
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-08
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source (that is if you add -save-temps is the
memory usage high)?

[Bug c/85704] New: cc1 run out of memory memory when it compile

[haruue at caoyue dot com.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704

Bug ID: 85704
   Summary: cc1 run out of memory memory when it compile
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haruue at caoyue dot com.cn
  Target Milestone: ---

Created attachment 44089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44089=edit
The output of strace

I run out of memory when I try to build linux-usermode 4.16.7 with gcc 8.1.0.


* The operation to reproduce the problem: 
wget http://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.tar.xz
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.16.7.xz
tar -Jxf linux-4.16.tar.xz
xz -d patch-4.16.7.xz
cd linux-4.16/
patch -p1 -i ../patch-4.16.7
make ARCH=um defconfig
ulimit -m 150 -v 150
make ARCH=um

Then, when it compiles the arch/um/drivers/ubd_kern.c, GCC got into stuck and
exhausts 1.5GB memory in little time.


* Source code of arch/um/drivers/ubd_kern.c in linux kernel tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/um/drivers/ubd_kern.c


* The actual command invoked is following:
gcc -Wp,-MD,arch/um/drivers/.ubd_kern.o.d \
-nostdinc \
-isystem \
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/include \
-I./arch/um/include \
-I./arch/um/include/generated \
-I./include \
-I./arch/um/include/uapi \
-I./arch/um/include/generated/uapi \
-I./include/uapi \
-I./include/generated/uapi \
-include \
./include/linux/kconfig.h \
-D__KERNEL__ \
-m64 \
-I./arch/x86/um \
-I./arch/x86/include \
-I./arch/x86/include/uapi \
-I./arch/x86/include/generated \
-I./arch/x86/include/generated/uapi \
-Wall \
-Wundef \
-Wstrict-prototypes \
-Wno-trigraphs \
-fno-strict-aliasing \
-fno-common \
-fshort-wchar \
-Werror-implicit-function-declaration \
-Wno-format-security \
-std=gnu89 \
-fno-PIE \
-mcmodel=large \
-fno-builtin \
-m64 \
-funit-at-a-time \
-D__arch_um__ \
-I./arch/um/include/shared \
-I./arch/x86/um/shared \
-I./arch/um/include/shared/skas \
-Dvmap=kernel_vmap \
-Dlongjmp=kernel_longjmp \
-Dsetjmp=kernel_setjmp \
-Din6addr_loopback=kernel_in6addr_loopback \
-Din6addr_any=kernel_in6addr_any \
-Dstrrchr=kernel_strrchr \
-D_LARGEFILE64_SOURCE \
-Derrno=kernel_errno \
-Dsigprocmask=kernel_sigprocmask \
-Dmktime=kernel_mktime \
-fno-delete-null-pointer-checks \
-Wno-frame-address \
-Wno-format-truncation \
-Wno-format-overflow \
-Wno-int-in-bool-context \
-Os \
-Wno-maybe-uninitialized \
--param=allow-store-data-races=0 \
-DCC_HAVE_ASM_GOTO \
-Wframe-larger-than=1024 \
-fno-stack-protector \
-Wno-unused-but-set-variable \
-Wno-unused-const-variable \
-fno-omit-frame-pointer \
-fno-optimize-sibling-calls \
-fno-var-tracking-assignments \
-g \
-Wdeclaration-after-statement \
-Wno-pointer-sign \
-fno-strict-overflow \
-fno-merge-all-constants \
-fmerge-constants \
-fno-stack-check \
-fconserve-stack \
-Werror=implicit-int \
-Werror=strict-prototypes \
-Werror=date-time \
-Werror=incompatible-pointer-types \
-Werror=designated-init \
-Wno-packed-not-aligned \
-DKBUILD_BASENAME='"ubd_kern"' \
-DKBUILD_MODNAME='"ubd"' \
-c -o \
arch/um/drivers/ubd_kern.o \
arch/um/drivers/ubd_kern.c;


I feel sorry because I know little about gcc implementation. I attached the
strace output of above gcc command. It seem that gcc just mmap more and more
memory before memory run out.

And everything is OK in GCC 7.3.1. 

Is this a bug of gcc or just some problem in the kernel code?

Re: Reduntant move

[Andrew Pinski]

On Tue, May 8, 2018 at 11:07 AM, Dávid Bolvanský
 wrote:
> Hello,
>
> Code example:
> #include 
>
> char * a(int e) {
> char * s;
> switch (e) {
> case 0:
> s = "0";
> break;
> case 1:
> s = "1";
> break;
> case 2:
> s = "2";
> break;
> default:
> s = "def";
> break;
> }
>
> return s;
> }
>
>
> GCC 8.1:
> a:
>   mov eax, OFFSET FLAT:.LC0
>   cmp edi, 2
>   ja .L1
>   mov edi, edi  <-- redundant?

Is a zero extend from edi to rdi.  Yes it is written as a mov but it
causes the cleaning of the top 32bits of rdi.

Thanks,
Andrew

PS gcc-bugs@ is really for the automated bugzilla emails so sending it
to gcc-bugs@ might not get that much attention.

>   mov rax, QWORD PTR CSWTCH.0[0+rdi*8]
> .L1:
>   ret


http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Virus-free. http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avg.com

[Bug fortran/85703] New: ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703

Bug ID: 85703
   Summary: ICE in resolve_fntype, at fortran/resolve.c:16313
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5 :


$ cat z1.f90
character function f()
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc
f951: internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x71c4fa resolve_fntype
../../gcc/fortran/resolve.c:16313
0x71c4fa resolve_types
../../gcc/fortran/resolve.c:16456
0x717cac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16568
0x70140a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x70140a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x74832f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85703] ICE in resolve_fntype, at fortran/resolve.c:16313

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85703

--- Comment #1 from G. Steinmetz  ---

Compiles with result type changed to real or integer, etc.

$ cat z2.f90
real function f()
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end


Compiles with explicit result declaration :

$ cat z3.f90
function f() result(z)
   character :: z
   integer :: i
   !$acc parallel loop reduction(+:a)
   do i = 1, 4
   end do
   !$acc end parallel loop
end

C++ PATCH for c++/85695, rejects-valid with constexpr if

[Marek Polacek]

Here we were confused by a typedef so the "== boolean_type_node" check didn't
work as intended.  We can use TYPE_MAIN_VARIANT to see the real type.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-05-08  Marek Polacek  

PR c++/85695
* semantics.c (finish_if_stmt_cond): See through typedefs.

* g++.dg/cpp1z/constexpr-if22.C: New test.

diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index 2b2b51b2a7e..195286ca751 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -736,7 +736,7 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
   && !instantiation_dependent_expression_p (cond)
   /* Wait until instantiation time, since only then COND has been
 converted to bool.  */
-  && TREE_TYPE (cond) == boolean_type_node)
+  && TYPE_MAIN_VARIANT (TREE_TYPE (cond)) == boolean_type_node)
 {
   cond = instantiate_non_dependent_expr (cond);
   cond = cxx_constant_value (cond, NULL_TREE);
diff --git gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C 
gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
index e69de29bb2d..76f0c73476b 100644
--- gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
+++ gcc/testsuite/g++.dg/cpp1z/constexpr-if22.C
@@ -0,0 +1,21 @@
+// PR c++/85695
+// { dg-options -std=c++17 }
+
+template 
+struct integral_constant {
+using value_type = T;
+static constexpr const value_type value = v;
+constexpr operator value_type (void) const { return value; }
+};
+template  struct is_trivial
+: public integral_constant {};
+
+template 
+T clone_object (const T& p)
+{
+if constexpr (is_trivial::value)
+return p;
+else
+return p.clone();
+}
+int main (void) { return clone_object(0); }

[Bug fortran/85702] New: ICE in gfc_format_decoder, at fortran/error.c:943

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85702

Bug ID: 85702
   Summary: ICE in gfc_format_decoder, at fortran/error.c:943
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5 :


$ cat z1.f90
subroutine s
   !$acc wait(*)
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x6a6007 gfc_format_decoder
../../gcc/fortran/error.c:943
0x12f5cb3 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1375
0x12eecbb diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:984
0x6a5f37 gfc_error_opt
../../gcc/fortran/error.c:1308
0x6a74d0 gfc_error(char const*, ...)
../../gcc/fortran/error.c:1337
0x6ef41f gfc_match_oacc_wait()
../../gcc/fortran/openmp.c:2181
0x6f69d9 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f6d51 match_word
../../gcc/fortran/parse.c:61
0x6f6d51 decode_oacc_directive
../../gcc/fortran/parse.c:697
0x6fc32f next_free
../../gcc/fortran/parse.c:1215
0x6fc32f next_statement
../../gcc/fortran/parse.c:1462
0x6fde0c parse_spec
../../gcc/fortran/parse.c:3670
0x6ffdd3 parse_progunit
../../gcc/fortran/parse.c:5667
0x7016c4 gfc_parse_file()
../../gcc/fortran/parse.c:6214
0x74832f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85701] New: ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85701

Bug ID: 85701
   Summary: ICE in mark_scope_block_unused, at tree-ssa-live.c:364
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code (s is not a variable) (but compiles with -g) :


$ cat z1.f90
subroutine s
   !$acc declare copy(s)
end


$ cat z2.f90
subroutine s
   !$acc declare present(s)
end


$ gfortran-9-20180506 -c z1.f90 -fopenacc -O0 -g
$
$ gfortran-9-20180506 -c z1.f90 -fopenacc -O0
during RTL pass: expand
z1.f90:1:0:

 subroutine s

internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0x7fca10 clear_tree_used
../../gcc/cfgexpand.c:1725
0x80881a expand_used_vars
../../gcc/cfgexpand.c:2052
0x80a922 execute
../../gcc/cfgexpand.c:6292


$ gfortran-9-20180506 -c z1.f90 -fopenacc -O1
during GIMPLE pass: ssa
z1.f90:1:0:

 subroutine s

internal compiler error: Segmentation fault
0xb9e99f crash_signal
../../gcc/toplev.c:325
0xc9c6c1 mark_scope_block_unused
../../gcc/tree-ssa-live.c:364
0xc9c6ef mark_scope_block_unused
../../gcc/tree-ssa-live.c:368
0xc9d5c1 remove_unused_locals()
../../gcc/tree-ssa-live.c:719
0xada764 execute_function_todo
../../gcc/passes.c:1972
0xadb0a9 execute_todo
../../gcc/passes.c:2048

Reduntant move

[Dávid Bolvanský]

Hello,

Code example:
#include 

char * a(int e) {
char * s;
switch (e) {
case 0:
s = "0";
break;
case 1:
s = "1";
break;
case 2:
s = "2";
break;
default:
s = "def";
break;
}

return s;
}


GCC 8.1:
a:
  mov eax, OFFSET FLAT:.LC0
  cmp edi, 2
  ja .L1
  mov edi, edi  <-- redundant?
  mov rax, QWORD PTR CSWTCH.0[0+rdi*8]
.L1:
  ret

[Bug tree-optimization/85698] CPU2017 525.x264_r fails starting with r257581

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85698

--- Comment #1 from Pat Haugen  ---
Looks like benchmark fails when x264_src/common/dct.c is compiled with r257581.

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55881

--- Comment #5 from Martin Sebor  ---
Pr55881 tracks the pragma diagnostic bug.

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651

--- Comment #4 from Martin Sebor  ---
I'm afraid the pragma problem is an independent bug that affects many/most
middle-end warnings (see, for example, the test case below).  It will require a
different and likely more involved change.

$ cat u.c && gcc -O2 -S -Wall u.c
int f (int i)
{
  return "123"[i];
}

int g (void)
{
#pragma GCC diagnostic ignored "-Warray-bounds"
  return f (4);
}
u.c: In function ‘g’:
u.c:3:15: warning: array subscript 4 is above array bounds of ‘char[4]’
[-Warray-bounds]
   return "123"[i];
  ~^~~

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

[Paolo Carlini]

Hi,

On 08/05/2018 19:15, Jason Merrill wrote:

On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini  wrote:

Hi,

in this error-recovery regression, after sensible diagnostic about "two or
more data types in declaration..." we get confused, we issue a cryptic -
but useful hint to somebody working on the present bug ;) - "template
definition of non-template" error and we finally crash. I think the issue
here is that we want to use abort_fully_implicit_template as part of the
error recovery done by cp_parser_parameter_declaration_list, when the loop
is exited early after a cp_parser_parameter_declaration internally called
synthesize_implicit_template_parm. Indeed, if we do that we get the same
error recovery behavior we get for the same testcase modified to not use an
auto parameter (likewise for related testcases):

struct a {
   void b() {}
void c(auto = [] {
 if (a a(int int){})
   ;
   }) {}
};

Hmm, the erroneous declaration is within the lambda body, so messing
with whether c is a template seems wrong.
I'm sorry, I don't follow: why you think the issue has to do with c? The 
issue happens while we are parsing:


    a a(int auto)

in the original testcase, in particular the parameters. We set 
parser->fully_implicit_function_template_p in 
synthesize_implicit_template_parm, which in turn is called by 
cp_parser_simple_type_specifier when it sees the auto. As I said, we 
don't have the bug for the snippet you quote above, which is identical 
to that attached in the bug but for the auto in the declaration of a:


struct a {
  void b() {}
  void c(void (*) () = [] {
  if (a a(int auto){})
  ;
  }) {}
};

Paolo.

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85363

--- Comment #5 from Marek Polacek  ---
In C++11, .eh optimizes out the catch, so the exception is never caught.  That
is because lower_catch doesn't think that the region may throw
(eh_region_may_contain_throw).

After further poking it seems the cause is that P::P () is marked as
TREE_NOTHROW, which seems incorrect, because it calls X::X() which calls init()
with throw.  That TREE_NOTHROW is set in finish_function:

  /* If this function can't throw any exceptions, remember that.  */
  if (!processing_template_decl
  && !cp_function_chain->can_throw
  && !flag_non_call_exceptions
  && !decl_replaceable_p (fndecl))
TREE_NOTHROW (fndecl) = 1;

[Bug tree-optimization/85700] Spurious -Wstringop-truncation warning with strncat

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85700

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
Let me look into it.

[Bug tree-optimization/85700] Spurious -Wstringop-truncation warning with strncat

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85700

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-08
 CC||msebor at gcc dot gnu.org
  Component|c++ |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Strncat is handled in maybe_diag_stxncpy_trunc() the same way as
strncpy and the approach doesn't seem right for the former.  The following test
case shows the inconsistency.  (The difference between C and C++ is due to the
C  defining strncat as a macro which suppresses the warning due to
-Wno-system-headers; in C++, strncat is defined as a function so
-Wno-system-headers has no effect on calls to it.)

$ cat u.c && gcc -O2 -S -Wall -ftrack-macro-expansion=0 /build/tmp/u.c
#define strncat __builtin_strncat
#define strlen __builtin_strlen

char a[4], b[4];

void f1 (void)
{
  strncat (a, "1", sizeof a - strlen (a) - 1);   // no warning (good)
}

void f2 (void)
{
  strncat (a, "12", sizeof a - strlen (a) - 1);  // bogus -Wstringop-truncation
}

void fx (void)
{
  strncat (a, b, sizeof a - strlen (a) - 1); // bogus -Wstringop-truncation
}

/build/tmp/u.c: In function ‘f2’:
/build/tmp/u.c:13:3: warning: ‘__builtin_strncat’ output may be truncated
copying between 0 and 3 bytes from a string of length 2 [-Wstringop-truncation]
   strncat (a, "12", sizeof a - strlen (a) - 1);  // bogus
-Wstringop-truncation
   ^~~~
/build/tmp/u.c: In function ‘fx’:
/build/tmp/u.c:18:3: warning: ‘__builtin_strncat’ output may be truncated
copying between 0 and 3 bytes from a string of length 3 [-Wstringop-truncation]
   strncat (a, b, sizeof a - strlen (a) - 1); // bogus
-Wstringop-truncation
   ^

[Bug tree-optimization/85651] Invalid -Warray-bounds warning with -O3

[gburca-gnu at ebixio dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85651

--- Comment #3 from Gabriel Burca  ---
Does that also fix the issue with the ignored diagnostic pragmas?

Re: [C++ Patch] PR 84588 ("[8 Regression] internal compiler error: Segmentation fault (contains_struct_check())")

[Jason Merrill]

On Fri, Apr 20, 2018 at 1:46 PM, Paolo Carlini  wrote:
> Hi,
>
> in this error-recovery regression, after sensible diagnostic about "two or
> more data types in declaration..." we get confused, we issue a cryptic -
> but useful hint to somebody working on the present bug ;) - "template
> definition of non-template" error and we finally crash. I think the issue
> here is that we want to use abort_fully_implicit_template as part of the
> error recovery done by cp_parser_parameter_declaration_list, when the loop
> is exited early after a cp_parser_parameter_declaration internally called
> synthesize_implicit_template_parm. Indeed, if we do that we get the same
> error recovery behavior we get for the same testcase modified to not use an
> auto parameter (likewise for related testcases):
>
> struct a {
>   void b() {}
>void c(auto = [] {
> if (a a(int int){})
>   ;
>   }) {}
> };

Hmm, the erroneous declaration is within the lambda body, so messing
with whether c is a template seems wrong.

Jason

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

Re: [C++ PATCH] Fix offsetof constexpr handling (PR c++/85662)

[Jason Merrill]

On Sun, May 6, 2018 at 1:56 PM, Jakub Jelinek  wrote:
> --- gcc/c-family/c-common.c.jj  2018-03-27 21:58:55.598502113 +0200
> +++ gcc/c-family/c-common.c 2018-05-05 10:55:47.951600802 +0200
> @@ -6171,7 +6171,7 @@ c_common_to_target_charset (HOST_WIDE_IN
> traditional rendering of offsetof as a macro.  Return the folded result.  
> */
>
>  tree
> -fold_offsetof_1 (tree expr, enum tree_code ctx)
> +fold_offsetof_1 (tree expr, bool nonptr, enum tree_code ctx)

The comment needs to document the NONPTR parameter.

> @@ -6287,7 +6291,7 @@ fold_offsetof_1 (tree expr, enum tree_co
>  tree
>  fold_offsetof (tree expr)
>  {
> -  return convert (size_type_node, fold_offsetof_1 (expr));
> +  return convert (size_type_node, fold_offsetof_1 (expr, true));
>  }

Since all the uses of fold_offset_1 involve converting to a particular
type, I wonder about wrapping it so that the argument for nonptr is
determined from that type.

Jason

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85693

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from Uroš Bizjak  ---
Target specific testcase that checks psadbw insn generation committed.

[PATCH, testsuite]: Add testcase to check for psadbw generation (PR 85693)

[Uros Bizjak]

Hello!

The testcase checks if the compiler is able to vectorize with psadbw
insn on x86 targets.

2018-05-08  Uros Bizjak  

PR target/85693
* gcc.target/i386/pr85693.c: New test.

Tested on x86_64-linux-gnu {,-m32}.

Committed to mainline SVN.

Uros.
Index: gcc.target/i386/pr85693.c
===
--- gcc.target/i386/pr85693.c   (nonexistent)
+++ gcc.target/i386/pr85693.c   (working copy)
@@ -0,0 +1,21 @@
+/* { dg-do compile }
+/* { dg-options "-msse2 -O2 -ftree-vectorize" } */
+
+#define N 1024
+
+int abs (int);
+
+unsigned char pix1[N], pix2[N];
+
+int foo (void)
+{
+  int i_sum = 0;
+  int i;
+
+  for (i = 0; i < N; i++)
+i_sum += abs (pix1[i] - pix2[i]);
+
+  return i_sum;
+}
+
+/* { dg-final { scan-assembler "psadbw" } } */

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85693

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May  8 16:48:43 2018
New Revision: 260047

URL: https://gcc.gnu.org/viewcvs?rev=260047=gcc=rev
Log:
PR target/85693
* gcc.target/i386/pr85693.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85693.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/85700] New: Spurious -Wstringop-truncation warning with strncat

[lopresti at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85700

Bug ID: 85700
   Summary: Spurious -Wstringop-truncation warning with strncat
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lopresti at gmail dot com
  Target Milestone: ---

Test program:

---
#include 
#include 

char buf1[256];

void append(const char *s)
{
  std::strncat(buf1, s, sizeof(buf1) - strlen(buf1) - 1);
}

void doit(int err)
{
  char tmp[256];
  std::snprintf(tmp, sizeof(tmp), " errno %d (%s)",
err, std::strerror(err));
  append(tmp);
}
---

Compile with "g++ -O3 -Wall -c test.cc".


Expected results:

No warning, as the documentation says for this idiomatic use of strncat().


Actual results:

In function ‘void append(const char*)’,
inlined from ‘void doit(int)’ at test.cc:16:9:
test.cc:8:15: warning: ‘char* strncat(char*, const char*, size_t)’ output may
b\
e truncated copying between 0 and 255 bytes from a string of length 255
[-Wstri\
ngop-truncation]
   std::strncat(buf1, s, sizeof(buf1) - strlen(buf1) - 1);
   ^~


Note that a similar program in C does not trigger the warning.

Re: libstdc++: ODR violation when using std::regex with and without -D_GLIBCXX_DEBUG

[Jonathan Wakely]

On 08/05/18 16:17 +0100, Jonathan Wakely wrote:

On 8 May 2018 at 15:45, Marc Glisse  wrote:

On Tue, 8 May 2018, Jonathan Wakely wrote:


On 8 May 2018 at 14:00, Jonathan Wakely wrote:


On 8 May 2018 at 13:44, Stephan Bergmann wrote:


I was recently bitten by the following issue (Linux, libstdc++ 8.0.1): A
process loads two dynamic libraries A and B both using std::regex, and A
is
compiled without -D_GLIBCXX_DEBUG while B is compiled with
-D_GLIBCXX_DEBUG.



This is only supported in very restricted cases.


B creates an instance of std::regex, which internally creates a
std::shared_ptr>,
where _NFA has various members of std::__debug::vector type (but which
isn't
reflected in the mangled name of that _NFA instantiation itself).

Now, when that instance of std::regex is destroyed again in library B,
the

std::shared_ptr>::~shared_ptr
destructor (and functions it in turn calls) that happens to get picked
is
the (inlined, and exported due to default visibility) instance from
library
A.  And that assumes that that _NFA instantiation has members of
non-debug
std::vector type, which causes a crash.

Should it be considered a bug that such mixture of debug and non-debug
std::regex usage causes ODR violations?



Yes, but my frank response is "don't do that".

The right fix here might be to ensure that _NFA always uses the
non-debug vector even in Debug Mode, but I'm fairly certain there are
other similar problems lurking.



N.B. I think this discussion belongs on the libstdc++ list.



Would it make sense to use the abi_tag attribute to help with that? (I
didn't really think about it, maybe it doesn't)


Yes, I think we could add it conditionally in debug mode, so that
types with members that are either std::xxx or __gnu_debug::xxx get a
different mangled name in debug mode.

For the regex _NFA type I don't think we want the debug mode checking,
because users can't access it directly so any errors are in the
libstdc++ implementation and we should have eliminated them ourselves,
not be pushing detection of those logic errors into users' programs.


I've committed this patch to do that.



For std::match_results (which derives from std::vector) it's possible
for users to use invalid iterators obtained from a match_results, so
Debug Mode can help. In that case we could decide whether to add the
abi_tag, or always derive from _GLIBCXX_STD_C::vector (i.e. the
non-debug mode one), or even provide an entire
__gnu_debug::match_results type.


"don't do that" remains the most sensible answer.


Yes, it's just asking for trouble.
commit 9e026542864d4ff5dd45ffdc43ec367e36aff8a6
Author: Jonathan Wakely 
Date:   Tue May 8 16:39:33 2018 +0100

Make std::regex automata use non-debug vector in Debug Mode

* include/bits/regex_automaton.h (_NFA_base::_M_paren_stack, _NFA):
Use normal std::vector even in Debug Mode.

diff --git a/libstdc++-v3/include/bits/regex_automaton.h b/libstdc++-v3/include/bits/regex_automaton.h
index bf51df79097..ff87dcc245d 100644
--- a/libstdc++-v3/include/bits/regex_automaton.h
+++ b/libstdc++-v3/include/bits/regex_automaton.h
@@ -210,7 +210,7 @@ namespace __detail
 _M_sub_count() const
 { return _M_subexpr_count; }
 
-std::vector   _M_paren_stack;
+_GLIBCXX_STD_C::vector _M_paren_stack;
 _FlagT_M_flags;
 _StateIdT _M_start_state;
 _SizeT_M_subexpr_count;
@@ -219,7 +219,7 @@ namespace __detail
 
   template
 struct _NFA
-: _NFA_base, std::vector<_State>
+: _NFA_base, _GLIBCXX_STD_C::vector<_State>
 {
   typedef typename _TraitsT::char_type	_Char_type;
   typedef _State<_Char_type>		_StateT;

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

--- Comment #2 from Jonathan Wakely  ---
This fixes it:

--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -736,7 +736,7 @@ finish_if_stmt_cond (tree cond, tree if_stmt)
   && !instantiation_dependent_expression_p (cond)
   /* Wait until instantiation time, since only then COND has been
 converted to bool.  */
-  && TREE_TYPE (cond) == boolean_type_node)
+  && strip_typedefs (TREE_TYPE (cond)) == boolean_type_node)
 {
   cond = instantiate_non_dependent_expr (cond);
   cond = cxx_constant_value (cond, NULL_TREE);

Re: [PATCH, rs6000] Map dcbtst, dcbtt to n2=0 for __builtin_prefetch builtin.

[Segher Boessenkool]

Hi Carl,

On Mon, May 07, 2018 at 01:34:55PM -0700, Carl Love wrote:
> This patch maps n2=0 to generate the dcbtstt mnemonic (dcbst for TH
> value of 0b1) for a write prefetch and dcbtst for n2 in range
> [1,3].  
> 
> The dcbtt mnemonic (dcbt for TH value of 0b1) is generated for a
> read prefetch when n2=0 and the dbct instruction is generated for n2 in
> range [1,3].
> 
> The ISA states that the value TH = 0b1 is a hint that the processor
> will probably soon perform a load from the addressed block. 

(s/dcbst/dcbtst/).  Yup, sounds good.

> The regression testing of the patch was done on 
> 
>powerpc64le-unknown-linux-gnu (Power 8 LE)
> 
> with no regressions.  

What ISA version is required for the TH field to do anything?  Will
it work on older machines too (just ignored)?  What assembler version
is required?

> 2018-05-07  Carl Love  
> 
> * config/rs6000/rs6000.md: Add dcbtst, dcbtt instruction generation
>   to define_insn prefetch.

* config/rs6000/rs6000.md (prefetch): Generate dcbtt and dcbtstt instructions
if operands[2] is 0.

or similar.

> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 2b15cca..7429d33 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -13233,10 +13233,19 @@
>(match_operand:SI 2 "const_int_operand" "n"))]
>""
>  {
> -  if (GET_CODE (operands[0]) == REG)
> -return INTVAL (operands[1]) ? "dcbtst 0,%0" : "dcbt 0,%0";
> -  return INTVAL (operands[1]) ? "dcbtst %a0" : "dcbt %a0";
> -}
> +  if (GET_CODE (operands[0]) == REG) {

Use REG_P please.

The correct formatting is

if (this)
  {
something;
  }
else
  {
whatever;
  }

> +if (INTVAL (operands[1]) == 0)

You can also say

  if (operands[1] == const0_rtx)

if that is easier to read.

> +  }
> + }

If you do indenting right there never is a single space indent difference
(always is even).

It's a pity we need to decide between %a0 and not.  Hardly seems worth
making another output modifier for though.


Segher

[Bug target/85683] [8 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] GCC 8  |[8 Regression] GCC 8
   |stopped using RMW (Read |stopped using RMW (Read
   |Modify Write) instructions  |Modify Write) instructions
   |on x86[_64] |on x86[_64]

--- Comment #6 from Jakub Jelinek  ---
Fixed for GCC9 so far, will backport to 8.2 after a while.

[Bug target/85683] [8/9 Regression] GCC 8 stopped using RMW (Read Modify Write) instructions on x86[_64]

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85683

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue May  8 16:17:34 2018
New Revision: 260045

URL: https://gcc.gnu.org/viewcvs?rev=260045=gcc=rev
Log:
PR target/85683
* config/i386/i386.md: Add peepholes for mem {+,-,&,|,^}= x; mem != 0
after cmpelim optimization.

* gcc.target/i386/pr49095.c: Add -masm=att to dg-options.  Add
scan-assembler-times checking that except for [fh]*xor other functions
don't use any load instructions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr49095.c

[Bug tree-optimization/85694] Generation of vectorized AVG (Average) instruction

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85694

--- Comment #3 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> Hmm, but if you have 255 + 255 + 1 then you need to use pavgw at least,
> otherwise the vectorization isn't semantically equivalent?  Or do the
> instructions compute
> the intermediate results in greater precision than 8 bits?  The specification
> doesn't seem to tell.
> 
> Can you clarify?

According to [1], intermediate result has 9 bit precision for pavgb and 17bit
precision for pavgw.

[1] http://www.felixcloutier.com/x86/PAVGB:PAVGW.html

Re: [PATCH] Add peephole2's for mem {+,-,&,|,^}= x; mem != 0 after cmpelim (PR target/85683)

[Uros Bizjak]

On Tue, May 8, 2018 at 5:21 PM, Jakub Jelinek  wrote:
> Hi!
>
> Since r247992 the cmpelim pass optimizes a few arithmetics with following
> comparisons and some of the peephole2s we have to recognize RMW instructions
> with comparisons don't trigger anymore.
> In particular, on the pr49095.c testcase in GCC 7 only 8 functions used
> load + comparison with arith + store ([fh]*xor, something to look at later),
> while in GCC 8/9 21 further functions do that.  This patch restores it to
> the GCC 7 counts.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> What about GCC 8.2?
>
> 2018-05-08  Jakub Jelinek  
>
> PR target/85683
> * config/i386/i386.md: Add peepholes for mem {+,-,&,|,^}= x; mem != 0
> after cmpelim optimization.
>
> * gcc.target/i386/pr49095.c: Add -masm=att to dg-options.  Add
> scan-assembler-times checking that except for [fh]*xor other functions
> don't use any load instructions.

OK for mainline and backport.

Thanks,
Uros.

[Bug c++/85695] [8/9 Regression] if constexpr misevaluates typedefed type value

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85695

Jonathan Wakely  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |8.2

--- Comment #1 from Jonathan Wakely  ---
Started with r258756

PR c++/84854
* semantics.c (finish_if_stmt_cond): Check if the type of the
condition
is boolean.

* g++.dg/cpp1z/constexpr-if15.C: New test.
* g++.dg/cpp1z/constexpr-if16.C: New test.

Re: Add clobbers around IFN_LOAD/STORE_LANES

[Richard Sandiford]

Richard Biener  writes:
> On Tue, May 8, 2018 at 3:25 PM, Richard Sandiford
>  wrote:
>> We build up the input to IFN_STORE_LANES one vector at a time.
>> In RTL, each of these vector assignments becomes a write to
>> subregs of the form (subreg:VEC (reg:AGGR R)), where R is the
>> eventual input to the store lanes instruction.  The problem is
>> that RTL isn't very good at tracking liveness when things are
>> initialised piecemeal by subregs, so R tends to end up being
>> live on all paths from the entry block to the store.  This in
>> turn leads to unnecessary spilling around calls, as well as to
>> excess register pressure in vector loops.
>>
>> This patch adds gimple clobbers to indicate the liveness of the
>> IFN_STORE_LANES variable and makes sure that gimple clobbers are
>> expanded to rtl clobbers where useful.  For consistency it also
>> uses clobbers to mark the point at which an IFN_LOAD_LANES
>> variable is no longer needed.
>>
>> Tested on aarch64-linux-gnu (with and without SVE), aaarch64_be-elf
>> and x86_64-linux-gnu.  OK to install?
>
> Minor comment inline.

Thanks, fixed.

> Also it looks like clobbers are at the moment all thrown away during
> RTL expansion?  Do the clobbers we generate with this patch eventually
> get collected somehow if they turn out to be no longer necessary?
> How many of them do we generate?  I expect not many decls get
> expanded to registers and if they are most of them are likely
> not constructed piecemail  - thus, maybe we should restrict ourselves
> to non-scalar typed lhs?  So, change it to
>
>   if (DECL_P (lhs)
>   && (AGGREGATE_TYPE_P (TREE_TYPE (lhs)) // but what about
> single-element aggregates?
>  || VECTOR_TYPE_P (TREE_TYPE (lhs))
>  || COMPLEX_TYPE_P (TREE_TYPE (lhs

How about instead deciding based on whether the pseudo register spans a
single hard register or multiple hard registers, as per the patch below?
The clobber is only useful if the pseudo register can be partially
modified via subregs.

This could potentially also help with any large single-element
aggregrates that get broken down into word-sized subreg ops.

> The vectorizer part is ok with the minor adjustment pointed out below.  Maybe
> you want to split this patch while we discuss the RTL bits.

OK, thanks.  I'll keep it as one patch for applying purposes,
but snipped the approved bits below.

Richard


2018-05-08  Richard Sandiford  

gcc/
* cfgexpand.c (expand_clobber): New function.
(expand_gimple_stmt_1): Use it.

Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c 2018-05-08 16:50:31.815501502 +0100
+++ gcc/cfgexpand.c 2018-05-08 16:50:31.997495804 +0100
@@ -3582,6 +3582,26 @@ expand_return (tree retval, tree bounds)
 }
 }
 
+/* Expand a clobber of LHS.  If LHS is stored it in a multi-part
+   register, tell the rtl optimizers that its value is no longer
+   needed.  */
+
+static void
+expand_clobber (tree lhs)
+{
+  if (DECL_P (lhs))
+{
+  rtx decl_rtl = DECL_RTL_IF_SET (lhs);
+  if (decl_rtl && REG_P (decl_rtl))
+   {
+ machine_mode decl_mode = GET_MODE (decl_rtl);
+ if (maybe_gt (GET_MODE_SIZE (decl_mode),
+   REGMODE_NATURAL_SIZE (decl_mode)))
+   emit_clobber (decl_rtl);
+   }
+}
+}
+
 /* A subroutine of expand_gimple_stmt, expanding one gimple statement
STMT that doesn't require special handling for outgoing edges.  That
is no tailcalls and no GIMPLE_COND.  */
@@ -3687,7 +3707,7 @@ expand_gimple_stmt_1 (gimple *stmt)
if (TREE_CLOBBER_P (rhs))
  /* This is a clobber to mark the going out of scope for
 this LHS.  */
- ;
+ expand_clobber (lhs);
else
  expand_assignment (lhs, rhs,
 gimple_assign_nontemporal_move_p (

[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85699

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8 regression]  |[9 regression]
   |gcc.dg/nextafter-2.c fail   |gcc.dg/nextafter-2.c fail

--- Comment #1 from Jakub Jelinek  ---
First of all, this test isn't present on 8 branch at all, only trunk.
And, this exact testcase uses -fno-builtin and thus tests the library, so if it
fails, likely your libc is buggy.
Which exact subtest fails for you?
E.g. replace
#define CHECK(x) if (!(x)) __builtin_abort ()
with
#define CHECK(x) if (!(x)) __builtin_printf ("bug at %d %s\n", __LINE__, #x);
and see what it prints?

Incremental LTO linking part 8: testsuite compensation

[Jan Hubicka]

Hi,
most testcases are written with assumption that -r will trigger code generation.
To make them still meaningful they need nolto-rel.  Bootstrapped/regtested 
x86_64-linux
with the rest of incremental link changes.

Honza

2018-05-08  Jan Hubicka  

* testsuite/g++.dg/lto/20081109-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081118_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081119-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081120-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081120-2_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081123_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081204-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20081219_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20090302_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20090313_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20091002-2_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20091002-3_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20091026-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20100724-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20101010-4_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20101015-2_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/20110311-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr45621_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr48042_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr48354-1_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr54625-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr54625-2_0.c: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/lto/pr68811_0.C: Add -flinker-output=nolto-rel.
* testsuite/g++.dg/torture/pr43760.C: New test. Add 
-flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081120-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081120-2_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081126_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081204-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081204-2_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081212-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20081224_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20090116_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20090126-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20090126-2_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20090206-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20090219_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20091013-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20091014-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20091015-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20091016-1_0.c: Add -flinker-output=nolto-rel.
* testsuite/gcc.dg/lto/20091020-1_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20091020-2_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20091027-1_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20100426_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20100430-1_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20100603-1_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20100603-2_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20100603-3_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/20111213-1_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr45736_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr52634_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr54702_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr59323-2_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr59323_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr60820_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr81406_0.c: Add -flinker-output-nolto-rel.
* testsuite/gcc.dg/lto/pr83388_0.c: Add -flinker-output-nolto-rel.
* testsuite/gfortran.dg/lto/20091016-1_0.f90: Add 
-flinker-output-nolto-rel.
* testsuite/gfortran.dg/lto/20091028-1_0.f90: Add 
-flinker-output-nolto-rel.
* testsuite/gfortran.dg/lto/20091028-2_0.f90: Add 
-flinker-output-nolto-rel.
* testsuite/gfortran.dg/lto/pr46911_0.f: Add 

Incremental LTO linking part 7: documentation

[Jan Hubicka]

Hi,
this patch adds documentation of -flinker-output.

* doc/invoke.texi (-flinker-output): Document
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 260042)
+++ doc/invoke.texi (working copy)
@@ -12208,6 +12208,50 @@
 object file names should not be used as arguments.  @xref{Overall
 Options}.
 
+@item -flinker-output=@var{type}
+@opindex -flinker-output
+This option controls the code generation of the link time optimizer.  By
+default the linker output is determined by the linker plugin automatically. For
+debugging the compiler and in the case of incremental linking to non-lto object
+file is desired, it may be useful to control the type manually.
+
+If @var{type} is @samp{exec} the code generation is configured to produce 
static
+binary. In this case @option{-fpic} and @option{-fpie} are both disabled.
+
+If @var{type} is @samp{dyn} the code generation is configured to produce shared
+library. In this case @option{-fpic} or @option{-fPIC} is preserved, but not
+enabled automatically.  This makes it possible to build shared libraries 
without
+position independent code on architectures this is possible, i.e. on x86.
+
+If @var{type} is @samp{pie} the code generation is configured to produce
+@option{-fpie} executable. This result in similar optimizations as @samp{exec}
+except that @option{-fpie} is not disabled if specified at compilation time.
+
+If @var{type} is @samp{rel} the compiler assumes that incremental linking is
+done.  The sections containing intermediate code for link-time optimization are
+merged, pre-optimized, and output to the resulting object file. In addition, if
+@option{-ffat-lto-objects} is specified the binary code is produced for future
+non-lto linking. The object file produced by incremental linking will be 
smaller
+than a static library produced from the same object files.  At link-time the
+result of incremental linking will also load faster to compiler than a static
+library assuming that majority of objects in the library are used.
+
+Finally @samp{nolto-rel} configure compiler to for incremental linking where
+code generation is forced, final binary is produced and the intermediate code
+for later link-time optimization is stripped. When multiple object files are
+linked together the resulting code will be optimized better than with link time
+optimizations disabled (for example, the cross-module inlining will happen),
+most of benefits of whole program optimizations are however lost. 
+
+During the incremental link (by @option{-r}) the linker plugin will default to
+@option{rel}. With current interfaces to GNU Binutils it is however not
+possible to link incrementally LTO objects and non-LTO objects into a single
+mixed object file.  In the case any of object files in incremental link can not
+be used for link-time optimization the linker plugin will output warning and
+use @samp{nolto-rel}. To maintain the whole program optimization it is
+recommended to link such objects into static library instead. Alternatively it
+is possible to use H.J. Lu's binutils with support for mixed objects.
+
 @item -fuse-ld=bfd
 @opindex fuse-ld=bfd
 Use the @command{bfd} linker instead of the default linker.

Incremental LTO linking part 6: dwarf2out support

[Jan Hubicka]

Hi,
this patch tells dwarf2out that it can have early debug not only in WPA mode
but also when incrementally linking. This prevents ICE on almost every testcase
compiled with -g.

Bootstrapped/regtested x86_64-linux with rest of incremental linking patchet.
Makes sense?

Honza

* dwarf2out.c (dwarf2out_die_ref_for_decl,
darf2out_register_external_decl): Support incremental link.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 260042)
+++ dwarf2out.c (working copy)
@@ -5822,7 +5822,7 @@
 {
   dw_die_ref die;
 
-  if (flag_wpa && !decl_die_table)
+  if ((flag_wpa || flag_incremental_link == 2) && !decl_die_table)
 return false;
 
   if (TREE_CODE (decl) == BLOCK)
@@ -5832,10 +5832,10 @@
   if (!die)
 return false;
 
-  /* During WPA stage we currently use DIEs to store the
- decl <-> label + offset map.  That's quite inefficient but it
- works for now.  */
-  if (flag_wpa)
+  /* During WPA stage and incremental linking we currently use DIEs
+ to store the decl <-> label + offset map.  That's quite inefficient
+ but it works for now.  */
+  if (flag_wpa || flag_incremental_link == 2)
 {
   dw_die_ref ref = get_AT_ref (die, DW_AT_abstract_origin);
   if (!ref)
@@ -5886,7 +5886,7 @@
   if (debug_info_level == DINFO_LEVEL_NONE)
 return;
 
-  if (flag_wpa && !decl_die_table)
+  if ((flag_wpa || flag_incremental_link == 2) && !decl_die_table)
 decl_die_table = hash_table::create_ggc (1000);
 
   dw_die_ref die
@@ -5921,7 +5921,8 @@
parent = BLOCK_DIE (ctx);
   else if (TREE_CODE (ctx) == TRANSLATION_UNIT_DECL
   /* Keep the 1:1 association during WPA.  */
-  && !flag_wpa)
+  && !flag_wpa
+  && flag_incremental_link != 2)
/* Otherwise all late annotations go to the main CU which
   imports the original CUs.  */
parent = comp_unit_die ();
@@ -5942,7 +5943,7 @@
   switch (TREE_CODE (decl))
 {
 case TRANSLATION_UNIT_DECL:
-  if (! flag_wpa)
+  if (! flag_wpa && flag_incremental_link != 2)
{
  die = comp_unit_die ();
  dw_die_ref import = new_die (DW_TAG_imported_unit, die, NULL_TREE);

Incremental LTO linking part 5: symtab and compilation driver support

[Jan Hubicka]

Hi,
this patch adds the symtab support for LTO incremental linking. Most of the
code path is same for both modes of incremental link except hat we want to
produce LTO object file rather than compile down to assembly.

Only non-obvious changes are in ipa.c where I hit a bug where we stream in 
initializers that are going to be eliminated form the symbol table for no
good reasons.

Bootstrapped/regtested x86_64-linux with rest of the incremental link patchset.

Honza

* passes.c (ipa_write_summaries): Only modify statements if body
is in memory.
* cgraphunit.c (ipa_passes): Also produce intermeidate code when
incrementally linking.
(ipa_passes): Likewise.
* lto-cgraph.c (lto_output_node): When incrementally linking do not
pass down resolution info.
* common.opt (flag_incremental_link): Update info.
* gcc.c (plugin specs): Turn flinker-output=* to
-plugin-opt=-linker-output-known
* toplev.c (compile_file): Also cut compilation when doing incremental
link.
* flag-types. (enum lto_partition_model): Add
LTO_LINKER_OUTPUT_NOLTOREL.
(invoke.texi): Add -flinker-output docs.
* ipa.c (symbol_table::remove_unreachable_nodes): Handle LTO incremental
link same way as WPA; do not stream in dead initializers.

* lang.opt (lto_linker_output): Add nolto-rel.
* lto-lang.c (lto_post_options): Handle LTO_LINKER_OUTPUT_REL
and LTO_LINKER_OUTPUT_NOLTOREL.
(lto_init): Generate lto when doing incremental link.
* lto.c (lto_precess_name): Add lto1-inclink.
Index: cgraphunit.c
===
--- cgraphunit.c(revision 260042)
+++ cgraphunit.c(working copy)
@@ -2452,8 +2452,10 @@
   if (flag_generate_lto || flag_generate_offload)
 targetm.asm_out.lto_start ();
 
-  if (!in_lto_p)
+  if (!in_lto_p || flag_incremental_link == 2)
 {
+  if (!quiet_flag)
+   fprintf (stderr, "Streaming LTO\n");
   if (g->have_offload)
{
  section_name_prefix = OFFLOAD_SECTION_NAME_PREFIX;
@@ -2472,7 +2474,9 @@
   if (flag_generate_lto || flag_generate_offload)
 targetm.asm_out.lto_end ();
 
-  if (!flag_ltrans && (in_lto_p || !flag_lto || flag_fat_lto_objects))
+  if (!flag_ltrans
+  && ((in_lto_p && flag_incremental_link != 2)
+ || !flag_lto || flag_fat_lto_objects))
 execute_ipa_pass_list (passes->all_regular_ipa_passes);
   invoke_plugin_callbacks (PLUGIN_ALL_IPA_PASSES_END, NULL);
 
@@ -2559,7 +2563,8 @@
 
   /* Do nothing else if any IPA pass found errors or if we are just streaming 
LTO.  */
   if (seen_error ()
-  || (!in_lto_p && flag_lto && !flag_fat_lto_objects))
+  || ((!in_lto_p || flag_incremental_link == 2)
+ && flag_lto && !flag_fat_lto_objects))
 {
   timevar_pop (TV_CGRAPHOPT);
   return;
Index: common.opt
===
--- common.opt  (revision 260042)
+++ common.opt  (working copy)
@@ -48,7 +48,8 @@
 
 ; This variable is set to non-0 only by LTO front-end.  1 indicates that
 ; the output produced will be used for incrmeental linking (thus weak symbols
-; can still be bound).
+; can still be bound) and 2 indicates that the IL is going to be linked and
+; and output to LTO object file.
 Variable
 int flag_incremental_link = 0
 
Index: flag-types.h
===
--- flag-types.h(revision 260042)
+++ flag-types.h(working copy)
@@ -289,6 +289,7 @@
 enum lto_linker_output {
   LTO_LINKER_OUTPUT_UNKNOWN,
   LTO_LINKER_OUTPUT_REL,
+  LTO_LINKER_OUTPUT_NOLTOREL,
   LTO_LINKER_OUTPUT_DYN,
   LTO_LINKER_OUTPUT_PIE,
   LTO_LINKER_OUTPUT_EXEC
Index: gcc.c
===
--- gcc.c   (revision 260042)
+++ gcc.c   (working copy)
@@ -961,6 +961,7 @@
 -plugin %(linker_plugin_file) \
 -plugin-opt=%(lto_wrapper) \
 -plugin-opt=-fresolution=%u.res \
+%{flinker-output=*:-plugin-opt=-linker-output-known} \
 %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} 
\
 }" PLUGIN_COND_CLOSE
 #else
Index: ipa.c
===
--- ipa.c   (revision 260042)
+++ ipa.c   (working copy)
@@ -130,9 +130,9 @@
 constant folding.  Keep references alive so partitioning
 knows about potential references.  */
  || (VAR_P (node->decl)
- && flag_wpa
- && ctor_for_folding (node->decl)
-!= error_mark_node
+ && (flag_wpa || flag_incremental_link == 2)
+ && dyn_cast  (node)
+  ->ctor_useable_for_folding_p ()
{
  /* Be sure that we will not optimize out alias target