[Bug target/86722] ifcvt produces x&0 that is never cleaned up

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
code-gen should go thorough simplify_gen_* which should perform constant
folding.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Tom de Vries from comment #5)
> The foo::foo function starts at label .LFB1520, which brings us to:
> ...
> .uleb128 0x8b   # (DIE (0x5a99) DW_TAG_subprogram)
> .long   0x5a75  # DW_AT_abstract_origin
> .long   .LASF897# DW_AT_linkage_name:
> "foo::foo(std::__cxx11::basic_string d::char_traits, std::allocator >)"
> ...
> with second parameter:
> ...
> .uleb128 0x59   # (DIE (0x5ac5) DW_TAG_formal_parameter)
> .long   0x5a8c  # DW_AT_abstract_origin
> .uleb128 0x2# DW_AT_location
> .byte   0x91# DW_OP_fbreg
> .sleb128 -32
> ...
> 
> The location expression is the generated for:
> ...
> (gdb) call debug_generic_expr (decl)
> dir_hint
> (gdb) call debug_generic_expr (decl.typed.type)
> struct string & restrict
> (gdb) p decl_by_reference_p (decl)
> $1 = false
> ...
> 
> In contrast, the abstract origin has:
> ...
> (gdb) call debug_generic_expr (decl.decl_common.abstract_origin)
> dir_hint
> (gdb) call debug_generic_expr (decl.decl_common.abstract_origin.typed.type)
> struct string & restrict
> (gdb) p decl_by_reference_p (decl.decl_common.abstract_origin)
> $3 = true
> ...

I think this is the issue - why do we have a mismatch between the origins
decl_by_reference_p and decls decl_by_reference_p?  Is that the in-charge
vs. not-in-charge constructor clones the C++ FE generates?

I think we shouldn't have abstract origins pointing to different
calling-convention things.

[Bug fortran/25829] [F03] Asynchronous IO support

[rguenth at gcc dot gnu.org]

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

Bug 34705 Summary: Reuse I/O structures to save memory and help the ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34705

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug fortran/34705] Reuse I/O structures to save memory and help the ME

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Richard Biener  ---
No, there are no "SFTs" anymore and we have clobbers now that make
stack-sharing of the I/O temporaries possible.

[Bug c/86729] New: address of vector element requested

[zhonghao at pku dot org.cn]

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

Bug ID: 86729
   Summary: address of vector element requested
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

gcc accepts the following code:

void a() {
 typedef float v4sf __attribute__ ((vector_size (16)));
 static v4sf q;
 float* r = &q[0];
}

clang rejects it:

clang code1.c 
code1.c:4:13: error: address of vector element requested
 float* r = &q[0];
^
1 error generated.


The error message of clang seems to be reasonable?

[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2018-07-30
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Clearly initializing to "1234aa" is the least expected and thus from a QOI
perspective we should either effectively truncate the excess initializers
or reject the program (if we may).

Re-opening.

[Bug c++/86730] New: use of deleted copy constructor (I am not using it)

[asif_bahrainwala at hotmail dot com]

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

Bug ID: 86730
   Summary: use of deleted copy constructor (I am not using it)
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asif_bahrainwala at hotmail dot com
  Target Milestone: ---

gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0

//Below code does not compile, I am not using the copy constructor, it seems to
work fine in Vs2013, CLANG (experimental P1144), tested using
https://godbolt.org/


struct A1{
  A1(int y){}
  A1(const A1 &a1)=delete;
};

int main()
{
A1 a1_=6;
A1 a1(5);
}

gcc main.cpp 
main.cpp: In function ‘int main()’:
main.cpp:8:12: error: use of deleted function ‘A1::A1(const A1&)’
 A1 a1_=6;
^
main.cpp:3:3: note: declared here
   A1(const A1 &a1)=delete;
   ^~
main.cpp:2:3: note:   after user-defined conversion: A1::A1(int)
   A1(int y){}

[Bug c/86729] address of vector element requested

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
How is that a bug? If anything, you could ask clang to implement this
extension.

[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Agreed completely.  Either change the FE to adjust the initializer to the right
length, or change the optimization to punt if the initializer is too long for
the field (note, you need to handle the one larger case with '\0' anyway), or
handle it by taking only the first 3 bytes from the first STRING_CST and then
use further bytes from the second one (my preference).  Note, string_constant
already has an argument in which it can optionally provide the lengths.

[Bug middle-end/86711] [9 Regression] wrong folding of memchr

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/86710] 3 missing logarithm optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 Ever confirmed|0   |1

[Bug target/86731] New: [8 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[jcowgill+gcc at jcowgill dot uk]

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

Bug ID: 86731
   Summary: [8 Regression] Miscompiles vec_sl at -O3 with -fwrapv
on ppc64el
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcowgill+gcc at jcowgill dot uk
  Target Milestone: ---

FFmpeg was hit by a bug which causes strange results when the optimized altivec
routines are compiled with -O3 and -fwrapv (which is used when FFmpeg is
configured with --toolchain=hardened). This bug only occurs with GCC 8.

Simplified extract which shows the bug:

#include 

vector unsigned int splat(void)
{
vector unsigned int mzero = vec_splat_u32(-1);
return (vector unsigned int) vec_sl(mzero, mzero);
}

The goal is to create a constant vector with each element containing 0x8000
(== -0.0f). If I am reading the altivec manual correctly, the above code is
valid because the second argument to vec_sl should interpreted modulo 32 (ie as
31 in this case).

With gcc-7 this generates this correct code:
 :
   0:   8c 03 5f 10 vspltisw v2,-1
   4:   84 11 42 10 vslwv2,v2,v2
   8:   20 00 80 4e blr

When compiled with "gcc-8 -O3 -fwrapv -c altivectest.c" this wrong code is
produced:
 :
   0:   8c 03 5f 10 vspltisw v2,-1
   4:   20 00 80 4e blr



If I pass -fdump-tree-all, I can see that the vec_sl gets transformed into a
normal left shift. My guess (which may be wrong) is that gcc is treating this
shift as UB because it is trying to shift > 32 bits.

[Bug middle-end/86705] [7/8/9 Regression] pr45678-2.c ICE with msp430-elf -mlarge

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c++/86706] [8/9 Regression] ICE in build_base_path, at cp/class.c:294

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||8.1.0
  Known to fail||8.2.0

[Bug tree-optimization/86707] Missed optimization: optimizing set of if statements

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 Blocks||85316
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  This requires conditional bit set/unset propagation.  CCP handles
this unconditional only and since it is a SSA propagator things cannot be
easily improved there.  EVRP could handle this but it doesn't track set
bits.

We might have a duplicate bugreport for this.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug tree-optimization/86702] [9 Regression] SPEC CPU2006 400.perlbench, CPU2017 500.perlbench_r ~3% performance drop after r262247

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |9.0
   Target Milestone|--- |9.0

[Bug target/86547] s390x: Maximum number of LRA assignment passes is achieved (30) when compiling a small inline assembler snippet

[krebbel at gcc dot gnu.org]

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

--- Comment #7 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Jul 30 08:30:06 2018
New Revision: 263063

URL: https://gcc.gnu.org/viewcvs?rev=263063&root=gcc&view=rev
Log:
lra: consider clobbers when selecting hard_regno to spill

The idea behind the rclass loop in spill_hard_reg_in_range() seems to
be: find a hard_regno, which in general conflicts with reload regno,
but does not do so between `from` and `to`, and then do the live range
splitting based on this information. To check the absence of conflicts,
we make use of insn_bitmap, which does not contain insns which clobber
the hard_regno.

gcc/ChangeLog:

2018-07-30  Ilya Leoshkevich  

PR target/86547
* lra-constraints.c (spill_hard_reg_in_range): When selecting the
hard_regno, make sure no insn between `from` and `to` clobbers it.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c

[Bug target/86684] ICE in extract_insn, at recog.c:2304 on ppc64le

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #3)
> I did try that.
> 
> Can you please give your config?  Some repro instructions, maybe on a given
> cfarm machine?

I used gcc14 machine. Download latest tarbal and:

$ ../configure --enable-languages=c,c++,fortran --disable-multilib
--prefix=/home/marxin/bin/gcc2 --disable-bootstrap --disable-libsanitizer
--target=ppc64le-linux-gnu
$ make -j8 all-host -k CFLAGS="-O0 -g" CXXFLAGS="-O0 -g"
$ ./xgcc -B.
/home/marxin//gcc/gcc-master/gcc/testsuite/gfortran.dg/bounds_check_19.f90

Should be visible. Thanks.

[Bug fortran/86472] allocatable array, bound-procedure, submodule

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #3)
> > Yes indeed with respect to the declaration of 't'. However, since the 
> > submodule
> > is a separate compilation unit, I believe that it also must contain
> > an 'implicit none' to pick up the undeclared variable 'x'. I will check
> > the standard on this.
> 
> If I add
> 
> implicit none
> real :: x
> 
> I get
> 
>  print *,t, a, x
>  1
> Error: Symbol 't' at (1) has no IMPLICIT type

This points to the underlying problem. Somehow the symbol for 't' is not being
harvested from the interface.

Cheers

Paul

[Bug tree-optimization/86732] New: Potential nullptr dereference does not propagate knowledge about the pointer

[antoshkka at gmail dot com]

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

Bug ID: 86732
   Summary: Potential nullptr dereference does not propagate
knowledge about the pointer
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Following example 

static const int* get_if(const int* v) {
if (v && *v == 0) return v;
return nullptr;
}

int example(const int& a) {
return *get_if(&a);
}

Generates quite a large assembly:

_Z7exampleRKi:
  mov eax, DWORD PTR [rdi]
  test eax, eax
  jne .L2
  xor eax, eax
  ret
_Z7exampleRKi.cold.0:
.L2:
  mov eax, DWORD PTR ds:0
  ud2

However clang generates a better code:
_Z7exampleRKi: # @_Z7exampleRKi
  mov eax, dword ptr [rdi]
  ret

If we unconditionally dereference the result of `get_if`, then it is UB to
return a nullptr. So all the nullptr checks could be eliminated.

[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer

[antoshkka at gmail dot com]

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

--- Comment #1 from Antony Polukhin  ---
Probably a more fair example< without taking an address of a reference:

static const int* get_if(const int* v) {
if (v && *v == 0) return v;
return nullptr;
}

int example(const int* a) {
return *get_if(a);
}

GCC produces the same suboptimal assembly:

_Z7examplePKi:
  test rdi, rdi
  je .L2
  mov eax, DWORD PTR [rdi]
  test eax, eax
  jne .L2
  xor eax, eax
  ret
_Z7examplePKi.cold.0:
.L2:
  mov eax, DWORD PTR ds:0
  ud2


While Clang just generates:
_Z7examplePKi: # @_Z7examplePKi
  mov eax, dword ptr [rdi]
  ret

[Bug c++/86706] [8/9 Regression] ICE in build_base_path, at cp/class.c:294

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 44463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44463&action=edit
gcc9-pr86706.patch

Thanks, that seems to work.  I've bootstrapped/regtested it successfully on
x86_64-linux and i686-linux, plus regtested with check-c++-all on x86_64-linux
too.  The testcase in this patch is reduced version of the reported testcase.

Will you commit this, or do you want me to commit it for you?

[Bug c++/86733] New: c++17 and #pragma GCC diagnostic warning "-Wall" resurrect pre-c++11 warnings.

[Emmanuel.Thome at inria dot fr]

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

Bug ID: 86733
   Summary: c++17 and #pragma GCC diagnostic warning "-Wall"
resurrect pre-c++11 warnings.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Emmanuel.Thome at inria dot fr
  Target Milestone: ---

gcc 8.1.0 here.

The following simple code expectedly fails to compile with -std=c++98 because
of the double angle brackets. (g++ -std=c++98 -c /tmp/foo.cpp)

#pragma GCC diagnostic warning "-Wall"
template class foo { };
template struct bar { struct type { }; };
template struct baz { typedef typename bar>::type type; };

With -std=c++11, this works fine, and no warning is triggered.

With -std=c++17, I get a warning that I had not expected.

localhost $ g++ -std=c++17 -c foo.cpp 
foo.cpp:4:56: warning: ‘>>’ operator is treated as two right angle brackets in
C++11 [-Wc++11-compat]
 template struct baz { typedef typename bar>::type type; };
^~
foo.cpp:4:56: note: suggest parentheses around ‘>>’ expression


The #pragma plays a role here. The warning is triggered only when the #pragma
is enabled. I haven't been able to trigger it with the #pragma commented out
and a command-line flag (e.g. not with -std=c++17 -Wall, nor with -std=c++17
-Wc++11-compat).

[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
While I would also like to see this optimized better, ISTR that this was done
on purpose, you may want to look at the old discussions. Some languages may
have things set up to catch null dereferences, but that should be controlled by
-fdelete-null-pointer-checks, -fnon-call-exceptions or some similar flag. Maybe
that was just because Jeff doesn't like __builtin_unreachable (for security
reasons).

[Bug middle-end/86718] [9 Regression] ICE during RTL pass: expand

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
   Target Milestone|--- |9.0
Summary|ICE during RTL pass: expand |[9 Regression] ICE during
   ||RTL pass: expand

[Bug tree-optimization/86724] Compilation error with new isl 0.20 (missing includes)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
I'll see to fix this.

[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||bart at bartjanssens dot org

--- Comment #1 from Richard Biener  ---
*** Bug 86727 has been marked as a duplicate of this bug. ***

[Bug target/86727] Struct argument in xmm0 register instead of rcx on Win64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug c++/86728] [8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P2
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|[Regression] unexpected |[8/9 Regression] unexpected
   |error: conversion from  |error: conversion from
   |',  |',
   |...)>' to non-scalar type   |...)>' to non-scalar type
   |'std::function'  |'std::function'
   |requested   |requested
  Known to fail||8.1.0

[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
We have the isolate-errorneous-paths pass which does:

example (const int & a)
{
  int _3;
  int _4;
  const int * _5;
  const int * _6;
  int _7;

   [local count: 1073741825]:
  _3 = *a_2(D);
  if (_3 == 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [local count: 598933193]:
  # _5 = PHI 
  _4 = *_5;
  return _4;

   [count: 0]:
  # _6 = PHI <0B(2)>
  _7 ={v} *_6;
  __builtin_trap ();

}

note how it doesn't eliminate the actual load which probably causes the 
odd code-generation.  Nothing removes it afterwards because it may
(and will!) trap.

Then isolate-errorneus-paths runs a bit late so the next CSE pass to
CSE *a_2(D) and *_5 is PRE.  But we still end up with the following
in the end, keeping the condition live.  As Marc said the condition
would be only dead if we'd use __builtin_unreachable () rather than
__builtin_trap () here which has security implications.  But the
load doesn't need to be there.

   [local count: 1073741825]:
  _3 = *a_2(D);
  if (_3 == 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [local count: 598933193]:
  return _3;

   [count: 0]:
  _7 ={v} MEM[(const int *)0B];
  __builtin_trap ();

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |8.3
Summary|[8 Regression] Miscompiles  |[8/9 Regression]
   |vec_sl at -O3 with -fwrapv  |Miscompiles vec_sl at -O3
   |on ppc64el  |with -fwrapv on ppc64el

[Bug middle-end/86718] [9 Regression] ICE during RTL pass: expand

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce, what target, what revision?  Current trunk (r263063) on both
x86_64-linux and i686-linux doesn't ICE for me.

[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Richard Biener from comment #3)
> note how it doesn't eliminate the actual load which probably causes the 
> odd code-generation.

The code says:

  /* We want the NULL pointer dereference to actually occur so that
 code that wishes to catch the signal can do so.

  /* If we had a NULL pointer dereference, then we want to insert the
 __builtin_trap after the statement, for the other cases we want
 to insert before the statement.  */

Maybe that should be protected by more flags, but it is done on purpose.

> security implications.

Those didn't convince me much at the time though, it is far from the only
transformation that can have such effect, and we are not consistent in using
trap vs unreachable.

[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI

[bart at bartjanssens dot org]

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

--- Comment #2 from Bart Janssens  ---
Any chance that this can be upgraded to "confirmed"? Seems this has been around
for a while...

gcc-bugs@gcc.gnu.org

[frankhb1989 at gmail dot com]

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

Bug ID: 86734
   Summary: [DR 2188] reverse_iterator::operator-> does not
support overloaded operator&
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frankhb1989 at gmail dot com
  Target Milestone: ---

Since this had been adopted by N3936, it should at least be in C++14 & C++17
modes. 

Note this is also in libc++ in all modes. Resolution from LWG 2775 seems to be
adopted MSVC++ 15.7 but I don't find it in the current draft.

BTW, the comment on reverse_iterator's default constructor is outdated. It took
me half an hour to find LWG 1012 :(

[Bug c++/86733] c++17 and #pragma GCC diagnostic warning "-Wall" resurrect pre-c++11 warnings.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Presumably the handling for the pragma just turns the option on without
considering the current cxx_dialect.

This should fix it:

--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9210,7 +9210,7 @@ cp_parser_binary_expression (cp_parser* parser, bool
cast_p,
   /* Get an operator token.  */
   token = cp_lexer_peek_token (parser->lexer);

-  if (warn_cxx11_compat
+  if (warn_cxx11_compat && cxx_dialect < cxx11
   && token->type == CPP_RSHIFT
   && !parser->greater_than_is_operator_p)
 {

[Bug fortran/86735] New: [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

Bug ID: 86735
   Summary: [8/9 Regression] Bad wrong-code bug with
"-march=skylake-avx512 -Ofast"
   Product: gcc
   Version: 8.2.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: ---

Consider this simple test case:


program avx512_bug

   implicit none

   integer, dimension(:), allocatable :: list
   integer, parameter :: maxList = 32
   integer :: i

   allocate(list(1:maxList))
   do i=1,maxList
  list(i) = i
   end do

   call test(list)

contains

   subroutine test(a)
  integer, dimension(:), intent(in) :: a
  integer, parameter :: maxSamples = 16
  integer, dimension(1:maxSamples) :: iarr
  integer :: i, cnt, nbSamples

  cnt = ubound(a,1)
  nbSamples = min(maxSamples, cnt)
  do i=1,nbSamples
 iarr(i) = i
  end do

  print *, iarr(1:nbSamples)
  print *, a(iarr(1:nbSamples))

   end subroutine

end


It should print the sequence from 1 to 16 twice, which it does with gfortran
versions up to 7.

With 8.2.0 and trunk, however, the second line has varying random numbers when
the code is compiled with "-march=skylake-avx512 -Ofast".

-march=skylake works, -O3 works as well.

[Bug lto/86736] New: [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[iains at gcc dot gnu.org]

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

Bug ID: 86736
   Summary: [9 regression] g++.dg/asan/pr81021.C   -O2 -flto
-flto-partition=none ICE at dwarf2out.c:3
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

I don't see this on x86_64-linux, but on x86_64-Darwin (several versions):

Perhaps some fallout from the disabled lto debug?

between r262500 and 262603 (present at 263045)

FAIL: g++.dg/asan/pr81021.C   -O2 -flto -flto-partition=none  (internal
compiler error)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto -flto-partition=none  (test for excess
errors)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto  (internal compiler error)
FAIL: g++.dg/asan/pr81021.C   -O2 -flto  (test for excess errors)

  /* We shouldn't have any symbols with delayed asm names for
 DIEs generated after early finish.  */
3  gcc_assert (deferred_asm_name == NULL);


deferred_asm_name->created_for is :

p debug_tree(deferred_asm_name->created_for)
 
unit-size 
align:64 warn_if_not_align:0 symtab:1176738304 alias-set -1
canonical-type 0x144d19c78
fields 
private nonlocal BLK
/scratch/10-12-sie/gcc-trunk-unpatched/x86_64-apple-darwin14/libstdc++-v3/include/bits/basic_string.h:155:20
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context
 chain > context 
pointer_to_this  reference_to_this
 chain >
asm_written in_system_header VOID
/scratch/10-12-sie/gcc-trunk-unpatched/x86_64-apple-darwin14/libstdc++-v3/include/bits/stringfwd.h:73:30
align:1 warn_if_not_align:0 context >

gcc-bugs@gcc.gnu.org

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 Ever confirmed|0   |1

[Bug tree-optimization/86506] [9 Regression] tree-vect-patterns.c:225: shift too large for type ?

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Jul 30 11:23:26 2018
New Revision: 263064

URL: https://gcc.gnu.org/viewcvs?rev=263064&root=gcc&view=rev
Log:
Resync inline implementation of ceil_log2 (PR 86506)

In r262961 I only updated the out-of-line copy of ceil_log2.  This patch
applies the same change to the other (inline) one.

2018-07-30  Richard Sandiford  

gcc/
PR tree-optimization/86506
* hwint.h (ceil_log2): Resync with hwint.c implementation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/hwint.h

[Bug c++/86607] constexpr function does not treat function pointers with external linkage as constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 Ever confirmed|0   |1

[Bug middle-end/86640] [8/9 regression] ICE in combine

[tnfchris at gcc dot gnu.org]

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

--- Comment #10 from Tamar Christina  ---
Hi Segher, bootstrap is ok and I found no regressions testing testing a softfp
and hard configuration.

[Bug rtl-optimization/67396] [5 regression] Performance regression compiling variadic function with many arguments in RTL DSE

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 CC||belyshev at depni dot 
sinp.msu.ru

--- Comment #14 from Serge Belyshev  ---
For the record: O(N^3) on the testcase with -mno-accumulate-outgoing-args
started with r169782.  And then it was "fixed" to O(N^2) by r234709 with the
help from max-dse-active-local-stores param introduced in r171090.

The testcase is interesting in that with different options
(-maccumulate-outgoing-args or -g -fVTA) it triggers another O(N^2) slowdowns
started from different revisions.

Current trunk with -mno-accumulate-outgoing-args exhibits saw-like O(N^2)
behaviour controlled by max-dse-active-local-stores param, and for N=5000
(right before max-dse-active-local-stores triggers) times are:

gcc-4.5 0.1 s
gcc-9.0 2.8 s

It is noticeable during glibc make check under qemu-riscv64, when
stdio-common/tst-printf-bz18872.c takes about 1h to compile.

[Bug target/86673] [8/9 regression] inline asm sometimes ignores 'register asm("reg")' declarations

[amonakov at gcc dot gnu.org]

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

--- Comment #18 from Alexander Monakov  ---
Author: amonakov
Date: Mon Jul 30 12:26:37 2018
New Revision: 263065

URL: https://gcc.gnu.org/viewcvs?rev=263065&root=gcc&view=rev
Log:
doc: discourage const/volatile on register variables (PR 86673)

PR target/86673
* doc/extend.texi (Global Register Variables): Discourage use of type
qualifiers.
(Local Register Variables): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/extend.texi

[Bug c++/86608] [6/7/8/9 Regression] volatile variable is taken as a constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 CC||jason at redhat dot com
  Known to work||5.4.0
Summary|volatile variable is taken  |[6/7/8/9 Regression]
   |as a constexpr  |volatile variable is taken
   ||as a constexpr
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
Regression started with r231351:

   Fix template/ref1.C, nontype15.C, addr-builtin1.C with -std=c++1z.

* parser.c (cp_parser_template_argument): Handle references in
C++1z mode.
* constexpr.c (potential_constant_expression_1): Don't error about
TREE_THIS_VOLATILE on declarations.
[COMPONENT_REF]: Don't consider the object if we're dealing with an
overloaded function.

[Bug fortran/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to janus from comment #0)
> With 8.2.0 and trunk, however, the second line has varying random numbers
> when the code is compiled with "-march=skylake-avx512 -Ofast".
> 
> -march=skylake works, -O3 works as well.

Instead of "-Ofast", it is sufficient to use "-O3 -fstack-arrays" to reproduce
the problem.

Last day of summer offer from Emaar - 80% post handover 5 year payment plan

[ZIa ul Islam]

View this email in your browser 
(https://mailchi.mp/7365eb78bd0d/last-day-of-summer-offer-from-emaar-80-post-handover-5-year-payment-plan?e=1c93265448)
http://aquaproperties.com/emaar/zia.html
http://aquaproperties.com/emaar/zia.html
Emaar is delighted to announce an exclusive 20/80 offer on villas and 
townhouses in Arabian Ranches. Take advantage of this limited time opportunity 
and own a home in a coveted area with incredible benefits.


** Starting From AED 2,262,888/-



** 80% POST-HANDOVER
5 YEAR PAYMENT PLAN*



** 100% OFF
REGISTRATION FEES



** 5-YEAR SERVICE
CHARGE WAIVER

Register Now (http://aquaproperties.com/emaar/zia.html)

http://aquaproperties.com/emaar/zia.html

For more information:
Zia ul Islam
Sales Director
+971 55 309 5036
z...@aquaproperties.com


** (https://twitter.com/aquaproperties)
** (https://www.facebook.com/aquaproperties)
** (https://www.aquaproperties.com)
Copyright © 2018 Aqua properties, All rights reserved.
 You are receiving this email because you are our valuable client.

Our mailing address is:
Aqua properties
Dubai
Dubai
United Arab Emirates
Want to change how you receive these emails?
You can ** update your preferences 
(https://aquaproperties.us18.list-manage.com/profile?u=57709ba3f7bfded8dfe1df62e&id=7ca9b7db8f&e=1c93265448)
or ** unsubscribe from this list 
(https://aquaproperties.us18.list-manage.com/unsubscribe?u=57709ba3f7bfded8dfe1df62e&id=7ca9b7db8f&e=1c93265448&c=9a96da4147)
.

[Bug tree-optimization/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |tree-optimization

--- Comment #2 from janus at gcc dot gnu.org ---
Since this problem only occurs only with optimization (and on a particular
architecture) it's probably not a front-end issue, so I'm changing the
component from "fortran" to "tree-optimization".

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Created attachment 44464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44464&action=edit
Tentative patch

[Bug rtl-optimization/85160] GCC generates mvn/and instructions instead of bic on aarch64

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Mon Jul 30 13:18:17 2018
New Revision: 263067

URL: https://gcc.gnu.org/viewcvs?rev=263067&root=gcc&view=rev
Log:
combine: Allow combining two insns to two insns

This patch allows combine to combine two insns into two.  This helps
in many cases, by reducing instruction path length, and also allowing
further combinations to happen.  PR85160 is a typical example of code
that it can improve.

This patch does not allow such combinations if either of the original
instructions was a simple move instruction.  In those cases combining
the two instructions increases register pressure without improving the
code.  With this move test register pressure does no longer increase
noticably as far as I can tell.

(At first I also didn't allow either of the resulting insns to be a
move instruction.  But that is actually a very good thing to have, as
should have been obvious).


PR rtl-optimization/85160
* combine.c (is_just_move): New function.
(try_combine): Allow combining two instructions into two if neither of
the original instructions was a move.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[steinar+gcc at gunderson dot no]

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

Steinar H. Gunderson  changed:

   What|Removed |Added

 CC||steinar+gcc at gunderson dot no

--- Comment #17 from Steinar H. Gunderson  ---
Hi,

Does this change mean now it's effectively impossible to have abstract base
classes under -Wall without adding boilerplate? Consider something like the
following:

class Base {
public:
  virtual ~Base() {}
  virtual void foo() = 0;
};

class Derived : Base {
public:
  ~Derived();
  void foo() override;
};

Base needs to have a virtual destructor since it has virtual member functions
(or half the world will give you warnings).

Any attempts now to copy Derived through the implicit copy constructor will
give a warning, since the synthesis of Base::Base(const Base &) is deprecated.
The only way I've found to suppress this is to add

  Base::Base(const Base &) = default;

However, this in turn disables the synthesis of Base::Base(), and also
Base::operator=(const Base &). So I need:

  Base() = default;
  Base(const Base &) = default;
  Base(Base &&) = default;
  Base &operator= (const Base &) = default;
  Base &operator= (Base &&) = default;

for something that doesn't have a single member!

Am I missing something?

[Bug gcov-profile/35543] Add more strOp for value profiling

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Martin Liška  ---
Out of: strncmp, memcmp, memmove, strncpy I'm planning to add support
only for memmove. The others have only possible inline expansion when size is 0
or 1. It's probably quite rare.

[Bug ada/84142] Implicit_Dereference with Generic Formal Incomplete Types

[simon at pushface dot org]

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

--- Comment #3 from simon at pushface dot org ---
All three test cases compile OK with 8.1.0.

[Bug tree-optimization/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
An observation in case it might help to narrow down the problem: gcc-8 changed
to prefer 256-bit-wide vectors on skylake-avx512, so adding
-mprefer-vector-width=512 option for gcc-8/trunk should make vectorization
behave a bit closer to gcc-7.

[Bug lto/86736] [9 regression] g++.dg/asan/pr81021.C -O2 -flto -flto-partition=none ICE at dwarf2out.c:31111

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-30
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can possibly be reproduced on x86_64-linux when compiling with -g0 and linking
with -g.

Let me take this bug until I get to try that.

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 CC||kyukhin at gcc dot gnu.org
  Component|tree-optimization   |target
   Target Milestone|--- |8.3

--- Comment #4 from Richard Biener  ---
Looks more like a target issue to me.  AVX2 uses very similar gather stuff.

[Bug c++/86738] New: gcc 8.2: Internal compiler error memcpy

[joerg.danne at nokia dot com]

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

Bug ID: 86738
   Summary: gcc 8.2: Internal compiler error memcpy
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.danne at nokia dot com
  Target Milestone: ---

Created attachment 44465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44465&action=edit
g++ hugo.cc ---> causes internal compiler error

/home/jdanne/gnu2/bin/g++ hugo.cc
hugo.cc: In member function 'int FooBarEvent::showFooBar()':
hugo.cc:38:108: internal compiler error: Segmentation fault
   memcpy(formatId, &(remoteInvDataString[((unsigned int) (unsigned
long)&((FooBarData *)0)->FormateID)]), 2);
   
^
0xbb58ef crash_signal
../../gcc/toplev.c:325
0xe4c1b3 selt
../../gcc/wide-int.cc:404
0xe4c1b3 wi::lts_p_large(long const*, unsigned int, unsigned int, long const*,
unsigned int)
../../gcc/wide-int.cc:480
0x67032b bool wi::les_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1917
0x67032b wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result
operator<= >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3171
0x67032b tree_int_cst_le(tree_node const*, tree_node const*)
../../gcc/tree.h:5737
0x67032b cxx_eval_array_reference
../../gcc/cp/constexpr.c:2429
0x67032b cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4504
0x66e334 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4366
0x66df00 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4598
0x671e79 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:4861
0x673dae maybe_constant_value(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:5079
0x67d9fa cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:2110
0x6835a7 cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:651
0x64e134 convert_like_real
../../gcc/cp/call.c:7126
0x6518d9 build_over_call
../../gcc/cp/call.c:7999
0x653ab7 build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4319
0x75f4ad finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2537
0x711e91 cp_parser_postfix_expression
../../gcc/cp/parser.c:7238
0x7125d1 cp_parser_unary_expression
../../gcc/cp/parser.c:8317
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


===

/home/jdanne/gnu2/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/jdanne/gnu2/bin/g++
COLLECT_LTO_WRAPPER=/home/jdanne/gnu2/libexec/gcc/x86_64-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --enable-multiarch
--enable-shared --enable-threads=posix --with-arch-32=i686 --disable-bootstrap
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-checking=release
--prefix=/home/jdanne/gnu2 --with-cpu=generic --enable-multilib --enable-nls
Thread model: posix
gcc version 8.2.0 (GCC) 


===

Code which caused the internal compiler error:
--


typedef unsigned int size_t;

extern void *memcpy (void *__restrict __dest,
   __const void *__restrict __src, size_t __n)
 throw () __attribute__ ((__nonnull__ (1, 2)));


typedef struct {
char FormateID[2];
char x1[4];
char x2[8];
char x3[10];
char x4[14];
char x5[14];
char x6[4];
char x7[16];
char x8[2];
char x9[6];
char x10[46];
}FooBarData;


class FooBarEvent
{
  public:
 int showFooBar();

};


int FooBarEvent::showFooBar()
{
  char dbgBuf[256];

  unsigned char remoteInvDataString[10];

  unsigned char formatId[2+1];
  memcpy(formatId, &(remoteInvDataString[((unsigned int) (unsigned
long)&((FooBarData *)0)->FormateID)]), 2);

  return 0;
}

[Bug bootstrap/86739] New: [9 Regression] Bootstrap broken with host GCC 4.1.2

[rguenth at gcc dot gnu.org]

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

Bug ID: 86739
   Summary: [9 Regression] Bootstrap broken with host GCC 4.1.2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Seen on x86_64-linux and ia64-linux.

g++ -std=gnu++98 -c   -g -DIN_GCC-fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wno-format -Wmissing-format-attribute -Woverloaded-virtual   -DHAVE_CONFIG_H
-DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/gcc/spec/sb-vangelis-head-64/gcc/gcc
-I/gcc/spec/sb-vangelis-head-64/gcc/gcc/build
-I/gcc/spec/sb-vangelis-head-64/gcc/gcc/../include 
-I/gcc/spec/sb-vangelis-head-64/gcc/gcc/../libcpp/include  \
-o build/vec.o /gcc/spec/sb-vangelis-head-64/gcc/gcc/vec.c
/usr/include/c++/4.1.2/bits/stl_pair.h: In instantiation of
'std::pair':
/gcc/spec/sb-vangelis-head-64/gcc/gcc/mem-stats.h:597:   instantiated from
'typename mem_alloc_description::mem_list_t*
mem_alloc_description::get_list(mem_alloc_origin, unsigned int*, int
(*)(const void*, const void*)) [with T = vec_usage]'
/gcc/spec/sb-vangelis-head-64/gcc/gcc/mem-stats.h:637:   instantiated from
'void mem_alloc_description::dump(mem_alloc_origin, int (*)(const void*,
const void*)) [with T = vec_usage]'
/gcc/spec/sb-vangelis-head-64/gcc/gcc/vec.c:175:   instantiated from here
/usr/include/c++/4.1.2/bits/stl_pair.h:84: error: forming reference to
reference type 'vec_usage*&'
/gcc/spec/sb-vangelis-head-64/gcc/gcc/hash-map.h: In member function
'std::pair hash_map<
, , 
>::iterator::operator*() [with KeyId =
mem_alloc_description::mem_location_hash, Value = vec_usage*, Traits
=
simple_hashmap_traits::mem_location_hash>,
vec_usage*>]':
/gcc/spec/sb-vangelis-head-64/gcc/gcc/mem-stats.h:597:   instantiated from
'typename mem_alloc_description::mem_list_t*
mem_alloc_description::get_list(mem_alloc_origin, unsigned int*, int
(*)(const void*, const void*)) [with T = vec_usage]'
/gcc/spec/sb-vangelis-head-64/gcc/gcc/mem-stats.h:637:   instantiated from
'void mem_alloc_description::dump(mem_alloc_origin, int (*)(const void*,
const void*)) [with T = vec_usage]'
/gcc/spec/sb-vangelis-head-64/gcc/gcc/vec.c:175:   instantiated from here
/gcc/spec/sb-vangelis-head-64/gcc/gcc/hash-map.h:229: error: no matching
function for call to 'std::pair::pair(mem_location*&, vec_usage*&)'
/usr/include/c++/4.1.2/bits/stl_pair.h:80: note: candidates are: std::pair<_T1,
_T2>::pair() [with _T1 = mem_location* const&, _T2 = vec_usage*&]
/usr/include/c++/4.1.2/bits/stl_pair.h:69: note:
std::pair::pair(const
std::pair&)
make[3]: *** [build/vec.o] Error 1

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Regressed between r262525 (good) and r262545 (bad).  Thus probably caused by
r262539.

/usr/include/c++/4.1.2/bits/stl_pair.h:84 is

  /** Two objects may be passed to a @c pair constructor to be copied.  */
  pair(const _T1& __a, const _T2& __b)
  : first(__a), second(__b) { }

so it somehow doesn't like _T1 == vec_usage*& here I added with

std::pair operator* ()
{
  hash_entry &e = *m_iter;
  return std::pair (e.m_key, e.m_value);
}

C++ folks?

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 44466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44466&action=edit
preprocessed source

For reference, here's preprocessed source.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Steinar H. Gunderson from comment #17)
> Base needs to have a virtual destructor since it has virtual member
> functions (or half the world will give you warnings).

Or a protected destructor, but that doesn't change anything relevant to your
problem.

> Any attempts now to copy Derived through the implicit copy constructor will
> give a warning, since the synthesis of Base::Base(const Base &) is
> deprecated. The only way I've found to suppress this is to add
> 
>   Base::Base(const Base &) = default;
> 
> However, this in turn disables the synthesis of Base::Base(), and also
> Base::operator=(const Base &). So I need:
> 
>   Base() = default;
>   Base(const Base &) = default;
>   Base(Base &&) = default;
>   Base &operator= (const Base &) = default;
>   Base &operator= (Base &&) = default;
> 
> for something that doesn't have a single member!

Yes. The deprecation means a future version of C++ might make your type
non-copyable. To explicitly say it's copyable (and make the code futureproof)
you need to add those defaulted members.

If you don't want to do that, you can use -Wno-deprecated-copy to suppress the
warnings.

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Alexander Monakov from comment #3)
> An observation in case it might help to narrow down the problem: gcc-8
> changed to prefer 256-bit-wide vectors on skylake-avx512, so adding
> -mprefer-vector-width=512 option for gcc-8/trunk should make vectorization
> behave a bit closer to gcc-7.

Indeed adding the flag "-mprefer-vector-width=512" makes the problem disappear.
Thanks for the comment.

[Bug tree-optimization/86725] ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-07-30
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
We're incorrectly treating the wo phi for the outer loop as a reduction, even
though it really forms a double induction with the phi in the inner loop.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[steinar+gcc at gunderson dot no]

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

--- Comment #19 from Steinar H. Gunderson  ---
Thanks for confirming; so GCC is absolutely right here, it's the standard that
makes a choice with surprising ramifications (to me, at least). I wonder if I
should try to ask someone in the standards committee to make an exception for
pure virtual destructors...

[Bug c++/86740] New: ICE with hana and nested lambdas (tsubst_copy, at cp/pt.c:15325)

[markus at dreseler dot de]

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

Bug ID: 86740
   Summary: ICE with hana and nested lambdas (tsubst_copy, at
cp/pt.c:15325)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: markus at dreseler dot de
  Target Milestone: ---

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

The attached file causes the following ICE:

gccice.cpp:35:26: internal compiler error: in tsubst_copy, at cp/pt.c:15325
 std::cout << params << std::endl;
  ^~
0x599570 tsubst_copy
../../src/gcc/cp/pt.c:15325
0x6ce257 tsubst_copy
../../src/gcc/cp/pt.c:15301
0x6ce257 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18843
0x6cf567 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17782
0x6cf640 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18630
0x6c1641 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:17412
0x6c4a04 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16584
0x6c4a04 tsubst_decl
../../src/gcc/cp/pt.c:13723
0x6bcdf7 tsubst_copy
../../src/gcc/cp/pt.c:15431
0x6ce257 tsubst_copy
../../src/gcc/cp/pt.c:15301
0x6ce257 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18843
0x6cf567 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17782
0x6d0c69 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:17553
0x6ce2df tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18923
0x6ce8f6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:18248
0x6c1641 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:17412
0x6c1425 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16613
0x6c0cc8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16599
0x6c0bab tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16896
0x6c1ffb tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../src/gcc/cp/pt.c:16866


I tried to cut the test case down as much as possible, but even seemingly
unrelated changes make the bug disappear. For example, try replacing YESSIR
with true.

First seen on g++-8 (Ubuntu 8.1.0-1ubuntu1) 8.1.0, but reproduced with svn
revision 263064. Command line is 'g++-8 -std=c++17 gccice.cpp'. Clang compiles
the file.

There is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67411, which looks
somewhat similar, but the bug described there is already fixed.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely  ---
(In reply to Steinar H. Gunderson from comment #19)
> Thanks for confirming; so GCC is absolutely right here, it's the standard
> that makes a choice with surprising ramifications (to me, at least). I

Yes. GCC could choose not to warn about that deprecation, but the whole point
of this bug report is that somebody was asking for GCC to do exactly that.

> wonder if I should try to ask someone in the standards committee to make an
> exception for pure virtual destructors...

I've heard worse ideas. The whole topic of deprecating those members is already
a bit contentious.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
P.S. it's arguable whether abstract base classes should be copyable in the
first place:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-copy-virtual
https://github.com/isocpp/CppCoreGuidelines/issues/1151

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The code is well-formed according to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#106 but that
doesn't seem to be implemented in GCC 4.1.2

template
struct X {
X(T&) { }
};

X f(int& i)
{
return X(i);
}

: In instantiation of 'X':
:6:   instantiated from here
:3: error: forming reference to reference type 'int&'

[Bug bootstrap/86739] [9 Regression] Bootstrap broken with host GCC 4.1.2

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
See PR 7412

"Fixed on mainline for GCC 4.3.0. DR 106 is implemented for C++0x mode and for
non-strict C++98 mode."

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[steinar+gcc at gunderson dot no]

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

--- Comment #22 from Steinar H. Gunderson  ---
C.67 would seem only to apply to non-abstract base classes, no? The code
doesn't compile if B has pure virtual member functions. (Well, it doesn't
compile as-is already, but change (d) to (*d) and it does.)

[Bug c/86721] use of undeclared identifier

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
GCC accepts C++ raw strings as an extension in -std=gnu* modes for C.  Use
standards conformance modes if you want it rejected for C (and, in general,
please try conformance modes, -pedantic etc. yourself to establish whether an
extension is involved before reporting a bug simply because of behaving
differently to another compiler).

[Bug tree-optimization/86741] New: [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[jsm28 at gcc dot gnu.org]

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

Bug ID: 86741
   Summary: [9 Regression] ICE in vrp_prop::check_mem_ref building
glibc for i686-gnu
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44468&action=edit
Preprocessed source from building glibc

The following ICE was introduced by r262893.

r262893 | msebor | 2018-07-19 23:36:34 + (Thu, 19 Jul 2018) | 20 lines

PR tree-optimization/84047
PR tree-optimization/83776
* tree-vrp.c (vrp_prop::check_mem_ref): New function.
(check_array_bounds): Call it.

It appears building glibc for i686-gnu, but can also be reproduced using the
same .i file with an x86_64-linux-gnu compiler with -m32.

Compile the attached .i file (for i686-gnu / i686-pc-linux-gnu /
x86_64-linux-gnu -m32) with -O2 -Warray-bounds (or -O2 -Wall).

during GIMPLE pass: vrp
../sysdeps/mach/hurd/i386/init-first.c: In function 'init1':
../sysdeps/mach/hurd/i386/init-first.c:97:1: internal compiler error:
Segmentation fault
0xc11d2f crash_signal
/scratch/jmyers/glibc/many9/src/gcc/gcc/toplev.c:325
0x77c1b7 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.h:3483
0x77c1b7 wi::extended_tree<128>::extended_tree(tree_node const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.h:5535
0xed25aa generic_wide_int >::generic_wide_int(tree_node const* const&)
/scratch/jmyers/glibc/many9/src/gcc/gcc/wide-int.h:780
0xed25aa wi::to_offset(tree_node const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.h:5487
0xed25aa vrp_prop::check_mem_ref(unsigned int, tree_node*, bool)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:5097
0xed3281 check_array_bounds
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:5267
0xf00932 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 >*))
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.c:11485
0xf00ea6 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 >*))
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.c:11803
0x95dfe0 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/gimple-walk.c:203
0xebbedc check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:5320
0x138b77a dom_walker::walk(basic_block_def*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/domwalk.c:353
0xec04bc vrp_prop::check_all_array_refs()
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:5337
0xec2f59 vrp_prop::vrp_finalize(bool)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:7113
0xed3c71 execute_vrp
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-vrp.c:7186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #6 from H.J. Lu  ---
This is caused by r257505.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Tom de Vries  ---
patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01850.html

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
#4  0x01250010 in vrp_prop::check_mem_ref (this=0x7fffced0,
location=102528417, ref=
, ignore_off_by_one=false) at
/home/marek/src/gcc/gcc/tree-vrp.c:5097
5097  arrbounds[1] = wi::to_offset (TYPE_SIZE_UNIT (reftype));

here reftype is "const void" so taking its size is wrong.

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
So I think this ought to fix it:

--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -5051,7 +5051,8 @@ vrp_prop::check_mem_ref (location_t location, tree ref,
bool ignore_off_by_one)
  to identify the member where the reference originated.  */
   tree reftype = TREE_TYPE (arg);
   if (POINTER_TYPE_P (reftype)
-  || RECORD_OR_UNION_TYPE_P (reftype))
+  || RECORD_OR_UNION_TYPE_P (reftype)
+  || VOID_TYPE_P (reftype))
 return;

   offset_int eltsize;

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Reduced:

struct S
{
  int s;
};

void fn2 (void);

void
fn1 ()
{
  extern void a;
  struct S *b = &a;
  if (b->s)
fn2 ();
}

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[gcc at ryandesign dot com]

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

Ryan Schmidt  changed:

   What|Removed |Added

 CC||gcc at ryandesign dot com

--- Comment #6 from Ryan Schmidt  ---
I can confirm the "DEF_INTERNAL_FLT_FN (...) has no associated built-in
functions" errors when building gcc 8.2.0 with Apple gcc 4.2.1 from Xcode 3.1.4
on PowerPC Mac OS X 10.5.8.

[Bug rtl-optimization/85160] GCC generates mvn/and instructions instead of bic on aarch64

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Author: segher
Date: Mon Jul 30 16:11:44 2018
New Revision: 263072

URL: https://gcc.gnu.org/viewcvs?rev=263072&root=gcc&view=rev
Log:
testcase for 2-2 combine


gcc/testsuite/
PR rtl-optimization/85160
* gcc.target/powerpc/combine-2-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/combine-2-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/86742] New: Documented function std::to_chars(char* first, char* last, double value) is not implemented

[j.wink...@fu-berlin.de]

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

Bug ID: 86742
   Summary: Documented function std::to_chars(char* first, char*
last, double value) is not implemented
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.wink...@fu-berlin.de
  Target Milestone: ---

In cppreference (https://en.cppreference.com/w/cpp/utility/to_chars) there is a
function std::to_chars documented that should work also for floating point
types. 

If I modify the given example to pass a double 42.0 instead of int 42 to the
function, the compiler gives the following error, contradicting the
documentation: 

g++-8 -std=c++17 examplefile.cpp

error: no matching function for call to 'to_chars(std::array::pointer, std::array::pointer, double)'
 if(auto [p, ec] = std::to_chars(str.data(), str.data() + str.size(),
42.0);

[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I didn't overlook anything.  I replied and explained what happens here:

  https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01272.html

Since the undefined behavior in this case is at compile time, rejecting the
code should be a valid/conforming response.  IMO, either issuing an error or
truncating it would be preferable to trying to deal with it in the middle-end. 
I think we've already agreed on the latter approach in the discussion of
another bug.  Rejecting it would be even better.

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Eric Gallager  ---
(In reply to Ryan Schmidt from comment #6)
> I can confirm the "DEF_INTERNAL_FLT_FN (...) has no associated built-in
> functions" errors when building gcc 8.2.0 with Apple gcc 4.2.1 from Xcode
> 3.1.4 on PowerPC Mac OS X 10.5.8.

ok, changing status to NEW then

[Bug c/79010] -Wlarger-than ineffective for VLAs, alloca, malloc

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
There was a change to how some of the larger-than warnings are controlled (bug
82063) but it hasn't affected this report.  The top of GCC 9 trunk still issues
the same warnings:

$ gcc -O2 -S -Wall -DN=123456 -S -Wall -Wextra -Wpedantic  -Wlarger-than=123
e.c
e.c:3:6: warning: size of ‘a’ 123456 bytes exceeds maximum object size 123
[-Wlarger-than=]
 char a[N];
  ^
e.c: In function ‘farray’:
e.c:7:8: warning: size of ‘a’ 123456 bytes exceeds maximum object size 123
[-Wlarger-than=]
   char a[N];
^
e.c: In function ‘funnamed_array’:
e.c:13:18: warning: size of ‘({anonymous})’ 123456 bytes exceeds maximum object
size 123 [-Wlarger-than=]
   sink ((char[N]){ 0 });
  ^
e.c:13:18: warning: size of ‘({anonymous})’ 123456 bytes exceeds maximum object
size 123 [-Wlarger-than=]


Alloca and VLA sizes are controlled by the -Walloca-larger-than= and
-Wvla-larger-than= options (new in GCC 7).  If it's thought to be useful to
exclude them from -Wlarger-than= the manual should be updated to make that
clear.

gcc -O2 -S -Wall -DN=123456 -S -Wall -Wextra -Wpedantic  -Wlarger-than=123
-Walloca-larger-than=123 -Wvla-larger-than=123 e.c
e.c:3:6: warning: size of ‘a’ 123456 bytes exceeds maximum object size 123
[-Wlarger-than=]
 char a[N];
  ^
e.c: In function ‘farray’:
e.c:7:8: warning: size of ‘a’ 123456 bytes exceeds maximum object size 123
[-Wlarger-than=]
   char a[N];
^
e.c: In function ‘funnamed_array’:
e.c:13:18: warning: size of ‘({anonymous})’ 123456 bytes exceeds maximum object
size 123 [-Wlarger-than=]
   sink ((char[N]){ 0 });
  ^
e.c:13:18: warning: size of ‘({anonymous})’ 123456 bytes exceeds maximum object
size 123 [-Wlarger-than=]
e.c: In function ‘fvla’:
e.c:19:8: warning: argument to variable-length array is too large
[-Wvla-larger-than=]
   char a[n];
^
e.c:19:8: note: limit is 123 bytes, but argument is 123456
e.c: In function ‘falloca’:
e.c:25:13: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   void *a = __builtin_alloca (N);
 ^~~~
e.c:25:13: note: limit is 123 bytes, but argument is 123456

gcc-bugs@gcc.gnu.org

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Mon Jul 30 17:13:05 2018
New Revision: 263074

URL: https://gcc.gnu.org/viewcvs?rev=263074&root=gcc&view=rev
Log:
PR libstdc++/86734 make reverse_iterator::operator-> more robust

Implement the proposed resolution from LWG 1052, which also resolves
DR 2118 by avoiding taking the address in the first place.

PR libstdc++/86734
* include/bits/stl_iterator.h (reverse_iterator::operator->): Call
_S_to_pointer (LWG 1052, LWG 2118).
(reverse_iterator::_S_to_pointer): Define overloaded helper functions.
* testsuite/24_iterators/reverse_iterator/dr1052.cc: New test.
* testsuite/24_iterators/reverse_iterator/dr2188.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/dr1052.cc
trunk/libstdc++-v3/testsuite/24_iterators/reverse_iterator/dr2188.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_iterator.h

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #39 from janus at gcc dot gnu.org ---
(In reply to uros from comment #37)
> Author: uros
> Date: Thu Feb  8 22:31:15 2018
> New Revision: 257505
> 
> URL: https://gcc.gnu.org/viewcvs?rev=257505&root=gcc&view=rev
> Log:
>   PR target/83008
>   * config/i386/x86-tune-costs.h (skylake_cost): Fix cost of
>   storing integer register in SImode.  Fix cost of 256 and 512
>   byte aligned SSE register store.
> 
>   * config/i386/i386.c (ix86_multiplication_cost): Fix
>   multiplication cost for TARGET_AVX512DQ.

This caused PR 86735.

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #15 from Martin Sebor  ---
Testing a patch for the constant case:

  const char a[] = { 'a', 'b', 'c', 0 };

  int f (void)
  {
return __builtin_strlen (a);
  }

[Bug target/86640] [8/9 regression] ICE in combine

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Author: segher
Date: Mon Jul 30 17:50:26 2018
New Revision: 263075

URL: https://gcc.gnu.org/viewcvs?rev=263075&root=gcc&view=rev
Log:
arm: Generate correct const_ints (PR86640)

In arm_block_set_aligned_vect 8-bit constants are generated as zero-
extended const_ints, not sign-extended as required.  Fix that.


PR target/86640
* config/arm/arm.c (arm_block_set_aligned_vect): Use gen_int_mode
instead of GEN_INT.

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

[Bug rtl-optimization/86685] [8/9 Regression] 436.cactusADM regression on aarch64

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-07-30
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from James Greenhalgh  ---
On the platforms I'm looking at, this is equal to a 13% regression in dynamic
instruction count, and a code size regression in the key loop. Confirmed.

[Bug c++/86743] New: Compilation failure when initializing POD structs containing constant member

[ldr709 at gmail dot com]

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

Bug ID: 86743
   Summary: Compilation failure when initializing POD structs
containing constant member
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldr709 at gmail dot com
  Target Milestone: ---

With this code: 

struct A
{
int i;
const int b;
};

// The union is to verify that A is a type that can be used in a union.
union U
{
A a;
int b;
};

int main()
{
U a = {1, 1};
U b = {2, 1};
}

I get an error message:

$ g++ -std=c++03
a.cpp:9:4: error: member ‘A U::a’ with copy assignment operator not allowed in
union
  A a;
^
a.cpp:9:4: note: unrestricted unions only available with -std=c++11 or
-std=gnu++11

$ g++ ---version
g++ (GCC) 8.1.1 20180531
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For reasoning about why this should compile without failure, see
https://stackoverflow.com/questions/27665567/pod-structs-containing-constant-member

[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index fc3d6f0aebc..a8709972e9c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -40402,6 +40402,10 @@ ix86_multiplication_cost (const struct processor_costs 
*cost,
   ? cost->mulsd : cost->mulss, true);
   else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
 {
+  /* vpmullq is used in this case. No emulation is needed.  */
+  if (TARGET_AVX512DQ)
+   return ix86_vec_cost (mode, cost->mulss, true);
+
   /* V*QImode is emulated with 7-13 insns.  */
   if (mode == V16QImode || mode == V32QImode)
{

triggered gather coedgen, which may lead to a latent bug.

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Testing a fix.

[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
On linux with 8.2.1 20180729, we have:

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr83480.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -g
-fselective-scheduling2 -ftree-vectorize -freorder-blocks-algorithm=simple
-fnon-call-exceptions -fno-guess-branch-probability -fno-peephole2
-fno-tree-sink -fno-tree-scev-cprop -S -o pr83480.s
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr83480.c: In function 'foo':
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr83480.c:29:6: warning: division
by zero [-Wdiv-by-zero]
during RTL pass: sched2
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr83480.c:32:1: internal compiler
error: in sel_target_adjust_priority, at sel-sched.c:3336
0x629eeb sel_target_adjust_priority
../../gcc/gcc/sel-sched.c:3336
0x629eeb fill_vec_av_set
../../gcc/gcc/sel-sched.c:3727
0x62b6cf fill_ready_list
../../gcc/gcc/sel-sched.c:4028
0x62b6cf find_best_expr
../../gcc/gcc/sel-sched.c:4388
0x62b6cf fill_insns
../../gcc/gcc/sel-sched.c:5549
0x62b6cf schedule_on_fences
../../gcc/gcc/sel-sched.c:7366
0x62b6cf sel_sched_region_2
../../gcc/gcc/sel-sched.c:7504
0x62db87 sel_sched_region_1
../../gcc/gcc/sel-sched.c:7546
0x62f777 sel_sched_region(int)
../../gcc/gcc/sel-sched.c:7647
0x630333 run_selective_scheduling()
../../gcc/gcc/sel-sched.c:7733
0x60e42f rest_of_handle_sched2
../../gcc/gcc/sched-rgn.c:3732
0x60e42f execute
../../gcc/gcc/sched-rgn.c:3876

[Bug tree-optimization/86741] [9 Regression] ICE in vrp_prop::check_mem_ref building glibc for i686-gnu

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Martin Sebor  ---
Thanks for reducing it to a small test case!

I posted the following patch for review:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01876.html

[Bug target/86744] New: gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86

[ro at gcc dot gnu.org]

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

Bug ID: 86744
   Summary: gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

Between 20180729 (r263050) and 20180730 (r263069), gcc.target/i386/addr-sel-1.c
started to XPASS on 32-bit x86.  Originally seen on Solaris/x86, also reports
for Linux/i686 and FreeBSD/i586.

[Bug target/86744] gcc.target/i386/addr-sel-1.c XPASSes on 32-bit x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/86745] New: [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86

[ro at gcc dot gnu.org]

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

Bug ID: 86745
   Summary: [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL
on 64-bit x86
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*, x86_64-*-*

Between 20180729 (r263050) and 20180730 (r263069), two tests started to XFAIL
on 64-bit x86:

+FAIL: gcc.target/i386/avx-cvt-2.c scan-assembler
vcvtps2pd[^\\n\\r]*(%xmm[^\\n\\r]*%ymm|ymm[^\\n\\r]*xmm)
+FAIL: gcc.target/i386/avx2-cvt-2.c scan-assembler
vcvtps2pd[^\\n\\r]*(%xmm[^\\n\\r]*%ymm|ymm[^\\n\\r]*xmm)

Initially seen on Solaris/x86, also reported on Linux/x86_64.

[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/85458] FAIL: gcc.dg/pr83480.c (internal compiler error)

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
The ICE occurs because pa_adjust_priority reduces priority from 1 to 0.

The documentations for TARGET_SCHED_ADJUST_PRIORITY states:

@deftypefn {Target Hook} int TARGET_SCHED_ADJUST_PRIORITY (rtx_insn
*@var{insn}, int @var{priority})
This hook adjusts the integer scheduling priority @var{priority} of
@var{insn}.  It should return the new priority.  Increase the priority to
execute @var{insn} earlier, reduce the priority to execute @var{insn}
later.  Do not define this hook if you do not need to adjust the
scheduling priorities of insns.
@end deftypefn

However, the assert in sel_target_adjust_priority only allows for an increase
in priority:

sel_target_adjust_priority (expr_t expr)
{
  int priority = EXPR_PRIORITY (expr);
  int new_priority;

  if (targetm.sched.adjust_priority)
new_priority = targetm.sched.adjust_priority (EXPR_INSN_RTX (expr),
priority);
  else
new_priority = priority;

  /* If the priority has changed, adjust EXPR_PRIORITY_ADJ accordingly.  */
  EXPR_PRIORITY_ADJ (expr) = new_priority - EXPR_PRIORITY (expr);

  gcc_assert (EXPR_PRIORITY_ADJ (expr) >= 0);

My first guess would be is that the assert is wrong.