[Bug c/84168] Please backport "Avoid assembler warnings from AArch64 constructor/destructor priorities."

[frank.mehnert at googlemail dot com]

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

--- Comment #3 from Frank Mehnert  ---
Sorry for the late response and thanks for bringing this up on gcc-patches.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov  ---
Also note that both the original and the reduced testcase can be tweaked to
exhibit the surprising transformation even when -fexcess-precision=standard is
enabled. A "lazy" way is via -mpc64, but I think it's possible even without the
additional option (by making the code more convoluted to enforce rounding to
double). Here's what happens on the reduced testcase:

$ gcc -m32 d.c -O -fdisable-tree-dom3 && ./a.out 
cc1: note: disable pass tree-dom3 for functions in the range of [0, 4294967295]
1 == 0

$ gcc -m32 d.c -O -fdisable-tree-dom3 -fexcess-precision=standard -mpc64 &&
./a.out 
cc1: note: disable pass tree-dom3 for functions in the range of [0, 4294967295]
0 == 1

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
Sorry, the above comment should have said 'b * 1e6' every time it said 'b'.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
To expand a bit: DOM makes the small testcase behave as if 'b' and 'ib' are
evaluated twice:

* one time, 'b' is evaluated in precision matching 'a' (either infinite or
double), and 'ib' is evaluated to 1; this instance is used in 'ia == ib'
comparison;
* a second time, 'b' is evaluated in extended precision and 'ib' is evaluated
to 0; this instance is passed as the last argument to printf.

This is surprising as the original program clearly evaluates 'b' and 'ib' just
once.

If there's no bug in DOM and the observed transformation is allowed to happen
when -fexcess-precision=fast is in effect, I think it would be nice to mention
that in the compiler manual.

[Bug libitm/85988] Incorrect offsets of __private_tm and pointer_guard

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com
Summary|Incorrect offset of |Incorrect offsets of
   |__private_tm|__private_tm and
   ||pointer_guard

--- Comment #1 from H.J. Lu  ---
The offsets of pointer_guard are:

i386:   24 bytes == 24 bytes
x32:28 bytes != 24 bytes
x86_64: 48 bytes == 48 bytes

[Bug c++/85991] New: [Concepts] Template placeholder: ICE cp_parser_lookup_name, at cp/parser.c:26223

[hstong at ca dot ibm.com]

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

Bug ID: 85991
   Summary: [Concepts] Template placeholder: ICE
cp_parser_lookup_name, at cp/parser.c:26223
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

When a partial-concept-id is formed for a concept with a template prototype
template parameter, GCC ICEs.

### SOURCE ():
template  class, int> concept bool TmplC = true;
template  class> struct A;
void f(A> *);


### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -xc++ -fconcepts -


### ACTUAL OUTPUT:
:3:17: internal compiler error: in cp_parser_lookup_name, at
cp/parser.c:26223
0x58ed8d cp_parser_lookup_name
../../source/gcc/cp/parser.c:26223
0x680e29 cp_parser_primary_expression
../../source/gcc/cp/parser.c:5528
0x6825f5 cp_parser_primary_expression
../../source/gcc/cp/parser.c:5637
0x6825f5 cp_parser_template_argument
../../source/gcc/cp/parser.c:16465
0x6825f5 cp_parser_template_argument_list
../../source/gcc/cp/parser.c:16274
0x6825f5 cp_parser_enclosed_template_argument_list
../../source/gcc/cp/parser.c:27695
0x682f4e cp_parser_template_id
../../source/gcc/cp/parser.c:15917
0x683498 cp_parser_class_name
../../source/gcc/cp/parser.c:22491
0x68e837 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6564
0x68e837 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:6250
0x6901a6 cp_parser_simple_type_specifier
../../source/gcc/cp/parser.c:17283
0x68a9f3 cp_parser_type_specifier
../../source/gcc/cp/parser.c:16956
0x696b2b cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13718
0x6971bb cp_parser_parameter_declaration
../../source/gcc/cp/parser.c:21607
0x697aef cp_parser_parameter_declaration_list
../../source/gcc/cp/parser.c:21433
0x697e43 cp_parser_parameter_declaration_clause
../../source/gcc/cp/parser.c:21362
0x687148 cp_parser_direct_declarator
../../source/gcc/cp/parser.c:20121
0x687148 cp_parser_declarator
../../source/gcc/cp/parser.c:19993
0x694b91 cp_parser_init_declarator
../../source/gcc/cp/parser.c:19509
0x69be63 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13150
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


### EXPECTED OUTPUT:
(No ICE).


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20180528 (experimental) (GCC)

[Bug target/85990] New: Wrong TARGET_THREAD_SPLIT_STACK_OFFSET

[hjl.tools at gmail dot com]

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

Bug ID: 85990
   Summary: Wrong TARGET_THREAD_SPLIT_STACK_OFFSET
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: i*86-pc-linux-gnu

In glibc, sysdeps/i386/nptl/tls.h has

typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  dtv_t *dtv;
  void *self;   /* Pointer to the thread descriptor.  */
  int multiple_threads;
  uintptr_t sysinfo;
  uintptr_t stack_guard;
  uintptr_t pointer_guard;
  int gscope_flag;
  int __glibc_reserved1;
  /* Reservation of some values for the TM ABI.  */
  void *__private_tm[4];
  /* GCC split stack support.  */
  void *__private_ss;
} tcbhead_t;

and sysdeps/x86_64/nptl/tls.h has

typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  dtv_t *dtv;
  void *self;   /* Pointer to the thread descriptor.  */
  int multiple_threads;
  int gscope_flag;
  uintptr_t sysinfo;
  uintptr_t stack_guard;
  uintptr_t pointer_guard;
  unsigned long int vgetcpu_cache[2];
  int __glibc_reserved1;
  int __glibc_unused1;
  /* Reservation of some values for the TM ABI.  */
  void *__private_tm[4];
  /* GCC split stack support.  */
  void *__private_ss;
  long int __glibc_reserved2;
  /* Must be kept even if it is no longer used by glibc since programs,
 like AddressSanitizer, depend on the size of tcbhead_t.  */
  __128bits __glibc_unused2[8][4] __attribute__ ((aligned (32)));

  void *__padding[8];
} tcbhead_t;

The offsets of __private_tm are

i386:   36 bytes
x32:48 bytes
x86_64: 80 bytes

gcc/config/i386/gnu-user64.h has

/* We steal the last transactional memory word.  */
#define TARGET_THREAD_SPLIT_STACK_OFFSET \
  (TARGET_64BIT ? (TARGET_X32 ? 0x40 : 0x70) : 0x30)

Should't it be

(TARGET_64BIT ? (TARGET_X32 ? 0x40 : 0x70) : 0x34)

[Bug middle-end/85989] New: Incorrect result for example involving unary minus in a loop

[ketan.surender at gmail dot com]

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

Bug ID: 85989
   Summary: Incorrect result for example involving unary minus in
a loop
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ketan.surender at gmail dot com
  Target Milestone: ---

Created attachment 44208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44208&action=edit
Preprocessed reproduction file

Please see the attached file 'standalone.i'. When I run this in -O0 I see the
result

gcc -Wall -Wstrict-aliasing=0 -O0 standalone.i -o standalone
./standalone

--> 0
--> 0

This is what I expect. If I compile with '-O1' I see

gcc -Wall -Wstrict-aliasing=0 -O1 standalone.i -o standalone
./standalone

--> 8
--> 8

Which is unexpected. I poked around in gdb and stared at the asm in godbolt and
it seems like the negation is being omitted in the following loop:

  for (b_P5 = 0; b_P5 < 8; b_P5++) {
P26 = P29;
P29 = -(int)*P5;
  }

Here is my gcc info

Using built-in specs.
COLLECT_GCC=[SNIP]/glnxa64/gcc-6.3.0/bin/gcc
COLLECT_LTO_WRAPPER=[SNIP]/glnxa64/gcc-6.3.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: [SNIP]/sources/gcc-6.3/configure
--with-gmp=[SNIP]/glnxa64/gcc-6.3/gmp-4.3 --with-mpfr=[SNIP]/gcc-6.3/mpfr
--with-mpc=[SNIP]/gcc-6.3/mpc --enable-languages=c,c++,fortran
--with-bugurl=[SNIP],_Debugging --enable-shared --enable-linker-build-id
--enable-plugin --enable-checking=release --enable-multiarch --enable-gold
--enable-ld=default --enable-libstdcxx-time=no
--prefix=[SNIP]/glnxa64/gcc-6.3.0 --with-pkgversion='MW GCC 6.3.0-GLIBC2.12'
--with-tune=generic --with-system-zlib --enable-multilib
--with-multilib-list=m32,m64 --with-arch-directory=amd64 --with-arch-32=i586
--with-abi=m64
Thread model: posix
gcc version 6.3.0 (MW GCC 6.3.0-GLIBC2.12)

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Patch submitted.

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01694.html

[Bug c++/85889] lambda expression can capture structured bindings

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED

--- Comment #3 from Jonathan Wakely  ---
Done.

[Bug libitm/85988] New: Incorrect offset of __private_tm

[hjl.tools at gmail dot com]

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

Bug ID: 85988
   Summary: Incorrect offset of __private_tm
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: x86-64-*-linux*

In glibc, sysdeps/i386/nptl/tls.h has

typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  dtv_t *dtv;
  void *self;   /* Pointer to the thread descriptor.  */
  int multiple_threads;
  uintptr_t sysinfo;
  uintptr_t stack_guard;
  uintptr_t pointer_guard;
  int gscope_flag;
  int __glibc_reserved1;
  /* Reservation of some values for the TM ABI.  */
  void *__private_tm[4];
  /* GCC split stack support.  */
  void *__private_ss;
} tcbhead_t;

and sysdeps/x86_64/nptl/tls.h has


typedef struct
{
  void *tcb;/* Pointer to the TCB.  Not necessarily the
   thread descriptor used by libpthread.  */
  dtv_t *dtv;
  void *self;   /* Pointer to the thread descriptor.  */
  int multiple_threads;
  int gscope_flag;
  uintptr_t sysinfo;
  uintptr_t stack_guard;
  uintptr_t pointer_guard;
  unsigned long int vgetcpu_cache[2];
  int __glibc_reserved1;
  int __glibc_unused1;
  /* Reservation of some values for the TM ABI.  */
  void *__private_tm[4];
  /* GCC split stack support.  */
  void *__private_ss;
  long int __glibc_reserved2;
  /* Must be kept even if it is no longer used by glibc since programs,
 like AddressSanitizer, depend on the size of tcbhead_t.  */
  __128bits __glibc_unused2[8][4] __attribute__ ((aligned (32)));

  void *__padding[8];
} tcbhead_t;

The offsets of __private_tm are

i386:   36 bytes != 4 * 10 bytes
x32:48 bytes != 4 * 10 btes
x86_64: 80 bytes == 8 * 10 bytes

But config/linux/x86/tls.h has

#ifdef __x86_64__
#ifdef __LP64__
# define SEG_READ(OFS)  "movq\t%%fs:(" #OFS "*8),%0"
# define SEG_WRITE(OFS) "movq\t%0,%%fs:(" #OFS "*8)"
# define SEG_DECODE_READ(OFS)   SEG_READ(OFS) "\n\t" \
"rorq\t$17,%0\n\t" \
"xorq\t%%fs:48,%0"
# define SEG_ENCODE_WRITE(OFS)  "xorq\t%%fs:48,%0\n\t" \
"rolq\t$17,%0\n\t" \
SEG_WRITE(OFS)
#else
// For X32.
# define SEG_READ(OFS)  "movl\t%%fs:(" #OFS "*4),%0"
# define SEG_WRITE(OFS) "movl\t%0,%%fs:(" #OFS "*4)"
# define SEG_DECODE_READ(OFS)   SEG_READ(OFS) "\n\t" \
"rorl\t$9,%0\n\t" \
"xorl\t%%fs:24,%0"
# define SEG_ENCODE_WRITE(OFS)  "xorl\t%%fs:24,%0\n\t" \
"roll\t$9,%0\n\t" \
SEG_WRITE(OFS)
#endif
#else
# define SEG_READ(OFS)  "movl\t%%gs:(" #OFS "*4),%0"
# define SEG_WRITE(OFS) "movl\t%0,%%gs:(" #OFS "*4)"
# define SEG_DECODE_READ(OFS)   SEG_READ(OFS) "\n\t" \
"rorl\t$9,%0\n\t" \
"xorl\t%%gs:24,%0"
# define SEG_ENCODE_WRITE(OFS)  "xorl\t%%gs:24,%0\n\t" \
"roll\t$9,%0\n\t" \
SEG_WRITE(OFS)
#endif

static inline struct gtm_thread *gtm_thr(void)
{
  struct gtm_thread *r;
  asm volatile (SEG_READ(10) : "=r"(r));
  return r;
}

static inline void set_gtm_thr(struct gtm_thread *x)
{
  asm volatile (SEG_WRITE(10) : : "r"(x));
}amespace GTM HIDDEN {

static inline struct abi_dispatch *abi_disp(void)
{
  struct abi_dispatch *r;
  asm volatile (SEG_DECODE_READ(11) : "=r"(r));
  return r;
}

static inline void set_abi_disp(struct abi_dispatch *x)
{
  void *scratch;
  asm volatile (SEG_ENCODE_WRITE(11) : "=r"(scratch) : "0"(x));
}

SEG_* macros are correct only for x86-64.

[Bug c++/85889] lambda expression can capture structured bindings

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Please suspend this bug. The change that made capturing bindings ill-formed in
P0588R1 was not in the design paper P0588R0. I plan to propose to revert this
change, and make capturing structured bindings well-defined in all standard
versions that support structured bindings.

[Bug tree-optimization/85964] compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|[8/9 Regression] Compile|compile time hog w/ -O3
   |time hog w/ -O3 -ftracer|-ftracer
   |-fno-guess-branch-probabili |-fno-guess-branch-probabili
   |ty  |ty

--- Comment #7 from Eric Botcazou  ---
Not a regression since #pragma GCC unroll is new.

[Bug c++/53281] poor error message for calling a non-const method from a const object

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
My patch fails to account for ref-qualifiers on the member function, so needs
some improvement.

[Bug target/85986] config/rl78/rl78.c:984: bad test ?

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dj at gcc dot gnu.org

--- Comment #1 from David Binderman  ---
svn blame says

181819 dj   if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
181819 dj && GET_CODE (XEXP (x, 0)) == CONST_INT)

[Bug tree-optimization/85971] Really Simple "If" with one function call inside is not optimized efficiently

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||85987
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
I think this is actually two different bugs.
One where cstore is not working when there is a function call inbetween.
If I add an argument to CreateChecksum and change the first PolyMod to + t and
the second PolyMod  to * t.  the cstore optimization work.  This is recorded
now as PR 85987.

The second one is the lowering of common function calls with slightly different
arguments.  I thought I saw one asking for this one but I can't find it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85987
[Bug 85987] cstore does not work with a store in one of the branches

[Bug tree-optimization/85987] New: cstore does not work with a store in one of the branches

[pinskia at gcc dot gnu.org]

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

Bug ID: 85987
   Summary: cstore does not work with a store in one of the
branches
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod, int *t) {
if (isTestNet == 0) {
*t += 1;
*mod = (5);
} else {
*mod = (9);
}
}

Cstore does not work here and commonize the store to mod.

[Bug target/85986] New: config/rl78/rl78.c:984: bad test ?

[dcb314 at hotmail dot com]

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

Bug ID: 85986
   Summary: config/rl78/rl78.c:984: bad test ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---
Target: rl78

rl78/rl78.c:984:4: warning: logical ‘and’ of mutually exclusive tests is always
false [-Wlogical-op]

Source code is

  if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
  && GET_CODE (XEXP (x, 0)) == CONST_INT)

Maybe better code

  if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
  || GET_CODE (XEXP (x, 0)) == CONST_INT)

[Bug target/85984] ICE in create_pseudo_cfg, at dwarf2cfi.c:2874

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
This code is undefined at runtime due to the use of naked and C code.

[Bug libfortran/85975] Incorrect size for spread array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 CC||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Stephan,

I tried the simply patch suggested in your analysis and
it does fix the problem.  I need to extend the patch to
fix the m4 files that utilize the macro as the 'b' 
parameter is no longer needed.

I've also Paul to the CC list.  He finished and sheparded
the array descriptor reform into the tree.  Paul, does 
Stephan's analysis look correct?

[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Perhaps cp_tree_equal should just handle USING_DECL like other DECLs.

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, May 29, 2018 at 07:53:33PM +, kargl at gcc dot gnu.org wrote:
>
> I have a patch.
> 

I have new patch.

[Bug c++/67711] Memory corruption when reassigning value to initializer_list

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue May 29 20:04:52 2018
New Revision: 260905

URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev
Log:
PR c++/67445 - returning temporary initializer_list.

PR c++/67711 - assigning from temporary initializer_list.
PR c++/48562 - new initializer_list.
* typeck.c (maybe_warn_about_returning_address_of_local): Also warn
about returning local initializer_list.
* cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove.
* call.c (build_over_call): Warn about assignment from temporary
init_list.
* init.c (build_new_1): Warn about 'new std::initializer_list'.
(find_list_begin, maybe_warn_list_ctor): New.
(perform_member_init): Use maybe_warn_list_ctor.

Added:
trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/c-c++-common/pr43395.c
trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C
trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C
trunk/gcc/testsuite/g++.dg/warn/return-reference2.C
trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C
trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C
trunk/libstdc++-v3/testsuite/util/testsuite_random.h

[Bug c++/67445] New warning: returning std::initializer_list bound to temporary

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue May 29 20:04:52 2018
New Revision: 260905

URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev
Log:
PR c++/67445 - returning temporary initializer_list.

PR c++/67711 - assigning from temporary initializer_list.
PR c++/48562 - new initializer_list.
* typeck.c (maybe_warn_about_returning_address_of_local): Also warn
about returning local initializer_list.
* cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove.
* call.c (build_over_call): Warn about assignment from temporary
init_list.
* init.c (build_new_1): Warn about 'new std::initializer_list'.
(find_list_begin, maybe_warn_list_ctor): New.
(perform_member_init): Use maybe_warn_list_ctor.

Added:
trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/c-c++-common/pr43395.c
trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C
trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C
trunk/gcc/testsuite/g++.dg/warn/return-reference2.C
trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C
trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C
trunk/libstdc++-v3/testsuite/util/testsuite_random.h

[Bug c++/48562] [C++0x] warn about uses of initializer_list that will lead to dangling pointers

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Tue May 29 20:04:52 2018
New Revision: 260905

URL: https://gcc.gnu.org/viewcvs?rev=260905&root=gcc&view=rev
Log:
PR c++/67445 - returning temporary initializer_list.

PR c++/67711 - assigning from temporary initializer_list.
PR c++/48562 - new initializer_list.
* typeck.c (maybe_warn_about_returning_address_of_local): Also warn
about returning local initializer_list.
* cp-tree.h (AUTO_TEMP_NAME, TEMP_NAME_P): Remove.
* call.c (build_over_call): Warn about assignment from temporary
init_list.
* init.c (build_new_1): Warn about 'new std::initializer_list'.
(find_list_begin, maybe_warn_list_ctor): New.
(perform_member_init): Use maybe_warn_list_ctor.

Added:
trunk/gcc/testsuite/g++.dg/warn/Winit-list1.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list2.C
trunk/gcc/testsuite/g++.dg/warn/Winit-list3.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/c-c++-common/pr43395.c
trunk/gcc/testsuite/g++.dg/cpp1y/pr77591.C
trunk/gcc/testsuite/g++.dg/warn/Wreturn-local-addr.C
trunk/gcc/testsuite/g++.dg/warn/return-reference2.C
trunk/gcc/testsuite/g++.old-deja/g++.bob/array1.C
trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash55.C
trunk/libstdc++-v3/testsuite/util/testsuite_random.h

[Bug c/85985] GCC >= 5.6 unaligned movaps

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Valentin Petrov from comment #3)
> Thanks, just to clarify. Do I understand correctly that the alignment
> requirement for bbb comes from __attribute__ (aligned) in aaa ?? (attribute
> makes a3 to be aligned, which makes aaa to be 64b aligned, which makes bbb
> 64b aligned) ?
> 
> Is this correct logic?

YES.  C11 added _Alignof to see what the alignment is required.

[Bug c/85985] GCC >= 5.6 unaligned movaps

[valentinp at mellanox dot com]

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

--- Comment #3 from Valentin Petrov  ---
Thanks, just to clarify. Do I understand correctly that the alignment
requirement for bbb comes from __attribute__ (aligned) in aaa ?? (attribute
makes a3 to be aligned, which makes aaa to be 64b aligned, which makes bbb 64b
aligned) ?

Is this correct logic?

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I have a patch.

[Bug c/85985] GCC >= 5.6 unaligned movaps

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
.

[Bug c/85985] GCC >= 5.6 unaligned movaps

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The alignment requirement for struct bbb is 64bytes but you cast a non aligned
data to that type.

This is undefined code since the type has an alignment requirement.

[Bug c/85985] New: GCC >= 5.6 unaligned movaps

[valentinp at mellanox dot com]

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

Bug ID: 85985
   Summary: GCC >= 5.6 unaligned movaps
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valentinp at mellanox dot com
  Target Milestone: ---

Test case:

#include 
#include 
#include 

struct aaa {
void *a1;
void *a2;
struct {
void* a3
#if defined(USE_ALIGN) && USE_ALIGN > 0
__attribute__((aligned(64)))
#endif
;
};
};

struct bbb {
volatile int b;
struct aaa A;
};


static void print_A(struct aaa *A) {
printf("a1: %p, %%8=%lu %%16=%lu %%32=%lu\na2: %p, %%8=%lu %%16=%lu
%%32=%lu\n",
   &A->a1, ((uint64_t)(&A->a1)) % 8, ((uint64_t)(&A->a1)) % 16,
((uint64_t)(&A->a1)) % 32,
   &A->a2, ((uint64_t)(&A->a2)) % 8, ((uint64_t)(&A->a2)) % 16,
((uint64_t)(&A->a2)) % 32);
}

static void __attribute__ ((noinline)) B_init(struct bbb *B) {
B->A.a2 = NULL;
B->A.a1 = NULL;
}


int main(int argc, char *argv[])
{
struct bbb *B;
void *storage = malloc(sizeof(struct bbb)*32);
B = (struct bbb*)((char*)storage + 8);
print_A(&B->A);
B_init(B);
free(storage);
return 0;
}


ASM:
.file   "compiler2.c"
.text
.p2align 4,,15
.type   B_init, @function
B_init:
.LFB42:
.cfi_startproc
pxor%xmm0, %xmm0
movaps  %xmm0, 64(%rdi)
ret
.cfi_endproc
.LFE42:
.size   B_init, .-B_init
.section.rodata.str1.8,"aMS",@progbits,1
.align 8
.LC0:
.string "a1: %p, %%8=%lu %%16=%lu %%32=%lu\na2: %p, %%8=%lu %%16=%lu
%%32=%lu\n"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl  main
.type   main, @function
main:
.LFB43:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$6144, %edi
callmalloc@PLT
leaq74(%rax), %rdx
movq%rax, %rbx
leaq82(%rax), %rax
leaq.LC0(%rip), %rsi
movl$1, %edi
movq%rax, %rcx
movq%rdx, %r9
movq%rdx, %r8
andl$31, %ecx
andl$31, %r9d
andl$15, %r8d
pushq   %rcx
.cfi_def_cfa_offset 24
movq%rax, %rcx
andl$15, %ecx
pushq   %rcx
.cfi_def_cfa_offset 32
pushq   $2
.cfi_def_cfa_offset 40
movl$2, %ecx
pushq   %rax
.cfi_def_cfa_offset 48
xorl%eax, %eax
call__printf_chk@PLT
leaq10(%rbx), %rdi
addq$32, %rsp
.cfi_def_cfa_offset 16
callB_init
movq%rbx, %rdi
callfree@PLT
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE43:
.size   main, .-main
.ident  "GCC: (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0"
.section.note.GNU-stack,"",@progbits


gcc --version
gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
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.

compile:
gcc -v --save-temps  -O3 -o ccc -DUSE_ALIGN=1 -Wall -Wextra compiler2.c

Description:
test always works with GCC 4.6
test works with GCC >= 5.6 and -DUSE_ALIGN=0
test segv on unaligned movaps with GCC >= 5.6 (latest tested GCC 7.2) and
-DUSE_ALIGN=1


This may be a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84525
but the test case here is different. Am I violating the spec with this test?

[Bug target/85961] scratch register rsi used after function call

[bki at hacon dot de]

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

--- Comment #4 from bki at hacon dot de ---
(In reply to Alexander Monakov from comment #3)
> You'd need to disable IPA-RA after forcing -O2 with the pragma, i.e.:
> 
> #pragma GCC optimize "O2"
> #pragma GCC optimize "no-ipa-ra"

Yes, this changes the problematic instruction sequence to:
  7e: 48 89 c5  mov%rax,%rbp
  81: e8 7a ff ff ffcallq  0
<_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6lengthEv.isra.0>
  86: 48 8d 54 05 00lea0x0(%rbp,%rax,1),%rdx

Which is better, since rbp is not a scratch register.


> [...]. Do we want to adjust it given that "pragma optimized" is documented as 
> "not suitable for production use"?
I appreciate the explanation which makes sense to me. In the original context,
I did introduce the pragma to reduce compilation times like this:
  #pragma GCC optimize "-fno-var-tracking", "-fno-var-tracking-assignments"

So, with instrumentation but without the optimize pragma, scratch registers
will always be considered changed across a function call?

This would then both fix my issue and more general doubts on the feasibility of
my ABI messing. I also agree that the pragma is clearly documented as not fit
for production use and would remove it accordingly. I think I can manage to
pass these options on the command line somehow.

[Bug c++/85889] lambda expression can capture structured bindings

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/85984] New: ICE in create_pseudo_cfg, at dwarf2cfi.c:2874

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

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

Bug ID: 85984
   Summary: ICE in create_pseudo_cfg, at dwarf2cfi.c:2874
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions 8/9 at -O[23] (no better example found).
Changed between 20170723 and 20170820.


$ cat z1.c
int fn1 (void);
void __attribute__((naked))
fn2 (void)
{
  if (!fn1())
abort ();
}
void fn3 (void)
{
  fn2 ();
}


$ gcc-9-20180527 -c z1.c -O2
z1.c: In function 'fn2':
z1.c:6:5: warning: implicit declaration of function 'abort'
[-Wimplicit-function-declaration]
 abort ();
 ^
z1.c:6:5: warning: incompatible implicit declaration of built-in function
'abort'
z1.c:6:5: note: include '' or provide a declaration of 'abort'
z1.c:1:1:
+#include 
 int fn1 (void);
z1.c:6:5:
 abort ();
 ^
during RTL pass: dwarf2
z1.c:7:1: internal compiler error: in create_pseudo_cfg, at dwarf2cfi.c:2874
 }
 ^
0x7cb7a7 create_pseudo_cfg
../../gcc/dwarf2cfi.c:2874
0x7cb7a7 execute_dwarf2_frame
../../gcc/dwarf2cfi.c:3049
0x7cb7a7 execute
../../gcc/dwarf2cfi.c:3540

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #1)
> Works with character(kind=1) :
> 
> 
> $ cat z2.f90
> program p
>integer, allocatable :: arr(:)
>integer :: stat
>character(len=128, kind=1) :: errmsg = ' '
>allocate (arr(3), stat=stat, errmsg=errmsg)
>print *, allocated(arr), stat, trim(errmsg)
> end
> 
> 
> $ gfortran-9-20180527 z2.f90 -static-libgfortran
> $ a.out
>  T   0

It ought to work with kind=1.  For the original code,
and error message should be issued as kind=4 is not
default character kind.

R928  alloc-opt is ERRMSG = errmsg-variable
R930  errmsg-variable   is scalar-default-char-variable
R906  default-char-variable is variable
C906  default-char-variable shall be default character.

[Bug fortran/85983] New: ICE in check_dtio_interface1, at fortran/interface.c:4748

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

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

Bug ID: 85983
   Summary: ICE in check_dtio_interface1, at
fortran/interface.c:4748
   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 incomplete or invalid dummy argument lists :


$ cat z1.f90
module m
   type t
   contains
  procedure :: s1
  procedure :: s2
  generic :: write(formatted) => s1
  generic :: write(formatted) => s2
   end type
contains
   subroutine s1 (dtv)
  class(t), intent(in) :: dtv
   end
   subroutine s2 (dtv, unit)
  class(t), intent(in) :: dtv
  integer, intent(in) :: unit
   end
end


$ cat z2.f90
module m
   type t
   contains
  procedure :: s1
  procedure :: s2
  generic :: write(formatted) => s1
  generic :: write(formatted) => s2
   end type
contains
   subroutine s1 (dtv, iomsg)
  class(t), intent(in) :: dtv
  character(*), intent(inout) :: iomsg
   end
   subroutine s2 (dtv, unit)
  class(t), intent(in) :: dtv
  integer, intent(in) :: unit
   end
end


$ gfortran-9-20180527 -c z1.f90
f951: internal compiler error: in check_dtio_interface1, at
fortran/interface.c:4748
0x6b1478 check_dtio_interface1
../../gcc/fortran/interface.c:4748
0x6b8f05 gfc_check_dtio_interfaces(gfc_symbol*)
../../gcc/fortran/interface.c:4900
0x73595b do_traverse_symtree
../../gcc/fortran/symbol.c:4153
0x71c570 resolve_types
../../gcc/fortran/resolve.c:16513
0x71794c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16586
0x701394 gfc_parse_file()
../../gcc/fortran/parse.c:6262
0x7480ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85982] ICE in resolve_component, at fortran/resolve.c:13696

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

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

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

Comparison sample :


$ cat z2.f90
program p
   type t
  integer :: a
  integer, external, pointer :: b
   end type
end


$ gfortran-9-20180527 -c z2.f90
z2.f90:4:23:

   integer, external, pointer :: b
   1
Error: Attribute at (1) is not allowed in a TYPE definition

[Bug fortran/85982] New: ICE in resolve_component, at fortran/resolve.c:13696

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

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

Bug ID: 85982
   Summary: ICE in resolve_component, at fortran/resolve.c:13696
   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: ---

Needs option -fdec or -fdec-structure :


$ cat z1.f90
program p
   structure /s/
  integer :: a
  integer, external, pointer :: b
   end structure
end


$ gfortran-9-20180527 -c z1.f90 -fdec
f951: internal compiler error: Segmentation fault
0xba072f crash_signal
../../gcc/toplev.c:325
0x71d62c resolve_component
../../gcc/fortran/resolve.c:13696
0x71e812 resolve_fl_struct
../../gcc/fortran/resolve.c:14012
0x718d77 resolve_symbol
../../gcc/fortran/resolve.c:14568
0x73595b do_traverse_symtree
../../gcc/fortran/symbol.c:4153
0x71c0da resolve_types
../../gcc/fortran/resolve.c:16472
0x71794c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16586
0x700e6a resolve_all_program_units
../../gcc/fortran/parse.c:6060
0x700e6a gfc_parse_file()
../../gcc/fortran/parse.c:6310
0x7480ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 29 18:35:34 2018
New Revision: 260903

URL: https://gcc.gnu.org/viewcvs?rev=260903&root=gcc&view=rev
Log:
PR target/85950
* config/i386/i386.md (l2):
Enable for TARGET_SSE4_1 and generate rounds{s,d} and cvtts{s,d}2si{,q}
sequence.
(sse4_1_round2): Use nonimmediate_operand
for operand 1 predicate.

testsuite/ChangeLog:

PR target/85950
* gcc.target/i386/pr85950.c: New test.


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

[Bug fortran/85981] ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

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

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

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

Works with character(kind=1) :


$ cat z2.f90
program p
   integer, allocatable :: arr(:)
   integer :: stat
   character(len=128, kind=1) :: errmsg = ' '
   allocate (arr(3), stat=stat, errmsg=errmsg)
   print *, allocated(arr), stat, trim(errmsg)
end


$ gfortran-9-20180527 z2.f90 -static-libgfortran
$ a.out
 T   0

[Bug fortran/85981] New: ICE in gfc_trans_string_copy, at fortran/trans-expr.c:6539

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

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

Bug ID: 85981
   Summary: ICE in gfc_trans_string_copy, at
fortran/trans-expr.c:6539
   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: ---

Down to at least 4.8 :


$ cat z1.f90
program p
   integer, allocatable :: arr(:)
   integer :: stat
   character(len=128, kind=4) :: errmsg = ' '
   allocate (arr(3), stat=stat, errmsg=errmsg)
   print *, allocated(arr), stat, trim(errmsg)
end


$ gfortran-9-20180527 -c z1.f90
z1.f90:5:0:

allocate (arr(3), stat=stat, errmsg=errmsg)

internal compiler error: in gfc_trans_string_copy, at fortran/trans-expr.c:6539
0x7782cf gfc_trans_string_copy(stmtblock_t*, tree_node*, tree_node*, int,
tree_node*, tree_node*, int)
../../gcc/fortran/trans-expr.c:6539
0x7bb884 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:6708
0x74acf7 trans_code
../../gcc/fortran/trans.c:1996
0x772269 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701040 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x701040 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x7480ef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug testsuite/85888] [9 Regression] New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue May 29 18:29:04 2018
New Revision: 260902

URL: https://gcc.gnu.org/viewcvs?rev=260902&root=gcc&view=rev
Log:
PR middle-end/85888 - New test case c-c++-common/attr-nonstring-6.c from
r260541 fails with excess errors

2018-05-29  Martin Sebor  
Richard Biener  

PR testsuite/85888
* calls.c (get_size_range): Call determine_value_range instead
of get_value_range..
* tree-vrp.h (determine_value_range): Declared new function.
* tree-vrp.c (determine_value_range_1, determine_value_range): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/tree-vrp.c
trunk/gcc/tree-vrp.h

[Bug testsuite/85888] [9 Regression] New test case c-c++-common/attr-nonstring-6.c from r260541 fails with excess errors

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed via r260902.

[Bug c++/85889] lambda expression can capture structured bindings

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug middle-end/85980] New: suboptimal code for strncmp for powerpc64

[msebor at gcc dot gnu.org]

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

Bug ID: 85980
   Summary: suboptimal code for strncmp for powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As discussed in https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01514.html, for
the following test case and the powerpc64le target, GCC emits the code below:

int f (__SIZE_TYPE__ i)
{
  return __builtin_strncmp ("1234", "123", i < 3 ? i : 3);
}

f:
.LFB0:
.cfi_startproc
.LCF0:
0:  addis 2,12,.TOC.-.LCF0@ha
addi 2,2,.TOC.-.LCF0@l
.localentry f,.-f
mflr 0
cmpldi 7,3,3
li 5,3
std 0,16(1)
stdu 1,-32(1)
.cfi_def_cfa_offset 32
.cfi_offset 65, 16
bgt 7,.L5
cmpdi 7,3,4  << unnecessary
mr 5,3   << 
ble 7,.L5<<
li 5,4   <<
.L5:
addis 4,2,.LC1@toc@ha
addis 3,2,.LC0@toc@ha
addi 4,4,.LC1@toc@l
addi 3,3,.LC0@toc@l
bl strncmp
nop
addi 1,1,32
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
blr

The comparison and the subsequent branch are helpful when strncmp is expanded
inline but do not benefit the library version of strncmp and only bloat and
slow down the caller.  (The origins of the code are tracked down in
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01406.html).  The following
simple patch is enough to improve the generated code:

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 841c1ef..5b9085b 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -4708,12 +4708,7 @@ expand_builtin_strncmp (tree exp, ATTRIBUTE_UNUSED rtx
target,
   return target;
 }

-  /* Expand the library call ourselves using a stabilized argument
- list to avoid re-evaluating the function's arguments twice.  */
-  tree fn = build_call_nofold_loc (loc, fndecl, 3, arg1, arg2, len);
-  gcc_assert (TREE_CODE (fn) == CALL_EXPR);
-  CALL_EXPR_TAILCALL (fn) = CALL_EXPR_TAILCALL (exp);
-  return expand_call (fn, target, target == const0_rtx);
+  return expand_call (exp, target, target == const0_rtx);
 }

 /* Expand a call to __builtin_saveregs, generating the result in TARGET,

[Bug c++/85977] Incorrect handling of array reference size deduction

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  We get:

85977.C: In function ‘void bar()’:
85977.C:4:13: error: no matching function for call to ‘foo()’
  foo({1,2,3});
 ^
85977.C:2:6: note: candidate: ‘template void foo(const long int (&)[N])’
 void foo(const long (&arr)[N]) {}
  ^~~
85977.C:2:6: note:   template argument deduction/substitution failed:
85977.C:4:13: note:   mismatched types ‘long int’ and ‘int’
  foo({1,2,3});
 ^

[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with r251438.

[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug target/85961] scratch register rsi used after function call

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
You'd need to disable IPA-RA after forcing -O2 with the pragma, i.e.:

#pragma GCC optimize "O2"
#pragma GCC optimize "no-ipa-ra"

We already have logic to disable IPA-RA when instrumentation/profiling is
active, but it's done once in toplev.c. Here the pragma re-enables IPA-RA after
toplev.c:process_options() has disabled it.

Do we want to adjust it given that "pragma optimized" is documented as "not
suitable for production use"?

[Bug c++/85883] class template argument deduction fails in new-expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 9.

[Bug c++/85883] class template argument deduction fails in new-expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 29 17:44:07 2018
New Revision: 260901

URL: https://gcc.gnu.org/viewcvs?rev=260901&root=gcc&view=rev
Log:
PR c++/85883
* init.c (build_new): Handle deducing a class with new
with more than one argument.

* g++.dg/cpp1z/class-deduction55.C: New test.
* g++.dg/cpp1z/class-deduction56.C: New test.
* g++.dg/cpp1z/class-deduction57.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction55.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction56.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction57.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/53281] poor error message for calling a non-const method from a const object

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
N.B. comment 6 is the subject of PR 85958 which is really a different bug to
this one. This is about invalid member function calls on cv-qualified objects,
and 85958 is about invalid attempts to bind references to cv-qualified objects.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-05-29
 CC||amonakov at gcc dot gnu.org
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #7 from Alexander Monakov  ---
Reopening, the issue here is way more subtle than bug 323 and points to a
possible issue in DOM. Hopefully Richi can have a look and comment.

It appears dom2 pass performs something like jump threading based on
compile-time-evaluated floating-point expression values without also
substituting those expressions in IR. At run time, they are evaluated to
different values, leading to an inconsistency. Namely, dom2 creates bb 10:

  :
  # iftmp.1_1 = PHI <"true"(7), "false"(8), "true"(10)>
  printf ("(a6 == b6) = %s\n", iftmp.1_1);
  return 0;

  :
  _24 = __n2_13 * 1.0e+6;
  b6_25 = (guint64) _24;
  printf ("a6 = %llu\n", 1);
  printf ("b6 = %llu\n", b6_25);
  goto ;

where jump to bb 9 implies that _24 evaluates to 1.0 and b6_25 to 1, but they
are not substituted as such, and at run time evaluate to 0.99... and 0 due to
excess precision.

The following reduced testcase demonstrates the same issue, but requires
-fdisable-tree-dom3 (on gcc-6 at least, as otherwise dom3 substitutes results
of compile-time evaluation).

__attribute__((noinline,noclone))
static double f(void)
{
  return 1e-6;
}

int main(void)
{
  double a = 1e-6, b = f();

  if (a != b) __builtin_printf("uneq");

  unsigned long long ia = a * 1e6, ib = b * 1e6;

  __builtin_printf("%lld %s %lld\n", ia, ia == ib ? "==" : "!=", ib);
}

[Bug c++/85963] [8/9 Regression] false positive "set but not used" warning [-Wunused-but-set-variable]

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
   Target Milestone|--- |8.2
Summary|false positive "set but not |[8/9 Regression] false
   |used" warning   |positive "set but not used"
   |[-Wunused-but-set-variable] |warning
   ||[-Wunused-but-set-variable]
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r253266, Jason, can you please have a look?

[Bug c++/85952] Bogus -Wunused-but-set-variable warning with array structured binding

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 29 17:07:57 2018
New Revision: 260899

URL: https://gcc.gnu.org/viewcvs?rev=260899&root=gcc&view=rev
Log:
PR c++/85952
* init.c (build_aggr_init): For structured binding initialized from
array call mark_rvalue_use on the initializer.

* g++.dg/warn/Wunused-var-33.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-33.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Testing a patch.

[Bug c++/85979] New: Diagnostic says "__alignof" when the source says "alignof"

[redi at gcc dot gnu.org]

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

Bug ID: 85979
   Summary: Diagnostic says "__alignof" when the source says
"alignof"
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

int f() { return alignof(f); }

m.cc: In function 'int f()':
m.cc:1:27: error: ISO C++ forbids applying '__alignof' to an expression of
function type [-fpermissive]
 int f() { return alignof(f); }
   ^

[Bug tree-optimization/85793] [8/9 Regression][AARCH64] ICE in verify_gimple during GIMPLE pass vect.

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from bin cheng  ---
Should be fixed.

[Bug target/85978] New: config/frv/frv.c: 3 * iffy code in switch

[dcb314 at hotmail dot com]

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

Bug ID: 85978
   Summary: config/frv/frv.c: 3 * iffy code in switch
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---
Target: frv

gcc/config/frv/frv.c:6715:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
gcc/config/frv/frv.c:6741:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]
gcc/config/frv/frv.c:6766:7: warning: this statement may fall through
[-Wimplicit-fallthrough=]

Source code for the first one is

  switch (to)
{
default:
  break;

Instead merely carrying on with the code after the switch,
and going into the next case for the outer switch,
perhaps better code would flag up in some way the unexpected
value of "to" ?

[Bug c++/85977] New: Incorrect handling of array reference size deduction

[jeremy at jeremyms dot com]

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

Bug ID: 85977
   Summary: Incorrect handling of array reference size deduction
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeremy at jeremyms dot com
  Target Milestone: ---

This code should compile, but does not.

template 
void foo(const long (&arr)[N]) {}
void bar() {
 foo({1,2,3});
}

See discussion here:
https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/FS5lNgf9_pQ

[Bug c++/85976] ICE in cp_tree_equal when building Blitz. May be nested templates.

[matthew.hambley at metoffice dot gov.uk]

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

--- Comment #1 from matthew.hambley at metoffice dot gov.uk ---
Created attachment 44207
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44207&action=edit
Processed source file

[Bug c++/85976] New: ICE in cp_tree_equal when building Blitz. May be nested templates.

[matthew.hambley at metoffice dot gov.uk]

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

Bug ID: 85976
   Summary: ICE in cp_tree_equal when building Blitz. May be
nested templates.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthew.hambley at metoffice dot gov.uk
  Target Milestone: ---

When compiling https://github.com/blitzpp/blitz v1.0.1 an ICE is generated.
This does not happen with GCC 6.4.0 or 7.1.0. Processed source file attached.

g++ -v -save-temps -DHAVE_CONFIG_H   -I../../blitz-1.0.1/testsuite
-I../../blitz-1.0.1 -I..  -I.../gcc/8.1.0/include -g -DBZ_DEBUG -DBZ_DEBUG  -MT
expression-slicing.o -MD -MP -MF .deps/expression-slicing.Tpo -c -o
expression-slicing.o ../../blitz-1.0.1/testsuite/expression-slicing.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.1.0/configure --prefix=.../gcc/8.1.0
--disable-multilib
Thread model: posix
gcc version 8.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I'
'../../blitz-1.0.1/testsuite' '-I' '../../blitz-1.0.1' '-I' '..' '-I'
'.../gcc/8.1.0/include' '-g' '-D' 'BZ_DEBUG' '-D' 'BZ_DEBUG' '-MT'
'expression-slicing.o' '-MD' '-MP' '-MF' '.deps/expression-slicing.Tpo' '-c'
'-o' 'expression-slicing.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 .../gcc/8.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.1.0/cc1plus -E -quiet
-v -I ../../blitz-1.0.1/testsuite -I ../../blitz-1.0.1 -I .. -I
.../gcc/8.1.0/include -iprefix
.../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/ -MD
expression-slicing.d -MF .deps/expression-slicing.Tpo -MP -MT
expression-slicing.o -D_GNU_SOURCE -D HAVE_CONFIG_H -D BZ_DEBUG -D BZ_DEBUG
../../blitz-1.0.1/testsuite/expression-slicing.cpp -mtune=generic -march=x86-64
-g -fworking-directory -fpch-preprocess -o expression-slicing.ii
ignoring nonexistent directory
".../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0"
ignoring duplicate directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-pc-linux-gnu"
ignoring duplicate directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward"
ignoring duplicate directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include"
ignoring duplicate directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include-fixed"
ignoring nonexistent directory
".../gcc/8.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory ".../gcc/8.1.0/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 ../../blitz-1.0.1/testsuite
 ../../blitz-1.0.1
 ..

.../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0

.../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/x86_64-pc-linux-gnu

.../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../include/c++/8.1.0/backward
 .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include
 .../gcc/8.1.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.1.0/include-fixed
 /usr/local/include
 .../gcc/8.1.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'HAVE_CONFIG_H' '-I'
'../../blitz-1.0.1/testsuite' '-I' '../../blitz-1.0.1' '-I' '..' '-I'
'.../gcc/8.1.0/include' '-g' '-D' 'BZ_DEBUG' '-D' 'BZ_DEBUG' '-MT'
'expression-slicing.o' '-MD' '-MP' '-MF' '.deps/expression-slicing.Tpo' '-c'
'-o' 'expression-slicing.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 .../gcc/8.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.1.0/cc1plus
-fpreprocessed expression-slicing.ii -quiet -dumpbase expression-slicing.cpp
-mtune=generic -march=x86-64 -auxbase-strip expression-slicing.o -g -version -o
expression-slicing.s
GNU C++14 (GCC) version 8.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 70ca2263e1163415e5052b440bbed5d9
In file included from ../../blitz-1.0.1/blitz/array/stencil-et.h:398,
 from ../../blitz-1.0.1/testsuite/expression-slicing.cpp:3:
../../blitz-1.0.1/blitz/a

[Bug libfortran/85975] New: Incorrect size for spread array

[stephan.kramer at imperial dot ac.uk]

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

Bug ID: 85975
   Summary: Incorrect size for spread array
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stephan.kramer at imperial dot ac.uk
  Target Milestone: ---

With the following program

program foo
  implicit none

  call bar(2, 3, 5, 7)

  contains

  subroutine bar(k, l, m, n)
integer, intent(in) :: k, l, m, n
real, dimension(k) :: a
real, dimension(k,l):: b
real, dimension(k,l,m):: c
real, dimension(k,l,m,n):: d

print *, size(spread(A, 1, 1))
print *, size(spread(b, 1, 1))
print *, size(spread(c, 1, 1))
print *, size(spread(d, 1, 1))

  end subroutine

end program

I get the following result:

$ gfortran test2.f90 
skramer@gyre:~/tst/gfortran8$ ./a.out 
   2
   6
   0
 210
skramer@gyre:~/tst/gfortran8$ ./a.out 
   0
   6
   754395868
 210

i.e. the results for the A and c arrrays are incorrect (and vary between
subsequent reruns).

After some digging in the libfortran source I think this is due to a bug in the 
GFC_DTYPE_COPY_SETRANK macro introduced in
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00369.html, where line 421 of
libgfortran/libgfortran.h changed from

(a)->dtype = (((b)->dtype & ~GFC_DTYPE_RANK_MASK) | n ); \

to

(a)->dtype.rank = ((b)->dtype.rank | n ); \

The thing is that the "| n" makes sense in the previous case where the relevant
bits that store the previous rank have been zeroed out first. Now that rank is
a separate field, I think it should just be:

(a)->dtype.rank = n

Note that in the example above the even ranked arrays (B and D) do get the
correct result. This is because in those cases it happens to be that
new_rank==(old_rank | new_rank) (3 == 2 | 3 and 5 == 4 | 5). In the case of
arrays A and C however, we get 1 | 2 == 3 and 3 | 4 == 7, so that the rank of
the resulting spread array is too big, and the size calculations uses spurious
uninitialised array extents.

I have found, what I think are, related issues, when passing the result of
spread of a rank-3 array into a subroutine, where in the "internal pack"
routine  would sometimes try to allocate a temporary that is way too big and
cause an out of memory error (similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85816). Unfortunately this one
seems a little harder to reproduce in a small program.

[Bug c/85974] Failure to optimize difference of two pointers into a compile time constant

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
In match.pd

 (simplify
- (pointer_diff (convert?@2 @0) (convert?@3 ADDR_EXPR@1))
+ (pointer_diff (convert?@2 @0) (convert1?@3 ADDR_EXPR@1))

(that is, we can have only one cast, not just 0 or 2)

and similarly for the adjacent transformation. I didn't check if that requires
any other adjustment, just pointing out a likely place for a patch.

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[linux at carewolf dot com]

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

--- Comment #6 from Allan Jensen  ---
Btw, I have tested and the patch works for my cases.

[Bug c/85974] New: Failure to optimize difference of two pointers into a compile time constant

[pkoning at gcc dot gnu.org]

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

Bug ID: 85974
   Summary: Failure to optimize difference of two pointers into a
compile time constant
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pkoning at gcc dot gnu.org
  Target Milestone: ---

This issue is exposed by test case testsuite/gcc.c-torture/compile/930326-1.c,
on platforms where ptrdiff_t is not "long" (such as pdp11).  In that case, the
last line:
   long i = s.f-&s.b;
fails with "error: initializer element is not computable at load time".

It's not a target bug; the problem can be reproduced for other targets by
changing the "long" to "char" in that statement.

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #4 from Martin Liška  ---
Confirmed with:
$  gcc pr85960.c  -O2 -Wall -fipa-pta && ./a.out 2

Let me take a look.

[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map

[jose.dapena at lge dot com]

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

Jose Dapena Paz  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #3 from Jose Dapena Paz  ---
Confirmed it is already fixed in 7.3.0. Also, the original bug report addresses
the same problem. Thanks!

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[gianni at scaramanga dot co.uk]

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

--- Comment #3 from Gianni Tedesco  ---
Both gcc-7.3 and gcc-8 from ubuntu on x86-64:

gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu
8-20180414-1ubuntu2) 
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[gianni at scaramanga dot co.uk]

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

--- Comment #2 from Gianni Tedesco  ---
Both gcc-7.3 and gcc-8 from ubuntu on x86-64:

gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu
8-20180414-1ubuntu2) 
gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)

[Bug c++/85973] New: [[nodiscard]] shall emit a warning for unused anonymous variable

[romain.geissler at amadeus dot com]

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

Bug ID: 85973
   Summary: [[nodiscard]] shall emit a warning for unused
anonymous variable
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

I would to know if the following (currently not implemented) behaviour of
[[nodiscard]] would be useful or not. I am raising this since we have just hit
this case in a real codebase.

Currently a class can be annotated [[nodiscard]] in which case you can't ignore
returned values of this class. However no warning is emitted when an anonymous
and apparently unused instance of this class is created.

It will be clearer with the following snippet:

class [[nodiscard]] A
{
public:
A(void* someArgument) { /* Get some RAII resources */}

~A() { /* Release some RAII resources */}

A(A&&) = default;
A& operator=(A&&) = default;

private:
A(const A&) = delete;
A& operator=(const A&) = delete;
};

A f();

void someStatement();

void g()
{
f(); // Here ignored A result is correctly warned

{
A(nullptr); // Here the anonymous A created does not yield any warning
// while one might expect to (ie we should write: A a(nullptr); using a
// non anonymous variable, which changes the semantic of the program.)

someStatement(); // statement using the fact that we use RAII resource
locking.
}
}

Typically A could be std::lock_guard.

As you can see in godbolt https://godbolt.org/g/AdxJMY only the call to f()
raises the warning, but not the anonymous A(nullptr). One (actually I) would
expect also a warning on the line A(nullptr). Is this improvement welcome or
not ?

Cheers,
Romain

[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
For the FSM part since we walk the whole function for _each_ control stmt name
this analysis part, find_jump_threads_backwards (basic_block bb, bool speed_p),
is quadratic in the number of BBs.

There's limiting via PARAM_FSM_MAXIMUM_PHI_ARGUMENTS but I guess it should
instead limit itself on the maximum length of a jump threading path and
do that already during analysis rather than only later throwing away
non-profitable ones.

[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Ok, it's not this part of CFG cleanup but the remove_edge_and_domiated_blocks
call in cleanup_control_expr_graph.  With the reduced testcase we call it
around
2000 times.

The FSM thing of course is separate, looks like some quadraticness.

I will see if I can somehow improve CFG cleanup (given it is called
remove_edge_and_dominated_blocks avoiding dominators sounds hard...).

[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
This was a defect in the standard, not GCC, and is already fixed in GCC 7.3.0

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

[Bug libstdc++/82522] std::map::insert(value_type &&) not selected

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jose.dapena at lge dot com

--- Comment #10 from Jonathan Wakely  ---
*** Bug 85970 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/85971] Really Simple "If" with one function call inside is not optimized efficiently

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug lto/85759] ICE output_profile_summary, at lto-cgraph.c:706 using -profile-use

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
Author: marxin
Date: Tue May 29 12:11:21 2018
New Revision: 260895

URL: https://gcc.gnu.org/viewcvs?rev=260895&root=gcc&view=rev
Log:
libgcov: report about a different timestamp (PR gcov-profile/85759).

2018-05-29  Martin Liska  

PR gcov-profile/85759
* doc/gcov.texi: Document GCOV_ERROR_FILE and GCOV_EXIT_AT_ERROR
env variables.
2018-05-29  Martin Liska  

PR gcov-profile/85759
* libgcov-driver-system.c (gcov_error): Introduce usage of
GCOV_EXIT_AT_ERROR env. variable.
* libgcov-driver.c (merge_one_data): Print error that we
overwrite a gcov file with a different timestamp.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi
trunk/libgcc/ChangeLog
trunk/libgcc/libgcov-driver-system.c
trunk/libgcc/libgcov-driver.c

[Bug target/85972] New: cr16/predicates.md:163: bad if test ?

[dcb314 at hotmail dot com]

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

Bug ID: 85972
   Summary: cr16/predicates.md:163: bad if test ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

runk/gcc/config/cr16/predicates.md:163:17: 
warning: logical ‘or’ of collectively exhaustive tests is always true
[-Wlogical
-op]

Source code is

return (IN_RAN(INTVAL (op), 0, 15) && ((INTVAL (op) != 9)
|| (INTVAL (op) != 11))) ? 1 : 0 ;

Maybe better code

return (IN_RAN(INTVAL (op), 0, 15) && ((INTVAL (op) != 9)
&& (INTVAL (op) != 11))) ? 1 : 0 ;

[Bug tree-optimization/85971] New: Really Simple "If" with one function call inside is not optimized efficiently

[mcccs at gmx dot com]

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

Bug ID: 85971
   Summary: Really Simple "If" with one function call inside is
not optimized efficiently
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcccs at gmx dot com
  Target Milestone: ---

GCC: 8 or 9/trunk

Optimization: O3 or Ofast

Code:

```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
if (isTestNet == 0) {
*mod = PolyMod(5);
} else {
*mod = PolyMod(9);
}
}
```

It is optimized very inefficiently. The
assembly has one branch.

However, if the compiler was as smart as the
people who develop it, he'd transform the code into
this:

```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
int a;
if (isTestNet == 0) {
a = 5;
} else {
a = 9;
}
*mod = PolyMod(a);
}
```

which compiles to assembly with zero branches.
Another way to reach the same efficient assembly would be

```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
*mod = PolyMod(isTestNet == 0 ? 5 : 9);
}
```

So, the compiler has problems seeing little powerful
argument optimizations.

[Bug libstdc++/85970] Cannot move a std::unique_ptr to insert into a map

[jose.dapena at lge dot com]

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

Jose Dapena Paz  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Jose Dapena Paz  ---
Though I reported to gcc, it seems it is actually related to the  libstdc++
library. GCC properly compiles this code using LLVM libc++.

[Bug c++/85970] New: Cannot move a std::unique_ptr to insert into a map

[jose.dapena at lge dot com]

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

Bug ID: 85970
   Summary: Cannot move a std::unique_ptr to insert into a map
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jose.dapena at lge dot com
  Target Milestone: ---

Created attachment 44206
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44206&action=edit
Test case

Trying to insert to an std::map with value type std::unique_ptr using a move to
the initializer list fails:

  std::map> map;

  std::string str = "a";
  std::unique_ptr a = std::make_unique();

  // This fails
  map.insert({str, std::move(a)});


But, if instead of this we do:

  map.insert(std::pair>(str, std::move(a)));

It works.

This is working in LLVM libc++.

The error we get is related to trying to use the copy contructor of std::pair
and std::unique_ptr:
/usr/include/c++/7/ext/new_allocator.h:136:4: error: use of deleted function
‘std::pair<_T1, _T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~
In file included from /usr/include/c++/7/bits/stl_algobase.h:64:0,
 from /usr/include/c++/7/bits/stl_tree.h:63,
 from /usr/include/c++/7/map:60,
 from main.cc:1:
/usr/include/c++/7/bits/stl_pair.h:292:17: note: ‘std::pair<_T1,
_T2>::pair(const std::pair<_T1, _T2>&) [with _T1 = const
std::__cxx11::basic_string; _T2 = std::unique_ptr]’ is implicitly
deleted because the default definition would be ill-formed:
   constexpr pair(const pair&) = default;
 ^~~~
/usr/include/c++/7/bits/stl_pair.h:292:17: error: use of deleted function
‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with
_Tp = A; _Dp = std::default_delete]’
In file included from /usr/include/c++/7/memory:80:0,
 from main.cc:2:
/usr/include/c++/7/bits/unique_ptr.h:388:7: note: declared here
   unique_ptr(const unique_ptr&) = delete;
   ^~

[Bug target/85918] Conversions to/from [unsigned] long long are not vectorized for AVX512DQ target

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 29 11:58:24 2018
New Revision: 260893

URL: https://gcc.gnu.org/viewcvs?rev=260893&root=gcc&view=rev
Log:
PR target/85918
* tree.def (VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): New tree codes.
* tree-pretty-print.c (op_code_prio): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR.
(dump_generic_node): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* tree-inline.c (estimate_operator_cost): Likewise.
* gimple-pretty-print.c (dump_binary_rhs): Handle VEC_PACK_FLOAT_EXPR.
* fold-const.c (const_binop): Likewise.
(const_unop): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR and
VEC_UNPACK_FIX_TRUNC_LO_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
(verify_gimple_assign_binary): Handle VEC_PACK_FLOAT_EXPR.
* cfgexpand.c (expand_debug_expr): Handle VEC_UNPACK_FIX_TRUNC_HI_EXPR,
VEC_UNPACK_FIX_TRUNC_LO_EXPR and VEC_PACK_FLOAT_EXPR.
* expr.c (expand_expr_real_2): Likewise.
* optabs.def (vec_packs_float_optab, vec_packu_float_optab,
vec_unpack_sfix_trunc_hi_optab, vec_unpack_sfix_trunc_lo_optab,
vec_unpack_ufix_trunc_hi_optab, vec_unpack_ufix_trunc_lo_optab): New
optabs.
* optabs.c (expand_widen_pattern_expr): For
VEC_UNPACK_FIX_TRUNC_HI_EXPR and VEC_UNPACK_FIX_TRUNC_LO_EXPR use
sign from result type rather than operand's type.
(expand_binop_directly): For vec_packu_float_optab and
vec_packs_float_optab allow result type to be different from operand's
type.
* optabs-tree.c (optab_for_tree_code): Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR.  Formatting fixes.
* tree-vect-generic.c (expand_vector_operations_1):  Handle
VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR and
VEC_PACK_FLOAT_EXPR.
* tree-vect-stmts.c (supportable_widening_operation): Handle
FIX_TRUNC_EXPR.
(supportable_narrowing_operation): Handle FLOAT_EXPR.
* config/i386/i386.md (fixprefix, floatprefix): New code attributes.
* config/i386/sse.md (*floatv2div2sf2): Rename to ...
(floatv2div2sf2): ... this.  Formatting fix.
(vpckfloat_concat_mode, vpckfloat_temp_mode, vpckfloat_op_mode): New
mode attributes.
(vec_pack_float_): New expander.
(vunpckfixt_mode, vunpckfixt_model, vunpckfixt_extract_mode): New mode
attributes.
(vec_unpack_fix_trunc_lo_,
vec_unpack_fix_trunc_hi_): New expanders.
* doc/md.texi (vec_packs_float_@var{m}, vec_packu_float_@var{m},
vec_unpack_sfix_trunc_hi_@var{m}, vec_unpack_sfix_trunc_lo_@var{m},
vec_unpack_ufix_trunc_hi_@var{m}, vec_unpack_ufix_trunc_lo_@var{m}):
Document.
* doc/generic.texi (VEC_UNPACK_FLOAT_HI_EXPR,
VEC_UNPACK_FLOAT_LO_EXPR): Fix pasto in description.
(VEC_UNPACK_FIX_TRUNC_HI_EXPR, VEC_UNPACK_FIX_TRUNC_LO_EXPR,
VEC_PACK_FLOAT_EXPR): Document.

* gcc.target/i386/avx512dq-pr85918.c: Add -mprefer-vector-width=512
and -fno-vect-cost-model options.  Add aligned(64) attribute to the
arrays.  Add suffix 1 to all functions and use 4 iterations rather
than N.  Add functions with conversions to and from float.
Add new set of functions with 8 iterations and another one
with 16 iterations, expect 24 vectorized loops instead of just 4.
* gcc.target/i386/avx512dq-pr85918-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr85918-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/generic.texi
trunk/gcc/doc/md.texi
trunk/gcc/expr.c
trunk/gcc/fold-const.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/optabs-tree.c
trunk/gcc/optabs.c
trunk/gcc/optabs.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512dq-pr85918.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-vect-generic.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree.def

[Bug target/85969] New: avr/gen-avr-mmcu-specs.c:56: unused function ?

[dcb314 at hotmail dot com]

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

Bug ID: 85969
   Summary: avr/gen-avr-mmcu-specs.c:56: unused function ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

config/avr/gen-avr-mmcu-specs.c:56:1: warning: ‘bool str_prefix_p(const char*,
const char*)’ defined but not used [-Wunused-function]

Source code is

221141gjl /* Return true iff STR starts with PREFIX.  */
221141gjl
221141gjl static bool
221141gjl str_prefix_p (const char *str, const char *prefix)
221141gjl {
255831  jakub   return strncmp (str, prefix, strlen (prefix)) == 0;
221141gjl }

$ fgrep str_prefix_p /home/dcb/gcc/trunk/gcc/config/avr/gen-avr-mmcu-specs.c
str_prefix_p (const char *str, const char *prefix)
$

[Bug c++/85965] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
There's nothing that can be done here. The error comes from the library (not
the compiler) and there's no way the compiler can possibly say "the static
assertion would have passed if the __is_invocable trait had been true, which
might have happened if the type was complete so that a conversion sequence from
const Biz* to const Bar* might be possible".

The is_invocable trait asks if that function object can be called with those
arguments, and when Biz is incomplete the answer is no.

I think sadly I have to remove that static_assertion, or just make it happen
later when the comparison function is used (by which point either the call
works, or you get an error anyway and the static assertion doesn't add any
value).

[Bug target/85968] New: gcc/config/arc/arc.c:9805: bad test ?

[dcb314 at hotmail dot com]

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

Bug ID: 85968
   Summary: gcc/config/arc/arc.c:9805: bad test ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

gcc/trunk/gcc/config/arc/arc.c:9805:65: warning: bitwise comparison always
evaluates to true [-Wtautological-compare]

Source code is

250266claziss   if (((fn_type & ARC_FUNCTION_ILINK1) |
ARC_FUNCTION_FIRQ) != 0)
250266claziss regno = ILINK1_REGNUM;
250266claziss   else if ((fn_type & ARC_FUNCTION_ILINK2) != 0)
250266claziss regno = ILINK2_REGNUM;
250266claziss   else
250266claziss gcc_unreachable ();

but

  /* Fast interrupt is only available on ARCv2 processors.  */
  ARC_FUNCTION_FIRQ= 1 << 3,

so regno only ever gets set to ILINK1_REGNUM.

[Bug target/85961] scratch register rsi used after function call

[bki at hacon dot de]

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

--- Comment #2 from bki at hacon dot de ---
(In reply to Richard Biener from comment #1)
> To me it shoulds you are messing with the ABI behind GCCs back.
True.

I'd still argue that the SysV-ABI suggests that a caller would need to save and
restore %rsi before/after a normal function call. But you are right in that the
function _ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE6lengthEv.isra.0
is not 'normal' in this case but completely in the hands of the compiler (who
does not clobber rsi).

I could rework my messing with the ABI to change fewer registers but since that
is very performance sensitive code, I'd like to understand better if it is
really necessary.

>  We use IPA
> register allocation to do this kind of transform that of course doesn't work
> if you do this.
> 
> So - does -fno-ipa-ra fix this for you?
No, I get the same instruction sequence with '-fno-ipa-ra'

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from avieira at gcc dot gnu.org ---
I believe my patch fixes this.

[Bug target/85961] scratch register rsi used after function call

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 Target||x86_64-*-*, i?86-*-*

--- Comment #1 from Richard Biener  ---
To me it shoulds you are messing with the ABI behind GCCs back.  We use IPA
register allocation to do this kind of transform that of course doesn't work
if you do this.

So - does -fno-ipa-ra fix this for you?

[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #4 from Richard Biener  ---
And the regression is likely for when I added

static bool
cleanup_tree_cfg_noloop (void)
{
...
  /* Ensure that we have single entries into loop headers.  Otherwise
 if one of the entries is becoming a latch due to CFG cleanup
 (from formerly being part of an irreducible region) then we mess
 up loop fixup and associate the old loop with a different region
 which makes niter upper bounds invalid.  See for example PR80549.
 This needs to be done before we remove trivially dead edges as
 we need to capture the dominance state before the pending transform.  */
  if (current_loops)
{
...
/* If we have more than one entry to the loop header
   create a forwarder.  */
if (found_latch && ! any_abnormal && n > 1)
  {
edge fallthru = make_forwarder_block (bb, mfb_keep_latches,
  NULL);

because make_forwarder_block adds a new block which in turn uses
iterate_fix_dominators to fix dominators.  We use dominators to find
latches but we could split the analysis from the transform part and
decide to throw away and re-compute dominators based on some threshold.
Not sure if it is possible to estimate the work of iterate_fix_dominators
up-front.

[Bug c++/85958] Make const qualifier error clear

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonny Grant from comment #1)
> My idea of what would be clearest is :-
> 
> Cannot pass ‘const int‘ as ‘int&‘ (non const)

I don't think that's an improvement at all.

But "... discards const qualifier" or "... discards volatile qualifier" or
"...discards const and volatile qualifiers" might be OK. Or saying "as
reference of non-const type 'int&'" similar to my proposed fix for PR 53281.

[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.2

--- Comment #3 from Richard Biener  ---
Maintaining dominators is costly.

diff --git a/gcc/dominance.c b/gcc/dominance.c
index 20671983f98..5ba765c82be 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -1475,6 +1475,8 @@ iterate_fix_dominators (enum cdi_direction dir,
vec bbs,
   return;
 }

+  timevar_push (TV_DOMINANCE);
+
   /* Construct the graph G.  */
   hash_map map (251);
   FOR_EACH_VEC_ELT (bbs, i, bb)
@@ -1537,6 +1539,8 @@ iterate_fix_dominators (enum cdi_direction dir,
vec bbs,
   free (parent);

   free_graph (g);
+
+  timevar_pop (TV_DOMINANCE);
 }

 void

shows

 backwards jump threading   :   9.02 ( 37%)   0.00 (  0%)   9.01 ( 37%)
  0 kB (  0%)
 dominance computation  :   9.89 ( 40%)   0.01 ( 33%)  10.02 ( 41%)
  0 kB (  0%)

so there are two offenders.  The dominance one is from CFG cleanup as
-ftime-report-details shows:

 tree CFG cleanup   :   3.52 ( 14%)   0.01 ( 25%)   3.43 ( 14%)
773 kB (  3%)
 `- dominance computation   :   9.66 ( 39%)   0.01 ( 25%)   9.77 ( 39%)
  0 kB (  0%)
 `- tree operand scan   :   0.00 (  0%)   0.00 (  0%)   0.01 (  0%)
  0 kB (  0%)
 `- CFG verifier:   0.04 (  0%)   0.00 (  0%)   0.02 (  0%)
  0 kB (  0%)

[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-29
  Known to work||5.5.0
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0

[Bug ipa/85960] -fipa-pta and ifunc are incompatible

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-29
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please specify the GCC version and architecture you are using.  I cannot
reproduce this on x86_64-linux with 4.8.5, 4.9.4, 5.5, 6.4, 7.3, 8.1 or current
trunk.

[Bug tree-optimization/85964] [8/9 Regression] Compile time hog w/ -O3 -ftracer -fno-guess-branch-probability

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
The original testcase looked like this:

int t8;

void
il (void)
{
  int uu = 8;

  do
{
  int yq = 8;

  do
{
  t8 /= (t8 < 2) ? 1 : 3;
  --yq;
}
  while (yq > 0);

  --uu;
}
  while (uu > 0);
}

int
px (int t8)
{
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
  il (); il (); il (); il (); il (); il (); il (); il ();
}

I've only replaced 128 distinct function calls w/ to-be-unrolled loop to save
some space. And gcc 8 and 9 still take much more time to compile this one than
earlier gcc branches.

[Bug middle-end/85956] [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1549

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|9.0 |8.2
Summary|[9 Regression] ICE in   |[8/9 Regression] ICE in
   |wide_int_to_tree_1, at  |wide_int_to_tree_1, at
   |tree.c:1549 |tree.c:1549

--- Comment #2 from Jakub Jelinek  ---
It actually started with r254830 if you drop the default(none) so that you
don't hit the bug r260156 was fixing.
Not really sure if it is desirable to slow down code at runtime for warnings
though, by forcing passing around array lengths for the cases of pointers to
VLA, even when nothing in the code refers to those temporaries.

The problem is in:
  warning_at (location, OPT_Warray_bounds,
  "array subscript %E is below array bounds of %qT",
  low_sub, artype);
where we've checked that low_bound is INTEGER_CST, but up_bound is
error_mark_node (what the temporary VAR_DECL that doesn't get passed to the
parallel region is replaced with).

So, either we shouldn't try to print %qT in this case, at least when up_bound
is error_mark_node, or the type printing should handle the case of
error_mark_node bounds gracefully (say print it as [] rather than crash), or
perhaps omp expansion could just try to replace these error_mark_node array
bounds with NULLs somewhere (no idea if that is actually possible though).

[Bug middle-end/85955] ICE in fold_convert_loc, at fold-const.c:2408

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c   |middle-end
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Mine as well.  We are gimplifying

3791  if (!update_call_from_tree (gsi, result))
3792gimplify_and_update_call_from_tree (gsi, result);
3793  return true;
(gdb) p debug_generic_expr (result)
*sinx_3(D) = IMAGPART_EXPR >;, *cosx_4(D)
= REALPART_EXPR >;

and as part of that failing the store because of the arg mismatch.  This is
because gimple_builtin_call_types_compatible_p uses useless_type_conversion_p
and double * and double ** do not require a conversion in GIMPLE.

[Bug target/85950] Unsafe-math-optimizations regresses optimization using SSE4.1 roundss

[ubizjak at gmail dot com]

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Allan Jensen from comment #4)
> Btw, I found this while trying to figure out why std::round() wasn't also
> optimized to a single roundss instruction, is that just a missing
> optimization or is there a quirk about that that makes them not fit?
> 
> I noticed the definition of the ROUND enum in i386.md is even missing the
> entry to for normal rounding (0 AFAIK)

round() rounds half away from zero, while roundss/roundsd (using normal
rounding) rounds half to even.

[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.2

--- Comment #3 from Richard Biener  ---
Another case of a missing DECL_EXPR for a variable-size type.

[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
   Target Milestone|--- |6.5

[Bug fortran/85953] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2370

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Confirmed, started with r228368.