[Bug c++/92221] New: [Regression] template argument deduction/substitution failed after "Implement P0846R0, ADL and function templates"

[dimitar.yordanov at sap dot com]

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

Bug ID: 92221
   Summary: [Regression] template argument deduction/substitution
failed after "Implement P0846R0, ADL and function
templates"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitar.yordanov at sap dot com
  Target Milestone: ---

Hi,

we see a regression for the following example:

$cat > foo.cpp << EOF
template  class a {
  using b = int;
  using c = int;
  b d;
  void e() { g(d); }
  template  static void g(f...);
};
EOF

$g++ -c foo.cpp

foo.cpp: In member function ‘void a<  >::e()’:
foo.cpp:5:20: error: no matching function for call to ‘a<
 >::g >::c>(a<
 >::b&)’
5 |   void e() { g(d); }
  |^
foo.cpp:6:40: note: candidate: ‘template template static
void a<  >::g(f ...)’
6 |   template  static void g(f...);
  |^
foo.cpp:6:40: note:   template argument deduction/substitution failed:
foo.cpp:5:20: note:   mismatched types ‘f’ and ‘int’
5 |   void e() { g(d); }
  |^

First appears after:

2018-11-01  Marek Polacek  
   Implement P0846R0, ADL and function templates.
   * decl.c (grokfndecl): Allow FUNCTION_DECL in assert.
   ...

Best wishes
Dimitar

[Bug c/92220] -Wconversion generates a false warning for modulo expression when the modulus has smaller type

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
No i think there is one case where what you said is incorrect. When both are
INT_MIN.

[Bug c/92220] New: -Wconversion generates a false warning for modulo expression when the modulus has smaller type

[gcc at mailinator dot com]

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

Bug ID: 92220
   Summary: -Wconversion generates a false warning for modulo
expression when the modulus has smaller type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
  Target Milestone: ---

```
[]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.2.0 (GCC) 

[]$ cat a.c
int f(long long a,int b){
return a%b;
}

[]$ gcc -Wall -Wconversion a.c -c
a.c: In function ‘f’:
a.c:2:10: warning: conversion from ‘long long int’ to ‘int’ may change value
[-Wconversion]
2 |  return a%b;
  | ~^~
```

The specification for `-Wconversion` is "Warn for implicit conversions that may
alter a value.". In this case the result is guaranteed to be convertible to the
type of `b` (`int`) without changing the value.

[Bug c/92219] New: -Wconversion generates a false warning for modulo expression when the modulus has smaller type

[gcc at mailinator dot com]

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

Bug ID: 92219
   Summary: -Wconversion generates a false warning for modulo
expression when the modulus has smaller type
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
  Target Milestone: ---

```
[]$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.2.0 (GCC) 

[]$ cat a.c
int f(long long a,int b){
return a%b;
}

[]$ gcc -Wall -Wconversion a.c -c
a.c: In function ‘f’:
a.c:2:10: warning: conversion from ‘long long int’ to ‘int’ may change value
[-Wconversion]
2 |  return a%b;
  | ~^~
```

The specification for `-Wconversion` is "Warn for implicit conversions that may
alter a value.". In this case the result is guaranteed to be convertible to the
type of `b` (`int`) without changing the value.

[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
/* The transfer function used by the DF equation solver to propagate
   live info through block with BB_INDEX according to the following
   equation:

 bb.livein = (bb.liveout - bb.kill) OR bb.gen
*/
static bool 
live_trans_fun (int bb_index)
{
  basic_block bb = get_bb_data_by_index (bb_index)->bb;
  bitmap bb_liveout = df_get_live_out (bb);
  bitmap bb_livein = df_get_live_in (bb);
  bb_data_t bb_info = get_bb_data (bb);

  bitmap_and_compl (_bitmap, bb_liveout, _hard_regs_bitmap);

This does "temp_bitmap = bb_liveout & ~all_hard_regs_bitmap" which
clears all hard live out registers.

  return bitmap_ior_and_compl (bb_livein, _info->gen_pseudos,
   _bitmap, _info->killed_pseudos);
}

[Bug target/92218] PowerPC indexed insn attribute misses some insns (bswap, atomic, small int float/vector load/store)

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-25
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
Summary|PowerPC indexed insn|PowerPC indexed insn
   |attribute misses some insns |attribute misses some insns
   |(bswap, atomic, small int   |(bswap, atomic, small int
   |float memory)   |float/vector load/store)
 Ever confirmed|0   |1

[Bug target/92218] New: PowerPC indexed insn attribute misses some insns (bswap, atomic, small int float memory)

[meissner at gcc dot gnu.org]

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

Bug ID: 92218
   Summary: PowerPC indexed insn attribute misses some insns
(bswap, atomic, small int float memory)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In working on the PowerPC 'future' processor, I was using the 'indexed' insn
attribute to know when a certain insn used indexed addressing instead of offset
addressing.

However it fails in one crucial case.  If the address is a single register
(i.e. indirect addressing) and the insn form requires indexed addressing, the
indexed_address_mem predicate function will fail.

Off the top of my head, the places where this happens is:
1) Load/store of 8/16/32-bit integers to/from vector/FPR registers;
2) Byte swap to/from memory; or
3) Atomic memory operations.

The simplest approach is to go into each of the problematical insns, and
explicitly set 'indexed' to 'yes' for the alternatives that require indexed
addressing.

[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
IRA has

; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(6){ }u1(7){ }u2(16){ }u3(19){ }}
;; lr  in5 [di] 6 [bp] 7 [sp] 16 [argp] 19 [frame]
;; lr  use   5 [di] 6 [bp] 7 [sp] 16 [argp] 19 [frame]

LRA become

; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u0(6){ }u1(7){ }u2(16){ }u3(19){ }}
;; lr  in68 [k0]  << This doesn't look right.
;; lr  use   5 [di] 6 [bp] 7 [sp] 16 [argp] 19 [frame]

[Bug plugins/92217] New: compiler crash due to get_named_event_id not initializing extra reallocated memory

[pageexec at gmail dot com]

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

Bug ID: 92217
   Summary: compiler crash due to get_named_event_id not
initializing extra reallocated memory
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pageexec at gmail dot com
  Target Milestone: ---

When trying to use get_named_event_id/etc for sending events from a plugin,
invoke_plugin_callbacks_full will likely segfault because XNEWVEC/XRESIZEVEC in
get_named_event_id don't initialize the extra part of the new memory block nor
does get_named_event_id memset it explicitly. Next, register_callback will then
link the new callback_info to whatever random memory content is found at
plugin_callbacks[event] and then invoke_plugin_callbacks_full will crash when
it tries to walk there.

This bug has been present since the beginning so I guess noone has ever tested
or used this facility before but it'd still be nice to get it fixed as it
simplifies certain inter-plugin communications a lot.

Thanks,
  PaX Team

[Bug c++/92134] static constinit members incorrectly compile

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Untested fix:

--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -990,6 +990,9 @@ grokfield (const cp_declarator *declarator,
   else
 flags = LOOKUP_IMPLICIT;

+  if (decl_spec_seq_has_spec_p (declspecs, ds_constinit))
+flags |= LOOKUP_CONSTINIT;
+
   switch (TREE_CODE (value))
 {
 case VAR_DECL:

[Bug c/85678] -fno-common should be default

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
This keeps getting brought up in bug 91766 (already added as related from the
other end)

[Bug c++/87768] [8 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:19002 when using concepts

[egallager at gcc dot gnu.org]

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

--- Comment #7 from Eric Gallager  ---
(In reply to gcc-bugs from comment #6)
> I can confirm that this works from 9 and up. Is there any chance to backport
> it to 8?

That's why this bug is still open.

> 
> In the ticket it says `Target Milestone: 8.4`, does that mean there will be
> a 8.4 release that fixes this?

Yes, there will be a release for 8.4, the intent is that 8.4 will fix this, but
the backport hasn't actually happened yet

[Bug c++/92194] maybe-uninitialized false positive with c++2a

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80635

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Possible duplicate of pr80635.

Well, related at least...

[Bug c++/92215] flawed diagnostic for bit-field with non-integral type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-24
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Patch incoming.

[Bug d/92216] New: GDC generate duplicate symbols when mixins and interfaces are used to gather

[kozzi11 at gmail dot com]

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

Bug ID: 92216
   Summary: GDC generate duplicate symbols when mixins and
interfaces are used to gather
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: kozzi11 at gmail dot com
  Target Milestone: ---

Created attachment 47109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47109=edit
Zip archive with b.d and c.d files

There seems to be an issue with generating object symbols for mixins. In some
cases gdc generate same symbols (not weak) in object files so there is a
collision when linking.

Trying to build gtkd package is one of examples. I have write small example to
mitigate this issue. It is add as an attachment.

$ gdc -c -o b.o b.d
$ gdc -c -o c.o c.d
$ gdc -o test.o b.o c.o

ld: c.o: in function `_DT16_D1b1B8__mixin24getSMFZPv':
c.d:(.text+0x27): multiple definition of `_DT16_D1b1B8__mixin24getSMFZPv';
b.o:b.d:(.text+0x38): first defined here

I have try this with gcc 9.2 (gdc (GCC) 9.2.0)

And with git gcc(gdc) 10 (from august)

same issue for both versions

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 84487, which changed state.

Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto 
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84613
Bug 84613 depends on bug 84487, which changed state.

Bug 84487 Summary: [8/9 Regression] Large rodate section increase in 465.tonto 
with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||bergner at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #31 from Peter Bergner  ---
(In reply to Christophe Lyon from comment #30)
> Since this was backported to gcc-8-branch, I've noticed:
> FAIL: gfortran.dg/pr51434.f90   -O2  execution test
> FAIL: gfortran.dg/pr51434.f90   -Os  execution test
> on arm and aarch64

I'm seeing this on powerpc64le-linux as well, also only on FSF 8 branch.  I'm
unsure if the patch is at fault or whether it's exposing a latent issue, since
I can get the tests to pass if I add -fno-tree-vrp.  Maybe there's some
interaction between this patch and VRP?

I'm reopening the bug until this is resolved.

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01771.html

[Bug tree-optimization/91812] [7 Regression] GCC ignores volatile modifier

[fuchedzhy at google dot com]

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

--- Comment #13 from Gregory Fuchedzhy  ---
(In reply to Richard Biener from comment #12)
> Fixed.
Thanks a lot, Richard!

[Bug c++/92215] New: flawed diagnostic for bit-field with non-integral type

[mpolacek at gcc dot gnu.org]

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

Bug ID: 92215
   Summary: flawed diagnostic for bit-field with non-integral type
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

struct S {
  int *foo : 3;
};

r.C:2:8: error: function definition does not declare parameters
2 |   int *foo : 3;
  |^~~

Huh?

We should say something like
r.C:2:8: error: bit-field 'foo' has non-integral type 'int *'

[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 47108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47108=edit
A testcase

[hjl@gnu-skx-1 mask-2]$
/export/build/gnu/tools-build/gcc-tuning-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-tuning-debug/build-x86_64-linux/gcc/ -O2
-march=skylake-avx512 -S foo.ii
during RTL pass: reload
foo.ii: In static member function ‘static void
Implementation::execute_refinement(Triangulation) [with int spacedim
= 3]’:
foo.ii:257:3: internal compiler error: in lra_assign, at lra-assigns.c:1647
  257 |   }
  |   ^
0x11d22d7 lra_assign(bool&)
/export/gnu/import/git/intel/gcc-tuning/gcc/lra-assigns.c:1647
0x11ca2fb lra(_IO_FILE*)
/export/gnu/import/git/intel/gcc-tuning/gcc/lra.c:2482
0x115ee51 do_reload
/export/gnu/import/git/intel/gcc-tuning/gcc/ira.c:5511
0x115f342 execute
/export/gnu/import/git/intel/gcc-tuning/gcc/ira.c:5697
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-skx-1 mask-2]$

[Bug rtl-optimization/92213] internal compiler error: in lra_assign, at lra-assigns.c:1647

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-24
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
1. A pseudo register, 9625, was assigned to mask register k0 and
df_set_regs_ever_live was called.
2. improve_inheritance reassigned 9625 to a different hard register without
updating DF info.
3. mark_pseudo_dead was called on 9625 from process_bb_lives

 EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, i)
{  
  update_pseudo_point (i, curr_point, DEF_POINT);
  mark_pseudo_dead (i);
}  

mark_pseudo_dead did

  lra_assert (!HARD_REGISTER_NUM_P (regno));
  lra_reg_info[regno].conflict_hard_regs |= hard_regs_live;

with incorrect DF info.

[Bug c++/92214] New: Unhelpful diagnostic for static_assert( some_concept(some_type) )

[redi at gcc dot gnu.org]

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

Bug ID: 92214
   Summary: Unhelpful diagnostic for static_assert(
some_concept(some_type) )
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 67491
  Target Milestone: ---

If you accidentally use parentheses instead of angle brackets you get a
confusing error:

template concept foo = true;
static_assert( foo(int) );


Compiled with -std=gnu++2a gives:

x.cc:3:16: error: expected 'auto' or 'decltype(auto)' after 'foo'
3 | static_assert( foo(int) );
  |^~~
x.cc:3:23: error: invalid use of 'auto [requires ::foo<, >]'
3 | static_assert( foo(int) );
  |   ^
x.cc:3:19: error: missing template arguments before '(' token
3 | static_assert( foo(int) );
  |   ^
x.cc:3:20: error: expected primary-expression before 'int'
3 | static_assert( foo(int) );
  |^~~


I wasn't trying to declare a variable using a placeholder type (which wouldn't
be allowed in a static_assert anyway), I was trying to say foo.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.5

--- Comment #12 from Jonathan Wakely  ---
Fixed for 7.5, 8.4 and 9.3

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #28 from rsandifo at gcc dot gnu.org  
---
(In reply to Tamar Christina from comment #26)
> > At least for this one there's the comment
> 
> > /* ??? At present we don't treat the int8_t and int16_t loops as
> >   reductions.  */
> >
> > but I guess it's the same for the rest.  You have to fixup the testcases
> > yourself - they are too complex and fragile.
> 
> Ah yeah fair enough. Thanks!

FWIW, I tested patches last night to fix this, but they were for the
state after: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01714.html

[Bug c++/53610] C++11: constructors accept silly initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-24
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Marek Polacek  ---
Oop.  Confirmed.

[Bug c++/53610] C++11: constructors accept silly initializers

[barry.revzin at gmail dot com]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #3 from Barry Revzin  ---
Shorter reproduction:

struct S {
S(int);
};

S s{.why = 42};

This still compiles on trunk, even with all warnings and -pedantic. 

Made for a very difficult-to-track down bug, since designated initializers are
a really nice way of mocking out named parameters (except when it's suddenly
not).

[Bug c/92212] incompatible calls to K functions not diagnosed

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
See bugs 14030, 26732, 48091, 64526.  Not sure how many bugs in this area 
are genuinely different - I suspect a single bug could be considered to 
cover the whole area of checking arguments to K functions (with 
warnings, not pedwarns or errors, for bad calls), as long as all different 
cases are properly covered with tests added for any fix.

[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[rearnsha at gcc dot gnu.org]

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

--- Comment #8 from Richard Earnshaw  ---
I'm 95%+ sure that this is a problem with qemu+newlib with the latter not
handling out-of-memory correctly.  If I run the good program to the same
instruction that faults in the bad program, I see:

Breakpoint 2, _malloc_r (reent_ptr=0x49570 , bytes=134217732)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2353
2353in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb) 
Continuing.

Breakpoint 1, 0x00018bc0 in _malloc_r (reent_ptr=0x49570 , 
bytes=)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592
2592in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
(gdb) info reg r2
r2 0x804aa40   134523456
(gdb) x/x $r2
0x804aa40:  0x
(gdb) x/x 0x805b000
0x805b000:  Cannot access memory at address 0x805b000

So the location to be written exists and is the last mapped page of memory.

In the 'bad' program, I see

(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
(gdb) p $r2
$14 = 134522216
(gdb) p *$4
$15 = {prev_size = 0, size = 0, fd = 0x804a568, bk = 0x494c0 <__malloc_av_>}
(gdb) p/x $r2
$16 = 0x804a568
(gdb) x/i $r2
   0x804a568:   Cannot access memory at address 0x804a568
(gdb) info reg pc
pc 0x18bc0 0x18bc0 <_malloc_r+1092>
(gdb) x/x 0x8049ffc
0x8049ffc:  0x

that is the location being written is not mapped (but the page before is), this
is despite the address being lower than in the 'good' version.

Note that the difference between the two addresses being written in the two
programs is exactly the same as the difference between the VMAs of the .bss
segment in the executable files.

Consequently, I don't think this is a bug that has been introduced by this
patch, but is most likely a latent issue in either qemu or newlib (or perhaps a
combination of the two).

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 15:31:00 2019
New Revision: 277414

URL: https://gcc.gnu.org/viewcvs?rev=277414=gcc=rev
Log:
PR libstdc++/92143 adjust for OS X aligned_alloc behaviour

OS X 10.15 adds aligned_alloc but it has the same restriction as the AIX
version, namely that alignments smaller than sizeof(void*) are not
supported.

Backport from mainline
2019-10-18  Jonathan Wakely  

PR libstdc++/92143
* libsupc++/new_opa.cc (operator new) [__APPLE__]: Increase alignment
to at least sizeof(void*).

Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/libsupc++/new_opa.cc

[Bug rtl-optimization/92213] New: internal compiler error: in lra_assign, at lra-assigns.c:1647

[hjl.tools at gmail dot com]

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

Bug ID: 92213
   Summary: internal compiler error: in lra_assign, at
lra-assigns.c:1647
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: vmakarov at redhat dot com
  Target Milestone: ---

When enabling mask register spill with:

@@ -21452,6 +21442,13 @@ ix86_get_mask_mode (poly_uint64 nunits, poly_uint64
vector_size)
 static reg_class_t
 ix86_spill_class (reg_class_t rclass, machine_mode mode)
 {
+  if (TARGET_AVX512BW
+  && (mode == QImode
+|| mode == HImode
+|| mode == SImode
+|| (TARGET_64BIT && mode == DImode))
+  && MAYBE_INTEGER_CLASS_P (rclass))
+return ALL_MASK_REGS;
   if (0 && TARGET_GENERAL_REGS_SSE_SPILL
   && TARGET_SSE2
   && TARGET_INTER_UNIT_MOVES_TO_VEC

I ran into

during RTL pass: reload
source/grid/tria.cc: In function 'execute_refinement':
source/grid/tria.cc:9243:4: internal compiler error: in lra_assign, at
lra-assigns.c:1647
 9243 |}
  |^
0xa45159 lra_assign(bool&)
/export/gnu/import/git/intel/gcc-tuning/gcc/lra-assigns.c:1647
0xa3fb4d lra(_IO_FILE*)
/export/gnu/import/git/intel/gcc-tuning/gcc/lra.c:2482
0x9fc3f1 do_reload
/export/gnu/import/git/intel/gcc-tuning/gcc/ira.c:5511
0x9fc3f1 execute
/export/gnu/import/git/intel/gcc-tuning/gcc/ira.c:5697
Please submit a full bug report,

from

 if (! lra_asm_error_p && flag_checking)
/* Check correctness of allocation for call-crossed pseudos but
   only when there are no asm errors as in the case of errors the
   asm is removed and it can result in incorrect allocation.  */
for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++) 
  if (lra_reg_info[i].nrefs != 0 
  && reg_renumber[i] >= 0 
  && overlaps_hard_reg_set_p (lra_reg_info[i].conflict_hard_regs,
  PSEUDO_REGNO_MODE (i), reg_renumber[i]))
gcc_unreachable ();


LRA calls

Check for conflict
assign_by_spills  < Assign mask register k0 to a pseudo
...
assign_spill_hard_regs  Assign mask register k0 to a different pseudo
...
Check for conflict <<< internal compiler error
assign_by_spills

assign_spill_hard_regs fails to notice that k0 has been assigned to
a pseudo.

[Bug c/92210] no warning for invariable used in loop condition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Found this ICE too, my test:

template  void a();
template  struct b;
template  using c = int;
template )> using f = e;
template  using g = f;
template  c>::i> j;

[Bug c/92212] New: incompatible calls to K functions not diagnosed

[msebor at gcc dot gnu.org]

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

Bug ID: 92212
   Summary: incompatible calls to K functions not diagnosed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Unlike some other compilers GCC doesn't diagnose incompatible calls to K
style functions in the same translation unit.

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
int f (i)
  int i;
{
  return i;
}

int g (void)
{
  return f ("");   // missing warning
}

Both Clang and ICC detect the problem and issue the equivalent of: 

warning: incompatible pointer to integer conversion passing 'char [1]' to
parameter of type 'int' [-Wint-conversion]

  return f ("");
^~

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Reduced test-case:

$ cat unified.ii
template  struct A;
class Vector {
  template  struct TypeIsGCThing {
template ::Type> using Vector = Vector;
struct B;
template  class ContainerIter {
  using Action = B;
  using ActionVector = Vector;
  ContainerIter a;
};
  };
};

$ g++ unified.ii -c
unified.ii:9:33: internal compiler error: in strip_typedefs, at cp/tree.c:1682
9 |   ContainerIter a;
  | ^
0x5c5ba0 strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.c:1682
0x5c5ba0 strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.c:1462
0x6f4311 canonicalize_type_argument
../../gcc/cp/pt.c:7928
0x6f4311 canonicalize_type_argument
../../gcc/cp/pt.c:7923
0x70734d coerce_template_parms
../../gcc/cp/pt.c:8771
0x7080df coerce_innermost_template_parms
../../gcc/cp/pt.c:8903
0x71842a lookup_template_class_1
../../gcc/cp/pt.c:9608
0x71842a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9978
0x730e0d finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:3396
0x6e28fd cp_parser_template_id
../../gcc/cp/parser.c:16545
0x6e2af7 cp_parser_class_name
../../gcc/cp/parser.c:23416
0x6df890 cp_parser_qualifying_entity
../../gcc/cp/parser.c:6724
0x6df890 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:6408
0x6dfe92 cp_parser_nested_name_specifier
../../gcc/cp/parser.c:6650
0x6e489a cp_parser_using_declaration
../../gcc/cp/parser.c:19603
0x6ef7bc cp_parser_member_declaration
../../gcc/cp/parser.c:24632
0x6cc220 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24492
0x6cc220 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23592
0x6cdc00 cp_parser_class_specifier
../../gcc/cp/parser.c:23899
0x6cdc00 cp_parser_type_specifier
../../gcc/cp/parser.c:17507

[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
And also 9.3.

Nobody's ever complained abut this, so I don't see a great need to backport it
to gcc-7-branch and gcc-8-branch.

[Bug libstdc++/92059] Crash on tr2::dynamic_bitset::operator=() with optimization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|9.3 |8.4

--- Comment #15 from Jonathan Wakely  ---
Fixed for 8.4 as well.

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 14:13:48 2019
New Revision: 277400

URL: https://gcc.gnu.org/viewcvs?rev=277400=gcc=rev
Log:
PR libstdc++/92143 adjust for OS X aligned_alloc behaviour

OS X 10.15 adds aligned_alloc but it has the same restriction as the AIX
version, namely that alignments smaller than sizeof(void*) are not
supported.

Backport from mainline
2019-10-18  Jonathan Wakely  

PR libstdc++/92143
* libsupc++/new_opa.cc (operator new) [__APPLE__]: Increase alignment
to at least sizeof(void*).

Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/libsupc++/new_opa.cc

[Bug libstdc++/92059] Crash on tr2::dynamic_bitset::operator=() with optimization

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 14:13:25 2019
New Revision: 277396

URL: https://gcc.gnu.org/viewcvs?rev=277396=gcc=rev
Log:
PR libstdc++/92059 fix several bugs in tr2::dynamic_bitset

Backport from mainline
2019-10-11  Jonathan Wakely  

PR libstdc++/92059
* include/tr2/dynamic_bitset (__dynamic_bitset_base): Define all
special member functions as defaulted. Add noexcept to most members.
(__dynamic_bitset_base(size_t, unsigned long long, const _Alloc&)):
Mask off unwanted bits in the __val parameter. Avoid undefined left
shifts.
(__dynamic_bitset_base::_M_assign): Remove.
(__dynamic_bitset_base::_M_do_reset): Use std::fill.
(__dynamic_bitset_base::_M_are_all_aux): Avoid integer promotion when
block_type has lower rank than int.
(dynamic_bitset): Add noexcept to most members. Use injected-class-name
in return types and parameter types.
(dynamic_bitset::_M_Nb): Add default member initializer.
(dynamic_bitset(), dynamic_bitset(const dynamic_bitset&)): Define as
defaulted.
(dynamic_bitset(dynamic_bitset&&)): Clear source object after move.
(dynamic_bitset::operator=(const dynamic_bitset&)): Define as
defaulted.
(dynamic_bitset::operator=(dynamic_bitset&&)): Add noexcept-specifier.
Define without using swap, to propagate allocator correctly.
(dynamic_bitset(const char*, const _Alloc&)): Use strlen.
(dynamic_bitset::_M_do_sanitize, dynamic_bitset::_M_do_fill): Use
casts to avoid unwanted integer promotions.
(dynamic_bitset::_M_copy_from_ptr): Rearrange template parameters and
add default template arguments and default argument to simplify usage.
(dynamic_bitset::_M_copy_from_string): Adjust call to _M_copy_from_ptr.
(operator==(const dynamic_bitset&, const dynamic_bitset&))
(operator<(const dynamic_bitset&, const dynamic_bitset&)): Use _M_Nb.
* include/tr2/dynamic_bitset.tcc (dynamic_bitset::_M_copy_from_ptr):
Adjust template parameters to match declaration.
* testsuite/tr2/dynamic_bitset/cmp.cc: New test.
* testsuite/tr2/dynamic_bitset/cons.cc: New test.
* testsuite/tr2/dynamic_bitset/copy.cc: New test.
* testsuite/tr2/dynamic_bitset/move.cc: New test.
* testsuite/tr2/dynamic_bitset/pr92059.cc: New test.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/cmp.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/cons.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/copy.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/move.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/pr92059.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/tr2/dynamic_bitset
branches/gcc-8-branch/libstdc++-v3/include/tr2/dynamic_bitset.tcc

[Bug c++/91962] [10 Regression] ice in build_target_expr, at cp/tree.c:488

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Fix:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7386,7 +7386,8 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
/* direct_reference_binding might have inserted a ck_qual under
   this ck_ref_bind for the benefit of conversion sequence ranking.
   Ignore the conversion; we'll create our own below.  */
-   if (next_conversion (convs)->kind == ck_qual)
+   if (next_conversion (convs)->kind == ck_qual
+   && !convs->need_temporary_p)
  {
gcc_assert (same_type_p (TREE_TYPE (expr),
 next_conversion (convs)->type));

[Bug c++/92211] New: Lamdas in unevaluated context bug

[pilarlatiesa at gmail dot com]

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

Bug ID: 92211
   Summary: Lamdas in unevaluated context bug
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

This code compiles fine (https://godbolt.org/z/JeuX4m):

template
struct Tensor {};

template
double mag(Tensor const &) { return 0.0; }

template
using TMag = decltype([](Tensor const ) { return mag(x); });

template
class UnaryExpr
{
TOp const Op = {};
};

UnaryExpr> fn() { return {}; }


This one does not (https://godbolt.org/z/rD3v8E):

template
struct Tensor {};

template
double mag(Tensor const &) { return 0.0; }

template
using TMag = decltype([](Tensor const ) { return mag(x); });

template
class UnaryExpr
{
TOp const Op = {};
};

template
UnaryExpr> fn() { return {}; }


This one causes GGC to segfault (https://godbolt.org/z/8GsGYe)

template
struct Tensor {};

template
double mag(Tensor const &) { return 0.0; }

template
using TMag = decltype([](Tensor const ) { return mag(x); });

template
class UnaryExpr
{
TOp const Op = {};
};

template>
UnaryExpr fn() { return {}; }

[Bug c/92210] New: no warning for invariable used in loop condition

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 92210
   Summary: no warning for invariable used in loop condition
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

There is no warning for an invariable used in loop condition:

$: cat s.c
int main(){
  for(int i = 0; i <2;){
  }
}

$: gcc-trunk -Wall -Wextra -pedantic -c s.c

gcc version 10.0.0 20191020 (experimental) (GCC)
target: Ubuntu 4.8.5-4ubuntu8~14.04.2

$: clang-trunk -Weverything -pedantic -c s.c
s.c:2:18: warning: variable 'i' used in loop condition not modified in loop
body [-Wfor-loop-analysis]
  for(int i = 0; i <2;){
 ^
1 warning generated.

Is it a better way to report the warning in loop condition, just like the way
Clang does?

[Bug c/92209] New: Imprecise column number for -Wstrict-prototypes

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 92209
   Summary: Imprecise column number for -Wstrict-prototypes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

GCC outputs a wrong column number of a declared function warning:

$ gcc-trunk -Wstrict-prototypes -c s.c
s.c:1:1: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
1 | static int func_1();
  | ^~

gcc version 10.0.0 20191020 (experimental) (GCC)
target: Ubuntu 4.8.5-4ubuntu8~14.04.2

$ clang -Wstrict-prototypes -c s.c
s.c:1:18: warning: this function declaration is not a prototype
[-Wstrict-prototypes]
static int func_1();
 ^
  void
1 warning generated.

$ cat s.c

static int func_1();

[Bug libstdc++/61761] [C++11] std::proj returns incorrect values

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.0|9.3

[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:55:27 2019
New Revision: 277393

URL: https://gcc.gnu.org/viewcvs?rev=277393=gcc=rev
Log:
PR libstdc++/90682 allow set_terminate(0) and set_unexpected(0)

Make these functions restore the default handlers when passed a null
pointer. This is consistent with std::pmr::set_default_resource(0), and
also matches the current behaviour of libc++.

In order to avoid duplicating the preprocessor condition from
eh_term_handler.cc more that into a new eh_term_handler.h header and
define a macro that can be used in both eh_term_handler.cc and
eh_terminate.cc.

Backport from mainline
2019-05-31  Jonathan Wakely  

PR libstdc++/90682
* libsupc++/eh_term_handler.cc: Include eh_term_handler.h to get
definition of _GLIBCXX_DEFAULT_TERM_HANDLER.
* libsupc++/eh_term_handler.h: New header defining
_GLIBCXX_DEFAULT_TERM_HANDLER.
* libsupc++/eh_terminate.cc: Include eh_term_handler.h.
(set_terminate): Restore default handler when argument is null.
(set_unexpected): Likewise.
* testsuite/18_support/set_terminate.cc: New test.
* testsuite/18_support/set_unexpected.cc: New test.

Added:
branches/gcc-9-branch/libstdc++-v3/libsupc++/eh_term_handler.h
  - copied, changed from r277392,
branches/gcc-9-branch/libstdc++-v3/libsupc++/eh_term_handler.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/18_support/set_terminate.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/18_support/set_unexpected.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/libsupc++/eh_term_handler.cc
branches/gcc-9-branch/libstdc++-v3/libsupc++/eh_terminate.cc

[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:54:58 2019
New Revision: 277388

URL: https://gcc.gnu.org/viewcvs?rev=277388=gcc=rev
Log:
PR libstdc++/89164 enforce constraints for uninitialized algos

The memmove optimizations for std::uninitialized_copy/fill/_n will
compile even if the type is not copy constructible, because std::copy
doesn't require copy construction to work. But the uninitialized
algorithms do require it.

This adds explicit static assertions to ensure we don't allow ill-formed
initializations.

Backport from mainline
2019-08-30  Jonathan Wakely  

PR libstdc++/89164
* include/bits/stl_algobase.h (__copy_move): Give descriptive names
to template parameters.
* include/bits/stl_uninitialized.h (uninitialized_copy)
(uninitialized_fill, uninitialized_fill_n): Add static assertions to
diagnose invalid uses.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc:
Adjust expected error.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/
89164.cc: New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/
89164.cc: New test.
* testsuite/23_containers/vector/cons/89164.cc: New test.
* testsuite/23_containers/vector/cons/89164_c++17.cc: New test.

Added:
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/89164.cc
  - copied, changed from r277387,
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy_n/89164.cc
  - copied, changed from r277387,
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill/89164.cc
  - copied, changed from r277387,
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_fill_n/89164.cc
  - copied, changed from r277387,
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/vector/cons/89164.cc
  - copied, changed from r277387,
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/23_containers/vector/cons/89164_c++17.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_algobase.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_uninitialized.h
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_copy/1.cc

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.3 too.

[Bug libstdc++/91456] std::function and std::is_invocable_r do not understand guaranteed elision

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:54:13 2019
New Revision: 277380

URL: https://gcc.gnu.org/viewcvs?rev=277380=gcc=rev
Log:
PR libstdc++/91456 make INVOKE work with uncopyable prvalues

In C++17 a function can return a prvalue of a type that cannot be moved
or copied. The current implementation of std::is_invocable_r uses
std::is_convertible to test the conversion to R required by INVOKE.
That fails for non-copyable prvalues, because std::is_convertible is
defined in terms of std::declval which uses std::add_rvalue_reference.
In C++17 conversion from R to R involves no copies and so is not the
same as conversion from R&& to R.

This commit changes std::is_invocable_r to check the conversion without
using std::is_convertible.

std::function also contains a similar check using std::is_convertible,
which can be fixed by simply reusing std::is_invocable_r (but because
std::is_invocable_r is not defined for C++11 it uses the underlying
std::__is_invocable_impl trait directly).

Backport from mainline
2019-08-15  Jonathan Wakely  

PR libstdc++/91456
* include/bits/std_function.h (__check_func_return_type): Remove.
(function::_Callable): Use std::__is_invocable_impl instead of
__check_func_return_type.
* include/std/type_traits (__is_invocable_impl): Add another defaulted
template parameter. Define a separate partial specialization for
INVOKE and INVOKE. For INVOKE replace is_convertible check
with a check that models delayed temporary materialization.
* testsuite/20_util/function/91456.cc: New test.
* testsuite/20_util/is_invocable/91456.cc: New test.

Added:
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/function/91456.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_invocable/91456.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/bits/std_function.h
branches/gcc-9-branch/libstdc++-v3/include/std/type_traits

[Bug libstdc++/61761] [C++11] std::proj returns incorrect values

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:55:21 2019
New Revision: 277392

URL: https://gcc.gnu.org/viewcvs?rev=277392=gcc=rev
Log:
PR libstdc++/61761 fix std::proj for targets without C99 cproj

The current generic implementation of __complex_proj used when cproj is
not available calculates the wrong projection, giving a different result
than given by C99's cproj.

When C99 cproj is not available but isinf and copysign are, use those to
give correct results for float, double and long double. Otherwise, and
for other specializations of std::complex, just use a generic version
that returns its argument, and so doesn't support infinities.

We might want to consider adding additional overloads of __complex_proj
to support extended types such as _Float64x, _Float128 etc.

Backport from mainline
2019-05-01  Jonathan Wakely  

PR libstdc++/61761
* include/std/complex (__complex_proj): Return parameter unchanged.
[_GLIBCXX_USE_C99_COMPLEX] (__complex_proj): Change overloads for
floating-point types to take std::complex arguments.
[_GLIBCXX_USE_C99_MATH_TR1] (__complex_proj): Add overloads for
floating-point types.
* testsuite/26_numerics/complex/proj.cc: New test.

Added:
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/complex/proj.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/std/complex

[Bug libstdc++/92059] Crash on tr2::dynamic_bitset::operator=() with optimization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.3
  Known to fail||7.4.0, 8.3.0, 9.2.0

--- Comment #13 from Jonathan Wakely  ---
Also fixed for 9.3

[Bug libstdc++/92143] std::pmr::polymorphic_allocator throws bad_alloc on macOS

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:54:44 2019
New Revision: 277386

URL: https://gcc.gnu.org/viewcvs?rev=277386=gcc=rev
Log:
PR libstdc++/92143 adjust for OS X aligned_alloc behaviour

OS X 10.15 adds aligned_alloc but it has the same restriction as the AIX
version, namely that alignments smaller than sizeof(void*) are not
supported.

Backport from mainline
2019-10-18  Jonathan Wakely  

PR libstdc++/92143
* libsupc++/new_opa.cc (operator new) [__APPLE__]: Increase alignment
to at least sizeof(void*).

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/libsupc++/new_opa.cc

[Bug libstdc++/92059] Crash on tr2::dynamic_bitset::operator=() with optimization

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 12:53:55 2019
New Revision: 277376

URL: https://gcc.gnu.org/viewcvs?rev=277376=gcc=rev
Log:
PR libstdc++/92059 fix several bugs in tr2::dynamic_bitset

Backport from mainline
2019-10-11  Jonathan Wakely  

PR libstdc++/92059
* include/tr2/dynamic_bitset (__dynamic_bitset_base): Define all
special member functions as defaulted. Add noexcept to most members.
(__dynamic_bitset_base(size_t, unsigned long long, const _Alloc&)):
Mask off unwanted bits in the __val parameter. Avoid undefined left
shifts.
(__dynamic_bitset_base::_M_assign): Remove.
(__dynamic_bitset_base::_M_do_reset): Use std::fill.
(__dynamic_bitset_base::_M_are_all_aux): Avoid integer promotion when
block_type has lower rank than int.
(dynamic_bitset): Add noexcept to most members. Use injected-class-name
in return types and parameter types.
(dynamic_bitset::_M_Nb): Add default member initializer.
(dynamic_bitset(), dynamic_bitset(const dynamic_bitset&)): Define as
defaulted.
(dynamic_bitset(dynamic_bitset&&)): Clear source object after move.
(dynamic_bitset::operator=(const dynamic_bitset&)): Define as
defaulted.
(dynamic_bitset::operator=(dynamic_bitset&&)): Add noexcept-specifier.
Define without using swap, to propagate allocator correctly.
(dynamic_bitset(const char*, const _Alloc&)): Use strlen.
(dynamic_bitset::_M_do_sanitize, dynamic_bitset::_M_do_fill): Use
casts to avoid unwanted integer promotions.
(dynamic_bitset::_M_copy_from_ptr): Rearrange template parameters and
add default template arguments and default argument to simplify usage.
(dynamic_bitset::_M_copy_from_string): Adjust call to _M_copy_from_ptr.
(operator==(const dynamic_bitset&, const dynamic_bitset&))
(operator<(const dynamic_bitset&, const dynamic_bitset&)): Use _M_Nb.
* include/tr2/dynamic_bitset.tcc (dynamic_bitset::_M_copy_from_ptr):
Adjust template parameters to match declaration.
* testsuite/tr2/dynamic_bitset/cmp.cc: New test.
* testsuite/tr2/dynamic_bitset/cons.cc: New test.
* testsuite/tr2/dynamic_bitset/copy.cc: New test.
* testsuite/tr2/dynamic_bitset/move.cc: New test.
* testsuite/tr2/dynamic_bitset/pr92059.cc: New test.

Added:
branches/gcc-9-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/cmp.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/cons.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/copy.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/move.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/tr2/dynamic_bitset/pr92059.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/tr2/dynamic_bitset
branches/gcc-9-branch/libstdc++-v3/include/tr2/dynamic_bitset.tcc

[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug libstdc++/90682] std::terminate() will happily call a null terminate handler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.0|9.3

[Bug tree-optimization/92205] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1688 since r277322

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 12:11:27 2019
New Revision: 277375

URL: https://gcc.gnu.org/viewcvs?rev=277375=gcc=rev
Log:
2019-10-24  Richard Biener  

PR tree-optimization/92205
* tree-vect-loop.c (vectorizable_reduction): Restrict
search for alternate vectype_in to lane-reducing patterns
we support.

* gcc.dg/vect/pr92205.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr92205.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/92205] [10 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1688 since r277322

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

[wilco at gcc dot gnu.org]

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

--- Comment #12 from Wilco  ---
(In reply to Andrew Pinski from comment #10)

> This should be a global change and not just an aarch64 change.  The reason
> is because then aarch64 is the odd man out when it comes to this.

Agreed, see https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01549.html. It would
be great to sort that out so C and C++ finally address globals identically.

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #6 from bin cheng  ---
I ran into a stackoverflow entry with following code:
#include 
#include 
#include 
#include 

static void cleanup(void *ptr)
{
}

void *child(void *ptr)
{
  pthread_cleanup_push(cleanup, NULL);
  pthread_exit(NULL);
  pthread_cleanup_pop(1);
  return NULL;
}

int main()
{
  pthread_t foo;
  pthread_create(, NULL, child, NULL);
  pthread_join(foo, NULL);
  return 0;
}

The abort can be reproduced when compiled using gcc-8.3 with following options:
$ g++ -o a.out test.cc -g -Wall -fexceptions  -pthread -static-libstdc++
-static-libgcc
$ gdb --args ./a.out
(gdb) r
(gdb) bt
#0  0xbf4972c8 in raise () from /lib64/libc.so.6
#1  0xbf498940 in abort () from /lib64/libc.so.6
#2  0x0040ec94 in _Unwind_SetGR ()
#3  0x00401c4c in __gxx_personality_v0 ()
#4  0xbec3fab8 in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0xbf462670, context=context@entry=0xbf461560,
frames_p=frames_p@entry=0xbf461198)
at ../../../libgcc/unwind.inc:182
#5  0xbec3fea0 in _Unwind_ForcedUnwind (exc=0xbf462670,
stop=0xbf5f7950 , stop_argument=0xbf461a30) at
../../../libgcc/unwind.inc:217
#6  0xbf5fa15c in _Unwind_ForcedUnwind () from /lib64/libpthread.so.0
#7  0xbf5f7aac in __pthread_unwind () from /lib64/libpthread.so.0
#8  0xbf5f1a08 in pthread_exit () from /lib64/libpthread.so.0
#9  0x00401460 in child (ptr=0x0) at test.cc:13
#10 0xbf5f0bb0 in start_thread () from /lib64/libpthread.so.0
#11 0xbf53e4c0 in thread_start () from /lib64/libc.so.6

Issue with this case is because of static-libgcc, not sure if it's the same to
the original case.

Thanks

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

[kamleshbhalui at gmail dot com]

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

--- Comment #11 from Kamlesh Kumar  ---
is this good?

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 0fffe60..9fead56 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -814,6 +814,10 @@ c_common_post_options (const char **pfilename)
   && flag_unsafe_math_optimizations == 0)
 flag_fp_contract_mode = FP_CONTRACT_OFF;

+  /* defaults to flag_no_common unless disabled with fcommon. */
+  if (!global_options_set.x_flag_no_common)
+  flag_no_common = 1;
+
   /* If we are compiling C, and we are outside of a standards mode,
  we can permit the new values from ISO/IEC TS 18661-3 for
  FLT_EVAL_METHOD.  Otherwise, we must restrict the possible values to

[Bug tree-optimization/92203] [9 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5492

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
   Target Milestone|10.0|9.4
Summary|[10 Regression] ICE in  |[9 Regression] ICE in
   |eliminate_stmt, at  |eliminate_stmt, at
   |tree-ssa-sccvn.c:5492   |tree-ssa-sccvn.c:5492

--- Comment #3 from Richard Biener  ---
Fixed on trunk but the issue is latent at least.

[Bug tree-optimization/92203] [10 Regression] ICE in eliminate_stmt, at tree-ssa-sccvn.c:5492

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 11:23:54 2019
New Revision: 277374

URL: https://gcc.gnu.org/viewcvs?rev=277374=gcc=rev
Log:
2019-10-24  Richard Biener  

PR tree-optimization/92203
* treee-ssa-sccvn.c (eliminate_dom_walker::eliminate_stmt):
Skip eliminating conversion stmts inserted by insertion.

* gcc.dg/torture/pr92203.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr92203.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[postmas...@trippelsdorf-de.bounceio.net]

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

--- Comment #16 from postmas...@trippelsdorf-de.bounceio.net ---
Created attachment 47107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47107=edit
attachment-70446-1.eml

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[postmas...@trippelsdorf-de.bounceio.net]

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

--- Comment #15 from postmas...@trippelsdorf-de.bounceio.net ---
   Your email was bounced...
   -

   ... because something went wrong between you and your recipient. Ugh!


   What to do next?
   

   Well, your specific problem was a *5.1.2 * error.

   Which means you should: Check the "trippelsdorf.de" part of
   "mar...@trippelsdorf.de" for misspellings or missing letters. If you
   find an error, correct it in your contacts list or address book for
   next time.

   Or further: It is possible that the domain is temporarily inactive. If
   the spelling looks correct, contact your mail provider and if
   necessary, contact your recipient another way (e.g., phone or text
   message).

   Get more Bounce Intelligence ™ on 5.1.2 errors here![1]

   Thanks, have a lovely day.

   Yours truly, betterbounces.net[2]

   Rate this email: Helpful[3] :) or... Not Helpful[4] :(

   Advertisement | Prefer no ads?[5]

   YOU MIGHT LIKE

   [6]

   [7]

   [8]

   Learn more about RevenueStripe...[9]

   -

   © 2017 betterbounces.net, All rights reserved. Privacy[10]

   [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

   1.
https://www.betterbounces.net/email-error/5.1.2?utm_source=7o9_medium=direct_campaign=trippelsdorf.de_content=SeretV2
   2. http://bit.ly/1AqkgOr
   3.
https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=677E5AFA-76D9-4DDC-BCAD-BFC0D2E82E83.1=7o9=Helpful
   4.
https://www.surveygizmo.com/s3/1609211/rtm01?tv=SeretV2=5.1.2=677E5AFA-76D9-4DDC-BCAD-BFC0D2E82E83.1=7o9=Not%20helpful
   5.
https://betterbounces.net/b/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7titT91WI150sPs4r2y2APILF5Fb_KY7JnWSvrTPQ_RLqzm5WLiQf9amSPLQH7QgRL0mXsbpxKfISjq.sIQjoNyvY6vg.dtzyFjKNTzMXb_i0jGTCjSlJMptuAbLHSmVg
   6.
http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571904521376_esp=threatwave_offset=0_stripeid=2454
   7.
http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571904521376_esp=threatwave_offset=1_stripeid=2454
   8.
http://stripe.rs-1117-a.com/stripe/redirect?cs_email=f34cde757c9729b925454a1cf67de4ac_sendid=1571904521376_esp=threatwave_offset=2_stripeid=2454
   9.
http://branding.rs-1117-a.com/?utm_source=contentstripe_medium=email_campaign=rs_2454_content=animatedlogo
   10. https://www.betterbounces.net/privacy-policy

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 10:23:52 2019
New Revision: 277373

URL: https://gcc.gnu.org/viewcvs?rev=277373=gcc=rev
Log:
2019-10-24  Richard Biener  

PR tree-optimization/65930
* gcc.dg/vect/vect-reduc-2short.c: Fix typo.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-2short.c

[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-24
Summary|[9 Regression] Useless code |[9/10 Regression] Useless
   |generated for stack /   |code generated for stack /
   |register operations on AVR  |register operations on AVR
 Ever confirmed|0   |1

--- Comment #4 from Georg-Johann Lay  ---
Still an issue with v10.

[Bug target/92190] [10 Regression] ICE in sp_valid_at, at config/i386/i386.c:6162 since r276648

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
It looks that we got partial saves of MS ABI functions all wrong.

According to Table 4 on page 10 of [1], the MS ABI callee saves only lower
128bit parts of XMM6 - XMM15. So, there is no guarantee that upper parts of
XMM6 - XMM15 will be saved. This means, that vzeroupper insertion has no effect
on MS ABI functions, and can be emitted without concern on how upper parts of
YMM/XMM registers are passed over function calls.

Also, the problem with "precise" vzeroupper description is, that clobber now
forces save of callee-saved register, so XMM6 - XMM15 are always saved, as soon
as vzeroupper is emitted.

Someone with access to authoritative documentation should confirm the above.

[1] https://www.agner.org/optimize/calling_conventions.pdf

[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
When single-stepping in the r277178 executable, the final
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
succeeds and
(gdb) p /x $r2
$2 = 0x804aa40

[Bug tree-optimization/65930] Reduction with sign-change not handled

[tnfchris at gcc dot gnu.org]

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

--- Comment #26 from Tamar Christina  ---

> At least for this one there's the comment

> /* ??? At present we don't treat the int8_t and int16_t loops as
>   reductions.  */
>
> but I guess it's the same for the rest.  You have to fixup the testcases
> yourself - they are too complex and fragile.

Ah yeah fair enough. Thanks!

> > I've also noticed a few ICEs on SPEC but haven't pinpointed it to this 
> > commit
> > yet. Running a bisect.
>
> Might be PR92205, I'm testing a patch for that.

Ah yeah it's that one. Thanks. I just noticed it so didn't get a chance to find
an existing report. I'll follow that one. Thanks!

[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
In particular, the execution continues after the last block dumped by qemu:
0x00018e40:  e5974008  ldr  r4, [r7, #8]
0x00018e44:  e0898008  add  r8, sb, r8
0x00018e48:  e3888001  orr  r8, r8, #1
0x00018e4c:  e5848004  str  r8, [r4, #4]
0x00018e50:  ea14  b#0x18aa8

I set a breakpoint at 0x00018e40, then single-step until the crash:
=> 0x18e40 <_malloc_r+1732>:ldr r4, [r7, #8]
=> 0x18e44 <_malloc_r+1736>:add r8, r9, r8
=> 0x18e48 <_malloc_r+1740>:orr r8, r8, #1
=> 0x18e4c <_malloc_r+1744>:str r8, [r4, #4]
=> 0x18e50 <_malloc_r+1748>:b   0x18aa8 <_malloc_r+812>
=> 0x18aa8 <_malloc_r+812>: ldr r3, [r10, #44]  ; 0x2c
=> 0x18aac <_malloc_r+816>: cmp r3, r1
=> 0x18ab0 <_malloc_r+820>: ldr r3, [r10, #48]  ; 0x30
=> 0x18ab4 <_malloc_r+824>: strcc   r1, [r10, #44]  ; 0x2c
=> 0x18ab8 <_malloc_r+828>: cmp r3, r1
=> 0x18abc <_malloc_r+832>: strcc   r1, [r10, #48]  ; 0x30
=> 0x18ac0 <_malloc_r+836>: bic r8, r8, #3
=> 0x18ac4 <_malloc_r+840>: sub r3, r8, r5
=> 0x18ac8 <_malloc_r+844>: cmp r3, #15
=> 0x18acc <_malloc_r+848>: movgt   r2, #0
=> 0x18ad0 <_malloc_r+852>: movle   r2, #1
=> 0x18ad4 <_malloc_r+856>: cmp r5, r8
=> 0x18ad8 <_malloc_r+860>: orrhi   r2, r2, #1
=> 0x18adc <_malloc_r+864>: cmp r2, #0
=> 0x18ae0 <_malloc_r+868>: beq 0x18ba4 <_malloc_r+1064>
=> 0x18ba4 <_malloc_r+1064>:add r2, r4, r5
=> 0x18ba8 <_malloc_r+1068>:orr r3, r3, #1
=> 0x18bac <_malloc_r+1072>:orr r5, r5, #1
=> 0x18bb0 <_malloc_r+1076>:str r5, [r4, #4]
=> 0x18bb4 <_malloc_r+1080>:mov r0, r6
=> 0x18bb8 <_malloc_r+1084>:str r2, [r7, #8]
=> 0x18bbc <_malloc_r+1088>:add r4, r4, #8
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
(gdb) p /x $r2
$1 = 0x804a568
(gdb) si

Program received signal SIGSEGV, Segmentation fault.
0x00018bc0 in _malloc_r (reent_ptr=0x49098 , bytes=)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592
2592in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de  ---
On Thu, 24 Oct 2019, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
> 
> --- Comment #22 from Tamar Christina  ---
> It also causes failures on AArch64.
> 
> 
> FAIL: gcc.target/aarch64/sve/reduc_2.c
> FAIL: gcc.target/aarch64/sve/slp_7.c
> FAIL: gcc.target/aarch64/sve/slp_5.c

At least for this one there's the comment

/* ??? At present we don't treat the int8_t and int16_t loops as
   reductions.  */

but I guess it's the same for the rest.  You have to fixup the testcases
yourself - they are too complex and fragile.

> FAIL: gcc.target/aarch64/sve/reduc_1.c
> 
> I've also noticed a few ICEs on SPEC but haven't pinpointed it to this commit
> yet. Running a bisect.

Might be PR92205, I'm testing a patch for that.

[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[rearnsha at gcc dot gnu.org]

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

--- Comment #5 from Richard Earnshaw  ---
Apart from the addresses used, the traces are identical right up until the
latter version crashes.

The testcase tries to allocate 128Mb+4bytes of memory, so my suspicion is that
this is a test that needs more memory in the simulation.  Why this patch
triggers this failure I'm not sure.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 09:59:24 2019
New Revision: 277372

URL: https://gcc.gnu.org/viewcvs?rev=277372=gcc=rev
Log:
2019-10-24  Richard Biener  

PR tree-optimization/65930
* gcc.dg/vect/vect-reduc-2char-big-array.c: Adjust again.
* gcc.dg/vect/vect-reduc-2char.c: Likewise.
* gcc.dg/vect/vect-reduc-2short.c: Likewise.
* gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise.
* gcc.dg/vect/vect-reduc-pattern-2c.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-2char-big-array.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-2char.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-2short.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-dot-s8b.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-pattern-2c.c

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
(In reply to Rainer Orth from comment #21)
> (In reply to Richard Biener from comment #19)
> > Author: rguenth
> > Date: Wed Oct 23 12:41:49 2019
> > New Revision: 277322
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=277322=gcc=rev
> > Log:
> > 2019-10-23  Richard Biener  
> > 
> > PR tree-optimization/65930
> > * tree-vect-loop.c (check_reduction_path): Allow conversions
> > that only change the sign.
> > (vectorizable_reduction): Relax latch def stmts we handle further.
> > 
> > * gcc.dg/vect/vect-reduc-2char-big-array.c: Adjust.
> > * gcc.dg/vect/vect-reduc-2char.c: Likewise.
> > * gcc.dg/vect/vect-reduc-2short.c: Likewise.
> > * gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise.
> > * gcc.dg/vect/vect-reduc-pattern-2c.c: Likewise.
> 
> This patch caused a couple of regressions on Solaris/SPARC (32 and 64-bit):
> 
> +FAIL: gcc.dg/vect/vect-reduc-2char-big-array.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-2char-big-array.c scan-tree-dump-times vect
> "vectorized 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-2char.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-2char.c scan-tree-dump-times vect "vectorized
> 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-2short.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-2short.c scan-tree-dump-times vect "vectorized
> 3 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c scan-tree-dump-times vect
> "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-pattern-2c.c -flto -ffat-lto-objects 
> scan-tree-dump-times vect "vectorized 1 loops" 1
> +FAIL: gcc.dg/vect/vect-reduc-pattern-2c.c scan-tree-dump-times vect
> "vectorized 1 loops" 1
> 
> I'm attaching the vect-reduc-2char-big-array.c dump as an example.

OK, there's

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/vect-reduc-2char-big-array.c:44:9:
missed:   not vectorized: relevant stmt not supported: min_47 = MIN_EXPR <_20,
min_88>;

looks like those XFAILs are not expected to pass within the constraints
of the testcases (guess that was to be expected).  There's vect_no_int_min_max
to cover up I guess.

For vect-reduc-dot-s8b.c I wonder why it detected the widen_mult pattern
but failed vectorization (dump file?)  Otherwise there's
vect_widen_mult_qi_to_hi which sparc doesn't have.  At least that was used
in the vect-reduc-pattern-2c.c case.

I'm going to install a patch.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[tnfchris at gcc dot gnu.org]

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

--- Comment #22 from Tamar Christina  ---
It also causes failures on AArch64.


FAIL: gcc.target/aarch64/sve/reduc_2.c
FAIL: gcc.target/aarch64/sve/slp_7.c
FAIL: gcc.target/aarch64/sve/slp_5.c
FAIL: gcc.target/aarch64/sve/reduc_1.c

I've also noticed a few ICEs on SPEC but haven't pinpointed it to this commit
yet. Running a bisect.

[Bug libstdc++/88338] Implement P0898R3, C++20 concepts library.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Thu Oct 24 09:47:25 2019
New Revision: 277371

URL: https://gcc.gnu.org/viewcvs?rev=277371=gcc=rev
Log:
PR libstdc++/88338 Implement P0898R3, C++20 concepts library

The implementation is already complete but this updates the docs and
adds tests for the feature test macro.

* doc/xml/manual/status_cxx2020.xml: Update status.
* doc/html/*: Regenerate.
* testsuite/std/concepts/1.cc: New test.
* testsuite/std/concepts/2.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/std/concepts/1.cc
trunk/libstdc++-v3/testsuite/std/concepts/2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/html/manual/status.html
trunk/libstdc++-v3/doc/xml/manual/status_cxx2020.xml

[Bug libstdc++/88322] Implement C++20 library features.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 88338, which changed state.

Bug 88338 Summary: Implement P0898R3, C++20 concepts library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88338

   What|Removed |Added

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

[Bug fortran/92208] New: internal compile error, character array of dynamic length returned from function and passed to subroutine

[nils.reiche at dlr dot de]

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

Bug ID: 92208
   Summary: internal compile error, character array of dynamic
length returned from function and passed to subroutine
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nils.reiche at dlr dot de
  Target Milestone: ---

Description:
A function creates and return an array of characters of a certain length that
is allocated at the call of the function. When the returned array is not passed
to any other function, the code compiles and runs perfectly. But passing this
character array to another subroutine causes an internal compiler error.
Attached is the source code of the test program. It has been working for
compiler versions gcc-5.2 and gcc-8.2, others were not tested.



Source code:

program stringtest

  implicit none
  integer, parameter :: noVars = 2

  print*, "varNames: ", createVarnames("var",noVars)
  call function1(noVars,createVarnames("var",noVars),"path")

contains

function createVarnames(string,noVars) result(stringArray)
  implicit none
  character(len=*),intent(in)  :: string
  integer, intent(in)  :: noVars
  character(len=len_trim(string)+6), dimension(noVars) :: stringArray
  integer :: i
  do i=1,noVars
write(stringArray(i),'(a,i0)') string, i
  enddo
end function createVarnames

subroutine function1(noVars,varNames,path)
  implicit none
  integer, intent(in)  :: noVars
  character(len=*), intent(in)  :: path
  character(len=*), dimension(noVars) :: varNames

  print*, "function1-path: ", trim(path)
  print*, "function1-varNames: ", varNames

end subroutine function1

end program stringtest


Compiler specifications:

gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home_as/ta/moes_mc/software_rhel7/compilers/gcc-9.2.0-install/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure
--prefix=/home_as/ta/moes_mc/software_rhel7/compilers/gcc-9.2.0-install
--enable-threads
Thread model: posix
gcc version 9.2.0 (GCC)



Compiler error message:

gfortran -Wall -Wextra string_test.F90
string_test.F90:1:0:

1 | program stringtest
  |
internal compiler error: ..__result from createvarnames referenced in
stringtest
0xbbac19 convert_nonlocal_reference_op
../../gcc-9.2.0/gcc/tree-nested.c:1053
0xd84882 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc-9.2.0/gcc/tree.c:12151
0x909619 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:253
0x9099f1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:586
0x909b30 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:51
0x909ab1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:631
0x909b30 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:51
0x909a71 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:675
0x909b30 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:51
0x909a71 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:675
0x909b30 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc-9.2.0/gcc/gimple-walk.c:51
0xbb8708 walk_body
../../gcc-9.2.0/gcc/tree-nested.c:703
0xbb8ee0 walk_function
../../gcc-9.2.0/gcc/tree-nested.c:714
0xbb8ee0 walk_all_functions
../../gcc-9.2.0/gcc/tree-nested.c:779
0xbbbe0c lower_nested_functions(tree_node*)
../../gcc-9.2.0/gcc/tree-nested.c:3507
0x7cae9c cgraph_node::analyze()

[Bug c++/67491] [meta-bug] concepts issues

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 88338, which changed state.

Bug 88338 Summary: Implement P0898R3, C++20 concepts library.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88338

   What|Removed |Added

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

[Bug libstdc++/88338] Implement P0898R3, C++20 concepts library.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
P0898R3 is fully implemented as of r277369.

[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|pr36449.C fails on arm  |[10 Regression] pr36449.C
   |after r277179   |fails on arm after r277179

[Bug tree-optimization/91812] [7 Regression] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.4.0

--- Comment #12 from Richard Biener  ---
Fixed.

[Bug debug/91887] [7 Regression] -fdebug-types-section ICE building chromium

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||7.4.0

--- Comment #11 from Richard Biener  ---
Fixed.

[Bug tree-optimization/91812] [7 Regression] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 09:38:56 2019
New Revision: 277370

URL: https://gcc.gnu.org/viewcvs?rev=277370=gcc=rev
Log:
2019-10-24  Richard Biener  

Backport from mainline
2019-10-17  Richard Biener  

PR debug/91887
* dwarf2out.c (gen_formal_parameter_die): Also try to match
context_die against a DW_TAG_GNU_formal_parameter_pack parent.

* g++.dg/debug/dwarf2/pr91887.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr91887.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-phiprop.c

[Bug debug/91887] [7 Regression] -fdebug-types-section ICE building chromium

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Oct 24 09:38:56 2019
New Revision: 277370

URL: https://gcc.gnu.org/viewcvs?rev=277370=gcc=rev
Log:
2019-10-24  Richard Biener  

Backport from mainline
2019-10-17  Richard Biener  

PR debug/91887
* dwarf2out.c (gen_formal_parameter_die): Also try to match
context_die against a DW_TAG_GNU_formal_parameter_pack parent.

* g++.dg/debug/dwarf2/pr91887.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/debug/dwarf2/pr91887.C
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/dwarf2out.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-phiprop.c

[Bug target/92207] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
Created attachment 47104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47104=edit
Execution trace for r277178

[Bug target/92207] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
Created attachment 47105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47105=edit
Execution trace for r277179

[Bug target/92207] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 47103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47103=edit
Executable from r277179

[Bug target/92207] pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 47102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47102=edit
Executable from r277178

[Bug target/92207] New: pr36449.C fails on arm after r277179

[clyon at gcc dot gnu.org]

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

Bug ID: 92207
   Summary: pr36449.C fails on arm after r277179
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01619.html
I have noticed a regression after r277179.

However, it seems tricky to reproduce, and I had to manually regenerate the
toolchains produced by my automatic CI system.

It might be related to the changes in linker offsets.

I'm attaching the full binaries produced at r277178 and r277179, along with the
traces produced with qemu 4.1.0:
qemu-arm -D in_asm,cpu pr36449.exe

Note that qemu traces do not dump all the target instructions, so it's probably
better to use gdb + qemu.

[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets

[rearnsha at gcc dot gnu.org]

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

--- Comment #7 from Richard Earnshaw  ---
(In reply to Kamlesh Kumar from comment #6)
> This Fixes it.
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index 2e73f3515bb..155f4c45500 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -16161,15 +16161,9 @@ aarch64_builtin_support_vector_misalignment
> (machine_mode mode,
>  const_tree type, int
> misalignment,
>  bool is_packed)
>  {
> -  if (TARGET_SIMD && STRICT_ALIGNMENT)
> +  if (STRICT_ALIGNMENT)
>  {
> -  /* Return if movmisalign pattern is not supported for this mode.  */
> -  if (optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
> -return false;
> -
> -  /* Misalignment factor is unknown at compile time.  */
> -  if (misalignment == -1)
> -   return false;
> +  return false;
>  }
>return default_builtin_support_vector_misalignment (mode, type,
> misalignment,
>   is_packed);

No, that bodges around it.  It's not a fix.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[ro at gcc dot gnu.org]

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

--- Comment #21 from Rainer Orth  ---
(In reply to Richard Biener from comment #19)
> Author: rguenth
> Date: Wed Oct 23 12:41:49 2019
> New Revision: 277322
> 
> URL: https://gcc.gnu.org/viewcvs?rev=277322=gcc=rev
> Log:
> 2019-10-23  Richard Biener  
> 
>   PR tree-optimization/65930
>   * tree-vect-loop.c (check_reduction_path): Allow conversions
>   that only change the sign.
>   (vectorizable_reduction): Relax latch def stmts we handle further.
> 
>   * gcc.dg/vect/vect-reduc-2char-big-array.c: Adjust.
>   * gcc.dg/vect/vect-reduc-2char.c: Likewise.
>   * gcc.dg/vect/vect-reduc-2short.c: Likewise.
>   * gcc.dg/vect/vect-reduc-dot-s8b.c: Likewise.
>   * gcc.dg/vect/vect-reduc-pattern-2c.c: Likewise.

This patch caused a couple of regressions on Solaris/SPARC (32 and 64-bit):

+FAIL: gcc.dg/vect/vect-reduc-2char-big-array.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 3 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-2char-big-array.c scan-tree-dump-times vect
"vectorized 3 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-2char.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 3 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-2char.c scan-tree-dump-times vect "vectorized 3
loops" 1
+FAIL: gcc.dg/vect/vect-reduc-2short.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 3 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-2short.c scan-tree-dump-times vect "vectorized 3
loops" 1
+FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c scan-tree-dump-times vect "vectorized 1
loops" 1
+FAIL: gcc.dg/vect/vect-reduc-pattern-2c.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-reduc-pattern-2c.c scan-tree-dump-times vect
"vectorized 1 loops" 1

I'm attaching the vect-reduc-2char-big-array.c dump as an example.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #20 from Rainer Orth  ---
Created attachment 47101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47101=edit
32-bit sparc-sun-solaris2.11 vect-reduc-2char-big-array.c.158t.vect

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-24
 CC||rsandifo at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug c++/92206] New: [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[marxin at gcc dot gnu.org]

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

Bug ID: 92206
   Summary: [10 Regression] ICE in strip_typedefs, at
cp/tree.c:1682 since r277281
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I see the ICE in Firefox:

$ g++ unified.ii -c -Wno-invalid-offsetof -fsyntax-only
In file included from
/home/abuild/rpmbuild/BUILD/obj/js/src/gc/Unified_cpp_js_src_gc0.cpp:29:
/home/abuild/rpmbuild/BUILD/firefox-69.0.3/js/src/gc/GC.cpp:6518:46: internal
compiler error: in strip_typedefs, at cp/tree.c:1682
0x5c5ba0 strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.c:1682
0x5c5ba0 strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.c:1462
0x6f4311 canonicalize_type_argument
../../gcc/cp/pt.c:7928
0x6f4311 canonicalize_type_argument
../../gcc/cp/pt.c:7923
0x70734d coerce_template_parms
../../gcc/cp/pt.c:8771
0x71842a lookup_template_class_1
../../gcc/cp/pt.c:9608
0x71842a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9978
0x730e0d finish_template_type(tree_node*, tree_node*, int)
../../gcc/cp/semantics.c:3396
0x6e28fd cp_parser_template_id
../../gcc/cp/parser.c:16545
0x6e2af7 cp_parser_class_name
../../gcc/cp/parser.c:23416
0x6df890 cp_parser_qualifying_entity
../../gcc/cp/parser.c:6724
0x6df890 cp_parser_nested_name_specifier_opt
../../gcc/cp/parser.c:6408
0x6dcce2 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:17925
0x6cdc58 cp_parser_type_specifier
../../gcc/cp/parser.c:17583
0x6e13c8 cp_parser_type_specifier_seq
../../gcc/cp/parser.c:22123
0x6da354 cp_parser_type_id_1
../../gcc/cp/parser.c:21952
0x6dc803 cp_parser_template_type_arg
../../gcc/cp/parser.c:22043
0x6e1572 cp_parser_template_argument
../../gcc/cp/parser.c:16984
0x6e1572 cp_parser_template_argument_list
../../gcc/cp/parser.c:16895
0x6e1572 cp_parser_enclosed_template_argument_list
../../gcc/cp/parser.c:29278

I'm reducing the test-case now..

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[postmas...@trippelsdorf-de.bounceio.net]

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

--- Comment #14 from postmas...@trippelsdorf-de.bounceio.net ---
Created attachment 47100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47100=edit
attachment-36069-1.eml

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 92174, which changed state.

Bug 92174 Summary: runtime error: index 15 out of bounds for type 'gfc_expr 
*[15]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92174

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/92174] runtime error: index 15 out of bounds for type 'gfc_expr *[15]

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Martin Liška  ---
Fixed now, I'm not planning to make backports.