Re: [PATCH 0/2] add unique_ptr class

[Trevor Saunders]

HI,

figured I'd ping this to see if we can come to some concensus, I don't
care much what we choose as a namespace, I just want to get this in so
we can use it more.

On Fri, Aug 11, 2017 at 09:43:21PM +0100, Jonathan Wakely wrote:
> On 05/08/17 20:05 +0100, Pedro Alves wrote:
> > On 08/04/2017 07:52 PM, Jonathan Wakely wrote:
> > > On 31/07/17 19:46 -0400, tbsaunde+...@tbsaunde.org wrote:
> > > > I've been saying I'd do this for a long time, but I'm finally getting to
> > > > importing the C++98 compatable unique_ptr class Pedro wrote for gdb a
> > > > while
> > > > back.
> > 
> > Thanks a lot for doing this!
> > 
> > > I believe the gtl namespace also comes from Pedro, but GNU template
> > > library seems as reasonable as any other name I can come up with.
> > 
> > Yes, I had suggested it here:
> > 
> >  https://sourceware.org/ml/gdb-patches/2017-02/msg00197.html
> > 
> > > 
> > > If it's inspired by "STL" then can we call it something else?
> > > 
> > > std::unique_ptr is not part of the STL, because the STL is a library
> > > of containers and algorithms from the 1990s. std::unique_ptr is
> > > something much newer that doesn't originate in the STL.
> > > 
> > > STL != C++ Standard Library
> > 
> > That I knew, but gtl was not really a reference to the
> > C++ Standard Library, so I don't see the problem.  It was supposed to
> > be the name of a library which would contain other C++ utilities
> > that would be shared by different GNU toolchain components.
> > Some of those bits would be inspired by, or be straight backports of
> > more-recent standards, but it'd be more than that.
> > 
> > An option would be to keep "gtl" as acronym, but expand it
> > to "GNU Toolchain Library" instead.
> 
> OK, that raises my hackles less. What bothered me was an apparent
> analogy to "STL" when that isn't even the right name for the library
> that provides the original unique_ptr.
> 
> And "template library" assumes we'd never add non-templates to it,
> which is unlikely (you already mentioned offset_type, which isn't a
> template).

Well, "GNU Toolchain Library" doesn't include template anywhere in the
name ;)

> It seems odd to make up a completely new acronym for this though,
> rather than naming it after something that exists already in the
> toolchain codebases.

That's fair, I suppose we could use namespace libiberty, but that's kind
of long.

> > For example, gdb has been growing C++ utilities under gdb/common/
> > that might be handy for gcc and other projects too, for example:
> > 
> > - enum_flags (type-safe enum bit flags)
> > - function_view (non-owning reference to callables)
> > - offset_type (type safe / distinct integer types to represent offsets
> >into anything addressable)
> > - optional (C++11 backport of libstdc++'s std::optional)
> > - refcounted_object.h (intrusively-refcounted types)
> > - scoped_restore (RAII save/restore of globals)
> > - an allocator that default-constructs using default-initialization
> >   instead of value-initialization.
> > 
> > and more.
> > 
> > GCC OTOH has code that might be handy for GDB as well, like for
> > example the open addressing hash tables (hash_map/hash_table/hash_set
> > etc.).
> > 
> > Maybe Gold could make use of some of this code too.  There
> > are some bits in Gold that might be useful for (at least) GDB
> > too.  For example, its Stringpool class.
> > 
> > I think there's a lot of scope for sharing more code between the
> > different components of the GNU toolchain, even beyond general
> > random utilities and data structures, and I'd love to see us
> > move more in that direction.
> > 
> > > If we want a namespace for GNU utilities, what's wrong with "gnu"?
> > 
> > That'd be an "obvious" choice, and I'm not terribly against it,
> > though I wonder whether it'd be taking over a name that has a wider
> > scope than intended?  I.e., GNU is a larger set of projects than the
> > GNU toolchain.  For example, there's Gnulib, which already compiles
> > as libgnu.a / -lgnu, which might be confusing.  GCC doesn't currently
> > use Gnulib, but GDB does, and, there was work going on a while ago to
> > make GCC use gnulib as well.
> 
> Good point. "gnutools" might be more accurate, but people might object
> to adding 10 extra characters for "gnutools::".

yeah, 3 or 4 characters seems to be the length of namespace names that
other people like, and its still fairly reasonable to use the fully
qualified name then.

> Naming is important, especially for a whole namespace (not just a
> single type) so I do think it's worth spending time getting it right.

True, though as far as I'm aware we wouldn't be promising any kind of
stability so would be free to rename it if we felt the need.

> But I could live with gtl as long as nobody ever says "GTL is the GNU
> STL" or mentions "gtl" and STL in the same breath :-)

heh, well feel free to be annoyed if I do it at least ;)

thanks

Trev

> 
> 

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[zeccav at gmail dot com]

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

--- Comment #24 from Vittorio Zecca  ---
I confirm this bug prevents building the Linux kernel 4.12 with gcc trunk
251201.
gcc 7.2 seems to build the kernel just fine.

[PING] [PATCH] detect incompatible aliases (PR c/81854)

[Martin Sebor]

Jeff, this is the other attribute patch I mentioned the other
day:

  https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01103.html

The Glibc and libstdc++ changes have already been committed:
  https://sourceware.org/ml/glibc-cvs/2017-q3/msg00587.html
  https://gcc.gnu.org/ml/gcc-cvs/2017-08/msg00459.html

Thanks
Martin

On 08/17/2017 09:21 PM, Martin Sebor wrote:

Joseph, while looking into implementing enhancement your request
pr81824 I noticed that GCC silently accepts incompatible alias
declarations (pr81854) so as sort of a proof-concept for the
former I enhanced the checking already done for other kinds of
incompatibilities to also detect those mentioned in the latter
bug.  Attached is this patch, tested on x85_64-linux.

Jonathan, the patch requires suppressing the warning in libstdc++
compatibility symbol definitions in compatibility.cc.  I couldn't
find a way to do it without the suppression but I'd be happy to
try again if you have an idea for how.

As an example, the patch lets GCC detect mistakes like:

   size_t __attribute__ ((ifunc ("bar_resolver")))
   bar (void*, const void*, size_t);

   void* fast_bar (void *d, const void *s, size_t n) { ... }
   void* slow_bar (void *d, const void *s, size_t n) { ... }

   void* bar_resolver (void)
   {
  return fast ? _bar : _bar;
   }

By complaining that the ifunc resolver should return a function
pointer it makes the programmer change the declaration of the
resolver to one of:

   __typeof__ (bar)* bar_resolver (void) { ... }

or

   __typeof__ (fast_bar)* bar_resolver (void) { ... }

which then triggers either -Wincompatible-pointer-types or
-Wattributes, respectively.  (I used the latter warning in
my patch but maybe the former would be more appropriate).

Martin

PS A documentation-only patch to update the description of
attribute ifunc was posted separately here:
   https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01095.html

PPS To make use of this checking (and compile without the new
warnings) Glibc needs the following patch:

diff --git a/include/libc-symbols.h b/include/libc-symbols.h
index fe3ab81..5413e56 100644
--- a/include/libc-symbols.h
+++ b/include/libc-symbols.h
@@ -790,7 +790,8 @@ for linking")

 /* Helper / base  macros for indirect function symbols.  */
 #define __ifunc_resolver(type_name, name, expr, arg, init, classifier) \
-  classifier inhibit_stack_protector void *name##_ifunc (arg)
   \
+  classifier inhibit_stack_protector   \
+  __typeof (type_name) *name##_ifunc (arg) \
   {\
 init ();   \
 __typeof (type_name) *res = expr;  \

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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

--- Comment #13 from Jack Howarth  ---
The following hack allows gcc 7.2.0 to complete the 3 stage bootstrap of the
c,c++,fortran,lto,objc,obj-c++ language set under High Sierra on an APFS
volume...

diff -uNr gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in
gcc-7.2.0/libstdc++-v3/include/Makefile.in
--- gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in 2017-07-25
14:05:07.0 -0400
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 12:22:08.0
-0400
@@ -1764,6 +1764,8 @@
 @GLIBCXX_HOSTED_TRUE@install-data-local: install-headers
 @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers

+.NOTPARALLEL: install-headers
+
 # This is a subset of the full install-headers rule.  We only need ,
 # , , , , , , ,
 # , , , , ,

Re: [RFC, vectorizer] Allow single element vector types for vector reduction operations

[Andreas Schwab]

On Aug 30 2017, "Jon Beniston" <j...@beniston.com> wrote:

> gcc/
> 2017-08-30  Jon Beniston  <j...@beniston.com>
> Richard Biener  <rguent...@suse.de>
>
> diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
> index cfdb72c..5ebeac2 100644
> --- a/gcc/tree-vect-patterns.c
> +++ b/gcc/tree-vect-patterns.c
> @@ -4150,7 +4150,7 @@ vect_pattern_recog_1 (vect_recog_func *recog_func,
>loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
>   
>if (VECTOR_BOOLEAN_TYPE_P (type_in)
> -  || VECTOR_MODE_P (TYPE_MODE (type_in)))
> +  || VECTOR_TYPE_P (type_in))
>  {
>/* No need to check target support (already checked by the pattern
>   recognition function).  */
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 013fb1f..fc62efb 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -9098,7 +9098,8 @@ get_vectype_for_scalar_type_and_size (tree
> scalar_type, unsigned size)
>else
>  simd_mode = mode_for_vector (inner_mode, size / nbytes);
>nunits = GET_MODE_SIZE (simd_mode) / nbytes;
> -  if (nunits <= 1)
> +  /* NOTE: nunits == 1 is allowed to support single element vector types.
> */
> +  if (nunits < 1)
>  return NULL_TREE;
>  
>vectype = build_vector_type (scalar_type, nunits);
>
>
>

That breaks vect/pr68577.c on aarch64.

during RTL pass: expand
/opt/gcc/gcc-20170902/gcc/testsuite/gcc.dg/vect/pr68577.c: In function 
'slp_test':
/opt/gcc/gcc-20170902/gcc/testsuite/gcc.dg/vect/pr68577.c:20:12: internal 
compiler error: in simplify_subreg, at simplify-rtx.c:6050
0xb55983 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc/simplify-rtx.c:6049
0xb595f7 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc/simplify-rtx.c:6278
0x81d277 store_bit_field_1
../../gcc/expmed.c:798
0x81d55f store_bit_field(rtx_def*, unsigned long, unsigned long, unsigned long, 
unsigned long, machine_mode, rtx_def*, bool)
../../gcc/expmed.c:1133
0x840bf7 store_field
../../gcc/expr.c:6950
0x84792f store_constructor_field
../../gcc/expr.c:6142
0x83edbf store_constructor
../../gcc/expr.c:6726
0x840443 expand_constructor
../../gcc/expr.c:8027
0x82d5bf expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10133
0x82eaeb expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9819
0x82dadf expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10942
0x82eaeb expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9819
0x83d197 expand_expr
../../gcc/expr.h:276
0x83d197 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:4971
0x71e2f3 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3653
0x71e2f3 expand_gimple_stmt
../../gcc/cfgexpand.c:3751
0x721cdb expand_gimple_basic_block
../../gcc/cfgexpand.c:5750
0x726b07 execute
../../gcc/cfgexpand.c:6357

Andreas.

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

[Bug target/53687] _mm_cmpistri generates redundant movslq %ecx,%rcx on x86-64

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #1 from Peter Cordes  ---
This behaviour is pretty understandable.  gcc doesn't know that the
return-value range is only 0-16, i.e. guaranteed non-negative integers.  Since
you used a signed int offset, makes sense that it *sign* extends from 32 to 64.

If you use  unsigned offset, the missed-optimization becomes more obvious. 
gcc7.2 still uses a  movl%ecx, %ecx  to zero-extend into rcx.

https://godbolt.org/g/wWvqpa

(Incidentally, same,same is the worst possible choice of registers for Intel
CPUs.  It means the mov can never be eliminated in the rename stage, and always
needs an execution port with non-zero latency.)

Even uintptr_t offset doesn't avoid it, because then the conversion from the
intrinsic to the variable results in sign-extension up to 64-bit.  It treats it
exactly like a function that returns int, which in the SysV ABI is allowed to
have garbage in the upper32.


(BTW, this use of flags from inline asm is not guaranteed to be safe.  Nothing
stops the optimizer from doing the pointer-increment after the `pcmpistri`,
which would clobber flags.  You could do `pcmpistri` inside the asm and produce
a uintptr_t output operand, except that doesn't work with goto.  So really you
should write the whole loop in inline asm)


Or better, don't use inline asm at all: gcc can CSE _mm_cmpistri with
_mm_cmpistra, so you can just use the intrinsic twice to get multiple operands,
and it will compile to a single instruction.  This is like using `/` and `%`
operators to get both results of a `div`.

[Bug target/81995] [8.0 Regression] gcc/reg-stack.c:2073:1: error: unrecognizable insn:

[gerald at pfeifer dot com]

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

Gerald Pfeifer  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #4 from Gerald Pfeifer  ---
Confirmed as fixed.

[Bug fortran/82086] New: namelist read with repeat count fails when item is member of array of structures

[jsberg at bnl dot gov]

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

Bug ID: 82086
   Summary: namelist read with repeat count fails when item is
member of array of structures
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsberg at bnl dot gov
  Target Milestone: ---

This program:

program t170902a
  implicit none
  type t
 character(64) :: c=''
  end type t
  type(t), dimension(16) :: ta
  namelist /n/ta

  open(1,file='170902a.txt')
  read(1,nml=n)
end program t170902a

With this text in '170902a.txt':


 ta(1:8)%c = 8*'bogus'
/

Gives the following on execution:

At line 10 of file 170902a.f90 (unit = 1, file = '170902a.txt')
Fortran runtime error: Repeat count too large for namelist object ta%c

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x

Compiler command line:

gfortran.exe -Wall -Wextra 170902a.f90 -o 170902a.exe

gcc -v:

Using built-in specs.
COLLECT_GCC=\mingw64-7_1_0\bin\gfortran.exe
COLLECT_LTO_WRAPPER=C:/mingw64-7_1_0/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw710/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-win32-seh-rev2, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw710/prerequisites/x86_64-zlib-static/include
-I/c/mingw710/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw710/x86_64-710-win32-seh-rt_v5-rev2/mingw64/opt/lib
-L/c/mingw710/prerequisites/x86_64-zlib-static/lib
-L/c/mingw710/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: win32
gcc version 7.1.0 (x86_64-win32-seh-rev2, Built by MinGW-W64 project)

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

--- Comment #13 from Georg-Johann Lay  ---
(In reply to Matthijs Kooijman from comment #12)
> Apologies if this is an obvious question, but I'm not familiar with gcc/g++
> internals. Georg-Johann, you say this requires address space support in c++,
> but I'm not sure I follow you there. Two things:
> You say WG21 will never add AS support to C++, but also say that language
> support for AS is not needed, only internal support in gcc/g++. So that
> means what WG21 does is not relevant for vtable handling in particular?

Front-end maintainers usually follow the WGs in what they implement and are
willing to approve.  When you propose some non-standard extensions — even as a
working patch with testcases, documentation, etc. — the maintainers will reject
it.  They fear it might be inconsistent with existing features or the code
"just being dropped" and maintenance burden is up to them.

Adding AS in the c++ front-end without exposing them to the language (i.e. you
still can't use __flash in c++) will be rejected by the maintainers as "too
specific", see below for similar case.

> Even if AS would not be used, what prevents g++ from emitting the vtables
> in the `progmem.data` section and generating vtable-invocation code using
> LPM instructions?

vtables are generated by the c++ front-end.  Some hacking in the avr back-end
might be enough to but these tables in flash, but you cannot access it
correctly without qualifying all accesses.  These qualifiers must be added by
the c++ FE so that any pointers / accesses / (internal) variables derived from
it use the correct AS.

We just saw the maintainers rejecting PR49857 (which is about putting
tree-switch-converted lookup-tables into flash / named AS) as "too specific". 
The avr part was approved.  The only change to the middle-end was a well
documented hook (statically) invoked only once in tree-switch-conversion
module.  The maintainers proposed "more generic" solution; none of proposals
would work and none of them would be more generic because the only object
that's opt to such optimization is CSWTCH from tree-switch-conversion.

I got the impression it wasn't even understood why one cannot just patch
sections.  And patching ASes won't work if any pass might copy a pointer. The
tables must be read-only, in static storage, not public, not weak, not
linkonce, not comdat, and must be artificial, i.e. cooked up by the compiler
(otherwise inline asm will break).  So the only use case was CSWTCH anyway...

For details see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49857#c17

vtables are even more restrictive because it would be an ABI change: all
modules accessing the vtable must agree upon it's AS, i.e. you cannot specify
the AS per command option.

> or some gcc-specific attribute on a class?

Attributes won't work — due to the same reason for why progmem does not work
with c / c++: with progmem: you'd need inline asm.  And because vtables are
artificial, you'll never gat a hand on them.

And to be honest:  My current impression is that avr-gcc is a dead horse. 
http://gcc.gnu.org/ml/gcc/2017-07/msg00224.html

Maintainers are proposing to deprecate bunch of backends as a side effect of
deprecating two essential features that are "old code" and not used by the
targets they get their bucks for.  Sooner or later they will succeed,
effectively throwing bunch of targets into the dust bin.

With that perspective and my recent impressions, I think working on avr-gcc has
become a waste of time.

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[zeccav at gmail dot com]

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

--- Comment #10 from Vittorio Zecca  ---
A related issue is the following:

/* UB sanitizer should detect undefined negation of LLONG_MIN */
/* must be compiled with -fsanitize=undefined and run */
#include 
int main()
{
long long int llnum=LLONG_MIN;
unsigned  int unum;
unum = - llnum;/*negation of -9223372036854775808 cannot be represented in type
'long long int'*/
return 0;
}

Or should I open a new bug?

Re: assuming signed overflow does not occur

[Bruce Korb]

Per request, the inlined functions

On Sat, Sep 2, 2017 at 12:59 PM, Bruce Korb  wrote:
> I know about all these theoretical possibilities of numbers behaving
> in strange ways when arithmetic optimizations assume that signed
> overflow won't occur when they actually might. Yep, it creates subtle
> bugs. The warning is worthwhile. Still and all:
>
> 485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
> 486 if (tvdiff.tv_sec != 0) {
>
> systime.c: In function 'step_systime':
> systime.c:486:5: warning: assuming signed overflow does not occur when
> simplifying conditional to constant [-Wstrict-overflow]
>
> What possible optimization might be going on to cause an overflow
> problem when I simply want to know if the "tv_sec" field is zero or
> not? (BTW, in current source, "tvdiff" is a structure that is returned
> by abs_tval())
>
> $ gcc --version
> gcc (SUSE Linux) 4.8.5
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


/* make sure microseconds are in nominal range */
static inline struct timeval
normalize_tval(
struct timeval  x
)
{
longz;

if (x.tv_usec < -3l * MICROSECONDS ||
x.tv_usec >  3l * MICROSECONDS  ) {
z = x.tv_usec / MICROSECONDS;
x.tv_usec -= z * MICROSECONDS;
x.tv_sec += z;
}

if (x.tv_usec < 0)
do {
x.tv_usec += MICROSECONDS;
x.tv_sec--;
} while (x.tv_usec < 0);
else if (x.tv_usec >= MICROSECONDS)
do {
x.tv_usec -= MICROSECONDS;
x.tv_sec++;
} while (x.tv_usec >= MICROSECONDS);

return x;
}
/* x = a - b */
static inline struct timeval
sub_tval(
struct timeval  a,
struct timeval  b
)
{
struct timeval  x;

x = a;
x.tv_sec -= b.tv_sec;
x.tv_usec -= b.tv_usec;

return normalize_tval(x);
}

/* x = abs(a) */
static inline struct timeval
abs_tval(
struct timeval  a
)
{
struct timeval  c;

c = normalize_tval(a);
if (c.tv_sec < 0) {
if (c.tv_usec != 0) {
c.tv_sec = -c.tv_sec - 1;
c.tv_usec = MICROSECONDS - c.tv_usec;
} else {
c.tv_sec = -c.tv_sec;
}
}

return c;
}

And the larger code fragment:


/* get the current time as l_fp (without fuzz) and as struct timeval */
get_ostime();
fp_sys = tspec_stamp_to_lfp(timets);
tvlast.tv_sec = timets.tv_sec;
tvlast.tv_usec = (timets.tv_nsec + 500) / 1000;

/* get the target time as l_fp */
L_ADD(_sys, _ofs);

/* unfold the new system time */
timetv = lfp_stamp_to_tval(fp_sys, );

/* now set new system time */
if (ntp_set_tod(, NULL) != 0) {
msyslog(LOG_ERR, "step-systime: %m");
if (enable_panic_check && allow_panic) {
msyslog(LOG_ERR, "step_systime: allow_panic is TRUE!");
}
return FALSE;
}

/* <--- time-critical path ended with 'ntp_set_tod()' <--- */

sys_residual = 0;
lamport_violated = (step < 0);
if (step_callback)
(*step_callback)();

tvdiff = abs_tval(sub_tval(timetv, tvlast));
if (tvdiff.tv_sec != 0) {

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on trunk and all open release branches. Closing.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 20:13:49 2017
New Revision: 251620

URL: https://gcc.gnu.org/viewcvs?rev=251620=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

assuming signed overflow does not occur

[Bruce Korb]

I know about all these theoretical possibilities of numbers behaving
in strange ways when arithmetic optimizations assume that signed
overflow won't occur when they actually might. Yep, it creates subtle
bugs. The warning is worthwhile. Still and all:

485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
486 if (tvdiff.tv_sec != 0) {

systime.c: In function 'step_systime':
systime.c:486:5: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]

What possible optimization might be going on to cause an overflow
problem when I simply want to know if the "tv_sec" field is zero or
not? (BTW, in current source, "tvdiff" is a structure that is returned
by abs_tval())

$ gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/82077] [7/8 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-02
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
This slightly reduced test case only needs a sinlge type and a one-dimensional
array:

  type :: child
  end type
  class(child), allocatable :: foo(:)
  allocate(foo(1))
  select type(foo)
class is (child)
  call gfortran7_ICE(foo(1:1))
  end select
contains
  subroutine gfortran7_ICE(bar)
class(child) bar(:)
  end subroutine
end

[Bug fortran/82077] [7/8 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org
Summary|[7.1 Regression]: ICE on|[7/8 Regression] ICE on
   |associating polymorphic |associating polymorphic
   |array dummy with a  |array dummy with a
   |type-guarded array section  |type-guarded array section

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 19:31:44 2017
New Revision: 251619

URL: https://gcc.gnu.org/viewcvs?rev=251619=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

[Bug fortran/82064] [7/8 Regression] [OOP] multiple incompatible definitions of extended derived type via module use

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-02
 CC||janus at gcc dot gnu.org
Summary|[OOP] multiple incompatible |[7/8 Regression] [OOP]
   |definitions of extended |multiple incompatible
   |derived type via module use |definitions of extended
   ||derived type via module use
 Ever confirmed|0   |1

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Daan van Vugt from comment #0)
> In the attached zip file are the files needed to reproduce.
> Run `make` to create `test_sep` from test_sep.f90 which prints ERR twice on
> my machine.
> Putting all the modules and the program together in one file yields a
> program that prints OK twice. (test.f90)

I can confirm that behavior with gfortran 7.1 and trunk.

Earlier versions (e.g. 6.3 and 5.1) seem to print OK twice with both variants.

[Bug fortran/81770] [5/6/7 Regression] Bogus warning: Pointer in pointer assignment might outlive the pointer target

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Sep  2 19:04:08 2017
New Revision: 251618

URL: https://gcc.gnu.org/viewcvs?rev=251618=gcc=rev
Log:
2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* expr.c (gfc_check_pointer_assign): Improve the check whether pointer
may outlive pointer target.


2017-09-02  Janus Weil  

Backport from trunk
PR fortran/81770
* gfortran.dg/warn_target_lifetime_3.f90: Fix a typo.
* gfortran.dg/warn_target_lifetime_4.f90: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_4.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_target_lifetime_3.f90

Re: backwards threader cleanups

[Aldy Hernandez]

On Fri, Sep 1, 2017 at 6:11 PM, Jeff Law  wrote:
> On 09/01/2017 02:18 PM, Aldy Hernandez wrote:
>> Hi.
>>
>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>> The main gist of the patch is making the path vectors live in the
>> heap, not GC.  But I also cleaned up some comments to reflect reality,
>> and renamed VAR_BB which could use a more meaningful name.  Finally, I
>> abstracted some common code to
>> register_jump_thread_path_if_profitable() in preparation for some
>> upcoming work by me :).
>>
>> Tested on x86-64 Linux.
> It looks like you dropped a level of indirection for path in
> profitable_jump_thread_path and perhaps others that push blocks onto the
> path?   Does your change from having the vectors in the GC space to the
> heap also change them from embeddable vectors to a space efficient
> vector?  It has to for this change to be safe.

Part of my initial motivation was eliminating the double indirection
as well as removing the out-of-line calls to vec_alloc() and
vec_whatever_push().

And yes, the default plain vector<> uses the heap:

template
struct GTY((user)) vec
{
};

...and va_heap defaults to the space efficient vector:

struct va_heap
{
  typedef vl_ptr default_layout;
...
}

>
> See the discussion in vec.h
>
> I don't recall any inherent reason we use the embedded vector layout.
> It's the default which is probably why it's used here more than anything.

Just a wild guess, but this may be why:

   FIXME - Ideally, they would all be vl_ptr to encourage using regular
   instances for vectors, but the existing GTY machinery is limited
   in that it can only deal with GC objects that are pointers
   themselves.

and:

  /* Use vl_embed as the default layout for GC vectors.  Due to GTY
 limitations, GC vectors must always be pointers, so it is more
 efficient to use a pointer to the vl_embed layout, rather than
 using a pointer to a pointer as would be the case with vl_ptr.  */

>
> Otherwise the change looks good.  I think you just to make sure you're
> not using the embedded layout.  Which I think is just a different type
> when  you declare the vec.

I have made the vectors auto_vec as Trevor suggested.  As auto_vec is
just an inherited plain vec<> with some magic allocation sauce, they
can be passed around interchangeably.

I also changed the hash sets so they live on the stack as opposed to
allocating memory dynamically, at Trevor's request as well.

Bootstraps.  OK pending another round of tests?

Aldy

Re: backwards threader cleanups

[Aldy Hernandez]

On Fri, Sep 1, 2017 at 10:16 PM, Trevor Saunders  wrote:
> On Fri, Sep 01, 2017 at 04:18:20PM -0400, Aldy Hernandez wrote:
>> Hi.
>>
>> Attached are misc cleanups to tree-ssa-threadbackwards.c and friends.
>> The main gist of the patch is making the path vectors live in the
>> heap, not GC.  But I also cleaned up some comments to reflect reality,
>> and renamed VAR_BB which could use a more meaningful name.  Finally, I
>> abstracted some common code to
>> register_jump_thread_path_if_profitable() in preparation for some
>> upcoming work by me :).
>>
>> Tested on x86-64 Linux.
>>
>> OK?
>
>  check_subpath_and_update_thread_path (basic_block last_bb, basic_block 
> new_bb,
>   hash_set *visited_bbs,
> - vec *,
> + vec ,
>   int *next_path_length)
>  {
>edge e;
>int e_count = 0;
>edge_iterator ei;
> -  vec *next_path;
> -  vec_alloc (next_path, 10);
> +  vec next_path = vNULL;
>
> I believe all paths out of this scope release next_path, so it can be
> said the scope owns this vector and you could use auto_vec here.

I originally wanted plain vec<> so it could be passed around to other
work I'm doing on the threader, but I see that auto_vec<> inherits
from vec, and the default vec<> is just vec.  So...it's all the same, and will work
seamlessly.

Thanks.  Will do.

>
> @@ -776,9 +786,8 @@ find_jump_threads_backwards (basic_block bb, bool speed_p)
>if (!name || TREE_CODE (name) != SSA_NAME)
>  return;
>
> -  vec *bb_path;
> -  vec_alloc (bb_path, 10);
> -  vec_safe_push (bb_path, bb);
> +  vec bb_path = vNULL;
>
> same holds here I think.

Will do.

>
> +  bb_path.safe_push (bb);
>hash_set *visited_bbs = new hash_set;
>
>btw I don't see why this hash table can't be just a hash_table<> and
>live on the stack.

Very good point.  Thanks.

[Bug c++/82085] New: Crash: Template variable reference used in nested template alias

[rbock at eudoxos dot de]

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

Bug ID: 82085
   Summary: Crash: Template variable reference used in nested
template alias
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbock at eudoxos dot de
  Target Milestone: ---

I am currently porting sqlpp11 to C++17 and encountered a compiler crash using
the following code

// ---
template 
using char_sequence_t = int;

template 
constexpr char name_of_v = 'x';

template 
using type = char_sequence_t<name_of_v>;
// ---


g++ (GCC) 8.0.0 20170902 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

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

--- Comment #12 from Jack Howarth  ---
Just to add in things that don't fix these failures, the following doesn't
help...

--- gcc-7.2.0/libstdc++-v3/include/Makefile.in.orig 2017-09-02
11:00:08.0 -0400
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-09-02 11:12:38.0
-0400
@@ -1887,16 +1887,37 @@
 # developer tries to create them via make in the include build
 # directory. (This is more of an example of how this kind of rule can
 # be made.)
-.PRECIOUS: $(std_headers) $(c_base_headers) $(tr1_headers) $(tr2_headers)
+.PRECIOUS: $(std_headers) $(bits_headers) $(c_base_headers) $(tr1_headers)
$(tr2_headers)
   $(decimal_headers) $(ext_headers) $(experimental_headers)
-  $(experimental_bits_headers)
+  $(experimental_bits_headers) $(bits_host_headers)
$(bits_sup_headers)
+  $(backward_headers) $(ext_compat_headers) $(ext_host_headers) 
+  $(experimental_filesystem_headers)
$(experimental_bits_filesystem_headers)
+  $(c_compatibility_headers) $(debug_headers) $(parallel_headers)
+  $(profile_headers) $(profile_impl_headers) $(host_headers)
$(thread_host_headers)
 $(std_headers): ; @:
+$(bits_headers): ; @:
+$(bits_host_headers): ; @:
+$(bits_sup_headers): ; @:
+$(backward_headers): ; @:
 $(c_base_headers): ; @:
 $(tr1_headers): ; @:
+$(tr2_headers): ; @:
 $(decimal_headers): ; @:
 $(ext_headers): ; @:
+$(ext_compat_headers): ; @:
+$(ext_host_headers): ; @:
 $(experimental_headers): ; @:
 $(experimental_bits_headers): ; @:
+$(experimental_filesystem_headers): ; @:
+$(experimental_bits_filesystem_headers): ; @:
+$(c_compatibility_headers): ; @:
+$(debug_headers): ; @:
+$(parallel_headers): ; @:
+$(profile_headers): ; @:
+$(profile_impl_headers): ; @:
+$(host_headers): ; @:
+$(thread_host_headers): ; @:
+

 # Tell versions [3.59,3.63) of GNU make to not export all variables.
 # Otherwise a system limit (for SysV at least) may be exceeded.

[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[andysem at mail dot ru]

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

andysem at mail dot ru changed:

   What|Removed |Added

 CC||andysem at mail dot ru

--- Comment #9 from andysem at mail dot ru ---
The docs
(https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins)
still says that `__atomic` builtins are intended to replace `__sync` builtins
and should be preferred in the new code. This is no longer true as `__sync`
builtins are now the only way to generate cmpxchg16b without having to write
assembler code. Please, update the docs accordingly.

Re: [C++] Fix PR bootstrap/81926

[Richard Biener]

On September 2, 2017 1:01:11 PM GMT+02:00, Eric Botcazou 
 wrote:
>Hi,
>
>this is the bootstrap failure reported for the 7 branch on
>SPARC64/Solaris:
>
>Comparing stages 2 and 3
>Bootstrap comparison failure!
>gcc/go/parse.o differs
>make[2]: *** [compare] Error 1
>
>On Solaris, the bootstrap is usually an old-style bootstrap, meaning
>that the 
>debug info is generated during stage2 & stage3 so the comparison also
>involves 
>the debug info, unlike on Linux.  This can be emulated on Linux by
>configuring 
>--with-build-config=no and indeed you get the comparison failure there
>too:
>
>Target: x86_64-suse-linux
>Configured with: /home/eric/svn/gcc-7.2.0/configure
>--build=x86_64-suse-linux 
>--prefix=/home/eric/install/gcc-7.2.0 --enable-languages=c,c++,go
>--enable-
>__cxa_atexit --disable-nls --with-build-config=no
>Thread model: posix
>gcc version 7.2.0 (GCC) 
>
>make[3]: Leaving directory '/home/eric/build/gcc-7.2.0'
>Comparing stages 2 and 3
>Bootstrap comparison failure!
>gcc/go/parse.o differs
>Makefile:24421: recipe for target 'compare' failed
>make[2]: *** [compare] Error 1
>
>The difference is:
>
>35 .debug_info   0016367a      0001faf8
> 2**0
>  CONTENTS, RELOC, READONLY, DEBUGGING
>
>35 .debug_info   00163670      0001faf8
> 2**0
>  CONTENTS, RELOC, READONLY, DEBUGGING
>
>   .byte   0   ! end of children of DIE 0x161dbc
>   .byte   0   ! end of children of DIE 0x161d9c
>   .byte   0   ! end of children of DIE 0x161d5b
>-  .byte   0xf2,0x1! uleb128 0xf2; (DIE (0x161dd2) 
>DW_TAG_ptr_to_member_type)
>-  .uaword 0x10445d! DW_AT_containing_type
>-  .uaword 0x14806e! DW_AT_type
>-  .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161ddc) 
>DW_TAG_subprogram)
>+  .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161dd2) 
>DW_TAG_subprogram)
>   .uaword 0x146733! DW_AT_abstract_origin
>
>It's a garbage collection issue similar to
>  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00541.html
>but for build_offset_type instead of build_complex_type.
>
>It's called from the get_debug_type langhook in C++:
>
>tree
>cp_get_debug_type (const_tree type)
>{
>  if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type))
>return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type),
> TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type)));
>
>  return NULL_TREE;
>}
>
>Since the OFFSET_TYPEs created there are not attached to any GC root,
>they are 
>swept by every collection, meaning that the contents of the debug info
>depends 
>on the actual collection points.
>
>The proposed fix is to build OFFSET_TYPEs manually instead.  As
>witnessed by 
>the change to g++.dg/debug/dwarf2/ref-3.C, this generates more DIEs in
>the 
>debug info, but DW_TAG_ptr_to_member_type DIEs only contain 10 bytes.

A solution would be to put them into a global GCed pointer-map or vector, 
freeing that at free-lang-data time. 

Richard. 

>Bootstrapped on x86-64/Linux & SPARC64/Solaris, OK for mainline and 7
>branch?
>
>
>2017-09-02  Eric Botcazou  
>
>   PR bootstrap/81926
>   * cp-objcp-common.c: Include stor-layout.h.
>   (cp_get_debug_type): Build OFFSET_TYPEs manually.
>
>
>2017-09-02  Eric Botcazou  
>
>   * g++.dg/debug/dwarf2/ref-3.C: Adjust DW_TAG_ptr_to_member_type count.

[PATCH, alpha] Don't refer to -mfp-trap-mode=n as a default

[Maya Rashish]

The typical usage on alpha is done with passing -mieee, which
sets -mfp-trap-mode=su.

I found it confusing, at least.
---
 gcc/doc/invoke.texi | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f7bad9d23..acdb17ba5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -17304,9 +17304,8 @@ The trap mode can be set to one of four values:
 
 @table @samp
 @item n
-This is the default (normal) setting.  The only traps that are enabled
-are the ones that cannot be disabled in software (e.g., division by zero
-trap).
+The only traps that are enabled are the ones that cannot be disabled in
+software (e.g., division by zero trap).
 
 @item u
 In addition to the traps enabled by @samp{n}, underflow traps are enabled
-- 
2.14.1

Re: [PATCH] Fix a pasto in lra-remat.c (reg_overlap_for_remat_p)

[Richard Biener]

On September 1, 2017 10:33:10 PM GMT+02:00, Jakub Jelinek  
wrote:
>Hi!
>
>This is something that has been reported privately to me.
>This is in code introduced in
>https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00660.html
>and looks indeed like a pasto to me, before the loop there is
>a very similar set of stmts without the 2 suffix, and unless
>regno being a hard reg (after possible reg_renumber) implies
>that regno2 (after possible reg_renumber) is a hard reg, if
>unlucky we might access out of bounds.
>
>I don't have a testcase for this, but have bootstrapped/regtested
>it on x86_64-linux and i686-linux, ok for trunk?

OK. 

Richard. 

>2017-09-01  Jakub Jelinek  
>
>   * lra-remat.c (reg_overlap_for_remat_p): Fix a pasto.
>
>--- gcc/lra-remat.c.jj 2017-05-25 10:37:00.0 +0200
>+++ gcc/lra-remat.c2017-09-01 19:42:07.615291583 +0200
>@@ -684,7 +684,7 @@ reg_overlap_for_remat_p (lra_insn_reg *r
> 
>   if (regno2 >= FIRST_PSEUDO_REGISTER && reg_renumber[regno2] >= 0)
> regno2 = reg_renumber[regno2];
>-  if (regno >= FIRST_PSEUDO_REGISTER)
>+  if (regno2 >= FIRST_PSEUDO_REGISTER)
> nregs2 = 1;
>   else
> nregs2 = hard_regno_nregs[regno2][reg->biggest_mode];
>
>   Jakub

Re: [PATCH] Fix gdbhooks.py

[Richard Biener]

On September 1, 2017 10:36:05 PM GMT+02:00, Jakub Jelinek  
wrote:
>Hi!
>
>I'm seeing on the trunk errors like:
>Traceback (most recent call last):
>  File "", line 1, in 
>  File "../../gcc/gdbhooks.py", line 441
>if name == 'E_VOIDmode':
>   ^
>TabError: inconsistent use of tabs and spaces in indentation
>.gdbinit:14: Error in sourced command file:
>Error while executing Python code.
>
>(with gdb 7.12.1).
>
>The following patch fixes that, bootstrapped/regtested on x86_64-linux
>and
>i686-linux, ok for trunk?

OK. 

Richard. 

>2017-09-01  Jakub Jelinek  
>
>   * gdbhooks.py (OptMachineModePrinter.to_string): Use 8 spaces
>   instead of tab.
>
>--- gcc/gdbhooks.py.jj 2017-09-01 09:26:27.0 +0200
>+++ gcc/gdbhooks.py2017-09-01 20:04:04.135133016 +0200
>@@ -438,8 +438,8 @@ class OptMachineModePrinter:
> 
> def to_string (self):
> name = str(self.gdbval['m_mode'])
>-  if name == 'E_VOIDmode':
>-  return ''
>+if name == 'E_VOIDmode':
>+return ''
> return name[2:] if name.startswith('E_') else name
> 
> ##
>
>
>   Jakub

[Bug c++/82084] New: internal compiler error: constructing wstring with -O3

[no_s...@loehndorf-flintbek.de]

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

Bug ID: 82084
   Summary: internal compiler error: constructing wstring with -O3
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: no_s...@loehndorf-flintbek.de
  Target Milestone: ---

Created attachment 42107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42107=edit
preprocessed file for gcc 7

#include 
int main()
{
wchar_t strs[4][2]= {  L"A", L"B", L"C" , L"D"};
std::wstring ss(strs[0]);
return 0;
}


Commandline:
gcc -O3 -c test.cpp -o test.o



Error message:
test.cpp: In function ‘int main()’:
test.cpp:2:5: internal compiler error: in vect_get_constant_vectors, at
tree-vect-slp.c:3221
 int main()
 ^~~~
0xcc009a vect_get_constant_vectors
../../src/gcc/tree-vect-slp.c:3221
0xcc084a vect_get_slp_defs(vec, _slp_tree*,
vec, va_heap, vl_ptr>*, int)
../../src/gcc/tree-vect-slp.c:3453
0xc93060 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
../../src/gcc/tree-vect-stmts.c:1558
0xc9bc16 vectorizable_store
../../src/gcc/tree-vect-stmts.c:6201
0xca68d6 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../src/gcc/tree-vect-stmts.c:8696
0xcbdeca vect_schedule_slp_instance
../../src/gcc/tree-vect-slp.c:3787
0xcbf715 vect_schedule_slp(vec_info*)
../../src/gcc/tree-vect-slp.c:3858
0xcc4d47 vect_slp_bb(basic_block_def*)
../../src/gcc/tree-vect-slp.c:2891
0xcc5fb5 execute
../../src/gcc/tree-vectorizer.c:908

gcc version: gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Debian 7.2.0-1) 


Compiles fine without optimization or -O2, also fails in with gcc-6

Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-3'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.4.0 20170805 (Debian 6.4.0-3)

Re: [PATCH] Add UBSAN_{PTR,BOUNDS} folding (PR sanitizer/81981, take 2)

[Richard Biener]

On September 1, 2017 10:28:16 PM GMT+02:00, Jakub Jelinek  
wrote:
>On Fri, Sep 01, 2017 at 07:10:51PM +0200, Richard Biener wrote:
>> OK, I thought we have one.  Can you add a helper for it please? 
>> replace_with_nop or so?  I thought there's maybe replace_with_value
>which
>> handles null lhs by replacing with nop.  (can't check, writing from
>phone)
>
>Actually, you're right, replace_call_with_value does the right thing
>when called on call without lhs (all these internal fns don't have
>lhs),
>and NULL_TREE val ensures we'd ICE if that ever wasn't the case.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK. 

Richard. 

>2017-09-01  Jakub Jelinek  
>
>   PR sanitizer/81981
>   * gimple-fold.c (gimple_fold_call): Optimize away useless UBSAN_PTR
>   and UBSAN_BOUNDS internal calls.  Clean up IFN_UBSAN_OBJECT_SIZE
>   handling.  Use replace_call_with_value with NULL instead of
>   gsi_replace, unlink_stmt_vdef and release_defs.
>
>   * gcc.dg/ubsan/pr81981.c: New test.
>
>--- gcc/gimple-fold.c.jj   2017-09-01 09:26:37.054748039 +0200
>+++ gcc/gimple-fold.c  2017-09-01 19:37:03.283795450 +0200
>@@ -3936,18 +3936,43 @@ gimple_fold_call (gimple_stmt_iterator *
>   gimple_call_arg (stmt, 2));
> break;
>   case IFN_UBSAN_OBJECT_SIZE:
>-if (integer_all_onesp (gimple_call_arg (stmt, 2))
>-|| (TREE_CODE (gimple_call_arg (stmt, 1)) == INTEGER_CST
>-&& TREE_CODE (gimple_call_arg (stmt, 2)) == INTEGER_CST
>-&& tree_int_cst_le (gimple_call_arg (stmt, 1),
>-gimple_call_arg (stmt, 2
>+{
>+  tree offset = gimple_call_arg (stmt, 1);
>+  tree objsize = gimple_call_arg (stmt, 2);
>+  if (integer_all_onesp (objsize)
>+  || (TREE_CODE (offset) == INTEGER_CST
>+  && TREE_CODE (objsize) == INTEGER_CST
>+  && tree_int_cst_le (offset, objsize)))
>+{
>+  replace_call_with_value (gsi, NULL_TREE);
>+  return true;
>+}
>+}
>+break;
>+  case IFN_UBSAN_PTR:
>+if (integer_zerop (gimple_call_arg (stmt, 1)))
>   {
>-gsi_replace (gsi, gimple_build_nop (), false);
>-unlink_stmt_vdef (stmt);
>-release_defs (stmt);
>+replace_call_with_value (gsi, NULL_TREE);
> return true;
>   }
> break;
>+  case IFN_UBSAN_BOUNDS:
>+{
>+  tree index = gimple_call_arg (stmt, 1);
>+  tree bound = gimple_call_arg (stmt, 2);
>+  if (TREE_CODE (index) == INTEGER_CST
>+  && TREE_CODE (bound) == INTEGER_CST)
>+{
>+  index = fold_convert (TREE_TYPE (bound), index);
>+  if (TREE_CODE (index) == INTEGER_CST
>+  && tree_int_cst_le (index, bound))
>+{
>+  replace_call_with_value (gsi, NULL_TREE);
>+  return true;
>+}
>+}
>+}
>+break;
>   case IFN_GOACC_DIM_SIZE:
>   case IFN_GOACC_DIM_POS:
> result = fold_internal_goacc_dim (stmt);
>--- gcc/testsuite/gcc.dg/ubsan/pr81981.c.jj2017-09-01
>19:35:37.555782465 +0200
>+++ gcc/testsuite/gcc.dg/ubsan/pr81981.c   2017-09-01 19:35:37.555782465
>+0200
>@@ -0,0 +1,21 @@
>+/* PR sanitizer/81981 */
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -Wmaybe-uninitialized -fsanitize=undefined
>-ffat-lto-objects" } */
>+
>+int v;
>+
>+int
>+foo (int i)
>+{
>+  int t[1], u[1];
>+  int n = 0;
>+
>+  if (i)
>+{
>+  t[n] = i;
>+  u[0] = i;
>+}
>+
>+  v = u[0];   /* { dg-warning "may be used uninitialized in this
>function" } */
>+  return t[0];/* { dg-warning "may be used uninitialized in 
>this
>function" } */
>+}
>
>
>   Jakub

[C++] Fix PR bootstrap/81926

[Eric Botcazou]

Hi,

this is the bootstrap failure reported for the 7 branch on SPARC64/Solaris:

Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
make[2]: *** [compare] Error 1

On Solaris, the bootstrap is usually an old-style bootstrap, meaning that the 
debug info is generated during stage2 & stage3 so the comparison also involves 
the debug info, unlike on Linux.  This can be emulated on Linux by configuring 
--with-build-config=no and indeed you get the comparison failure there too:

Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc-7.2.0/configure --build=x86_64-suse-linux 
--prefix=/home/eric/install/gcc-7.2.0 --enable-languages=c,c++,go --enable-
__cxa_atexit --disable-nls --with-build-config=no
Thread model: posix
gcc version 7.2.0 (GCC) 

make[3]: Leaving directory '/home/eric/build/gcc-7.2.0'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
Makefile:24421: recipe for target 'compare' failed
make[2]: *** [compare] Error 1

The difference is:

 35 .debug_info   0016367a      0001faf8  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING

 35 .debug_info   00163670      0001faf8  2**0
  CONTENTS, RELOC, READONLY, DEBUGGING

.byte   0   ! end of children of DIE 0x161dbc
.byte   0   ! end of children of DIE 0x161d9c
.byte   0   ! end of children of DIE 0x161d5b
-   .byte   0xf2,0x1! uleb128 0xf2; (DIE (0x161dd2) 
DW_TAG_ptr_to_member_type)
-   .uaword 0x10445d! DW_AT_containing_type
-   .uaword 0x14806e! DW_AT_type
-   .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161ddc) 
DW_TAG_subprogram)
+   .byte   0xa5,0x1! uleb128 0xa5; (DIE (0x161dd2) 
DW_TAG_subprogram)
.uaword 0x146733! DW_AT_abstract_origin

It's a garbage collection issue similar to
  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00541.html
but for build_offset_type instead of build_complex_type.

It's called from the get_debug_type langhook in C++:

tree
cp_get_debug_type (const_tree type)
{
  if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type))
return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type),
  TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type)));

  return NULL_TREE;
}

Since the OFFSET_TYPEs created there are not attached to any GC root, they are 
swept by every collection, meaning that the contents of the debug info depends 
on the actual collection points.

The proposed fix is to build OFFSET_TYPEs manually instead.  As witnessed by 
the change to g++.dg/debug/dwarf2/ref-3.C, this generates more DIEs in the 
debug info, but DW_TAG_ptr_to_member_type DIEs only contain 10 bytes.

Bootstrapped on x86-64/Linux & SPARC64/Solaris, OK for mainline and 7 branch?


2017-09-02  Eric Botcazou  

PR bootstrap/81926
* cp-objcp-common.c: Include stor-layout.h.
(cp_get_debug_type): Build OFFSET_TYPEs manually.


2017-09-02  Eric Botcazou  

* g++.dg/debug/dwarf2/ref-3.C: Adjust DW_TAG_ptr_to_member_type count.

-- 
Eric BotcazouIndex: cp/cp-objcp-common.c
===
--- cp/cp-objcp-common.c	(revision 251553)
+++ cp/cp-objcp-common.c	(working copy)
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.
 #include "coretypes.h"
 #include "cp-tree.h"
 #include "cp-objcp-common.h"
+#include "stor-layout.h"
 #include "dwarf2.h"
 
 /* Special routine to get the alias set for C++.  */
@@ -138,8 +139,20 @@ tree
 cp_get_debug_type (const_tree type)
 {
   if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type))
-return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type),
-			  TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type)));
+{
+  /* We cannot call build_offset_type here because the function uses the
+	 type canonicalization hashtable, which is GC-ed, so its behavior
+	 depends on the actual collection points.  Since we are building these
+	 types on the fly for the debug info, they are not attached to any
+	 GC root and will always be swept, so we would make the contents of
+	 the debug info depend on the collection points.  */
+  tree t = make_node (OFFSET_TYPE);
+  TYPE_OFFSET_BASETYPE (t)
+	= TYPE_MAIN_VARIANT (TYPE_PTRMEMFUNC_OBJECT_TYPE (type));
+  TREE_TYPE (t) = TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type));
+  layout_type (t);
+  return t;
+}
 
   return NULL_TREE;
 }
Index: testsuite/g++.dg/debug/dwarf2/ref-3.C
===
--- testsuite/g++.dg/debug/dwarf2/ref-3.C	(revision 251553)
+++ testsuite/g++.dg/debug/dwarf2/ref-3.C	(working copy)
@@ -3,7 +3,7 @@
 // { dg-final { scan-assembler-times " DW_AT_reference" 5 { xfail *-*-aix* } } }
 // { dg-final { scan-assembler-times " DW_AT_rvalue_reference" 5 { xfail *-*-aix* } } }
 // { dg-final { 

New mirror site

[Daniel Volchixin]

URL: http://mirror.linux-ia64.org/gnu/gcc/
Country/City: Russia / Novosibirsk
Contact email / name: dan...@volchixin.co.uk (Daniel Volchixin)

[Bug c++/82069] [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/82082] [8 Regression] ICE: in tsubst, at cp/pt.c:13700

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/82083] New: sanitizer detects signed integer overflow in tree-data-ref.c with -O3

[zeccav at gmail dot com]

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

Bug ID: 82083
   Summary: sanitizer detects signed integer overflow in
tree-data-ref.c with -O3
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

// from test case pr60183.c
// must be compiled with -O3 option
// signed integer overflow in tree-data-ref.c
int j = 2;

void
foo (unsigned long *x, unsigned char *y)
{
  int i;
  unsigned long w = x[0];
  for (i = 0; i < j; i++)
{
  w += *y;
  y += 0x1;
  w += *y;
}
  x[1] = w;
}
/*../../gcc/gcc/tree-data-ref.c:3427:16: runtime error: signed integer
overflow: 65536 * -65536 cannot be represented in type 'int'
../../gcc/gcc/tree-data-ref.c:3350:16: runtime error: signed integer overflow:
1073741824 + 1073741824 cannot be represented in type 'int'
../../gcc/gcc/tree-data-ref.c:3429:7: runtime error: negation of -2147483648
cannot be represented in type 'int'; cast to an unsigned type to negate this
value to itself
../../gcc/gcc/tree-data-ref.c:3428:7: runtime error: negation of -2147483648
cannot be represented in type 'int'; cast to an unsigned type to negate this
value to itself*/

[Bug c++/82082] New: [8 Regression] ICE: in tsubst, at cp/pt.c:13700

[trippels at gcc dot gnu.org]

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

Bug ID: 82082
   Summary: [8 Regression] ICE: in tsubst, at cp/pt.c:13700
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42106=edit
Somewhat reduced testcase

More r251433 outfall:

 % g++ -w -c logical.ii
logical.ii: In instantiation of ‘TestLogical< 
>::TestLogical(Xs) [with Xs = tuple;  =
when]:: [with auto:1 =
; auto:2 = ; auto:3 = ; auto:4 = ]’:
logical.ii:80:29:   required from ‘auto partial_t::operator()(Y ...) [with Y = {ebo,
int>}; long unsigned int ...n = {0}; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>; X = {int}]’
logical.ii:138:18:   required from ‘void on_each::operator()(Xs ...) [with
Xs = {ebo, int>}; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>, int>*]’
logical.ii:63:7:   required from ‘static auto
unpack_impl::apply(basic_tuple_impl, F) [with long unsigned int ...i = {0}; Xn = {int}; F =
on_each::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>, int>, int>*>]’
logical.ii:87:16:   [ skipping 20 instantiation contexts, use
-ftemplate-backtrace-limit=0 to disable ]
logical.ii:87:16:   required from ‘constexpr decltype(auto)
unpack_t::operator()(Xs&&, F&&) const [with Xs = basic_tuple&; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>&]’
logical.ii:109:11:   required from ‘static auto
unpack_impl::apply(Xs, F) [with Xs = tuple; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>]’
logical.ii:87:16:   required from ‘constexpr decltype(auto)
unpack_t::operator()(Xs&&, F&&) const [with Xs = tuple&; F =
on_each<_compose, tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >*>]’
logical.ii:143:11:   required from ‘static void for_each_impl::apply(Xs, F) [with Xs = tuple; F =
_compose,
tuple >, partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >; T = tuple_tag; bool condition = false]’
logical.ii:132:17:   required from ‘constexpr void for_each_t::operator()(Xs&&,
F&&) const [with Xs = tuple&; F = _compose, tuple >,
partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int> > >]’
logical.ii:148:13:   required from ‘void for_each_n_t::operator()(Xs, F)
[with Xs = tuple; F = partial_t::TestLogical(Xs) [with Xs = tuple;
 = when]::, int>; int i = 3]’
logical.ii:162:13:   required from ‘TestLogical< 
>::TestLogical(Xs) [with Xs = tuple;  =
when]’
logical.ii:167:41:   required from here
logical.ii:163:56: internal compiler error: in tsubst, at cp/pt.c:13700
  [](auto, auto, auto, auto) { auto true_valued = [] {};
}));
^~~
0x1044231b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13700
0x1043cb13 tsubst_decl
../../gcc/gcc/cp/pt.c:13047
0x104406f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13552
0x1042ebe3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16013
0x1042e217 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15944
0x1042ed0f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16183
0x1042ed0f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16183

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[matthijs at stdin dot nl]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #12 from Matthijs Kooijman  ---
Apologies if this is an obvious question, but I'm not familiar with gcc/g++
internals. Georg-Johann, you say this requires address space support in c++,
but I'm not sure I follow you there. Two things:
 - You say WG21 will never add AS support to C++, but also say that language
support for AS is not needed, only internal support in gcc/g++. So that means
what WG21 does is not relevant for vtable handling in particular?
 - Even if AS would not be used, what prevents g++ from emitting the vtables in
the `progmem.data` section and generating vtable-invocation code using LPM
instructions? This behaviour could be toggled using a commandline option, or
some gcc-specific attribute on a class?

I would be happy if you could comment on the feasibility of these two
approaches, thanks!

[Bug libstdc++/71660] [5/6/7/8 regression] alignment of std::atomic<8 byte primitive type> (long long, double) is wrong on x86

[chgans at gmail dot com]

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

Christian Gagneraud  changed:

   What|Removed |Added

 CC||chgans at gmail dot com

--- Comment #6 from Christian Gagneraud  ---
Hi there,

What is the status of this bug report? Will this be fixed one day? Isn't this a
serious issue?

Qt cannot currently be fully built because of this. See
http://lists.qt-project.org/pipermail/interest/2017-September/027953.html
http://lists.qt-project.org/pipermail/interest/2017-September/027955.html

Honestly this all look scary to me, either gcc behaviour or Qt beahaviour or
both.

Full thread on Qt ML:
http://lists.qt-project.org/pipermail/interest/2017-September/027948.html

[Bug c++/82081] Tail call optimisation of noexcept function leads to exception allowed through

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The C++ front-end should have wrapped noexcept_function's body with:
try {
...
} catch(..)
{
  std::terminate();
}

Like it does for throw() case.

[Bug c++/82081] New: Tail call optimisation of noexcept function leads to exception allowed through

[thiago at kde dot org]

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

Bug ID: 82081
   Summary: Tail call optimisation of noexcept function leads to
exception allowed through
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

When a noexcept function gets optimised with tail-call, the frame disappears so
the unwinder cannot know that the function was noexcept and thus
std::terminate() should be called.

Code:

$ cat throw.cpp
void noexcept_function() noexcept;

bool false_condition = false;
void will_throw()
{
throw 1;
}

void wrapper()
{
noexcept_function();
if (false_condition)
throw 42;
}
$ cat main.cpp
#include 

void will_throw();  // throws int
void wrapper();
extern bool false_condition;

void noexcept_function() noexcept { will_throw(); }

int main()
{
try {
wrapper();
} catch (int v) {
std::cout << "Caught " << v;
return v;
}
return 0;
}

By bouncing around translation units, we prevent inlining. The compiler cannot
know that wrapper() calls noexcept_function(), which calls will_throw().

In debug mode, the program behaves as expected

$ g++ -O0 -g throw.cpp main.cpp
$ ./a.out
terminate called after throwing an instance of 'int'
[1]46552 abort (core dumped)  ./a.out
(gdb) bt
#0  0x7f9df0ce1a90 in raise () from /lib64/libc.so.6
#1  0x7f9df0ce30f6 in abort () from /lib64/libc.so.6
#2  0x7f9df1615235 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6
#3  0x7f9df1613026 in ?? () from /usr/lib64/libstdc++.so.6
#4  0x7f9df1611fe9 in ?? () from /usr/lib64/libstdc++.so.6
#5  0x7f9df1612958 in __gxx_personality_v0 () from
/usr/lib64/libstdc++.so.6
#6  0x7f9df10633a3 in ?? () from /lib64/libgcc_s.so.1
#7  0x7f9df10638b0 in _Unwind_RaiseException () from /lib64/libgcc_s.so.1
#8  0x7f9df16132a6 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#9  0x004009ed in will_throw () at throw.cpp:6
#10 0x00400a2f in noexcept_function () at main.cpp:7
#11 0x004009f6 in wrapper () at throw.cpp:11
#12 0x00400a40 in main () at main.cpp:12

However, when optimised, we see that the exception thrown from will_throw()
does pass through and is caught by main():

$ g++ -O2 -g throw.cpp main.cpp
$ ./a.out 
Caught 1
(gdb) disass noexcept_function
Dump of assembler code for function noexcept_function():
   0x00400b10 <+0>: jmpq   0x400aa0 


I see two possible paths to solving this.
1) forbid tail-call optimisation of a noexcept(false) call in a noexcept
function, so that there is a frame in place for the unwinder to find. That is,
the noexcept_function should be:
  sub  %rsp, 8
  call will_throw()
  retq
(GCC generates this under some conditions, like placing all functions in the
same TU but using -fno-inline)

2) wrap the call point of the noexcept function (in this case, wrapper()) with
an EH table that enforces that no exceptions should come out of it.

The first solution implies a performance penalty due to optimisation that could
not be used. If you choose to implement this, please try to disable this
correction under -fno-exceptions.

The second solution allows the runtime performance at the expense of expanding
EH tables around every noexcept function.

Neither solution completely solves the problem for mixed-age code in different
libraries: solution 1 solves the problem if the callee is recompiled but lets
the problem still happen if only the caller is recompiled. Solution 2 is the
dual converse: if the caller is recompiled, the problem is solved, but the
problem still happens if only the callee is recompiled.

Re: [PATCH][RFA/RFC] Stack clash mitigation patch 06/08 - V3

[Jeff Law]

On 08/29/2017 05:14 PM, Segher Boessenkool wrote:
> Hi Jeff,
> 
> Sorry for the delay in reviewing this.  It mostly looks good :-)
Thanks.  No worries about the delay.  Your input definitely helped move
the target independent stuff to a better place.  And frankly I
wanted/needed some time away from this stuff.

> 
> On Sun, Jul 30, 2017 at 11:45:16PM -0600, Jeff Law wrote:
>>
>> This contains the PPC bits for stack clash protection.
>>
>> Changes since V2:
>>
>> Exploits inlined/unrolled probes and rotated loops for the dynamic area.
>>  Some trivial simplifications.  It also uses the new params to control
>> if probes are needed and how often to probe.
> 
> 
>>  * config/rs6000/rs6000-protos.h (output_probe_stack_range): Update
>>  prototype for new argument.
>>  * config/rs6000/rs6000.c (wrap_frame_mem): New function extracted
>>  from rs6000_emit_allocate_stack.
>>  (handle_residual): New function. 
> 
> Trailing space.
Fixed, along with the other ChangeLog nits you pointed out.



> 
> 
>> +/* INSN allocates SIZE bytes on the stack (STACK_REG) using a store
>> +   with update style insn.
>> +
>> +   Set INSN's alias set/attributes and add suitable flags and notes
>> +   for the dwarf CFI machinery.  */
>> +static void
>> +wrap_frame_mem (rtx insn, rtx stack_reg, HOST_WIDE_INT size)
> 
> This isn't such a great name...  Something with "frame allocate"?  And
> the "wrap" part is meaningless...  "set_attrs_for_frame_allocation"?
> Or maybe "stack allocation" is better.
The name is terrible.  I shouldn't have let that get through.  I think
set attrs_for_stack_allocation is better given the current behavior of
the function, but as you note some further refinement would probably
help here and would result in a different name.


> 
> Actually, everywhere it is used it has a Pmode == SImode wart before
> it, to emit the right update_stack insn...  So fold that into this
> function, name it rs6000_emit_allocate_stack_1?
Agreed.  That seems like a nice cleanup.  Look at the call from
rs6000_emit_allocate_stack.  Instead of a Pmode == SImode, it tests
TARGET_32BIT instead.  But I think that one is still safe to convert
based on how we set Pmode in rs6000_option_override_internal.


> 
>> +/* Allocate ROUNDED_SIZE - ORIG_SIZE bytes on the stack, storing
>> +   ORIG_SP into *sp after the allocation.
> 
> This is a bit misleading: it has to store it at the _same time_ as doing
> any change to r1.  Or, more precisely, it has to ensure r1 points at a
> valid stack backchain at all times.  Since the red zone is pretty small
> (if it exists at all, it doesn't on all ABIs) you need atomic store-with-
> update in most cases.
Yea, I was imprecise in my language.
> 
>> +static rtx_insn *
>> +handle_residual (HOST_WIDE_INT orig_size,
>> + HOST_WIDE_INT rounded_size,
>> + rtx orig_sp)
> 
> Not a great name either.  Since this is only used once, and it is hard
> to make a good name for it, and it is only a handful of statements, just
> inline it?
It was originally used multiple times, but refactoring resulted in a
single use.  I'll just inline it -- it's trivial after we revamp
wrap_frame_mem.



> 
>> +/* Allocate ORIG_SIZE bytes on the stack and probe the newly
>> +   allocated space every STACK_CLASH_PROTECTION_PROBE_INTERVAL bytes.
>> +
>> +   COPY_REG, if non-null, should contain a copy of the original
>> +   stack pointer modified by COPY_OFF at exit from this function.
>> +
>> +   This is subtly different than the Ada probing in that it tries hard to
>> +   prevent attacks that jump the stack guard.  Thus it is never allowed to
>> +   allocate more than STACK_CLASH_PROTECTION_PROBE_INTERVAL bytes of stack
>> +   space without a suitable probe.  */
> 
> Please handle the COPY_OFF part in the (single) caller of this, that
> will simplify things a little I think?
Sure.  I thought I had it that way at one point.


> 
> You don't describe what the return value here is (but neither does
> rs6000_emit_allocate_stack); it is the single instruction that actually
> changes the stack pointer?  For the split stack support?  (Does the stack
> clash code actually work with split stack, has that been tested?)
As far as I was able to ascertain (and essentially duplicate) we return
the insn that allocates the stack, but only if the allocation was
handled a single insn.  Otherwise we return NULL.

But that was determined largely by guesswork.  It interacts with split
stack support, but I'm not entirely what it's meant to do.  If you have
insights here, I'll happily add comments to the routines -- when I was
poking at this stuff I was rather distressed to not have any real
guidance on what the return value should be.

I have not tested stack clash and split stacks. ISTM they ought to be
able to work together, but I haven't though real deep about it.



> 
> Maybe we should keep track of that sp_adjust insn in a global, or in
> machine_function, or even in the stack info struct.
Maybe.  It's