date:20181102

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #7)

> It's not clear to me what you would have liked it to do instead?

The loads from constant memory pools always have REG_EQUAL of a relevant
constant attached to the instruction. As seen from Comment #3, combine first
tries to combine memory reference to a constant pool with the plus operation,
but fails the combination, since subst simplifies the load from constant pool
to an immediate constant. Later, combine retries the combination with the
REG_EQUAL from the load, which again results in the same immediate, and again
fails.

I would like to propose that combine handles constant pool memory references in
a different way. In the second try, it shouldn't just substitute REG_EQUAL
(since avoid_costant_pool_reference will return the same immediate constant
anyway), but should try to combine memory reference itself. This way, combine
will return combined instruction with a memory reference to a constant pool,
which is valid instruction in the x86 case.

So, tl;dr version reduces to - how to convice combine to return combined
instruction that refers to a constant pool in the second try instead of the
same invalid combined instruction with an immediate constant.

[Bug c/83656] missing -Wbuiltin-declaration-mismatch on declaration without prototype

2018-11-02 Thread msebor at gcc dot gnu.org

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

--- Comment #5 from Martin Sebor  ---
Revised patch that should resolve the autoconf concerns:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00120.html

[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

2018-11-02 Thread marco_atzeri at yahoo dot it

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

--- Comment #7 from marco atzeri  ---
I am trying to update the draft patch of Tobias to gcc-7.3.0
the current gcc on cygwin.

The attached patch builds but does not solve the problem of

 !GCC$ attributes dllexport :: /mydata/
   1
Error: Invalid character in name at (1)

nor 

 !GCC$ attributes dllexport :: mydata
1
Warning: Unused variable ‘mydata’ declared at (1) [-Wunused-variable]


I see two possibilities:

1) the original path was missing the portion of interpreting "/mydata/" as
   valid symbol

2) my guess of "com->head->attr" for original "common_sym->attr" is wrong

and eventually both applies.

Any suggestion for solving "Error: Invalid character in name at (1)" ?

[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

2018-11-02 Thread marco_atzeri at yahoo dot it

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

--- Comment #6 from marco atzeri  ---
Created attachment 44949
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44949=edit
updated patch for 7.3.0

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

2018-11-02 Thread ibuclaw at gdcproject dot org

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

--- Comment #3 from Iain Buclaw  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw  ---
> > This is part of the dmd frontend which as no interaction with gcc.  So
> > gcc_unreachable() can't be used here.
> 
> I see.  However, if upstream dmc were built with similar warning options
> than gcc, the problem would exist there as well.
> 
> > Sounds like some independent compatibility layer is required here instead.
> 
> That's certainly an option.  Among others, what to do here depends on
> how prevalent the problem is: if Solaris 10 is the only OS affected and
> the other pre-Solaris 11.4 issues (especially PR d/87865) cannot be
> resolved for the GCC 9 release, one might as well close the bug as
> WONTFIX given Solaris 10 is obsoleted in GCC 9.

This would even be automatically fixed in GCC 10, where I intend on swapping
the frontend C++ sources with D, where assert() is a built-in contract and the
false branch is treated as __noreturn__.

But until then, this is a bootstrap problem if GCC 9 is to be used to build GCC
10 on Solaris.

[Bug c/87869] Unrolled loop leads to excessive code bloat with -Os on ARC EM.

2018-11-02 Thread nbowler at draconx dot ca

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

--- Comment #1 from Nick Bowler  ---
Er, I can't count, the unrolled loop is only ~four times the size.

[Bug c/87869] New: Unrolled loop leads to excessive code bloat with -Os on ARC EM.

2018-11-02 Thread nbowler at draconx dot ca

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

Bug ID: 87869
   Summary: Unrolled loop leads to excessive code bloat with -Os
on ARC EM.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nbowler at draconx dot ca
  Target Milestone: ---

Consider the following code:

  % cat >test.c <<'EOF'
  #include 

  void do_stuff_12iter(void)
  {
 volatile uint32_t *blah = (void *)0xf000;
 unsigned i;

 for (i = 0; i < 12; i++) {
blah[i] = 3;
 }
  }

  void do_stuff_11iter(void)
  {
 volatile uint32_t *blah = (void *)0xf000;
 unsigned i;

 for (i = 0; i < 11; i++) {
blah[i] = 3;
 }
  }
EOF

When I compile this with gcc:

  % arc-unknown-elf-gcc -v
  Using built-in specs.
 
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arc-unknown-elf/gcc-bin/8.2.0/arc-unknown-elf-gcc
  COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arc-unknown-elf/8.2.0/lto-wrapper
  Target: arc-unknown-elf
  Configured with:
/var/tmp/portage/cross-arc-unknown-elf/gcc-8.2.0-r3/work/gcc-8.2.0/configure
--host=x86_64-pc-linux-gnu --target=arc-unknown-elf --build=x86_64-pc-linux-gnu
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arc-unknown-elf/gcc-bin/8.2.0
--includedir=/usr/lib/gcc/arc-unknown-elf/8.2.0/include
--datadir=/usr/share/gcc-data/arc-unknown-elf/8.2.0
--mandir=/usr/share/gcc-data/arc-unknown-elf/8.2.0/man
--infodir=/usr/share/gcc-data/arc-unknown-elf/8.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/arc-unknown-elf/8.2.0/include/g++-v8
--with-python-dir=/share/gcc-data/arc-unknown-elf/8.2.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 8.2.0-r3' --disable-esp --enable-libstdcxx-time
--enable-poison-system-directories --disable-libstdcxx-time
--with-sysroot=/usr/arc-unknown-elf --disable-bootstrap --with-newlib
--enable-multilib --disable-altivec --disable-fixed-point --disable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp
  Thread model: single
  gcc version 8.2.0 (Gentoo 8.2.0-r3) 

  % arc-unknown-elf-gcc -c -Os -mcpu=arcem -mno-sdata -mcode-density -mq-class
-mbarrel-shifter -mmpy-option=3 -mswap test.c

The 11-iteration loop gets fully unrolled with pretty horrible results:

0018 :
  18:   730cmov_s   r0,3
  1a:   1e00 7000 f000  st  r0,[0xf000]
  22:   1e00 7000 f000 0004 st  r0,[0xf004]
  2a:   1e00 7000 f000 0008 st  r0,[0xf008]
  32:   1e00 7000 f000 000c st  r0,[0xf00c]
  3a:   1e00 7000 f000 0010 st  r0,[0xf010]
  42:   1e00 7000 f000 0014 st  r0,[0xf014]
  4a:   1e00 7000 f000 0018 st  r0,[0xf018]
  52:   1e00 7000 f000 001c st  r0,[0xf01c]
  5a:   1e00 7000 f000 0020 st  r0,[0xf020]
  62:   1e00 7000 f000 0024 st  r0,[0xf024]
  6a:   1e00 7000 f000 0028 st  r0,[0xf028]
  72:   7ee0j_s [blink]

That's almost five times the size of the 12-iteration one which didn't
get unrolled:

 :
   0:   41c3 f000   mov_s   r1,0xf000
   6:   734cmov_s   r2,3
   8:   d80cmov_s   r0,0xc
   a:   240a 7000   mov lp_count,r0
   e:   20a8 0140   lp  10  ;16 
  12:   1904 0090   st.ab   r2,[r1,4]
  16:   7ee0j_s [blink]

That one's pretty good.  This specific example could be a _tiny_
bit better, because the constant values moved to r2 and r0 could be
immediates in the instructions where those registers are used but
I'm not bothered by that.

Since I requested size optimizations, it would be nice if my code
size didn't get quintupled like this.

[Bug c++/16166] -Weffc++ finer granularity

2018-11-02 Thread egallager at gcc dot gnu.org

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

--- Comment #14 from Eric Gallager  ---
This came up on the gcc-help mailing list here:
https://gcc.gnu.org/ml/gcc-help/2018-11/msg3.html

[Bug c/87868] New: testsuite/c-c++-common/pr60101.c with -O3 and ubsan

2018-11-02 Thread dcb314 at hotmail dot com

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

Bug ID: 87868
   Summary: testsuite/c-c++-common/pr60101.c with -O3 and ubsan
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Compiling -c++-common/pr60101.c from the gcc/testsuite with
flag -O3 on a recent version of ubsan gcc trunk does this:

$ ~/gcc/results.265631.ubsan/bin/gcc -c -g -O3 ./c-c++-common/pr60101.c
../../trunk/gcc/postreload-gcse.c:1174:45: runtime error: signed integer
overflow: 10 * 2304690102552494078 cannot be represented in type 'long int'

Interestingly, no problem with -O2:

$ ~/gcc/results.265631.ubsan/bin/gcc -c -g -O2 ./c-c++-common/pr60101.c
$ 

postreload-gcse.c source code is

  if (ok_count.to_gcov_type ()
  < GCSE_AFTER_RELOAD_CRITICAL_FRACTION * critical_count.to_gcov_type ())
goto cleanup;

and svn blame says

248863hubicka   if (ok_count.to_gcov_type ()
248863hubicka   < GCSE_AFTER_RELOAD_CRITICAL_FRACTION *
critical_count.to_gcov_type ())

[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers

2018-11-02 Thread mgulick at mathworks dot com

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

--- Comment #11 from Mike Gulick  ---
(In reply to Mike Gulick from comment #10)
> In hopes of seeing some progress on this bug, I will rebase the patches on
> the latest gcc master branch and re-test.  I will also refactor the main
> patch to separate out the functional fix from the diagnostics change, which
> will hopefully make reviewing easier.  I'll reply here with a link to the
> gcc-patches archive once I have posted them.

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00025.html

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2018-11-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Buclaw  ---
> Is there another way to get a section in earlier versions of Solaris?

What I initially did in LLVM's compiler-rt (which prompted the addition
of __start_SEC/__stop_SEC support to ld) was to add two startup files to
define the necessary labels and link the __start_SEC one early, the
__stop_SEC one late:

http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/

See sancov_begin.S and sancov_end.S.

As long as only a single section needs to be dealt with, that's a viable
option.  With too many sections needing similar treatment, this gets out
of hand.

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

2018-11-02 Thread ro at CeBiTec dot Uni-Bielefeld.DE

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Iain Buclaw  ---
> This is part of the dmd frontend which as no interaction with gcc.  So
> gcc_unreachable() can't be used here.

I see.  However, if upstream dmc were built with similar warning options
than gcc, the problem would exist there as well.

> Sounds like some independent compatibility layer is required here instead.

That's certainly an option.  Among others, what to do here depends on
how prevalent the problem is: if Solaris 10 is the only OS affected and
the other pre-Solaris 11.4 issues (especially PR d/87865) cannot be
resolved for the GCC 9 release, one might as well close the bug as
WONTFIX given Solaris 10 is obsoleted in GCC 9.

[Bug c++/87867] New: ICE on virtual destructor (-mlong-calls -ffunction-sections) on arm-none-eabi

2018-11-02 Thread mihail.ionescu at arm dot com

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

Bug ID: 87867
   Summary: ICE on virtual destructor (-mlong-calls
-ffunction-sections) on arm-none-eabi
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mihail.ionescu at arm dot com
  Target Milestone: ---

The issue is fixed on trunk. GCC 7.3 and 8.2 crash when compiling the following
example with these specific options: "-mlong-calls", "-ffunction-sections".


class A
{
public:
virtual ~A() { }
};

class B
{
public:
virtual ~B() { }
};

class C : public A, public B
{
public:
virtual ~C();
};

C::~C()
{
}


gcc-arm-error.cpp: In member function 'virtual void* C::_ZThn4_N1CD1Ev()':
gcc-arm-error.cpp:21:1: internal compiler error: in gen_reg_rtx, at
emit-rtl.c:1155
 }
 ^
0xa3a98c gen_reg_rtx(machine_mode)
/arm-none-eabi/build/src/gcc/gcc/emit-rtl.c:1155
0xa54e1e force_reg(machine_mode, rtx_def*)
/arm-none-eabi/build/src/gcc/gcc/explow.c:655
0x143237e gen_sibcall(rtx_def*, rtx_def*, rtx_def*)
/arm-none-eabi/build/src/gcc/gcc/config/arm/arm.md:8272
0x11c3f0e arm32_output_mi_thunk
/arm-none-eabi/build/src/gcc/gcc/config/arm/arm.c:26778
0x11c3f0e arm_output_mi_thunk
/arm-none-eabi/build/src/gcc/gcc/config/arm/arm.c:26799
0x9813cb cgraph_node::expand_thunk(bool, bool)
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:1787
0x9836af cgraph_node::assemble_thunks_and_aliases()
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2067
0x983715 cgraph_node::assemble_thunks_and_aliases()
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2085
0x983c1c cgraph_node::expand()
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2202
0x98508a output_in_order
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2381
0x98508a symbol_table::compile()
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2623
0x987392 symbol_table::finalize_compilation_unit()
/arm-none-eabi/build/src/gcc/gcc/cgraphunit.c:2717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

2018-11-02 Thread ibuclaw at gdcproject dot org

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

--- Comment #1 from Iain Buclaw  ---
Is there another way to get a section in earlier versions of Solaris?

The alternative is to support a vagary of methods in order to determine loaded
modules at runtime.

[Bug rtl-optimization/87678] Redundant vmovss with -fPIC

2018-11-02 Thread segher at gcc dot gnu.org

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

--- Comment #7 from Segher Boessenkool  ---
Hi Uros,

It's not clear to me what you would have liked it to do instead?

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

2018-11-02 Thread ibuclaw at gdcproject dot org

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

--- Comment #1 from Iain Buclaw  ---
This is part of the dmd frontend which as no interaction with gcc.  So
gcc_unreachable() can't be used here.

Sounds like some independent compatibility layer is required here instead.

Got germs?

2018-11-02 Thread Gina Cianfrone

Hi Enrique,

Flu season is here, and the office is the perfect place for those germs to
spread like wildfire. The risks are nothing to sneeze at: according to the
Centers for Disease Control and Prevention, the flu alone costs U.S.
companies $10.4 billion per year.

Bringing Vanguard Cleaning Systems in to clean your space once per day
or once per week kills those germs before they can infect your staff. Our
advanced, healthy office cleaning methods and products help contain,
capture, and remove dust, bacteria, mold, pollen, and other allergens from
your office.

It’s a win-win! (Well, not for the germs).

May I give you a complimentary cleaning quote? ---
Gina Cianfrone
Vice President of Marketing
Vanguard Cleaning Systems of Northern New Jersey

Read what our valued clients have to say:

"Vanguard Cleaning Service has provided cleaning services for The
Cardiovascular Care Group in all three of our locations in Clifton, Springfield,
and Westfield since 2008. They have proven to be both reliable and trustworthy.
They clean both offices and surgical suites daily. They have provided us with a
written policy to meet with our accreditation standards. They provide us
additional
services like carpet and floor strip and wax at a reasonable price. They are
truly a
full-service company." —Kathleen Demytrk, CFO, The Cardiovascular Care Group

© 2018 Vanguard Cleaning Systems of Northern New Jersey
Our address is 115 Route 46 West, Suite A-8, Mountain Lakes, New Jersey, 07046

In order to unsubscribe from this mailing list, please click here
http://email.vanguardnnj.com/c/eJx1j8mKwzAQRL_Gvo1Qq9Vq6eBDSMh_yFK878vE8deP5zowUIdHPSiomKn8xdqldaYkWACpwCiNUoDAhyH94Dvfbvau6Zlo-e2HcvdLHIZGhLFPqyzkkBdgo3HemAIM-pcuAtnAEWP0Ie0zRpaoddpl1bZNCd4S9byyLT604s_ir8LnsXcJPmiWkt5jA2O_GiPPzwyeaQWa69AcDvPzU_l1W874PqMtwjEV_nw1Dcmlq_yAre8-fdu7SbZ2rqc8Ueaor90yhK98L9frz4WiHHYxLmW6ZP-ILdt8KYA0ABM7FghW29_CITrFF6FjUEYJYA2GjBNEbJnMDwuNac4

[Bug rtl-optimization/87678] Redundant vmovss with -fPIC

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

--- Comment #6 from Uroš Bizjak  ---
Here is a bit simpler testcase:

--cut here--
typedef float __v4sf __attribute__((__vector_size__ (16)));

__v4sf
foo (__v4sf x)
{
  return x + (__v4sf){ 2.3f, 2.3f, 2.3f, 2.3f };
}
--cut here--

"cc1 -O2" on x86_64 target will show the issue in _.combine dump.

[Bug rtl-optimization/87678] Redundant vmovss with -fPIC

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

--- Comment #5 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #4)
> It tries twice, first just the substitution, and then that modified with
> the REG_EQUAL.  You know a mem is not often valid in the resulting insn,
> but combine doesn't, and that is not the same thing as not having a mem
> in the inputs anyway!

I have traced this a bit through the combine.c. When creating the combined
pattern in subst (), there is following code at the end:

  for (i = 0; i < 4; i++)
{
  /* If X is sufficiently simple, don't bother trying to do anything
 with it.  */
  if (code != CONST_INT && code != REG && code != CLOBBER)
x = combine_simplify_rtx (x, op0_mode, in_dest, in_cond);

  if (GET_CODE (x) == code)
break;

  code = GET_CODE (x);

  /* We no longer know the original mode of operand 0 since we
 have changed the form of X)  */
  op0_mode = VOIDmode;
}

And going through combine_simplify_rtx:

case RTX_COMM_ARITH:
case RTX_BIN_ARITH:
  temp = simplify_binary_operation (code, mode, XEXP (x, 0), XEXP (x, 1));
  break;

Following this to simplify_binary_operation, we have at the beginning:

  trueop0 = avoid_constant_pool_reference (op0);
  trueop1 = avoid_constant_pool_reference (op1);

  tem = simplify_const_binary_operation (code, mode, trueop0, trueop1);

Here, all hope is lost. avoid_constant_pool_reference *always* simplifies
memory fetch to a constant for constant pool symbol references, defeating all
chances of memory operand propagation.

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

2018-11-02 Thread sch...@linux-m68k.org

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

--- Comment #3 from Andreas Schwab  ---
http://gcc.gnu.org/ml/gcc-patches/2018-09/msg01052.html

[Bug rtl-optimization/87678] Redundant vmovss with -fPIC

2018-11-02 Thread segher at gcc dot gnu.org

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

--- Comment #4 from Segher Boessenkool  ---
It tries twice, first just the substitution, and then that modified with
the REG_EQUAL.  You know a mem is not often valid in the resulting insn,
but combine doesn't, and that is not the same thing as not having a mem
in the inputs anyway!

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

2018-11-02 Thread tnfchris at gcc dot gnu.org

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

--- Comment #42 from Tamar Christina  ---
Author: tnfchris
Date: Fri Nov  2 15:27:30 2018
New Revision: 265749

URL: https://gcc.gnu.org/viewcvs?rev=265749=gcc=rev
Log:
Fix mingw-w64 Ada native bootstrap (PR81878).

Due to the changes in PR81878 builds of GCC8 and trunk are impossible
with Ada enabled[1][2].

The reason the patch breaks the bootstrap is due to how gnatlink receives it's
arguments.

gnatlink is usually invoked as

$(GNATLINK) -v gnatcmd -o ../../gnat$(exeext) \
  --GCC="$(CC) $(ADA_INCLUDES)" --LINK="$(GCC_LINK)" $(TOOLS_LIBS)

so it passes $(CC) and $(GCC_LINK) as quoted arguments to the program.
Because of this quotation the msys2 shell does not translate any paths in
$(CC) and $(GCC_LINK) from their Unix version to their Windows version.

Furthermore because there are multiple paths in the values separated by space
and because the paths often contain a prefix like -L (e.g. -L/f/foo) we can't
use `fix_srcfile_path` to fix this.

An alternative solution would have been to create a stub program that echos the
commandline options it receives back, and calling this program with $(CC) and
$(GCC_LINK)
unquoted to get them translated.  However this was a bit more invasive.

So instead for native compilations we add -B../../ such that it picks up the
lto plugin
from the previous built compiler.  Since it's native there shouldn't be a
mismatch here.

[1] https://github.com/Alexpux/MINGW-packages/pull/3877#issuecomment-408651809
[2] https://gcc.gnu.org/ml/gcc/2018-07/msg00410.html

gnattools/ChangeLog:

2018-11-02  Tamar Christina  

Backport from mainline
2018-10-29  Tamar Christina  

PR ada/81878
* Makefile.in (TOOLS_FLAGS_TO_PASS_NATIVE): Add -B ../../.


Modified:
branches/gcc-8-branch/gnattools/ChangeLog
branches/gcc-8-branch/gnattools/Makefile.in

[Bug middle-end/70831] [7/8/9 Regression] FTBFS: Build fails with bootstrap-lto and profiledbootstrap

2018-11-02 Thread law at redhat dot com

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #18 from Jeffrey A. Law  ---
MPX/CHKP is dead.  62077 tracks the deeper issues.

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

2018-11-02 Thread mpolacek at gcc dot gnu.org

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

--- Comment #2 from Marek Polacek  ---
It's unlikely that this is caused by my latest patch implementing P0846R0, that
only triggers with C++2a.

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Terry Guo from comment #5)
> What about a fix like below? I tested with bootstrap and regression test,
> there is no problem.

LGTM.

[Bug middle-end/87852] [9 Regression] FAIL: gcc.c-torture/execute/pr53465.c

2018-11-02 Thread ebotcazou at gcc dot gnu.org

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

--- Comment #7 from Eric Botcazou  ---
> Eric, you added partitions_for_undefined_values and IIRC that was just narrow
> scope enough to fix a specific issue but not generally address shortcomings
> within RTL?

Yes, it's only enabled for SUBREG_PROMOTED_VAR_P at the moment.

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

2018-11-02 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
When did this start?

[Bug d/87866] gdc fails to compile minimal test

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/87866] New: gdc fails to compile minimal test

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

Bug ID: 87866
   Summary: gdc fails to compile minimal test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.10

Continuing from the failure described in PR d/87865 with the workaround
mentioned
there,libphobos fails to configure:

configure: error: can't compile D sources!

config.log shows

configure:4846: /var/gcc/regression/trunk/10-gcc-gas/build/./gcc/gdc
-B/var/gcc/regression/trunk/10-gcc-gas/build/./gcc/
-B/vol/gcc/sparc-sun-solaris2.10/bin/ -B/vol/gcc/sparc-sun-solaris2.10/lib/
-isystem /vol/gcc/sparc-sun-solaris2.10/include -isystem
/vol/gcc/sparc-sun-solaris2.10/sys-include   -fchecking=1 -c -fno-moduleinfo
-nostdinc -I /vol/gcc/src/hg/trunk/local/libphobos/libdruntime  -O2 -g
conftest.d >&5
d21: error: cannot find source code for runtime library file 'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' for
installation
 instructions.

in pp_string, at pretty-print.c:1701
0x1188dc3 pp_string(pretty_printer*, char const*)
/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:1701
0x1188dc3 pp_string(pretty_printer*, char const*)
/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:1699
0x118a23b pp_format(pretty_printer*, text_info*)
/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:1294
0x11785a7 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1004
0x336fe7 d_diagnostic_report_diagnostic
/vol/gcc/src/hg/trunk/local/gcc/d/d-diagnostic.cc:138
0x3371f7 errorSupplemental(Loc const&, char const*, ...)
/vol/gcc/src/hg/trunk/local/gcc/d/d-diagnostic.cc:206
0x22871f Module::read(Loc)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dmodule.c:313
0x22aa43 Module::load(Loc, Array*, Identifier*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dmodule.c:278
0x20f003 Import::load(Scope*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dimport.c:155
0x20f227 Import::importAll(Scope*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dimport.c:174
0x20f227 Import::importAll(Scope*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dimport.c:170
0x227fff Module::importAll(Scope*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dmodule.c:790
0x227fff Module::importAll(Scope*)
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/dmodule.c:725
0x3415b7 d_parse_file()
/vol/gcc/src/hg/trunk/local/gcc/d/d-lang.cc:1099

When I run the compiler under truss -f, I find that it only looks in its
 working directory for some reason:

4398:   read(4, " m o d u l e   m o d ;\n".., 50)   = 50
4398:   close(4)= 0
4398:   stat64("object.di", 0xFFBFE980) Err#2 ENOENT
4398:   stat64("object.d", 0xFFBFE980)  Err#2 ENOENT
4398:   stat64("object", 0xFFBFE980)Err#2 ENOENT
4398:   open64("object.d", O_RDONLY)Err#2 ENOENT

I haven't yet dug further or compared with what happens on Solaris 11 where
this works fine.

[Bug d/87865] gdc doesn't build unless assert is marked noreturn

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|9.0 |10.0

[Bug d/87865] New: gdc doesn't build unless assert is marked noreturn

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

Bug ID: 87865
   Summary: gdc doesn't build unless assert is marked noreturn
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.10

When I tried to build gdc on Solaris 10, it failed to compile like this:

/vol/gcc/src/hg/trunk/local/gcc/d/dmd/arrayop.c: In member function 'virtual
void buildArrayIdent(Expression*, OutBuffer*,
Expressions*)::BuildArrayIdentVisitor::visit(BinAssignExp*)':
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/arrayop.c:336:29: error: 's' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  336 | buf->writestring(s);
  | ^~~

/vol/gcc/src/hg/trunk/local/gcc/d/dmd/ctfeexpr.c: In function 'int
comparePointers(TOK, Expression*, dinteger_t, Expression*, dinteger_t)':
/vol/gcc/src/hg/trunk/local/gcc/d/dmd/ctfeexpr.c:925:13: error: 'n' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
  925 | int n;
  | ^

and several more, obviously due to assert not being marked noreturn in
, unlike Solaris 11.

When I manually add __attribute__((__noreturn__)) to the _assert declarations
and place the result in gcc/include-fixed/assert.h, the gdc compilation to
finish.

If only a single target were affected by this, doing the fixup via fixincludes
might be an options; in case there are others, that doesn't seem the right
solution.

In fact, gdc should use gcc_unreachable () anyway: gcc/tsystem.h adds the
noreturn attribute to the declaration to avoid the failure.

[Bug d/87864] libdruntime doesn't link with /bin/ld before Solaris 11.4

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug d/87864] New: libdruntime doesn't link with /bin/ld before Solaris 11.4

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

Bug ID: 87864
   Summary: libdruntime doesn't link with /bin/ld before Solaris
11.4
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.*

When I tried to build libphobos on Solaris 11.3 (all previous attempts have
been
on 11.4 or 11.5 Beta), linking libdruntime failed:

Undefined first referenced
 symbol in file
__stop_minfocore/.libs/atomic.o  (symbol scope
specifies local binding)
__start_minfo   core/.libs/atomic.o  (symbol scope
specifies local binding)
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:1709: libgdruntime.la] Error 1

This is no wonder actually, since DCFG_MINFO_BRACKETING=false.  Support for the
automatic creation of __start_ and __stop_ symbols (a GNU ld
extension) was only added to Solaris ld in 11.4 due to its several uses in
LLVM.

[Bug c++/87862] Different behavior with -O2 with template specialization of virtual member function

2018-11-02 Thread redi at gcc dot gnu.org

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

--- Comment #2 from Jonathan Wakely  ---
The relevant quote from the standard is:

If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that specialization that would cause an implicit instantiation to take place,
in every translation unit in which such a use occurs; no diagnostic is
required.

[Bug target/87853] _mm_cmpgt_epi8 broken with -funsigned-char

2018-11-02 Thread xuepeng.guo at intel dot com

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

--- Comment #5 from Terry Guo  ---
Hi folks,

What about a fix like below? I tested with bootstrap and regression test, there
is no problem.

diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
index 7a6ff80..3c1f04b 100644
--- a/gcc/config/i386/emmintrin.h
+++ b/gcc/config/i386/emmintrin.h
@@ -45,6 +45,7 @@ typedef unsigned int __v4su __attribute__ ((__vector_size__
(16)));
 typedef short __v8hi __attribute__ ((__vector_size__ (16)));
 typedef unsigned short __v8hu __attribute__ ((__vector_size__ (16)));
 typedef char __v16qi __attribute__ ((__vector_size__ (16)));
+typedef signed char __v16qs __attribute__ ((__vector_size__ (16)));
 typedef unsigned char __v16qu __attribute__ ((__vector_size__ (16)));

 /* The Intel API is flexible enough that we must allow aliasing with other
@@ -1295,7 +1296,7 @@ _mm_xor_si128 (__m128i __A, __m128i __B)
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
 _mm_cmpeq_epi8 (__m128i __A, __m128i __B)
 {
-  return (__m128i) ((__v16qi)__A == (__v16qi)__B);
+  return (__m128i) ((__v16qs)__A == (__v16qs)__B);
 }

 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
@@ -1313,7 +1314,7 @@ _mm_cmpeq_epi32 (__m128i __A, __m128i __B)
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
 _mm_cmplt_epi8 (__m128i __A, __m128i __B)
 {
-  return (__m128i) ((__v16qi)__A < (__v16qi)__B);
+  return (__m128i) ((__v16qs)__A < (__v16qs)__B);
 }

 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
@@ -1331,7 +1332,7 @@ _mm_cmplt_epi32 (__m128i __A, __m128i __B)
 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
 _mm_cmpgt_epi8 (__m128i __A, __m128i __B)
 {
-  return (__m128i) ((__v16qi)__A > (__v16qi)__B);
+  return (__m128i) ((__v16qs)__A > (__v16qs)__B);
 }

 extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))

[Bug c++/87863] [9 Regression] c-c++-common/gomp/gridify-{2,3}.c ICE

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|c-c++-common/gomp/gridify-{ |[9 Regression]
   |2,3}.c ICE  |c-c++-common/gomp/gridify-{
   ||2,3}.c ICE

[Bug c++/87862] Different behavior with -O2 with template specialization of virtual member function

2018-11-02 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This looks like undefined behaviour. You have a template specialization in
s.cpp but none of the other files can see that specialization exists, and so
they implicitly instantiate t::get_b based on the primary template, which
returns a null pointer, which you dereference.

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 44948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44948=edit
gcc9-pr87859.patch

WIP patch.

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #15 from Richard Biener  ---
But the following fixes it:

diff --git a/gcc/alias.c b/gcc/alias.c
index 7963ece291a..4c88c0980d3 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1235,14 +1235,14 @@ record_component_aliases (tree type)
   Accesses to it conflicts with accesses to any other pointer
   type.  */
tree t = TREE_TYPE (field);
-   if (in_lto_p)
+   if (1)
  {
/* VECTOR_TYPE and ARRAY_TYPE share the alias set with their
   element type and that type has to be normalized to void *,
   too, in the case it is a pointer. */
while (!canonical_type_used_p (t) && !POINTER_TYPE_P (t))
  {
-   gcc_checking_assert (TYPE_STRUCTURAL_EQUALITY_P (t));
+   gcc_checking_assert (!in_lto_p ||
TYPE_STRUCTURAL_EQUALITY_P (t));
t = TREE_TYPE (t);
  }
if (POINTER_TYPE_P (t))

[Bug c++/87863] New: c-c++-common/gomp/gridify-{2,3}.c ICE

2018-11-02 Thread tschwinge at gcc dot gnu.org

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

Bug ID: 87863
   Summary: c-c++-common/gomp/gridify-{2,3}.c ICE
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, nathan at gcc dot gnu.org
  Target Milestone: ---

As of r265714 "[ABI PATCH] static anonymous unions of function scope", and with
checking enabled (might be relevant, see "gcc_checking_assert" below), I'm
seeing the following regressions:

PASS: c-c++-common/gomp/gridify-2.c  -std=gnu++14  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-2.c  -std=gnu++14 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-2.c  -std=gnu++14 (test for excess
errors)
PASS: c-c++-common/gomp/gridify-2.c  -std=gnu++17  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-2.c  -std=gnu++17 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-2.c  -std=gnu++17 (test for excess
errors)
PASS: c-c++-common/gomp/gridify-2.c  -std=gnu++98  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-2.c  -std=gnu++98 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-2.c  -std=gnu++98 (test for excess
errors)
PASS: c-c++-common/gomp/gridify-3.c  -std=gnu++14  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-3.c  -std=gnu++14 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-3.c  -std=gnu++14 (test for excess
errors)
PASS: c-c++-common/gomp/gridify-3.c  -std=gnu++17  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-3.c  -std=gnu++17 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-3.c  -std=gnu++17 (test for excess
errors)
PASS: c-c++-common/gomp/gridify-3.c  -std=gnu++98  scan-tree-dump omplower
"Target construct will be turned into a gridified HSA kernel"
[-PASS:-]{+FAIL: c-c++-common/gomp/gridify-3.c  -std=gnu++98 (internal
compiler error)+}
{+FAIL:+} c-c++-common/gomp/gridify-3.c  -std=gnu++98 (test for excess
errors)

(gdb) bt
#0  fancy_abort (file=0x1af2e90 "[...]/gcc/cp/mangle.c", line=1925,
function=0x1af3970 
"discriminator_for_local_entity") at [...]/gcc/diagnostic.c:1560
#1  0x007c8ac1 in discriminator_for_local_entity
(entity=entity@entry=0x76934ea0) at [...]/gcc/cp/mangle.c:1925
#2  0x007d04eb in write_local_name (entity=0x76934ea0,
local_entity=0x76934ea0, function=) at
[...]/gcc/cp/mangle.c:2035
#3  write_name (decl=decl@entry=0x76934ea0,
ignore_local_scope=ignore_local_scope@entry=0) at [...]/gcc/cp/mangle.c:963
#4  0x007d4c8a in write_encoding (decl=0x76934ea0) at
[...]/gcc/cp/mangle.c:824
#5  0x007d6ab0 in mangle_decl_string
(decl=decl@entry=0x76934ea0) at [...]/gcc/cp/mangle.c:3765
#6  0x007d6cf9 in get_mangled_id (decl=0x76934ea0) at
[...]/gcc/cp/mangle.c:3787
#7  mangle_decl (decl=0x76934ea0) at [...]/gcc/cp/mangle.c:3825
#8  0x011f6616 in decl_assembler_name (decl=0x76934ea0) at
[...]/gcc/tree.c:691
#9  0x00a430fd in symbol_table::insert_to_assembler_name_hash
(this=0x767ac100, node=0x76933e00, with_clones=) at
[...]/gcc/symtab.c:174
#10 0x00a45495 in symbol_table::symtab_initialize_asm_name_hash
(this=0x767ac100) at [...]/gcc/symtab.c:266
#11 0x00a454d5 in symbol_table::symtab_initialize_asm_name_hash
(this=) at [...]/gcc/symtab.c:262
#12 0x00a5d6c3 in analyze_functions
(first_time=first_time@entry=true) at [...]/gcc/cgraphunit.c:1289
#13 0x00a5dcc3 in symbol_table::finalize_compilation_unit
(this=0x767ac100) at [...]/gcc/cgraphunit.c:2833
#14 0x00f2f06d in compile_file () at [...]/gcc/toplev.c:480
#15 0x006b7095 in do_compile () at [...]/gcc/toplev.c:2172
#16 toplev::main (this=this@entry=0x7fffc260, argc=argc@entry=33,
argv=argv@entry=0x7fffc368) at [...]/gcc/toplev.c:2307
#17 0x006ba9c7 in main (argc=33, argv=0x7fffc368) at
[...]/gcc/main.c:39
(gdb) frame 1
#1  0x007c8ac1 in discriminator_for_local_entity
(entity=entity@entry=0x76934ea0) at [...]/gcc/cp/mangle.c:1925
1925  gcc_checking_assert (DECL_ARTIFICIAL (entity));
(gdb) call debug_tree(entity)
 
sizes-gimplified type_6 BLK
size 
unit-size

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #14 from Richard Biener  ---
The following does _not_ fix it (but an assert that the alias-set is -1 does
trigger).  We probably have to adjust all types the record parent is embedded
into as well for which there's no easy way.

Well.  Not compute any alias-sets before free-lang-data  -Wstrict-aliasing
computes it for example, so does folding, for example in make_bit_field_ref
(in fact that seems to be the only caller...).

diff --git a/gcc/tree.c b/gcc/tree.c
index 069d62d51be..47cbbaab9b5 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -5515,7 +5515,10 @@ free_lang_data_in_decl (tree decl, struct
free_lang_data_d *fld)
 }
   else if (TREE_CODE (decl) == FIELD_DECL)
 {
+  tree orig = TREE_TYPE (decl);
   TREE_TYPE (decl) = fld_simplified_type (TREE_TYPE (decl), fld);
+  if (TREE_TYPE (decl) != orig)
+   TYPE_ALIAS_SET (DECL_CONTEXT (decl)) = -1;
   DECL_INITIAL (decl) = NULL_TREE;
 }
   else if (TREE_CODE (decl) == TRANSLATION_UNIT_DECL

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #13 from Richard Biener  ---
So the alias machinery disambiguates them at

static bool
indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
   poly_int64 offset1, poly_int64 max_size1,
...
  /* Do type-based disambiguation.  */
  if (base1_alias_set != base2_alias_set
  && !alias_sets_conflict_p (base1_alias_set, base2_alias_set))
return false;

where base2_alias_set == ref2_alias_set from *p_11 and
ref1_alias_set == ref2_alias_set but base1_alias_set == 22 (from v_16->locs).

And somehow the alias-set for *v_16 doesn't have v_16->locs as child
(well, it probably has the pointer-to-complete one as child since we built
the alias-set for *v_16 _before_ adjusting the FIELD_DECLs type!?)

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #12 from Richard Biener  ---
OK, so in GCC 8 at least pointer-to-incomplete type gets the alias set of void
* and that conflicts with any other pointer.  So that works.

Not sure what breaks here now...

[Bug c++/87862] New: Different behavior with -O2 with template specialization of virtual member function

2018-11-02 Thread john.eric.martin at gmail dot com

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

Bug ID: 87862
   Summary: Different behavior with -O2 with template
specialization of virtual member function
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.eric.martin at gmail dot com
  Target Milestone: ---

Created attachment 44947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44947=edit
Test case source and -save-temps output

I admit it's probably not well written code and should be re-factored; however,
there is no error or warning and the compiler is generating undesired behavior
only when optimization (tested with -O3) is turned on.

Since it's related to the optimization path I was weary about combining the
source files. Please pardon the zip file with multiple sources. The zip file
contains the files generated with -save-temps in addition to a Makefile that
builds and runs the optimized and not optimized versions of the test case
demonstrating that they crash and print a number respectively. Output below is
also in the output.txt file in the zip archive.


g++ -v -save-temps -Wall -Wextra -std=c++14 -O3 -o testcase bug.cpp s.cpp m.cpp
b.cpp v.cpp e.cpp k.cpp o.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-21ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-21ubuntu1~16.04) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++14' '-O3'
'-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE bug.cpp -mtune=generic -march=x86-64 -std=c++14
-Wall -Wextra -O3 -fpch-preprocess -fstack-protector-strong -Wformat-security
-o bug.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/7
 /usr/include/x86_64-linux-gnu/c++/7
 /usr/include/c++/7/backward
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++14' '-O3'
'-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -fpreprocessed bug.ii -quiet -dumpbase
bug.cpp -mtune=generic -march=x86-64 -auxbase bug -O3 -Wall -Wextra -std=c++14
-version -fstack-protector-strong -Wformat-security -o bug.s
GNU C++14 (Ubuntu 7.3.0-21ubuntu1~16.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (Ubuntu 7.3.0-21ubuntu1~16.04) version 7.3.0 (x86_64-linux-gnu)
compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 612ffb48244e46eb953b6d77363adac8
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++14' '-O3'
'-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.26.1
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++14' '-O3'
'-o' 'testcase' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #11 from Richard Biener  ---
That said - we used to give all pointer types the same alias-set but you
somehow convinced yourself that not doing that is safe.  Even when considering
pointer-to-complete and pointer-to-incomplete types.  Do you remember any
details?

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #10 from Richard Biener  ---
I can only see that v->locs might be affected by fld because the type of the
FIELD_DECL changes but the (alias) type of *p_11 remains the same.  Thus
we have get_alias_set (ptr-to-incomplete) and get_alias_set (ptr-to-complete)
not agreeing.  But of course they have to.

I guess we can make a two-unit LTO testcase like the following - but it
doesn't miscompile since we end up substituting the MEM_REF base type
for the store in foo() somehow so even with more fiddling I always get

  *p_5 = 
  py ={v} 
  _1 ={v} py;
  MEM[(struct Y *)_1].p = 
^^^ will not use the alias set of .p

  _2 = *p_5;




struct X;
struct Y { struct X *p; };

void foo (struct Y *p, struct X *v)
{
  p->p = v;
}

---

struct X { int i; };
struct Y { struct X *p; };

void foo (struct Y *, struct X *);
struct X ** volatile px;
struct X a, b;
int main()
{
  struct Y y;
  px = 
  struct X **p = px; 
  *p = 
  foo (, );
  if (*p != )
__builtin_abort ();
  return 0;
}

[Bug ada/25844] [7/8/9 regression] ICE on overloaded renames

2018-11-02 Thread simon at pushface dot org

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

--- Comment #21 from simon at pushface dot org ---
This bug was fixed in GCC 5 (5.2.0, x86_64-apple-darwin15) and is still fixed
up to GCC 9.0.0 20180927.

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

2018-11-02 Thread hubicka at gcc dot gnu.org

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

--- Comment #9 from Jan Hubicka  ---
Created attachment 44946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44946=edit
reproducer

I am attaching the preprocessed file and will be away till 2pm.
What seems to be wrong is that we optimize out decrease of n_useless_values in
discard_useless_locs.
fre1 already differs:

 discard_useless_locs (void * * x, void * info)
 {
   struct elt_loc_list * l;
@@ -8886,9 +8895,6 @@
   struct rtx_def * _4;
   int _5;
   struct elt_loc_list * _7;
-  struct elt_loc_list * _8;
-  int n_useless_values.142_9;
-  int _10;
   struct elt_loc_list * _25;
   struct elt_loc_list * empty_elt_loc_lists.98_26;

@@ -8947,27 +8953,6 @@

:
   # DEBUG BEGIN_STMT
-  if (_1 != 0B)
-goto ; [INV]
-  else
-goto ; [INV]
-
-   :
-  _8 = v_16->locs;
-  if (_8 == 0B)
-goto ; [INV]
-  else
-goto ; [INV]
-
-   :
-  # DEBUG BEGIN_STMT
-  n_useless_values.142_9 = n_useless_values;
-  _10 = n_useless_values.142_9 + 1;
-  n_useless_values = _10;
-  # DEBUG BEGIN_STMT
-  values_became_useless = 1;
-
-   :
   # DEBUG BEGIN_STMT

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
  Known to work||8.2.0
  Known to fail||8.2.1

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #8 from Richard Biener  ---
(In reply to Jan Hubicka from comment #7)
> > If we have less MEM_REFs then we probably strip them because we think they
> > reference equal types.
> > 
> > I think I already told you that given that MEM_REFs use pointer types
> > to carry alignment info _those_ may not become incomplete!  But I didn't
> > expect that to cause wrong-code but missed optimizations.
> 
> We do not make them incomplete.  The problem actually seems to be in
> early optimization where we optimize out the if conditional above.
> Not sure why -ffat-lto-objects worked in this context.

So can you attach preprocessed source for the affected file?  And name the
affected function? (dump is stripped too early)

[Bug target/14557] va_list is automatically taken address-of when passed as argument

2018-11-02 Thread nsz at gcc dot gnu.org

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

--- Comment #23 from nsz at gcc dot gnu.org ---
(In reply to felix from comment #21)
> > va_list ap2;
> > va_copy(ap2, ap);
> 
> > and then use , this always works.
> 
> > the proposed macros are both broken and unnecessary.
> 
> That's not equivalent. Using va_arg(ap2, T) does not propagate state changes
> back to ap, which is the main motivation to form a pointer to ap in the
> first place. The macros do that just fine. You mean they are unportable?
> That part is true, I admitted as much. Pick your poison.
> 

state changes are propagated to ap2, which is
what you should use after you made the copy,
it does exactly what you want.

[Bug middle-end/87852] [9 Regression] FAIL: gcc.c-torture/execute/pr53465.c

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

--- Comment #6 from Richard Biener  ---
And fwprop before that questionable code does

  /* We used to have a def reaching a use that is _before_ the def,
 with the def not dominating the use even though the use and def
 are in the same basic block, when a register may be used
 uninitialized in a loop.  This should not happen anymore since
 we do not use reaching definitions, but still we test for such
 cases and assume that DEF is not available.  */
  if (def_bb == target_bb
  ? DF_INSN_LUID (def_insn) >= DF_INSN_LUID (target_insn)
  : !dominated_by_p (CDI_DOMINATORS, target_bb, def_bb))
return true;

so that suggests a fix like the following which fixes the testcase for me

diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 0fca0f1edbc..cd44c0ef637 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -767,7 +767,11 @@ use_killed_between (df_ref use, rtx_insn *def_insn,
rtx_insn *target_insn)
   def = DF_REG_DEF_CHAIN (regno);
   if (def
   && DF_REF_NEXT_REG (def) == NULL
-  && regno >= FIRST_PSEUDO_REGISTER)
+  && regno >= FIRST_PSEUDO_REGISTER
+  && (BLOCK_FOR_INSN (DF_REF_INSN (def)) == def_bb
+ ? DF_INSN_LUID (DF_REF_INSN (def)) < DF_INSN_LUID (def_insn)
+ : dominated_by_p (CDI_DOMINATORS,
+   def_bb, BLOCK_FOR_INSN (DF_REF_INSN (def)
 return false;

   /* Check locally if we are in the same basic block.  */

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-02
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
So, the bug is that in the code introduced in the PR86844 fix, if we skip any
stores because their order was > last_order, we should have marked the
merged_store with some flag that prevents merging that with any further stores.

Plus, there is obviously a missed optimization (and regression on that),
because in this testcase there is no reason why any of the INTEGER_CST stores
should be skipped.

We have stores (bitposition, bitsize):
0 32
0 1
1 1
...
21 1
32 32
64 32
66 1
where 0 32 has order 0, 0 1 has order 9, 1 1 has order 15, 32 32 has order 1,
64 32 has order 2 and 66 1 has the highest order.
All the stores at offsets 0 to 21 are overlapping.  We go and merge as
overlapping store 0 32, 0 1 and all stores with order in between those (but
that means skipping 1 1 and various others).  If we have to do that, e.g.
because the
1 1 store would be not INTEGER_CST store, then we need to arrange not to merge
with it anymore stores with order above that problematic store.
If all the to be skipped stores are INTEGER_CSTs, then we should obviously try
to merge them in all (as was the case before the PR86844 fix on this testcase).

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

2018-11-02 Thread hubicka at ucw dot cz

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

--- Comment #7 from Jan Hubicka  ---
> If we have less MEM_REFs then we probably strip them because we think they
> reference equal types.
> 
> I think I already told you that given that MEM_REFs use pointer types
> to carry alignment info _those_ may not become incomplete!  But I didn't
> expect that to cause wrong-code but missed optimizations.

We do not make them incomplete.  The problem actually seems to be in
early optimization where we optimize out the if conditional above.
Not sure why -ffat-lto-objects worked in this context.

[Bug middle-end/87852] [9 Regression] FAIL: gcc.c-torture/execute/pr53465.c

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Alex - I belive you relaxed out-of-SSA coalescing of (undefined) default-defs,
so maybe you have an idea/opinion here as well?

[Bug sanitizer/87857] case label does not reduce to an integer constant

2018-11-02 Thread stsp at users dot sourceforge.net

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

--- Comment #5 from Stas Sergeev  ---
(In reply to Jakub Jelinek from comment #4)
> The reason you get an error is that the expression isn't constant, because
> it needs to emit the runtime diagnostics.  Just fix the bug and get away
> with that?  1U<<31 will do.

I of course already "fixed" my code as per
earlier comments here. So you can close this
if you want. But I am sure gcc is not doing
the right thing here. Just make it a warning,
and, more importantly, -W warning, independent
of any -f. Then people will get this warning
with -Wall or whatever, and will not get a
compilation failure with -fsanitize on otherwise
warning-less code.

I am not sure I understand how the run-time
diagnostic makes the expression non-const.

[Bug middle-end/87852] [9 Regression] FAIL: gcc.c-torture/execute/pr53465.c

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

Richard Biener  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
So we have, after inserting the backedge copy

   [local count: 1034442873]:
  # c_22 = PHI 
  c_2 = c_22;
  d_14 = MEM[base: x_12(D), index: _9, step: 4, offset: 0B];
  if (d_14 == 0)
goto ; [3.66%]
  else
goto ; [96.34%]

   [local count: 996582264]:
  _4 = b_21 != 0;
  _5 = d_14 <= c_2;
  _6 = _4 & _5;
  if (_6 != 0)

and we coalesce c_22 and d_14 (as desired).

But then somehow fwprop comes along and changes

(insn 14 13 15 4 (set (reg/v:SI 83 [ c ])
(reg/v:SI 88 [ d ])) 67 {*movsi_internal}
 (nil))
(insn 15 14 16 4 (set (reg/v:SI 88 [ d ])
(mem:SI (plus:SI (mult:SI (reg/v:SI 89 [ i ])
(const_int 4 [0x4]))
(reg/v/f:SI 90 [ x ])) [0 MEM[base: x_12(D), index: _9, step:
4, offset: 0B]+0 S4 A32]))
"/space/rguenther/src/gcc-slpcost/gcc/testsuite/gcc.c-torture/execute/pr53465.c":15:11
67 {*movsi_internal}
 (nil))
...
(insn 23 42 24 6 (set (reg:CCGC 17 flags)
(compare:CCGC (reg/v:SI 88 [ d ])
(reg/v:SI 83 [ c ])))
"/space/rguenther/src/gcc-slpcost/gcc/testsuite/gcc.c-torture/execute/pr53465.c":18:18
11 {*cmpsi_1}
 (nil))


In insn 23, replacing
 (compare:CCGC (reg/v:SI 88 [ d ])
(reg/v:SI 83 [ c ]))
 with (compare:CCGC (reg/v:SI 88 [ d ])
(reg/v:SI 88 [ d ]))

it looks like it forwards the copy in insn 14 across the setter of 88 in insn
15!?  Note that 88 is initially undefined!

In fwprop use_killed_between returns false because of the following which
is of course bogus if you consider backedges and coalescing with
uninitialized regs.  That is, what applies to hard regs also applies
to regs that are used uninitialized.

  /* Check if the reg in USE has only one definition.  We already
 know that this definition reaches use, or we wouldn't be here.
 However, this is invalid for hard registers because if they are
 live at the beginning of the function it does not mean that we
 have an uninitialized access.  */
  regno = DF_REF_REGNO (use);
  def = DF_REG_DEF_CHAIN (regno);
  if (def
  && DF_REF_NEXT_REG (def) == NULL
  && regno >= FIRST_PSEUDO_REGISTER)
return false;

So maybe this is what triggers the issue - the copy that is inserted
references an uninitialized value (well, on SSA the PHI node constitutes
a copy from that uninit value already).

Eric, you added partitions_for_undefined_values and IIRC that was just narrow
scope enough to fix a specific issue but not generally address shortcomings
within RTL?

[Bug c++/87861] New: [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165

2018-11-02 Thread sch...@linux-m68k.org

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

Bug ID: 87861
   Summary: [9 regression] ICE in
output_constructor_regular_field, at varasm.c:5165
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: polacek at redhat dot com
  Target Milestone: ---
Target: ia64-*-*

libtool: compile:  /usr/local/gcc/gcc-20180919/Build/./gcc/xgcc -shared-libgcc
-B/usr/local/gcc/gcc-20180919/Build/./gcc -nostdinc++
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/src/.libs
-L/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/libsupc++/.libs
-B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem
/usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include
-fno-checking -I/usr/local/gcc/gcc-20180919/libstdc++-v3/../libgcc
-I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include/ia64-suse-linux
-I/usr/local/gcc/gcc-20180919/Build/ia64-suse-linux/libstdc++-v3/include
-I/usr/local/gcc/gcc-20180919/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=bad_typeid.lo -O2 -g -D_GNU_SOURCE -c
../../../../libstdc++-v3/libsupc++/bad_typeid.cc  -fPIC -DPIC -D_GLIBCXX_SHARED
-o bad_typeid.o
../../../../libstdc++-v3/libsupc++/bad_typeid.cc:36:1: internal compiler error:
in output_constructor_regular_field, at varasm.c:5165
36 | } // namespace std
   | ^
0x4176abaf output_constructor_regular_field
../../gcc/varasm.c:5165
0x4176d09f output_constructor
../../gcc/varasm.c:5475
0x4176940f output_constant
../../gcc/varasm.c:4967
0x4175414f assemble_variable_contents
../../gcc/varasm.c:2143
0x4175586f assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2319
0x417a564f varpool_node::assemble_decl()
../../gcc/varpool.c:586
0x417a74cf symbol_table::output_variables()
../../gcc/varpool.c:752
0x407b806f symbol_table::compile()
../../gcc/cgraphunit.c:2611
0x407bd8ef symbol_table::compile()
../../gcc/cgraphunit.c:2791
0x407bd8ef symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2788

(gdb) up
#1  0x4176abb0 in output_constructor_regular_field (
local=0x600ee920) at ../../gcc/varasm.c:5165
5165gcc_assert (fieldpos == local->total_bytes);
(gdb) p fieldpos
$1 = 16
(gdb) p local->total_bytes
$2 = 24

[Bug rtl-optimization/87678] Redundant vmovss with -fPIC

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

--- Comment #3 from Uroš Bizjak  ---
Another similar problem:

__m128
bar (__m128 x)
{
  return x + _mm_set1_ps (2.3f);
}

gcc -O2 -msse2 creates following _combine dump:

--cut here--
Trying 6 -> 7:
6: r85:V4SF=[`*.LC0']
  REG_EQUAL const_vector
7: r84:V4SF=r86:V4SF+r85:V4SF
  REG_DEAD r86:V4SF
  REG_DEAD r85:V4SF
Failed to match this instruction:
(set (reg:V4SF 84)
(plus:V4SF (reg:V4SF 86)
(const_vector:V4SF [
(const_double:SF 2.299523162841796875e+0 [0x0.93p+2])
repeated x4
])))

Trying 6 -> 7:
6: r85:V4SF=const_vector
  REG_EQUAL const_vector
7: r84:V4SF=r86:V4SF+r85:V4SF
  REG_DEAD r86:V4SF
  REG_DEAD r85:V4SF
Failed to match this instruction:
(set (reg:V4SF 84)
(plus:V4SF (reg:V4SF 86)
(const_vector:V4SF [
(const_double:SF 2.299523162841796875e+0 [0x0.93p+2])
repeated x4
])))
--cut here--

Please note that the compiler tries to combine insns twice, once with:

6: r85:V4SF=[`*.LC0']
  REG_EQUAL const_vector

and the second time with:

6: r85:V4SF=const_vector
  REG_EQUAL const_vector

However, memory operand is never propagated, although the pattern would accept
one.

[Bug c++/70380] SFINAE error with constexpr expressions referencing a non-const variable

2018-11-02 Thread redi at gcc dot gnu.org

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

--- Comment #3 from Jonathan Wakely  ---
Both Clang and EDG also reject the same two statements.

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

2018-11-02 Thread fiesh at zefix dot tv

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

--- Comment #4 from fiesh at zefix dot tv ---
Heh ok, you tricked me ;)

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

2018-11-02 Thread ville.voutilainen at gmail dot com

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

--- Comment #3 from Ville Voutilainen  ---
The fix is not quite right. I'll do a more intrusive one. Stay tuned.

[Bug libstdc++/87855] std::optional only copy-constructible if T is trivially copy-constructible

2018-11-02 Thread fiesh at zefix dot tv

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

--- Comment #2 from fiesh at zefix dot tv ---
This fixes the problem.  Thank you so much for your effort!

[Bug sanitizer/87857] case label does not reduce to an integer constant

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

--- Comment #4 from Jakub Jelinek  ---
The reason you get an error is that the expression isn't constant, because it
needs to emit the runtime diagnostics.  Just fix the bug and get away with
that?  1U<<31 will do.

[Bug middle-end/87854] [9 Regression] gcc.c-torture/compile/pr46534.c ICE for 16-bit size_t

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

Richard Biener  changed:

   What|Removed |Added

 Target||msp430, avr
 CC||law at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug middle-end/87852] [9 Regression] FAIL: gcc.c-torture/execute/pr53465.c

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will investigate.

[Bug fortran/87851] [8/9 Regression] Wrong return type for len_trim

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug middle-end/64928] [7/8/9 Regression] Inordinate cpu time and memory usage in "phase opt and generate" with -ftest-coverage -fprofile-arcs

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

--- Comment #27 from Richard Biener  ---
Btw, on trunk for the small testcase the main peak memory user is

Bitmaps LeakPeak   
Times  N searches Search iter  Type

...
tree-ssa-live.c:931 (new_tree_live_info) 4089900520: 42.6%4089900600
102257849: 11.3%   35539   42909  heap
tree-ssa-live.c:932 (new_tree_live_info) 4099840160: 42.7%4099840200
103153730: 11.4%  326917   98706  heap

Total9592285400 
906070505

that's livein/liveout.  SSA conflicts are probably similar but harder
to decipher from the stats:

tree-ssa-coalesce.c:586 (ssa_conflicts_add_one)   43056:  0.0%198672   
398160:  0.0%   19205   39415  heap

next top is

df-problems.c:4400 (df_md_alloc)  218129480:  2.3% 218146320  
5654706:  0.6%   71264  127594  heap
df-problems.c:4401 (df_md_alloc)  218142960:  2.3% 218159920  
5640467:  0.6%   71675  127395  heap

[Bug c++/81486] Class template argument deduction fails with (), succeeds with {}

2018-11-02 Thread ted at lyncon dot se

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

Ted Lyngmo  changed:

   What|Removed |Added

 CC||ted at lyncon dot se

--- Comment #3 from Ted Lyngmo  ---
A comparison between g++ 8.2 and clang++ 6.0.1

g++ -fsanitize=undefined -std=c++17 -Wall -Wextra -Wshadow -Weffc++ -pedantic
-pedantic-errors -Wc++14-compat -Wc++17-compat -c test.cpp
clang++ -fsanitize=undefined -std=c++17 -Wall -Wextra -Wshadow -Weffc++
-pedantic -pedantic-errors -Wc++14-compat -Wc++17-compat -c test.cpp

#include 

std::less lt_g;
std::greater gt_g;
// ok in g++ 8.2
// clang++ 6.0.1:
//  error: declaration of variable 'lt' with deduced type 'std::less' requires
an initializer
//  error: declaration of variable 'gt' with deduced type 'std::greater'
requires an initializer

auto lt_c = std::less();
auto gt_c = std::greater();
// ok in clang++ 6.0.1
// g++ 8.2:
//  error: cannot deduce template arguments for ‘less’ from ()
//  error: cannot deduce template arguments for ‘greater’ from ()

auto lt_b = std::less{};
auto gt_b = std::greater{};
// ok in both

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

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

Martin Liška  changed:

   What|Removed |Added

URL||https://reviews.llvm.org/D5
   ||4030

--- Comment #1 from Martin Liška  ---
Patch candidate has been sent to upstream of libsanitizer:
https://reviews.llvm.org/D54030

[Bug tree-optimization/87849] Missed optimization: useless for-loop must be eliminated

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-02
 CC||matz at gcc dot gnu.org
  Component|c++ |tree-optimization
Version|tree-ssa|9.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  I think the only realistic way to prove this is to fuse the loops
and then see

 l = max(min(l, x), x);

Thus - loop fusion required.

[Bug tree-optimization/87848] [9 Regression] internal compiler error: in compare_range_with_value, at vr-values.c:1665

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||aldyh at gcc dot gnu.org
   Target Milestone|--- |9.0

[Bug ipa/87843] [9 Regression] SPEC miscompilation of 403.gcc and 502.gcc_r benchmarks

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

--- Comment #6 from Richard Biener  ---
If we have less MEM_REFs then we probably strip them because we think they
reference equal types.

I think I already told you that given that MEM_REFs use pointer types
to carry alignment info _those_ may not become incomplete!  But I didn't
expect that to cause wrong-code but missed optimizations.

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-02
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug sanitizer/87860] New: [9 Regression] libsanitizer build fails on sparc64-linux-gnu

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

Bug ID: 87860
   Summary: [9 Regression] libsanitizer build fails on
sparc64-linux-gnu
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Error message:

libtool: compile: 
/home/marxin/Programming/gcc/gcc-9.0.0+r265711/objdir/./gcc/xgcc -shared-libgcc
-B/home/marxin/Programming/gcc/gcc-9.0.0+r265711/objdir/./gcc -nostdinc++
-L/home/marxin/Programming/gcc/gcc-9.0.0+r265711/objdir/sparc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/marxin/Programming/gcc/gcc-9.0.0+r265711/objdir/sparc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/marxin/Programming/gcc/gcc-9.0.0+r265711/objdir/sparc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../libsanitizer/sanitizer_common -I.. -I
../../../../libsanitizer/include -isystem
../../../../libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/sparc64-unknown-linux-gnu
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I
../../../../libsanitizer/../include -include
../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -D_GNU_SOURCE
-MT sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc  -fPIC -DPIC -o
.libs/sanitizer_linux.o
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
‘void* __sanitizer::internal_start_thread(void (*)(void*), void*)’:
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1733:58: warning:
cast between incompatible function types from ‘void (*)(void*)’ to ‘void*
(*)(void*)’ [-Wcast-function-type]
 1733 |   real_pthread_create(, nullptr, (void*(*)(void *arg))func, arg);
  |  ^~~~
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In function ‘void
__sanitizer::GetPcSpBp(void*, __sanitizer::uptr*, __sanitizer::uptr*,
__sanitizer::uptr*)’:
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1962:31: error:
‘struct mcontext_t’ has no member named ‘gregs’; did you mean ‘mc_gregs’?
 1962 |   *pc = ucontext->uc_mcontext.gregs[REG_PC];
  |   ^
  |   mc_gregs
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:1963:31: error:
‘struct mcontext_t’ has no member named ‘gregs’; did you mean ‘mc_gregs’?
 1963 |   *sp = ucontext->uc_mcontext.gregs[REG_O6];
  |   ^
  |   mc_gregs
make[4]: *** [Makefile:663: sanitizer_linux.lo] Error 1

It comes from libsanitizer merge. I have a patch for it.

[Bug tree-optimization/87776] [9 Regression] Compile time hog during RPO VN

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

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

Richard Biener  changed:

   What|Removed |Added

 Target||sparc
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-11-02
  Component|c   |middle-end
  Known to work||4.9.4
Version|6.4.0   |7.3.0
 Ever confirmed|0   |1
  Known to fail||7.3.0

--- Comment #1 from Richard Biener  ---
Note GCC 6 is no longer supported.  Can you inspect with gdb and see if this is
an unaligned access?

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> That is unfortunately too hard, because there are just too many places where
> the FEs can construct these.
> That said, having one macro like TYPE_OVERFLOW_UNDEFINED that would combine
> that and !TYPE_OVERFLOW_SANITIZED for that type might make things easier.

But then we go back to that tri-state of -fno-strict-overflow we had before...

Thus, !TYPE_OVERFLOW_UNDEFINED doesn't imply TYPE_OVERFLOW_WRAPS (ok, -ftrapv
"breaks" that as well, but -ftrapv should instrument ops IMHO and in reality
we need some IL representation of UNDEFINED vs. WRAPS as well).

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug tree-optimization/87859] New: [8/9 Regression] store-merging miscompilation of mesa

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

Bug ID: 87859
   Summary: [8/9 Regression] store-merging miscompilation of mesa
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct S {
  union F {
struct T {
#define A(n) unsigned n:1;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) \
 A(n##5) A(n##6) A(n##7) A(n##8) A(n##9)
  B(f) B(f1) B(f2) B(f3) B(f4) B(f5)
  A(f60) A(f61) A(f62) A(f63) A(f64) A(f65) A(f66)
} q;
unsigned int i[3];
  } f;
};

struct S s = {
  .f.q.f0 = 1, .f.q.f1 = 1, .f.q.f2 = 1, .f.q.f5 = 1, .f.q.f6 = 1,
  .f.q.f7 = 1, .f.q.f8 = 1, .f.q.f9 = 1, .f.q.f13 = 1, .f.q.f14 = 1,
  .f.q.f15 = 1, .f.q.f16 = 1, .f.q.f17 = 1, .f.q.f19 = 1, .f.q.f21 = 1,
  .f.q.f66 = 1
};

__attribute__((noipa)) void
bar (unsigned *x)
{
  if (x[0] != s.f.i[0] || x[1] != s.f.i[1] || x[2] != s.f.i[2])
__builtin_abort ();
}

__attribute__((noipa)) void
foo (unsigned char *state)
{
  struct S i;
  i.f.i[0] = 0;
  i.f.i[1] = 0;
  i.f.i[2] = 0;
  i.f.q.f7 = 1;
  i.f.q.f2 = 1;
  i.f.q.f21 = 1;
  i.f.q.f19 = 1;
  i.f.q.f14 = 1;
  i.f.q.f5 = 1;
  i.f.q.f0 = 1;
  i.f.q.f15 = 1;
  i.f.q.f16 = 1;
  i.f.q.f6 = 1;
  i.f.q.f9 = 1;
  i.f.q.f17 = 1;
  i.f.q.f1 = 1;
  i.f.q.f8 = 1;
  i.f.q.f13 = 1;
  i.f.q.f66 = 1;
  if (*state)
{
  i.f.q.f37 = 1;
  i.f.q.f38 = 1;
  i.f.q.f39 = 1;
  i.f.q.f40 = 1;
  i.f.q.f41 = 1;
  i.f.q.f36 = 1;
}
  bar (i.f.i);
}

int
main ()
{
  unsigned char z = 0;
  foo ();
  return 0;
}

started failing with r264232.

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

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

--- Comment #7 from Jakub Jelinek  ---
That is unfortunately too hard, because there are just too many places where
the FEs can construct these.
That said, having one macro like TYPE_OVERFLOW_UNDEFINED that would combine
that and !TYPE_OVERFLOW_SANITIZED for that type might make things easier.

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

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

--- Comment #6 from Richard Biener  ---
Just have to repeat that I very much dislike TYPE_OVERFLOW_SANITIZED being
sprinkled all over the place...  just instrument before folding things?

[Bug tree-optimization/83348] Missed optimization in math expression: can be used std::pow function

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

--- Comment #3 from Richard Biener  ---
Well, as said in the comment there's room for improvements.

[Bug tree-optimization/83353] Missed optimization in math expression: sin(asin(a)) == a

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

--- Comment #4 from Richard Biener  ---
So asin(sin(a)) would be a no-brainer but sin(asin(a)) needs to handle a being
outside of [-1,1].

[Bug d/87827] libgphobos.spec in the wrong place with --enable-version-specific-runtime-libs

2018-11-02 Thread ibuclaw at gcc dot gnu.org

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

--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Fri Nov  2 08:29:50 2018
New Revision: 265742

URL: https://gcc.gnu.org/viewcvs?rev=265742=gcc=rev
Log:
Fix libgphobos.spec in the wrong place with
--enable-version-specific-runtime-libs

libphobos/ChangeLog:

2018-11-01  Iain Buclaw  

PR d/87827
* Makefile.in: Rebuild.
* configure: Rebuild.
* configure.ac: Properly set MULTISUBDIR.
* d_rules.am: Set toolexecdir and toolexeclibdir.
* libdruntime/Makefile.in: Rebuild.
* m4/druntime.m4 (DRUNTIME_INSTALL_DIRECTORIES): Add
--enable-version-specific-runtime-libs.
* src/Makefile.in: Rebuild.
* testsuite/Makefile.in: Rebuild.

Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/Makefile.in
trunk/libphobos/configure
trunk/libphobos/configure.ac
trunk/libphobos/d_rules.am
trunk/libphobos/libdruntime/Makefile.in
trunk/libphobos/m4/druntime.m4
trunk/libphobos/src/Makefile.in
trunk/libphobos/testsuite/Makefile.in

[Bug tree-optimization/83352] Missed optimization in math expression: sqrt(sqrt(a)) == pow(a, 1/4)