[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||sandra at codesourcery dot com

--- Comment #8 from Eric Gallager  ---
Changing status to ASSIGNED since there's a recent-enough assignee
(In reply to Eric Gallager from comment #7)
> Changing status to ASSIGNED since there's a recent-enough assignee

Also cc-ing Sandra since she wrote this:

(In reply to Eric Gallager from comment #6)
> 
> Right, I found the thread (I think) I was thinking of:
> https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00957.html

[Bug other/85716] No easy way for end-user to tell what GCC is doing when compilation is slow

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #7 from Eric Gallager  ---
Changing status to ASSIGNED since there's a recent-enough assignee

[Bug tree-optimization/56572] GCC generates non-optimal transactional code when inlining nested transaction.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-12/msg01693.htm
   ||l
   Assignee|aldyh at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Eric Gallager from comment #10)
> (In reply to Aldy Hernandez from comment #9)
> > Created attachment 31787 [details]
> > removal of transactions from clones
> > 
> > This is a patch that fixes part of the problem, but as discussed in the
> > thread, is not sufficient since the uninstrumented code path will still end
> > up containing a nested transaction after inlining.
> > 
> > I am attaching this patch for further reference when this PR is picked up
> > again.  See thread for more details.
> 
> Are you still working on it?

No reply; taking that as a "no"

[Bug c++/77502] -Wzero-as-null-pointer-constant : misleading/imprecise messages

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c++/77370] missing -Wignored-qualiifiers on a bogus const reference

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Martin Sebor from comment #0)
> > GCC rejects the program below because it tries to initialize the non-const
> > reference object cr with a temporary, but it doesn't diagnose the
> > declaration of the reference type CR where it disregards the const
> > qualifier.  In contrast, Clang diagnoses both.  GCC could be improved by
> > doing the same.
> > 
> > $ (set -x && cat z.C && /build/gcc-trunk-svn/gcc/xgcc -B
> > /build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic z.C;
> > /build/llvm-trunk/bin/clang -S -Wall z.C)
> > + cat z.C
> > typedef char& R;
> > typedef const R CR;
> > 
> > char c;
> > R r = c;
> > CR cr = 'b';
> > + /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall -Wextra
> > -Wpedantic z.C
> > z.C:6:9: error: cannot bind non-const lvalue reference of type ‘CR {aka
> > char&}’ to an rvalue of type ‘char’
> >  CR cr = 'b';
> >  ^~~
> > + /build/llvm-trunk/bin/clang -S -Wall z.C
> > z.C:2:9: warning: 'const' qualifier on reference type 'R' (aka 'char &') has
> > no
> >   effect [-Wignored-qualifiers]
> > typedef const R CR;
> > ^~
> > z.C:6:4: error: non-const lvalue reference to type 'char' cannot bind to a
> >   temporary of type 'char'
> > CR cr = 'b';
> >^~~~
> > 1 warning and 1 error generated.
> 
> My version of clang only prints the one error, but then again my version of
> clang is old (because my computer is old). Confirmed anyways that it'd still
> be a nice additional warning to have.
> 
> $ /usr/local/bin/g++ -c -Wall -Wextra -pedantic 77370.cc
> 77370.cc:6:9: error: cannot bind non-const lvalue reference of type ‘CR {aka
> char&}’ to an rvalue of type ‘char’
>  CR cr = 'b';
>  ^~~
> $ /sw/opt/llvm-3.1/bin/clang++ -c -S -Wall -Wextra -pedantic 77370.cc
> 77370.cc:6:4: error: non-const lvalue reference to type 'char' cannot bind
> to a temporary of type 'char'
> CR cr = 'b';
>^~~~
> 1 error generated.
> $

Update: On a newer computer with a newer version of clang I can confirm that I
get the additional warning from -Wignored-qualifiers too: 

$ clang++ -c -S -Wall -Wextra -pedantic 77370.cc
77370.cc:2:9: warning: 'const' qualifier on reference type 'R' (aka 'char &')
has no effect [-Wignored-qualifiers]
typedef const R CR;
^~
77370.cc:6:4: error: non-const lvalue reference to type 'char' cannot bind to a
temporary of type 'char'
CR cr = 'b';
   ^~~~
1 warning and 1 error generated.
$

[Bug c++/80144] Concept introduced with "template" is not diagnosed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #3 from Eric Gallager  ---
cc-ing de facto "concepts" maintainer

[Bug c++/81178] [concepts] poor (partial?) diagnostic for alias substitution failure in a concept body

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Eric Gallager  ---
cc-ing closest thing we have to a "concepts" maintainer

[Bug c++/71138] [concepts] ill-formed non-constant expression use in nested requirement produces duplicated diagnostics with poor source locations

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Eric Gallager  ---
cc-ing Paolo Carlini, who seems to be the main person working on Concepts stuff

[Bug c++/70125] attributes diagnostics missing essential context

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
I see you've been working on attribute diagnostics again lately; any progress
on this one?

[Bug rtl-optimization/26190] combine misses some distributivity

[wilson at gcc dot gnu.org]

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

--- Comment #7 from Jim Wilson  ---
I didn't realize it was assigned to me.  I changed it to unassigned.

[Bug fortran/56789] Wrong code with contiguous dummy argument

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #8)
> Paul, I'm adding you to the CC in the hope that the analysis
> in comment#7 might help you towards a solution that is
> glaringly obvious to you (but not to me :-)

Coo! A Golden Oldie - I can hear Elvis in the background...

I'll take a look.

Tschuess

Paul

[Bug c/87482] Clarify behaviour of resolvers with parameters in for __attribute__((ifunc))

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
I expect it's valid to use (void) if that particular IFUNC resolver 
doesn't use the HWCAP information passed, even if the HWCAP information is 
passed to resolvers on that architecture.  And I wouldn't assume resolvers 
are necessarily consistent about which integer type of a given size is 
used - the AArch64 glibc dynamic linker uses uint64_t, for example, but a 
user could well use (unsigned) long int or (unsigned) long long int rather 
than exactly matching what the dynamic linker uses.  (Using a narrower 
integer type if you only care about low bits of the HWCAP is riskier, 
depending on what the ABI says about high bits of the register passing 
such a narrower integer argument.)

[Bug rtl-optimization/26190] combine misses some distributivity

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Jim Wilson from comment #5)
> I haven't done any further work on this.

The reason I was asking was because this bug shows up in my search of bugs with
an assignee but that aren't marked as ASSIGNED. So, should I change the status
to ASSIGNED here, or leave it as NEW and remove you as the assignee?

[Bug c/87482] Clarify behaviour of resolvers with parameters in for __attribute__((ifunc))

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Besides updating the manual it might be helpful to detect resolver declarations
that are inconsistent with the expected signature and issue a warning.

Joseph, is the resolver signature fixed for each hardware target or can it vary
even for the same target?

[Bug c/81824] Warn for missing attributes with function aliases

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #9 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00047.html

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Actually the patch is better expressed as:


diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..4710b7d2975 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
  goto error;
}

-  if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+  if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+   && CLASS_DATA (me_arg)->ts.u.derived->attr.pdt_type))
{
  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
 " the derived-type %qs", me_arg->name, proc->name,


But one still needs to make sure that the PDT template and the PDT type
actually belong to each other and enforce another condition: "All length type
parameters of the passed object dummy argument must be assumed." (as ifort puts
it)

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
One can get around the error with a patch like this:


diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..6b6e34c0d86 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
  goto error;
}

-  if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+  if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+   && gfc_str_startswith (CLASS_DATA (me_arg)->ts.u.derived->name,
"Pdt")))
{
  gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
 " the derived-type %qs", me_arg->name, proc->name,


It is sufficient to accept the code in comment #4, but otherwise not fully
complete. With this patch, the code in comment #0 is still rejected:


29 |call b%foo()
   | 1
Error: ‘foo’ at (1) is not a member of the ‘pdttypedef’ structure

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||janus at gcc dot gnu.org
Summary|Error derived type-bound|[F03] Error with type-bound
   |procedure PASS(this)|procedure of parametrized
   ||derived type

--- Comment #4 from janus at gcc dot gnu.org ---
Reduced test case for the error:


module testmod
   public :: foo
   type, public :: t(n)
  integer, len :: n = 1
   contains
  procedure :: foo
   end type

contains
   subroutine foo(this)
  class(t(*)), intent(inout) :: this
   end subroutine
end module



   procedure :: foo
   1
Error: Argument ‘this’ of ‘foo’ with PASS(this) at (1) must be of the
derived-type ‘t’

[Bug debug/87484] New: internal compiler error: in dwf_regno, at dwarf2cfi.c:909

[zwilcox at sandia dot gov]

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

Bug ID: 87484
   Summary: internal compiler error: in dwf_regno, at
dwarf2cfi.c:909
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zwilcox at sandia dot gov
  Target Milestone: ---

Created attachment 44774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44774&action=edit
Files that produce errors

Host: Win10
Target: PowerPC
Flags: -O0 -g3 -Wall -mspe=yes -mabi=spe -mfloat-gprs=double -c -mbig-endian
-fno-builtin -fomit-frame-pointer -Wno-unknown-pragmas -mcpu=8548 -MMD -MP -MF

Command line that triggered bug: powerpc-eabi-gcc -O0 -g3 -Wall -mspe=yes
-mabi=spe -mfloat-gprs=double -c -mbig-endian -fno-builtin -fomit-frame-pointer
-Wno-unknown-pragmas -mcpu=8548 -MMD -MP -MF"src/CompilerError.d"
-MT"src/CompilerError.o" -o "src/CompilerError.o" "../src/CompilerError.c"


Compiler output:
 In function 'foo':
../src/CompilerError.c:13:20: warning: unused variable 'lower'
[-Wunused-variable]
  volatile uint64_t lower =  *(ADDR1);
^
../src/CompilerError.c:16:1: internal compiler error: in dwf_regno, at
dwarf2cfi.c:909

Attached is a tar file.
The tar file contains three versions of the code; one that produces the error,
and two that do not, and the preprocessed file

[Bug rtl-optimization/26190] combine misses some distributivity

[wilson at gcc dot gnu.org]

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

--- Comment #5 from Jim Wilson  ---
I haven't done any further work on this.

[Bug c/87483] attribute alias accepted on a symbol definition

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I can fix that.

[Bug fortran/56789] Wrong code with contiguous dummy argument

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Thomas Koenig  ---
Paul, I'm adding you to the CC in the hope that the analysis
in comment#7 might help you towards a solution that is
glaringly obvious to you (but not to me :-)

[Bug target/64525] Duplicate instructions in both paths in conditional code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Maxim Kuvyrkov from comment #2)
> Kugan's work-in-progress patches may fix this one.

Are they still work-in-progress?

[Bug c++/87478] Hidden member function falsely takes part in qualified name lookup

[okannen at gmail dot com]

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

Olivier Kannengieser  changed:

   What|Removed |Added

 CC||okannen at gmail dot com

--- Comment #2 from Olivier Kannengieser  ---
Is this realy a bug or an other instance of core issue 1980:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1980.

I think the behavior of Gcc is the one expected by the standardization
commitee.

[Bug jit/66074] gcc_jit_result_get_code returns a void*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I'm surprised this hasn't caused any issues with -Wcast-function-type yet

[Bug c++/56868] Constexpr example in 7.1.5/5 fails to compile correctly

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Kai Tietz from comment #7)
> This issue gets fixed with delayed-folding. Therefore assign it to me.

Since it's assigned to you, changing status to ASSIGNED, too

[Bug rtl-optimization/26190] combine misses some distributivity

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Jim Wilson from comment #3)
> This ior/shift/xor optimization be done during combine with a simplify-rtx.c
> patch.  I wrote a prototype and tested it.  Combine canonicalizes
> shift/logical as logical/shift, so we actually have to look for
> ior/xor/shift.  I see that the optimization does not happen on arm and
> aarch64 because the 0x4002 value does not fit into the immediate range for
> logical ops, gets loaded into a register, pulled out of the loop, and hence
> is not available to combine.  We would have to perform the optimization
> earlier for it to work for arm/aarch64.  I tried MIPS, and see that because
> MIPS promotes HImode to SImode we don't have enough info to prove that the
> opt is safe.  We need type info to make this work.  This prototype does work
> for the x86 target which has both 16-bit immediates and HImode instructions.
> 
> Next I wrote a prototype for match-and-simplify.  This one works for all 4
> targets.  We have to handle ior/shift/xor as match-and-simplify does not
> canonicalize logical/shift.  I noticed that if I change the xor to an ior,
> then it gets optimized in combine because of the canonicalization for mips
> and x86, but not for arm/aarch64 again because the constant was pulled out
> of the loop.  So it seems that match-and-simplify should canonicalize
> shift/logical to logical/shift too.  That would also reduce the number of
> patterns we need to match when performing this ior/shift/xor optimization.
> 
> These are prototype patches that need a bit more work to handle more cases,
> and to prove that they test all conditions necessary to make them safe. 
> This is my first attempt to use the wi:: functions, so there might be a
> better way to do this.

Have you made further attempts since?

[Bug target/38629] target-specific parameters for inline heuristics not defined for AVR

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Jan Hubicka from comment #6)
> OK, at -Os the issue is that function is called once so inlining is a win.
> Making multiple copies of it leads to GCC making clone:
> delay_wait_us_ms.constprop.0:
> .LFB3:  
> movl$136, %edi
> jmp delay_wait_us
> .LFE3:  
> and then calling it
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> calldelay_wait_us_ms.constprop.0
> at -Os,that is
> 
> With -O2 it is different story, we end up inlining everything. We get:
> Analyzing function body size: delay_wait_us
>   freq:  1000 size:  1 time:  1 __asm__ __volatile__("wdr");
>   freq:  1000 size:  1 time:  1 MEM[(volatile unsigned char *)82B] ={v}
> timeout_2(D);
>   freq:  1000 size:  1 time:  1 D.2719_5 ={v} MEM[(volatile unsigned char
> *)88B];
>   freq:  1000 size:  1 time:  1 D.2720_6 = D.2719_5 | 1;
>   freq:  1000 size:  1 time:  1 MEM[(volatile unsigned char *)88B] ={v}
> D.2720_6;
>   freq: 1 size:  1 time:  1 D.2721_8 ={v} MEM[(volatile unsigned char
> *)88B];
>   freq: 1 size:  0 time:  0 D.2722_9 = (int) D.2721_8;
>   freq: 1 size:  1 time:  1 D.2723_10 = D.2722_9 & 1;
>   freq: 1 size:  2 time:  2 if (D.2723_10 == 0)
>   freq:  1000 size:  1 time:  2 return;
> Likely eliminated
> Overall function body time: 51-2 size: 10-1
> With function call overhead time: 51-13 size: 10-3
> 
> that fits in early-inlining-insns. With --param early-inlining-insns=0 we
> get it right.  GCC inliner is guessing here that inlining such a small leaf
> function will result in enough optimization so it pays back. I am not sure
> what we can do here, early-inlining-insns is being pushed up by C++ code...
> 
> It is not terribly bad tradeoff even at -O2. I will try to get some data how
> much early inlining insns cost us at -O2 and if it is too much, I will
> disable the allowed growth for functions not declared inline.

Are you still working on this?

[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
(In reply to Hans-Peter Nilsson from comment #16)
> (In reply to Jonathan Wakely from comment #14)
> > Can we close this?
> 
> No.  IIUC, we're still/again using __atomic_is_lock_free with alignment
> deduced from the current object rather than the type (even though it's now a
> proxy-object; the faked pointer is constructed from the alignment of the
> current object).
> 
> So, r221701 was wrong to change from null to the alignment-deduced
> fake-pointer.

So, if we can't close, does it make sense to still leave it in WAITING? WAITING
implies a threat to close if what's being waited upon isn't produced.

[Bug libstdc++/63776] [C++11] Regex collate matching not working

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Tim Shen from comment #9)
> Ping.

Who exactly was this ping directed towards?

[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Ian Lance Taylor from comment #3)
> The 64bit-out.go case appears to be similar.  It is also a generated file,
> and it also takes a long time to compile.  The register allocator is not
> quite as dominant, only 43% of compilation time.  In any case I will revisit
> 64bit-out when and if cmplxdivide is fixed.

Has cmplxdivide been fixed yet?

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #2)
> Related test case by the bug reporterm
> https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/
> UvBX1kfuFqs
> 
> 
> This time rejecting the code instead of ICEing:
> 
>print *,x%i
>  1
> Error: Symbol 'x' at (1) has no IMPLICIT type

One can get past this error via:

diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 6f45afa86ea..311e3aafc85 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2111,7 +2111,7 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
bool sub_flag,
  sym->ts = tgt_expr->ts;
}

-  if (sym->ts.type == BT_UNKNOWN)
+  if (sym->ts.type == BT_UNKNOWN && !sym->assoc)
{
  gfc_error ("Symbol %qs at %C has no IMPLICIT type", sym->name);
  return MATCH_ERROR;

but then one runs into:

7 | print *,x%i
  |  1
Error: Syntax error in PRINT statement at (1)



> program p
>   type t
> integer :: i = 0
>   end type
> 
>   associate (x=>f())
> print *,x%i
>   end associate
> 
>   contains
> function f()
>   type(t) f
>   f%i = 5
> end function
> end program


The general problem with this case is that we can not infer the type of 'x'
before parsing the print statement. Right now I can not see how to get around
this issue.

[Bug jit/64196] No automated test coverage for debugging of JIT-generated code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> gcc/jit/docs/intro/tutorial04.rst shows an example of debugging,
> single-stepping through JIT-generated code in gdb [1].
> 
> This was all tested by hand.  We don't yet have any automated test coverage
> to verify that this works.
> 
> [1]: built HTML version of this currently here:
> https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/intro/tutorial04.
> html#single-stepping-through-the-generated-code

Are you still working on this?

[Bug c/87483] New: attribute alias accepted on a symbol definition

[msebor at gcc dot gnu.org]

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

Bug ID: 87483
   Summary: attribute alias accepted on a symbol definition
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC silently accepts attribute alias on the definition of a symbol in
contradiction to the attribute's purpose.

int f (void) { return 0; }

__attribute__ ((alias ("f"))) int g () { return 1; }

int h (void)
{
  return g ();
}

Other compilers that support the attribute (e.g., Clang and ICC) reject the
definition with the attribute with an error:

t.c:3:35: error: redefinition of 'g'

__attribute__ ((alias ("f"))) int g () { return 1; }

[Bug c/85948] printf format attribute warning line carat inaccurate

[jg at jguk dot org]

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

--- Comment #2 from Jonny Grant  ---
Great work Manuel

[Bug fortran/56789] Wrong code with contiguous dummy argument

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Ah, I see where the problem is.

Consider the test case

module zero
  implicit none
contains
  subroutine foo(a)
real, contiguous :: a(:,:)
print *,a
  end subroutine foo
  subroutine bar(a)
real :: a(:,:)
print *,a
  end subroutine bar
end module zero

program main
  use zero
  implicit none
  real, dimension(5,5) :: a
  data a /1.,2.,3.,4.,5.,6.,7.,8.,9.,10.,11.,12.,13.,14.,15.,16.,17., &
   & 18.,19.,20.,21.,22.,23.,24.,25./
  call bar(a(1:5:2,1:5:2))
  call foo(a(1:5:2,1:5:2))
end program main

This gets translated to, for the call to bar,

  {
struct array02_real(kind=4) parm.16;

parm.16.span = 4;
parm.16.dtype = {.elem_len=4, .rank=2, .type=3};
parm.16.dim[0].lbound = 0;
parm.16.dim[0].ubound = 2;
parm.16.dim[0].stride = 2;
parm.16.dim[1].lbound = 0;
parm.16.dim[1].ubound = 2;
parm.16.dim[1].stride = 10;
parm.16.data = (void *) &a[0];
parm.16.offset = 0;
bar (&parm.16);
  }

and for the call to foo

  {
struct array02_real(kind=4) parm.17;
void * origptr.18;
void * D.3863;

parm.17.span = 4;
parm.17.dtype = {.elem_len=4, .rank=2, .type=3};
parm.17.dim[0].lbound = 0;
parm.17.dim[0].ubound = 2;
parm.17.dim[0].stride = 2;
parm.17.dim[1].lbound = 0;
parm.17.dim[1].ubound = 2;
parm.17.dim[1].stride = 10;
parm.17.data = (void *) &a[0];
parm.17.offset = 0;
origptr.18 = parm.17.data;
D.3863 = _gfortran_internal_pack (&parm.17);
parm.17.data = D.3863;
foo (&parm.17);
parm.17.data = origptr.18;
if ((real(kind=4)[0:] *) parm.17.data != (real(kind=4)[0:] *) D.3863)
  {
_gfortran_internal_unpack (&parm.17, D.3863);
__builtin_free (D.3863);
  }
  }

The problem is that the data gets packed, but we pass the constructor to the
original, unpacked data to bar.

We should build a new one.

[Bug c/87482] Clarify behaviour of resolvers with parameters in for __attribute__((ifunc))

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Yes, on some platforms the resolver takes the HWCAP as an argument and so 
should be declared as a function taking that argument (if it uses it, 
anyway).

[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Carl Love  ---
Closing

[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

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

--- Comment #4 from Carl Love  ---
Patch committed.  Closing the bugzilla

[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #3 from Carl Love  ---
Note, the actual commit was  r264762.  Commit  r264764 added the PR number to
the commit logs.

[Bug target/69431] There should be builtins for PowerPC mtfsb0, mtfsb1

[carll at gcc dot gnu.org]

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

--- Comment #2 from Carl Love  ---
Author: carll
Date: Mon Oct  1 15:57:13 2018
New Revision: 264764

URL: https://gcc.gnu.org/viewcvs?rev=264764&root=gcc&view=rev
Log:
Update, forgot to put the PR number in the Change Log.  

gcc/ChangeLog:

2018-10-01  Carl Love  

PR 69431
* config/rs6000/rs6000-builtin.def (__builtin_mffsl): New.
(__builtin_mtfsb0): New.
(__builtin_mtfsb1): New.
( __builtin_set_fpscr_rn): New.
(__builtin_set_fpscr_drn): New.
* config/rs6000/rs6000.c (rs6000_expand_mtfsb_builtin): Add.
(rs6000_expand_set_fpscr_rn_builtin): Add.
(rs6000_expand_set_fpscr_drn_builtin): Add.
(rs6000_expand_builtin): Add case statement entries for
RS6000_BUILTIN_MTFSB0, RS6000_BUILTIN_MTFSB1,
RS6000_BUILTIN_SET_FPSCR_RN, RS6000_BUILTIN_SET_FPSCR_DRN,
RS6000_BUILTIN_MFFSL.
(rs6000_init_builtins): Add ftype initialization and def_builtin
calls for __builtin_mffsl, __builtin_mtfsb0, __builtin_mtfsb1,
__builtin_set_fpscr_rn, __builtin_set_fpscr_drn.
* config/rs6000.md (rs6000_mtfsb0, rs6000_mtfsb1, rs6000_mffscrn,
rs6000_mffscdrn): Add define_insn.
(rs6000_set_fpscr_rn, rs6000_set_fpscr_drn): Add define_expand.
* doc/extend.texi: Add documentation for the builtins.

gcc/testsuite/ChangeLog:

2018-10-01  Carl Love  

PR 69431
* gcc.target/powerpc/test_mffsl-p9.c: New file.
* gcc.target/powerpc/test_fpscr_rn_builtin.c: New file.
* gcc.target/powerpc/test_fpscr_drn_builtin.c: New file.
* gcc.target/powerpc/test_fpscr_rn_builtin_error.c: New file.
* gcc.target/powerpc/test_fpscr_drn_builtin_error.c: New file.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

Cloud Computing Users Contact List

[jessica . martin]

style="color:rgb(31,78,121)">Hi, 


style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Hope this note finds you  
well. 


style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Are you in the market to target AWS/Azure  
users for your lead generation and marketing purposes?style="color:rgb(31,78,121)"> Email list for your email campaigns

we provide the Database across North
America, EMEA, APAC and Latin America.style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Every contact from this database has completed  
verification

on the 03rd of Aug 2018 to give you 98% accuracy and ensure your message
reaches the right contact from the right company. 

style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">We also have other technology  
users:


style="color:rgb(31,78,121)"> 


style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">

Salesforce
Users

style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">
Rackspace  
Users


style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">
Go Grid  
Users


style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">
Citrix  
Users


style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">

Soft layer
Users

style="font-family:Symbol;color:rgb(31,78,121)">·style="font:7pt "Times New Roman"">

VMware Users
and more.

style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Please review and let me know if you are  
looking for any of
the above or let me know your requirement and I will get back to you with  
more

information for the same. 

style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Await for your  
response! 


style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">Regards, 

Jessica Martin
Demand Generation-Database Coordinator   

style="color:rgb(31,78,121)"> 


style="color:rgb(31,78,121)">If you wish not to include or mailing kindly  
reply “Opt

Out” in the Subject Line






 href='chrome.google.com/webstore/detail/gsm-mailmerge/fjimadonilpeknihlnnkbgmlmjneodgk'>powered  
by GSM. Free mail merge and email marketing software for Gmail.

[Bug c/87482] New: Clarify behaviour of resolvers with parameters in for __attribute__((ifunc))

[peter.smith at linaro dot org]

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

Bug ID: 87482
   Summary: Clarify behaviour of resolvers with parameters in  for
__attribute__((ifunc))
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.smith at linaro dot org
  Target Milestone: ---

In the documentation for
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
it says: "The resolver should be declared to be a function taking no arguments
and returning a pointer to a function of the same type as the implementation."

I would like to check if the documentation is correct here as the
implementation accepts a parameter and on some architectures, such as Arm and
AArch64, the hwcaps is passed in to the resolver as a parameter by the dynamic
loader? To me it looks like the documentation isn't quite right, but I could be
missing something important.

For example a quick modification of the example on the page:

#include 
void *my_memcpy (void *dst, const void *src, size_t len)
{
  return dst;
}

void *my_memcpy2 (void *dst, const void *src, size_t len)
{
  return dst;
}

static void * (*resolve_memcpy (int hwcap))(void *, const void *, size_t)
{
if (hwcap == 1)
return my_memcpy;
else
return my_memcpy2;
}

void *memcpy(void *, const void*, size_t) __attribute__((ifunc
("resolve_memcpy")));

Compiles without a problem.

From what I can see glibc doesn't use __attribute__((ifunc("resolver")))
instead it uses __asm__ (".type " resolver, %gnu_indirect_function). 

For context clang will give an error message if the ifunc resolver has a
parameter.
ifunc2.c:20:58: error: ifunc resolver function must have no parameters
void *memcpy(void *, const void*, size_t) __attribute__((ifunc ("resolve...

There is a thread on cfe-dev asking if the GCC documentation is correct and to
see if clang should be following the documentation or the implementation:
http://lists.llvm.org/pipermail/cfe-dev/2018-September/059548.html  


There was a recent change for 8.0 that made "The resolver should be declared to
be a function taking no arguments" more explicit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81882

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Reproduces on trunk for powerpc64le-linux-gnu also.

[Bug fortran/65677] Incomplete assignment on deferred-length character variable

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Mon Oct  1 14:27:17 2018
New Revision: 264759

URL: https://gcc.gnu.org/viewcvs?rev=264759&root=gcc&view=rev
Log:
2018-10-01  Paul Thomas  

PR fortran/65677
* trans-expr.c (gfc_trans_assignment_1): Set the 'identical'
flag in the call to gfc_check_dependency.


2018-10-01  Paul Thomas  

PR fortran/65677
* gfortran.dg/dependency_52.f90 : Expand the test to check both
the call to adjustl and direct assignment of the substring.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dependency_52.f90

[Bug c++/87481] [7/8/9 Regression] Endless loop with optimisation in C++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||memory-hog
 CC||jason at gcc dot gnu.org
  Known to work||6.4.0
Summary|Endless loop with   |[7/8/9 Regression] Endless
   |optimisation in C++17   |loop with optimisation in
   ||C++17
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #2 from Jonathan Wakely  ---
Further reduced:

void f()
{
  []{
while (true) {
  for (unsigned cc = 0; cc < 1; ++cc) ;
  millliseconds m;
}
  };
}

Regression started with r239268:

Implement C++17 constexpr lambda.

gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Update __cpp_constexpr for
C++17 constexpr lambdas.
gcc/cp/
* class.c (finalize_literal_type_property): Handle lambdas.
* constexpr.c (is_valid_constexpr_fn): Likewise.  No longer static.
(explain_invalid_constexpr_fn, cxx_eval_call_expression): Handle
lambdas.
(cxx_eval_constant_expression): Handle capture proxy.
(var_in_constexpr_fn): Don't check for C++14.
(var_in_maybe_constexpr_fn): New.
(potential_constant_expression_1): Use it.  Check DECL_EXPR for
declarations not allowed in constexpr function.
* decl.c (make_rtl_for_nonlocal_decl): Use
var_in_maybe_constexpr_fn.
(finish_function): Set DECL_DECLARED_CONSTEXPR_P on lambda members.
* lambda.c (begin_lambda_type): Set CLASSTYPE_LITERAL_P.
(maybe_add_lambda_conv_op): Clear thunk CALL_EXPR location.
(lambda_static_thunk_p): New.
* parser.c (cp_keyword_starts_decl_specifier_p): Add RID_CONSTEXPR.
(CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): New enumerator.
(cp_parser_decl_specifier_seq): Handle it.
(cp_parser_lambda_declarator_opt): Use
cp_parser_decl_specifier_seq.
* pt.c (instantiate_class_template_1): Set CLASSTYPE_LITERAL_P.
(tsubst_copy_and_build) [CALL_EXPR]: Propagate CALL_FROM_THUNK_P.
* error.c (dump_function_decl): Check TFF_NO_TEMPLATE_BINDINGS.
(dump_expr) [FUNCTION_DECL]: Pass it.

I'm going to call this ice-on-invalid even though it doesn't actually ICE, it
just loops until killed.

[Bug c++/87481] Endless loop with optimisation in C++17

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Reduced:

struct thread {
  template thread(F) { }
};

template
void sleep_for(D) { }

template struct duration { };
using milliseconds = duration;

void f()
{
  thread sleeper([]{
while (true) {
  for (unsigned cc = 0; cc < 1; ++cc) ;
  sleep_for(millliseconds(50));
}
  });
}

[Bug c++/87480] [8/9 Regression] SFINAE constructor not matched, only in templated function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

--- Comment #2 from Jonathan Wakely  ---
Slightly further reduced (it happens for any function template, not just
constructors):

template T&& declval();

template ().d)> void f(T) { }

struct A {
  double d;
};

#ifndef FIX
template 
#endif
void j(A& a) {
  f(a);
}

[Bug c++/87481] New: Endless loop with optimisation in C++17

[bug-reporter at tuta dot io]

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

Bug ID: 87481
   Summary: Endless loop with optimisation in C++17
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bug-reporter at tuta dot io
  Target Milestone: ---

Created attachment 44773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44773&action=edit
minimal example

Compile the attached code with 'std=c++17 -O1'.

This will generate the message "minimal.cc:9:45: error: ‘millliseconds’ is not
a member of ‘std::chrono’" and then leave the compiler an endless,
memory-eating loop. I can reproduce the bug with any version of g++ that
supports C++17 and any optimisation level greater than zero.

[Bug c++/87480] [8/9 Regression] SFINAE constructor not matched, only in templated function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||rejects-valid
   Last reconfirmed||2018-10-01
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|SFINAE constructor not  |[8/9 Regression] SFINAE
   |matched, only in templated  |constructor not matched,
   |function|only in templated function
  Known to fail||8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Started to be rejected with r258039

PR c++/84489 - dependent default template argument

* pt.c (type_unification_real): Handle early substitution failure.

[Bug c++/87480] New: SFINAE constructor not matched, only in templated function

[fiesh at zefix dot tv]

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

Bug ID: 87480
   Summary: SFINAE constructor not matched, only in templated
function
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fiesh at zefix dot tv
  Target Milestone: ---

The following code compiles with gcc <= 7.3 and clang.  It also compiles with
gcc >= 8 when FIX is defined.  It does not compile with gcc >=8 without FIX
though.

struct e {
  template d)> e(f);
};

struct A {
  double d;
};

#ifndef FIX
template 
#endif
void j() {
  A k{};
  (void) static_cast(k);
}

[Bug c++/87366] [6/7/8/9 Regression] SFINAE trait as template parameter causes incorrect application of trait to other areas

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 CC||jason at gcc dot gnu.org
  Known to work||4.9.4
Summary|SFINAE trait as template|[6/7/8/9 Regression] SFINAE
   |parameter causes incorrect  |trait as template parameter
   |application of trait to |causes incorrect
   |other areas |application of trait to
   ||other areas
 Ever confirmed|0   |1
  Known to fail||5.5.0, 6.4.0, 7.3.0, 8.2.0,
   ||9.0

--- Comment #1 from Jonathan Wakely  ---
Reduced:

struct A {};
struct B {};

template  struct wrapper {};

template  struct enable_if_A { };
template<> struct enable_if_A { using type = void; };

template ::type> using ok_t = T;

template  void not_even_called(wrapper&> a);

template  int called(wrapper a);

void test(wrapper& val)
{
called(val);
}


87366.cc: In function 'void test(wrapper&)':
87366.cc:17:15: error: no matching function for call to 'called(wrapper&)'
17 | called(val);
   |   ^
87366.cc:13:27: note: candidate: 'template int
called(wrapper&>)'
13 | template  int called(wrapper a);
   |   ^~
87366.cc:13:27: note:   template argument deduction/substitution failed:
87366.cc: In substitution of 'template int called(wrapper&>)
[with T = B]':
87366.cc:17:15:   required from here
87366.cc:13:27: error: no type named 'type' in 'struct enable_if_A'


This was accepted prior to gcc-5, it started to be rejected with r217250:

DR 1558
* pt.c (dependent_alias_template_spec_p): New.
(dependent_type_p_r): Handle dependent alias template
specialization.
(template_args_equal): A dependent alias template specializations
is not equal to its underlying type as a template argument.
* tree.c (strip_typedefs): Don't strip a dependent alias
template-id.

[Bug rtl-optimization/87479] [9 Regression] FAIL: gcc.target/i386/pr63527.c

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #2 from Peter Bergner  ---
Mine.

[Bug target/87474] ICE in extract_insn, at recog.c:2305

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc |powerpc*-*-*
   Target Milestone|--- |9.0

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #2 from Bill Schmidt  ---
Mine, will investigate this week.

[Bug target/87474] ICE in extract_insn, at recog.c:2305

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
This looks like I screwed up the conditions, clearly it shouldn't be trying to
generate the vector/vsx strncmp expansion with -mno-power8-vector.

[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax

[matthijsvanduin at gmail dot com]

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

--- Comment #7 from Matthijs van Duin  ---
Ah! I should have checked the actual tests of 51253 before calling it a
regression, apologies. I just kinda assumed that these simple cases would be
covered by the work done back then.

[Bug c++/87478] Hidden member function falsely takes part in qualified name lookup

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Confirmed, not a regression. Reduced:

template struct is_int { };
template<> struct is_int { using type = void; };

class MyTag {};

template struct is_tag { };
template<> struct is_tag { using type = void; };

struct Base
{
template 
typename is_int::type create(RType)
{
}
};

struct Derived : Base
{
using Base::create;

template 
typename is_tag::type create(Tag)
{
}
};

int main()
{
Derived d;

d.create(MyTag());
d.create(0);
}

[Bug c++/87478] Hidden member function falsely takes part in qualified name lookup

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 Ever confirmed|0   |1

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #8 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 12:49:35 2018
New Revision: 264747

URL: https://gcc.gnu.org/viewcvs?rev=264747&root=gcc&view=rev
Log:
Updated stack-clash implementation supporting 64k probes.

This patch implements the use of the stack clash mitigation for aarch64.
In Aarch64 we expect both the probing interval and the guard size to be 64KB
and we enforce them to always be equal.

We also probe up by 1024 bytes in the general case when a probe is required.

AArch64 has the following probing conditions:

 1a) Any initial adjustment less than 63KB requires no probing.  An ABI defined
 safe buffer of 1Kbytes is used and a page size of 64k is assumed.

  b) Any final adjustment residual requires a probe at SP + 1KB.
 We know this to be safe since you would have done at least one page worth
 of allocations already to get to that point.

  c) Any final adjustment more than remainder (total allocation amount) larger
 than 1K - LR offset requires a probe at SP.


  safe buffer mentioned in 1a is maintained by the storing of FP/LR.
  In the case of -fomit-frame-pointer we can still count on LR being stored
  if the function makes a call, even if it's a tail call.  The AArch64 frame
  layout code guarantees this and tests have been added to check against
  this particular case.

 2) Any allocations larger than 1 page size, is done in increments of page size
and probed up by 1KB leaving the residuals.

 3a) Any residual for initial adjustment that is less than guard-size - 1KB
 requires no probing.  Essentially this is a sliding window.  The probing
 range determines the ABI safe buffer, and the amount to be probed up.

Incrementally allocating less than the probing thresholds, e.g. recursive
functions will
not be an issue as the storing of LR counts as a probe.


+---+   
|  ABI SAFE REGION  |   
  +--   
  | |   |   
  | |   |   
  | |   |   
  | |   |   
  | |   |   
  | |   |   
 maximum amount   | |   |   
 not needing a| |   |   
 probe| |   |   
  | |   |   
  | |   |   
  | |   |   
  | |   |Probe offset when  
  |  probe is required  
  | |   |   
  + +---+   Point of first
probe 
|  ABI SAFE REGION  |   
-   
|   |   
|   |   
|   |   

Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Target was tested with stack clash on and off by default.

GLIBC testsuite also ran with stack clash on by default and no new
regressions.

gcc/
PR target/86486
* config/aarch64/aarch64.md
(probe_stack_range): Add k (SP) constraint.
* config/aarch64/aarch64.h (STACK_CLASH_CALLER_GUARD,
STACK_CLASH_MAX_UNROLL_PAGES): New.
* config/aarch64/aarch64.c (aarch64_output_probe_stack_range): Emit
stack probes for stack clash.
(aarch64_allocate_and_probe_stack_space): New.
(aarch64_expand_prologue): Use it.
(aarch64_expand_epilogue): Likewise and update IP regs re-use criteria.
(aarch64_sub_sp): Add emit_move_imm optional param.

gcc/testsuite/

PR target/86486
* gcc.target/aarch64/stack-check-12.c: New.
* gcc.target/aarch64/stack-check-13.c: New.
* gcc.target/aarch64/stack-check-cfa-1.c: New.
* gcc.target/aarch64/stack-check-cfa-2.c: New.
* gcc.target/aarch64/stack-check-prologue-1.c: New.
* gcc.target/aarch64/stack-check-prolog

[Bug rtl-optimization/87479] [9 Regression] FAIL: gcc.target/i386/pr63527.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

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

[Bug c++/87469] [9 Regression] ice in record_estimate, at tree-ssa-loop-niter.c:3271

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||kugan at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started with r261682

PR middle-end/82479
* ipa-fnsummary.c (will_be_nonconstant_expr_predicate): Handle
CALL_EXPR.
* tree-scalar-evolution.c (interpret_expr): Likewise.
(expression_expensive_p): Likewise.
* tree-ssa-loop-ivopts.c (contains_abnormal_ssa_name_p): Likewise.
* tree-ssa-loop-niter.c (number_of_iterations_popcount): New.
(number_of_iterations_exit_assumptions): Use
number_of_iterations_popcount.
(ssa_defined_by_minus_one_stmt_p): New.

[Bug c++/84191] [7/8/9 Regression] Compiler ICEs when trying to resolve impossible arithmetic operations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 CC||jason at gcc dot gnu.org
Summary|Compiler ICEs when trying   |[7/8/9 Regression] Compiler
   |to resolve impossible   |ICEs when trying to resolve
   |arithmetic operations   |impossible arithmetic
   ||operations
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
At r254713 this started to ICE with:

/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp: In lambda
function:
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp:249:52: error:
Local declaration from a different function
D.311875
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp:250:40: note: in
statement
_1 = &D.311875;
during GIMPLE pass: cfg
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp:249:52: internal
compiler error: verify_gimple failed
0x11f8dde verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5392
0x1075f49 execute_function_todo
../../gcc/passes.c:1994
0x1074ef0 do_per_function
../../gcc/passes.c:1659
0x1076139 execute_todo
../../gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

That commit was:

Capture adjustments for P0588R1.

* semantics.c (process_outer_var_ref): Capture variables when
they are named; complain about non-capture uses when odr-used.
* expr.c (mark_use): Rvalue use looks through capture proxy.
* constexpr.c (potential_constant_expression_1): Improve error
about
use of captured variable.
* lambda.c (need_generic_capture, dependent_capture_r)
(do_dependent_capture, processing_nonlambda_template): Remove.
* call.c (build_this): Remove uses of the above.
* decl.c (cp_finish_decl): Likewise.
* semantics.c (maybe_cleanup_point_expr)
(maybe_cleanup_point_expr_void, finish_goto_stmt)
(maybe_convert_cond): Likewise.
* typeck.c (check_return_expr): Likewise.

I haven't tried to reduce it.

With later trunk revisions it fails differently, so I haven't checked if it the
regression also affects the gcc-8-branch and current trunk.

In file included from /usr/lib/gcc/x86_64-linux-gnu/7/include/immintrin.h:45,
 from /usr/local/include/glm/simd/platform.h:358,
 from /usr/local/include/glm/detail/setup.hpp:36,
 from /usr/local/include/glm/vec2.hpp:4,
 from
/mnt/c/Users/cjdbn/projects/doge/doge/include/doge/hid.hpp:23,
 from
/mnt/c/Users/cjdbn/projects/doge/doge/include/doge/engine.hpp:19,
 from
/mnt/c/Users/cjdbn/projects/doge/doge/test/doge/gl/uniform.cpp:17:
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h: In function ‘__m128d
_mm_scalef_sd(__m128d, __m128d)’:
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:11265:20: error:
‘__builtin_ia32_scalefsd_round’ was not declared in this scope
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:11265:20: note:
suggested alternative: ‘__builtin_ia32_rndscalesd_round’
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h: In function ‘__m128
_mm_scalef_ss(__m128, __m128)’:
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:11274:19: error:
‘__builtin_ia32_scalefss_round’ was not declared in this scope
/usr/lib/gcc/x86_64-linux-gnu/7/include/avx512fintrin.h:11274:19: note:
suggested alternative: ‘__builtin_ia32_rndscaless_round’

[Bug tree-optimization/87465] [8 Regression] Loop removal regression

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct  1 13:10:48 2018
New Revision: 264758

URL: https://gcc.gnu.org/viewcvs?rev=264758&root=gcc&view=rev
Log:
2018-10-01  Richard Biener  

PR tree-optimization/87465
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Fix typo
causing branch miscounts.

* gcc.dg/tree-ssa/cunroll-15.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/cunroll-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ivcanon.c

[Bug tree-optimization/87465] [8 Regression] Loop removal regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[8/9 Regression] Loop   |[8 Regression] Loop removal
   |removal regression  |regression
  Known to fail||8.2.0

--- Comment #3 from Richard Biener  ---
Fixed on trunk.

[Bug c++/83372] ICE in GC within gt_ggc_mx building Mir

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
So is this fixed?

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 13:05:30 2018
New Revision: 264754

URL: https://gcc.gnu.org/viewcvs?rev=264754&root=gcc&view=rev
Log:
Cleanup the AArch64 testsuite when stack-clash is on.

This patch cleans up the testsuite when a run is done with stack clash
protection turned on.

Concretely this switches off -fstack-clash-protection for a couple of tests:

* assembler scan: some tests are quite fragile in that they check for exact
   assembly output, e.g. check for exact amount of sub etc.  These won't
   match now.
* vla: Some of the ubsan tests negative array indices. Because the arrays
weren't
   used before the incorrect $sp wouldn't have been used. The correct value
is
   restored on ret.  Now however we probe the $sp which causes a segfault.
* params: When testing the parameters we have to skip these on AArch64 because
of our
  custom constraints on them.  We already test them separately so this
isn't a
  loss.

Note that the testsuite is not entire clean due to gdb failure caused by alloca
with
stack clash. On AArch64 we output an incorrect .loc directive, but this is
already the
case with the current implementation in GCC and is a bug unrelated to this
patch series.

gcc/testsuite/

PR target/86486
* gcc.dg/pr82788.c: Skip for AArch64.
* gcc.dg/guality/vla-1.c: Turn off stack-clash.
* gcc.target/aarch64/subsp.c: Likewise.
* gcc.dg/params/blocksort-part.c: Skip stack-clash checks
on AArch64.
* gcc.dg/stack-check-10.c: Add AArch64 specific checks.
* gcc.dg/stack-check-12.c: ILP32 fixup.
* gcc.dg/stack-check-5.c: Add AArch64 specific checks.
* gcc.dg/stack-check-6a.c: Skip on AArch64, we don't support this.
* testsuite/lib/target-supports.exp
(check_effective_target_frame_pointer_for_non_leaf): AArch64 does not
require frame pointer for non-leaf functions.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/ubsan/vla-1.c
trunk/gcc/testsuite/gcc.dg/params/blocksort-part.c
trunk/gcc/testsuite/gcc.dg/pr82788.c
trunk/gcc/testsuite/gcc.dg/stack-check-10.c
trunk/gcc/testsuite/gcc.dg/stack-check-5.c
trunk/gcc/testsuite/gcc.dg/stack-check-6a.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-12.c
trunk/gcc/testsuite/gcc.target/aarch64/subsp.c
trunk/gcc/testsuite/lib/target-supports.exp

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #6 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 13:03:31 2018
New Revision: 264753

URL: https://gcc.gnu.org/viewcvs?rev=264753&root=gcc&view=rev
Log:
Set default values for stack-clash and do basic validation in back-end.


This patch enforces that the default guard size for stack-clash protection for
AArch64 be 64KB unless the user has overriden it via configure in which case
the user value is used as long as that value is within the valid range.

It also does some basic validation to ensure that the guard size is only 4KB or
64KB and also enforces that for aarch64 the stack-clash probing interval is
equal to the guard size.

gcc/

PR target/86486
* config/aarch64/aarch64.c (aarch64_override_options_internal):
Add validation for stack-clash parameters and set defaults.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #5 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 13:02:21 2018
New Revision: 264752

URL: https://gcc.gnu.org/viewcvs?rev=264752&root=gcc&view=rev
Log:
Allow setting of stack-clash via configure options.

This patch defines a configure option to allow the setting of the default
guard size via configure flags when building the target.

The new flag is:

 * --with-stack-clash-protection-guard-size=

The patch defines a new macro DEFAULT_STK_CLASH_GUARD_SIZE which targets need
to use explicitly is they want to support this configure flag and values that
users may have set.

gcc/

PR target/86486
* configure.ac: Add stack-clash-protection-guard-size.
* doc/install.texi: Document it.
* config.in (DEFAULT_STK_CLASH_GUARD_SIZE): New.
* params.def: Update comment for guard-size.
(PARAM_STACK_CLASH_PROTECTION_GUARD_SIZE,
PARAM_STACK_CLASH_PROTECTION_PROBE_INTERVAL): Update description.
* configure: Regenerate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/doc/install.texi
trunk/gcc/params.def

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #4 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 13:00:58 2018
New Revision: 264751

URL: https://gcc.gnu.org/viewcvs?rev=264751&root=gcc&view=rev
Log:
Ensure that outgoing argument size is at least 8 bytes when alloca and
stack-clash.

This patch adds a requirement that the number of outgoing arguments for a
function is at least 8 bytes when using stack-clash protection and alloca.

By using this condition we can avoid a check in the alloca code and so have
smaller and simpler code there.

A simplified version of the AArch64 stack frames is:

   +---+  
   |   | 
   |   |  
   |   |  
   +---+  
   |LR |  
   +---+  
   |FP |  
   +---+  
   |dynamic allocations|   expanding area which will push the outgoing
   +---+   args down during each allocation.
   |padding|
   +---+
   |outgoing stack args|  safety buffer of 8 bytes (aligned)
   +---+

By always defining an outgoing argument, alloca(0) effectively is safe to probe
at $sp due to the reserved buffer being there.  It will never corrupt the
stack.

This is also safe for alloca(x) where x is 0 or x % page_size == 0.  In the
former it is the same case as alloca(0) while the latter is safe because any
allocation pushes the outgoing stack args down:

   |FP |  
   +---+  
   |   |
   |dynamic allocations|   alloca (x)
   |   |
   +---+
   |padding|
   +---+
   |outgoing stack args|  safety buffer of 8 bytes (aligned)
   +---+

Which means when you probe for the residual, if it's 0 you'll again just probe
in the outgoing stack args range, which we know is non-zero (at least 8 bytes).

gcc/

PR target/86486
* config/aarch64/aarch64.h (STACK_CLASH_MIN_BYTES_OUTGOING_ARGS,
STACK_DYNAMIC_OFFSET): New.
* config/aarch64/aarch64.c (aarch64_layout_frame):
Update outgoing args size.
(aarch64_stack_clash_protection_alloca_probe_range,
TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE): New.

gcc/testsuite/

PR target/86486
* gcc.target/aarch64/stack-check-alloca-1.c: New.
* gcc.target/aarch64/stack-check-alloca-10.c: New.
* gcc.target/aarch64/stack-check-alloca-2.c: New.
* gcc.target/aarch64/stack-check-alloca-3.c: New.
* gcc.target/aarch64/stack-check-alloca-4.c: New.
* gcc.target/aarch64/stack-check-alloca-5.c: New.
* gcc.target/aarch64/stack-check-alloca-6.c: New.
* gcc.target/aarch64/stack-check-alloca-7.c: New.
* gcc.target/aarch64/stack-check-alloca-8.c: New.
* gcc.target/aarch64/stack-check-alloca-9.c: New.
* gcc.target/aarch64/stack-check-alloca.h: New.
* gcc.target/aarch64/stack-check-14.c: New.
* gcc.target/aarch64/stack-check-15.c: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-14.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-15.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-1.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-10.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-2.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-3.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-4.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-5.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-6.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-7.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-8.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca-9.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-alloca.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/testsuite/ChangeLog

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #3 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 12:58:21 2018
New Revision: 264750

URL: https://gcc.gnu.org/viewcvs?rev=264750&root=gcc&view=rev
Log:
Add a hook to support telling the mid-end when to probe the stack.

This patch adds a hook to tell the mid-end about the probing requirements of
the
target.  On AArch64 we allow a specific range for which no probing needs to
be done.  This same range is also the amount that will have to be probed up
when
a probe is needed after dropping the stack.

Defining this probe comes with the extra requirement that the outgoing
arguments
size of any function that uses alloca and stack clash be at the very least 8
bytes.  With this invariant we can skip doing the zero checks for alloca and
save some code.

A simplified version of the AArch64 stack frame is:

   +---+  
   |   | 
   |   |  
   |   |  
   +---+  
   |LR |  
   +---+  
   |FP |  
   +---+  
   |dynamic allocations| -\  probe range hook effects these   
   +---+   --\   and ensures that outgoing stack  
   |padding|  -- args is always > 8 when alloca.  
   +---+  ---/   Which means it's always safe to probe
   |outgoing stack args|-/   at SP
   +---+  


This allows us to generate better code than without the hook without affecting
other targets.

With this patch I am also removing the
stack_clash_protection_final_dynamic_probe
hook which was added specifically for AArch64 but that is no longer needed.

gcc/

PR target/86486
* explow.c (anti_adjust_stack_and_probe_stack_clash): Support custom
probe ranges.
* target.def (stack_clash_protection_alloca_probe_range): New.
(stack_clash_protection_final_dynamic_probe): Remove.
* targhooks.h (default_stack_clash_protection_alloca_probe_range) New.
(default_stack_clash_protection_final_dynamic_probe): Remove.
* targhooks.c: Likewise.
* doc/tm.texi.in (TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE):
New.
(TARGET_STACK_CLASH_PROTECTION_FINAL_DYNAMIC_PROBE): Remove.
* doc/tm.texi: Regenerate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/explow.c
trunk/gcc/target.def
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h

[Bug c++/87476] [9 Regression] char-array initialized from wide-string

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||law at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started to fail with r264042

* c-common.c (braced_list_to_string): Remove eval parameter.
Add some more checks.  Always create zero-terminated STRING_CST.
* c-common.h (braced_list_to_string): Adjust prototype.

* c-decl.c (finish_decl): Call braced_list_to_string here ...
* c-parser.c (c_parser_declaration_or_fndef): ... instead of here.

* decl.c (eval_check_narrowing): Remove.
(check_initializer): Move call to braced_list_to_string from here
...
* typeck2.c (store_init_value): ... to here.
(digest_init_r): Remove handing of signed/unsigned char strings.

* c-c++-common/array-init.c: New test.
* g++.dg/init/string2.C: Remove xfail.

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #2 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 12:56:40 2018
New Revision: 264749

URL: https://gcc.gnu.org/viewcvs?rev=264749&root=gcc&view=rev
Log:
Add support for SVE stack clash probing.

This patch adds basic support for SVE stack clash protection.
It is a first implementation and will use a loop to do the
probing and stack adjustments.

An example sequence is:

.cfi_startproc
mov x15, sp
cntbx16, all, mul #11
add x16, x16, 304
.cfi_def_cfa_register 15
.SVLPSPL0:
cmp x16, 61440
b.lt.SVLPEND0
sub sp, sp, 61440
str xzr, [sp, 0]
sub x16, x16, 61440
b  .SVLPSPL0
.SVLPEND0:
sub sp, sp, x16
.cfi_escape 0xf,0xc,0x8f,0,0x92,0x2e,0,0x8,0x58,0x1e,0x23,0xb0,0x2,0x22

for a 64KB guard size, and for a 4KB guard size

.cfi_startproc
mov x15, sp
cntbx16, all, mul #11
add x16, x16, 304
.cfi_def_cfa_register 15
.SVLPSPL0:
cmp x16, 3072
b.lt.SVLPEND0
sub sp, sp, 3072
str xzr, [sp, 0]
sub x16, x16, 3072
b   .SVLPSPL0
.SVLPEND0:
sub sp, sp, x16
.cfi_escape 0xf,0xc,0x8f,0,0x92,0x2e,0,0x8,0x58,0x1e,0x23,0xb0,0x2,0x22

This has about the same semantics as alloca, except we prioritize the common
case
where no probe is required.  We also change the amount we adjust the stack and
the probing interval to be the nearest value to `guard size - abi buffer` that
fits in the 12-bit shifted immediate used by cmp.

While this would mean we probe a bit more often than we require, in practice
the
amount of SVE vectors you'd need to spill is significant. Even more so to enter
the
loop more than once.


gcc/

PR target/86486
* config/aarch64/aarch64-protos.h
(aarch64_output_probe_sve_stack_clash): New.
* config/aarch64/aarch64.c (aarch64_output_probe_sve_stack_clash,
aarch64_clamp_to_uimm12_shift): New.
(aarch64_allocate_and_probe_stack_space): Add SVE specific section.
* config/aarch64/aarch64.md (probe_sve_stack_clash): New.

gcc/testsuite/

PR target/86486
* gcc.target/aarch64/stack-check-prologue-16.c: New test
* gcc.target/aarch64/stack-check-cfa-3.c: New test.
* gcc.target/aarch64/sve/struct_vect_24.c: New test.
* gcc.target/aarch64/sve/struct_vect_24_run.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-cfa-3.c
trunk/gcc/testsuite/gcc.target/aarch64/stack-check-prologue-16.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_24.c
trunk/gcc/testsuite/gcc.target/aarch64/sve/struct_vect_24_run.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug target/86486] GCC 8 stack clash protection on AArch64 is incomplete

[tnfchris at gcc dot gnu.org]

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

--- Comment #1 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct  1 12:53:34 2018
New Revision: 264748

URL: https://gcc.gnu.org/viewcvs?rev=264748&root=gcc&view=rev
Log:
stack-clash: Add LR assert to layout_frame.

Since stack clash depends on the LR being saved for non-leaf functions this
patch adds an assert such that if this changes we would notice this.

gcc/
PR target/86486
* config/aarch64/aarch64.c (aarch64_layout_frame): Add assert.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-08-24 00:00:00 |2018-10-1

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> The fix for bug 51253 only changed the code generation, it didn't stop the
> warnings being printed.

And it didn't affect the result for any of the testcases in this bug.

So it seems the fix for 51253 was simply incomplete, but there's no regression.

[Bug rtl-optimization/87479] New: [9 Regression] FAIL: gcc.target/i386/pr63527.c

[hjl.tools at gmail dot com]

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

Bug ID: 87479
   Summary: [9 Regression] FAIL: gcc.target/i386/pr63527.c
   Product: gcc
   Version: 9.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: bergner at vnet dot ibm.com
  Target Milestone: ---

On i686, r264726 caused:

FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx
FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx
FAIL: gcc.target/i386/pr64317.c scan-assembler addl[
\\t]+[$]_GLOBAL_OFFSET_TABLE_, %ebx
FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)]

[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely  ---
There's no regression (see bug 70792 comment 5).

G++ still warns for the testcasese here, even though it produces the right code
now.

[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Matthijs van Duin from comment #4)
> It seems bug 51253 previously addressed this, which means this is a
> regression.

No. To be a regression it has to have previously worked, then stopped working.
All versions of GCC warn about this code, so it's not a regression.

The fix for bug 51253 only changed the code generation, it didn't stop the
warnings being printed.

[Bug c++/65667] [5 Regression] FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
(In reply to Paul Thomas from comment #4)
> Author: pault
> Date: Sat Sep 29 17:17:09 2018
> New Revision: 264715
> 
> URL: https://gcc.gnu.org/viewcvs?rev=264715&root=gcc&view=rev
> Log:
> 2018-09-29  Paul Thomas  
> 
>   PR fortran/65667
>   * trans-expr.c (gfc_trans_assignment_1): If there is dependency
>   fix the rse stringlength.
> 
> 2018-09-29  Paul Thomas  
> 
>   PR fortran/65667
>   * gfortran.dg/dependency_52.f90 : New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/dependency_52.f90
> Modified:
> trunk/gcc/fortran/ChangeLog
> trunk/gcc/fortran/trans-expr.c
> trunk/gcc/testsuite/ChangeLog

Sorry for the noise - this should have been PR65677.

Paul

[Bug c++/87478] New: Hidden member function falsely takes part in qualified name lookup

[mario.biel...@tu-dresden.de]

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

Bug ID: 87478
   Summary: Hidden member function falsely takes part in qualified
name lookup
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario.biel...@tu-dresden.de
  Target Milestone: ---

Created attachment 44772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44772&action=edit
Example code, which should be rejected

In the attached example, a base class is defined with a member function
template and a derived class is defined with the same member function template.
Both member function templates have the same parameter list but are SFINAE'd
with exclusive conditions.

However, according to http://eel.is/c++draft/namespace.udecl#1 hidden functions
shall not participate in the name lookup and the base function template is
hidden according to http://eel.is/c++draft/namespace.udecl#15. Therefore, the
example code should be rejected, but it compiles without warnings.

The issue came up on this stackoverflow question:
https://stackoverflow.com/questions/52590220/name-lookup-error-of-enable-ifd-inherited-member-functions

[Bug fortran/38936] [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #21 from Paul Thomas  ---
Now replaced with the meta-bug set up by Janus.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org]

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

Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936

   What|Removed |Added

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

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[pault at gcc dot gnu.org]

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

Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936

   What|Removed |Added

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

[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function

[pault at gcc dot gnu.org]

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

Bug 38936 Summary: [F03] ASSOCIATE construct / improved SELECT TYPE (a=>expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38936

   What|Removed |Added

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

[Bug fortran/87359] [9 regression] pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

Jürgen Reuter  changed:

   What|Removed |Added

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

--- Comment #46 from Jürgen Reuter  ---
Checked (again) that with our code which triggered this reproducer everything
works fine again, taking as reference r264725.

[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
 CC||wschmidt at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

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

#1  0x01e11b98 in create_add_on_incoming_edge (c=0x2fc4000, basis_name=
, increment=..., 
e= 6)>, loc=2147483670, known_stride=false)
at /tmp/trunk2/gcc/gimple-ssa-strength-reduction.c:2344
2344  gcc_unreachable ();
(gdb) p increment
$1 = {> = {val = {-2, -1, 140737488345120, 
  10789461}, len = 1}, static is_sign_extended = }

(so the value is -2)

from

  /* If the phi argument is the base name of the CAND_PHI, then
 this incoming arc should use the hidden basis.  */
  if (operand_equal_p (arg, phi_cand->base_expr, 0))
if (basis->index == 0)
  feeding_def = gimple_assign_lhs (basis->cand_stmt);
else
  {
widest_int incr = -basis->index;
feeding_def = create_add_on_incoming_edge (c, basis_name, incr,
   e, loc, known_stride);
  }

we get there with basis->index == 2, eventually generated from

_16 = _15 + 2;

[Bug fortran/41599] [OOP] SELECT TYPE with associate-name => exp: Use (sometimes) a restricted pointer

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #4)
> I still get an ICE when compiling the second test in comment 3 with r228594.

From 7.3.1 onwards, this now gives the correct error:
Error: Component ‘bar’ with CLASS at (1) must be allocatable or pointer

6.4.1 ICEs still.

It seems to me that this should be closed.

Paul

[Bug c++/87476] [9 Regression] char-array initialized from wide-string

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-01
Version|unknown |9.0
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

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

[Bug rtl-optimization/87475] [8/9 Regression] ICE in patch_jump_insn, at cfgrtl.c:1275

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug tree-optimization/87261] Optimize bool expressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/87261] Optimize bool expressions

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Mon Oct  1 11:25:45 2018
New Revision: 264744

URL: https://gcc.gnu.org/viewcvs?rev=264744&root=gcc&view=rev
Log:
2018-10-01  MCC CS 

PR tree-optimization/87261
* match.pd: Remove trailing whitespace.
Add (x & y) | ~(x | y) -> ~(x ^ y),
(~x | y) ^ (x ^ y) -> x | ~y and (x ^ y) | ~(x | y) -> ~(x & y)

* gcc.dg/pr87261.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr87261.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug fortran/87477] New: [meta-bug] [F03] issues concerning the ASSOCIATE statement

[janus at gcc dot gnu.org]

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

Bug ID: 87477
   Summary: [meta-bug] [F03] issues concerning the ASSOCIATE
statement
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

[Bug gcov-profile/87442] Add options to filter files we want to instrument for code coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug c++/87476] New: [9 Regression] char-array initialized from wide-string

[larsbj at gullik dot net]

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

Bug ID: 87476
   Summary: [9 Regression] char-array initialized from wide-string
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsbj at gullik dot net
  Target Milestone: ---

Created attachment 44771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44771&action=edit
Source showing error

Using g++ -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-9/bin/g++
COLLECT_LTO_WRAPPER=/opt/gcc/gcc-9/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gcc/gcc-9
--enable-checking=release --enable-languages=c,c++
Thread model: posix
gcc version 9.0.0 20180925 (experimental) (GCC)

When compiling the attached source snippet I get:

g++ -c foo.cpp
foo.cpp: In instantiation of ‘void f<  >::operator()()
[with  = int]’:
foo.cpp:9:14:   required from here
foo.cpp:4:33: error: char-array initialized from wide string
4 | constexpr unsigned char p[1]{};
  |

With g++ --version
g++ (GCC) 8.1.1 20180712 (Red Hat 8.1.1-5)
this compiles without any errors.

[Bug sanitizer/87453] Maybe implement -fsanitize=float-cast-overflow and -fsanitize=float-divide-by-zero

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Great, thanks.

[Bug c++/87373] Byte by byte accessing to the peripheral registers causes issues on ARM v7-m architecture

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #35 from Richard Earnshaw  ---
I haven't researched the history of this change, but it was probably
deliberate.  Device memory on processors (a memory classification that implies
that the underlying contents may contain memory mapped devices that have side
effects) is generally intolerant of misaligned accesses.  As such, emitting an
unaligned access to it may cause the system to fault.

If that was the reason for the change to GCC, it won't be reversed.  (The fact
that in your example the optimizers discover the alignment and change the code
back to an aligned access does not alter this general observation.)

[Bug target/84039] x86 retpolines and CFI

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

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

--- Comment #6 from Florian Weimer  ---
Sorry, but why is this bug in WAITING?

[Bug sanitizer/87453] Maybe implement -fsanitize=float-cast-overflow and -fsanitize=float-divide-by-zero

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #4 from Alexander Monakov  ---
Oops - actually both were implemented by Marek in 2014 and appeared in gcc-5
with exactly those option names. So, nothing to do here.

[Bug debug/87472] Unknown macro opcode with -gsplit-dwarf -g3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed with GCC 8 and just -g3 -gsplit-dwarf.  readelf isn't very verbose of
which macro section it complains about though...

Mark?