[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default

2018-02-10 Thread sherpya at netfarm dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148

Gianluigi Tiesi  changed:

   What|Removed |Added

 CC||sherpya at netfarm dot it

--- Comment #3 from Gianluigi Tiesi  ---
I get illegal instruction on a AMD GEODE (something like i586):

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 5
model   : 10
model name  : Geode(TM) Integrated Processor by AMD PCS
stepping: 2
cpu MHz : 498.044
cache size  : 128 KB
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext
3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs: sysret_ss_attrs spectre_v1 spectre_v2
bogomips: 996.08
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


simple testcase:
__asm volatile("endbr32");

[Bug ada/84320] New: Program_Error exp_util.adb:4352 explicit raise related to lock-free protected type

2018-02-10 Thread matsilvabustos at abc dot gob.ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84320

Bug ID: 84320
   Summary: Program_Error exp_util.adb:4352 explicit raise related
to lock-free protected type
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matsilvabustos at abc dot gob.ar
  Target Milestone: ---

Created attachment 43390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43390=edit
main.adb

GNAT will raise Program_Error exp_util.adb:4352 by the combination of these
three declarations:

- a protected type declaration with Lock_Free aspect set to True
- subtyping that protected type
- declaring a record field of this subtype

Attached main.adb.

[mat@localhost src]$ LC_ALL=posix gcc -c main.adb  -Wall -Wextra -gnatd.n -v
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-Wall' '-Wextra' '-gnatd.n' '-v' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/7/gnat1 -gnatwa -quiet -dumpbase main.adb
-auxbase main -Wall -Wextra -gnatd.n -mtune=generic -march=x86-64 main.adb -o
/tmp/ccS0v9B8.s
/usr/lib/gcc/x86_64-redhat-linux/7/adainclude/system.ads
main.adb
+===GNAT BUG DETECTED==+
| 7.2.1 20170915 (Red Hat 7.2.1-2) (x86_64-redhat-linux) Program_Error
exp_util.adb:4352 explicit raise|
| Error detected at main.adb:29:4  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

main.adb

compilation abandoned

[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic

2018-02-10 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|RESOLVED|NEW
 CC||pault at gcc dot gnu.org
 Resolution|DUPLICATE   |---

--- Comment #4 from Dominique d'Humieres  ---
This PR is not fixed by revision r257550, thus is not an exact duplicate of
pr56691.

[Bug c++/84289] warning: variable uninitialized, emit right check only with O(1,2,3) optimisation level (in try/catch)

2018-02-10 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|warning : variabile |warning: variable
   |unitialized, emit right |uninitialized, emit right
   |check only with O(1,2,3)|check only with O(1,2,3)
   |optimisation level (in  |optimisation level (in
   |try/catch)  |try/catch)

--- Comment #3 from Eric Gallager  ---
(In reply to claudio daffra from comment #2)
> yes, but people expects g++ emit warning , Independent from optimisation
> level , referring others simlar bug . can you fix ?

Once the other similar bug is fixed, this one will be fixed, too. 
(I'm just here to fix the title so it shows up when searching)

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

2018-02-10 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089

--- Comment #9 from John David Anglin  ---
Author: danglin
Date: Sat Feb 10 20:04:59 2018
New Revision: 257553

URL: https://gcc.gnu.org/viewcvs?rev=257553=gcc=rev
Log:
Backport from mainline
2018-02-01  Aldy Hernandez  

PR target/84089
* config/pa/predicates.md (base14_operand): Handle VOIDmode.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/pa/predicates.md

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

2018-02-10 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089

--- Comment #8 from John David Anglin  ---
Author: danglin
Date: Sat Feb 10 19:55:06 2018
New Revision: 257552

URL: https://gcc.gnu.org/viewcvs?rev=257552=gcc=rev
Log:
Backport from mainline
2018-02-01  Aldy Hernandez  

PR target/84089
* config/pa/predicates.md (base14_operand): Handle VOIDmode.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/pa/predicates.md

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #12 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report, Marco.

Paul

[Bug fortran/84155] [8 Regression] program hangs on valid code

2018-02-10 Thread juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155

--- Comment #22 from Jürgen Reuter  ---
I just started building r257550 of the trunk and will check our code. I'll
report back of there are any issues.

[Bug fortran/84155] [8 Regression] program hangs on valid code

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #21 from Paul Thomas  ---
Refixed following comment #18, for which thanks.

Although I retained the caching of the dtype in GFC_TYPE_ARRAY_DTYPE, I checked
that it is not used anywhere. I will try removing it altogether in the near
future.

Paul

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
Bug 84141 depends on bug 84155, which changed state.

Bug 84155 Summary: [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155

   What|Removed |Added

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

[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code

2018-02-10 Thread wdijkstr at arm dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114

--- Comment #3 from Wilco  ---
(In reply to Richard Biener from comment #1)
> This is probably related to targetm.sched.reassociation_width where reassoc
> will widen a PLUS chain so several instructions will be executable in
> parallel
> without dependences.  Thus, (x + (y + (z + w))) -> (x + y) + (z + w).  When
> all of them are fed by multiplications this goes from four fmas to two.
> 
> It's basically a target request we honor so it works as designed.
> 
> At some point I thought about integrating FMA detection with reassociation.

It should understand FMA indeed, A*B + p[0] + C*D + p[1] + E*F + p[2] can
become(((p[0] + p[1] + p[2]) + A*B) + C*D) + E*F. 

Also we're missing a reassociation depth parameter. You need to be able to
specify how long a chain needs to be before it is worth splitting - the example
shows a chain of 5 FMAs is not worth splitting since FMA latency on modern
cores is low, but if these were integer operations (not MADD) then the chain
should be split.

[Bug fortran/84155] [8 Regression] program hangs on valid code

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155

--- Comment #20 from Paul Thomas  ---
Author: pault
Date: Sat Feb 10 18:16:14 2018
New Revision: 257550

URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev
Log:
2018-02-10  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Revert the change made
in revision 257356 setting the dtype.
* trans-types.c (gfc_get_dtype): Do not use the cached dtype.
Call gfc_get_dtype_rank_type every time.

PR fortran/56691
* trans-array.c (gfc_conv_expr_descriptor): If the source array
is a descriptor type, use its offset, removing the condition
that is be a class expression.

2018-02-10  Paul Thomas  

PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141

--- Comment #38 from Paul Thomas  ---
Author: pault
Date: Sat Feb 10 18:16:14 2018
New Revision: 257550

URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev
Log:
2018-02-10  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Revert the change made
in revision 257356 setting the dtype.
* trans-types.c (gfc_get_dtype): Do not use the cached dtype.
Call gfc_get_dtype_rank_type every time.

PR fortran/56691
* trans-array.c (gfc_conv_expr_descriptor): If the source array
is a descriptor type, use its offset, removing the condition
that is be a class expression.

2018-02-10  Paul Thomas  

PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Sat Feb 10 18:16:14 2018
New Revision: 257550

URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev
Log:
2018-02-10  Paul Thomas  

PR fortran/84141
PR fortran/84155
* trans-array.c (gfc_array_init_size): Revert the change made
in revision 257356 setting the dtype.
* trans-types.c (gfc_get_dtype): Do not use the cached dtype.
Call gfc_get_dtype_rank_type every time.

PR fortran/56691
* trans-array.c (gfc_conv_expr_descriptor): If the source array
is a descriptor type, use its offset, removing the condition
that is be a class expression.

2018-02-10  Paul Thomas  

PR fortran/56691
* gfortran.dg/type_to_class_4.f03: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/84219] [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
I had better take it.

Paul

[Bug fortran/84244] [7/8 Regression] ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535

2018-02-10 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84244

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. Revision r243909 (2016-12-23) compiles, r244868 (2017-01-24)
> gives the ICE.

Andre made a number of coarray commits between those dates.

Paul

[Bug sanitizer/83987] [6/7 Regression] ICE with OpenMP, sanitizer and virtual bases

2018-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83987

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with
   |OpenMP, sanitizer and   |OpenMP, sanitizer and
   |virtual bases   |virtual bases

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/84308] [7 Regression] Memory leak in spread_components

2018-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84308

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[7/8 Regression] Memory |[7 Regression] Memory leak
   |leak in spread_components   |in spread_components

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug ada/83892] Various ICEs and link-errors with running ACATS with -O2 -g -flto

2018-02-10 Thread simon at pushface dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83892

--- Comment #7 from simon at pushface dot org ---
(In reply to rguent...@suse.de from comment #5)

> It would be nice if acats could honor dejagnu RUNTESTFLAGS.  That is,
> I regularly do
> 
> make check RUNTESTFLAGS="--target_board=unix/-g"
> 
> and that should append -g to all flags used.  That might need a "simple"
> acats.exp to wrap the run_acats/all.sh scripts.  Currently acats seems
> to be invoked via check-acats in gcc/ada/gcc-interface/Make-lang.in

I have a patch to do this, but 
(a) I’ve just seen that you said "append", 
(b) if the added switches include -gnat, you’d need to make sure
you only ran "make check-acats" - -g looks like a debug 
option
(c) RUNTESTFLAGS doesn’t get transmitted to the sub-makes in the
check-acats target if you 'make -j'

[Bug fortran/84276] Invalid error for valid statement function

2018-02-10 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276

--- Comment #14 from Steve Kargl  ---
On Sat, Feb 10, 2018 at 02:20:20AM +, mecej4 at outlook dot com wrote:
> 
> Will keyword arguments in statement function references be retained as a GNU
> extension?
> 

The extension will remain, but I intend to hope a new bug
report about the issue.

[Bug debug/84319] [8 regression] Location views break bootstrap with Solaris/SPARC as

2018-02-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84319

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug debug/84319] New: [8 regression] Location views break bootstrap with Solaris/SPARC as

2018-02-10 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84319

Bug ID: 84319
   Summary: [8 regression] Location views break bootstrap with
Solaris/SPARC as
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.*
Target: sparc-sun-solaris2.*
 Build: sparc-sun-solaris2.*

The location views patch breaks bootstrap on Solaris/SPARC with the native as.

The picture is a bit complicated because some builds fail earlier due to the
SEGV
described in PR debug/84317.  Here's the overview:

as/ld   gas/ld  gas/gld as/ld-64 gas/ld-64

  s10   segvsegvsegvdiff ok
  s11   diffsegvsegvdiff ok
  s11.4 ok  ok  ok  diff ???

(s11 is Solaris 11.3, s11.4 is Solaris 11.4 Beta)

The `diff' cases fail like this (e.g. compiling the 64-bit
libstdc++-v3/src/c++11/iostream-inst.cc) with -fPIC:

/usr/ccs/bin/as: "iostream-inst.s", line 26808: error: can't compute difference
between symbols in different segments

.uahalf .LLM93-.LLM92

  .LLM93:
.text._ZNSt14basic_iostreamIwSt11char_traitsIwEED1Ev%_ZNSt14basic_iostreamIwSt11char_traitsIwEED1Ev
  .LLM92:
.text._ZNSt14basic_iostreamIwSt11char_traitsIwEED0Ev%_ZNSt14basic_iostreamIwSt11char_traitsIwEED0Ev

/usr/ccs/bin/as: "iostream-inst.s", line 26813: error: can't compute difference
between symbols in different segments

.uahalf .LLM94-.LLM93

  .LLM94: .text._ZNSdD1Ev%_ZNSdD1Ev

  with -dA:

/usr/ccs/bin/as: "iostream-inst.s", line 30361: error: can't compute difference
between symbols in different segments

.uaxword.LLM92
.byte   0x1 ! copy line 856
.byte   0x5 ! column 27
.byte   0x1b! uleb128 0x1b; 27
.byte   0x9 ! fixed advance PC, increment view to 1
.uahalf .LLM93-.LLM92   ! from *.LLM92 to *.LLM93

The last line is from dwarf2out.c (output_one_line_info_table) using
dw2_asm_output_delta, which has a fat comment about targets that cannot compute
the difference between symbols in different sections.

Adding -gno-variable-location-views to the compilation makes it succeed.

  Rainer
The last line is from

[Bug c++/84289] warning : variabile unitialized, emit right check only with O(1,2,3) optimisation level (in try/catch)

2018-02-10 Thread daffra.claudio at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289

--- Comment #2 from claudio daffra  ---
yes, but people expects g++ emit warning , Independent from optimisation
level , referring others simlar bug . can you fix ?

Il 09 feb 2018 00:09, "manu at gcc dot gnu.org" 
ha scritto:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289
>
> Manuel López-Ibáñez  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |RESOLVED
>  CC||manu at gcc dot gnu.org
>  Resolution|--- |DUPLICATE
>
> --- Comment #1 from Manuel López-Ibáñez  ---
> The try-catch creates:
>
>   # n_1 = PHI 
>   # .MEM_2 = PHI <.MEM_4(3), .MEM_12(9)>
>   _15 = n_1;
>
> and PHI is only handled with optimization.
>
> *** This bug has been marked as a duplicate of bug 43361 ***
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code

2018-02-10 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263

David Malcolm  changed:

   What|Removed |Added

   Keywords||patch
 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00435.html

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

2018-02-10 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83372

--- Comment #16 from David Malcolm  ---
(In reply to David Malcolm from comment #15)
> Alan: are you able to test Nathan's bug to see if it fixes the issue for you?
  ^^^
  patch, I meant to say

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

2018-02-10 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83372

David Malcolm  changed:

   What|Removed |Added

   Keywords||GC, ice-on-valid-code,
   ||needs-bisection,
   ||needs-reduction, patch
 Status|ASSIGNED|WAITING
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84263
Summary|Compiler segfaults building |ICE in GC within
   |Mir |gt_ggc_mx building Mir

--- Comment #15 from David Malcolm  ---
I tried Nathan's patch from here:
  [PR c++/84263] GC ICE with decltype
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00435.html

With the patch, it successfully compiles the file.

Without the patch: it ICEs, with corrupted memory in the buffer pointer to by
"checks":

(gdb) p *x
$10 = {value = 0x7ffe4295b7e0, checks = 0x7ffe425ca6c0, qualifying_scope = 0x0}

(gdb) p *x->checks
$14 = {m_vecpfx = {m_alloc = 1919901535, m_using_auto_storage = 0, m_num =
1953709151}, m_vecdata = {{binfo = 0x75665f73693a3a64, 
  decl = 0x763c6e6f6974636e, diag_decl = 0x26262a282064696f, loc =
1803036713}}}

(gdb) call debug(x->value)

full-name "class std::unique_ptr"
needs-constructor needs-destructor X() has-type-conversion X(constX&)
this=(X&) n_parents=0 use_template=1 interface-unknown

(gdb) call inform (x->location, "token is here")
/builddir/build/BUILD/mir-5500595810c28c150a3bd9edf19b392c2aeab932/src/server/frontend/wayland/wayland_connector.cpp:980:17:
note: token is here

Hence it looks like this is a duplicate of PR c++/84263 (but hard to be sure
without properly reducing it).

Nathan: does this look like a duplicate to you?  Any ideas on how to reduce the
reproducer?  (the ~1hr time to hit the bug when forcing GC is making this
awkward).

Alan: are you able to test Nathan's bug to see if it fixes the issue for you?

Thanks.

[Bug target/84077] [7/8 Regression] Likely wrong code with `__builtin_expect()` on i686-linux-gnu

2018-02-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Besides inline asm barriers another option is volatile {float,double} vars in
certain spots (to ensure rounding to {float,double} where required).  And
again, you don't need to do anything if FLT_EVAL_METHOD is 0, or for double
computations also if FLT_EVAL_METHOD is 1.

[Bug target/84077] [7/8 Regression] Likely wrong code with `__builtin_expect()` on i686-linux-gnu

2018-02-10 Thread floessie.mail at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077

--- Comment #13 from Flössie  ---
Thanks for the thorough analysis. We'll discuss in our team how to cope with
it.

Best regards,
Flössie