[Bug c++/87594] constexpr rejects-valid code with range-based for-loop

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Oct 29 19:40:18 2018
New Revision: 265600

URL: https://gcc.gnu.org/viewcvs?rev=265600=gcc=rev
Log:
PR c++/87594 - constexpr rejects-valid with range-based for.
* constexpr.c (potential_constant_expression_1): If the condition
can't be evaluated, return true.

* g++.dg/cpp1y/constexpr-loop8.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-loop8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87594] constexpr rejects-valid code with range-based for-loop

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Kai Tietz from comment #16)
> > If you want to experiment, try the following patch:
> > 
> > Index: config/i386/mingw32.h
> > ===
> > --- config/i386/mingw32.h   (revision 265582)
> > +++ config/i386/mingw32.h   (working copy)
> > @@ -251,6 +251,10 @@
> >  #undef  CHECK_EXECUTE_STACK_ENABLED
> >  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
> >  
> > +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> > +#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
> > +  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> > +
> >  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
> >  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
> >  #if DWARF2_UNWIND_INFO> 
> > But I don't know the details of MS ABI, so I can't tell if the patch is
> > correct.
> 
> The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
> alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
> alignment on function entry is the natural one, but there is in general no
> strict requirement for it. So the patch looks fine, but should be commented
> in the release notes, as there might be fallout seen caused by it.

Unfortunately, I have no way of testing the patch on windows targets.

Please also note that the testcase still ICEs with patched compiler when
-mpreferred-stack-bonudary=4 option is used. Based on the comments in
emit-rtl.h:

  /* The largest alignment needed on the stack, including requirement
 for outgoing stack alignment.  */
  unsigned int stack_alignment_needed;

  /* Preferred alignment of the end of stack frame, which is preferred
 to call other functions.  */
  unsigned int preferred_stack_boundary;

it looks that somewhere stack_alignment_needed should be set to at least the
value of preferred_stack_boundary. Just above the assert in i386.c, there is:

  /* 64-bit MS ABI seem to require stack alignment to be always 16,
 except for function prologues, leaf functions and when the defult
 incoming stack boundary is overriden at command line or via
 force_align_arg_pointer attribute.  */
  if ((TARGET_64BIT_MS_ABI && crtl->preferred_stack_boundary < 128)
  && (!crtl->is_leaf || cfun->calls_alloca != 0
  || ix86_current_function_calls_tls_descriptor
  || ix86_incoming_stack_boundary < 128))
{
  crtl->preferred_stack_boundary = 128;
  crtl->stack_alignment_needed = 128;
}

so this maybe hints what to do in x86 case. Perhaps the patch in Comment #8 is
the way to go.

[Bug tree-optimization/87800] New: [9 Regression] CPU2006 416.gamess failed to build with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 87800
   Summary: [9 Regression] CPU2006 416.gamess failed to build with
LTO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r265457 caused:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64aldeci.fppized.o algnci.fppized.o
basecp.fppized.o basext.o bashuz.o bashz2.o basn21.fppized.o basn31.o
bassto.fppized.o blas.fppized.o ccaux.o ccsdt.fppized.o chgpen.fppized.o
cisgrd.fppized.o cosmo.fppized.o cphf.fppized.o cpmchf.o cprohf.fppized.o
ddi.fppized.o delocl.fppized.o dft.fppized.o dftaux.fppized.o dftexc.fppized.o
dftfun.o dftgrd.fppized.o dftint.fppized.o dgeev.o dmulti.fppized.o
drc.fppized.o dummygetenv.fppized.o ecp.fppized.o ecpder.fppized.o
ecplib.fppized.o ecppot.o efdrvr.fppized.o efelec.o efgrd2.fppized.o
efgrda.fppized.o efgrdb.fppized.o efgrdc.fppized.o efinp.fppized.o
efinta.fppized.o efintb.fppized.o efpaul.fppized.o efpcm.fppized.o
efpcov.fppized.o eigen.fppized.o eomcc.fppized.o ffield.fppized.o
frfmt.fppized.o fsodci.fppized.o gamess.fppized.o globop.fppized.o
gradex.fppized.o grd1.fppized.o grd2a.fppized.o grd2b.o grd2c.fppized.o
guess.fppized.o gugdga.fppized.o gugdgb.fppized.o gugdm.fppized.o
gugdm2.fppized.o gugdrt.fppized.o gugem.fppized.o gugsrt.fppized.o
gvb.fppized.o hess.fppized.o hss1a.fppized.o hss1b.fppized.o hss2a.fppized.o
hss2b.fppized.o inputa.fppized.o inputb.fppized.o inputc.fppized.o
int1.fppized.o int2a.fppized.o int2b.o iolib.fppized.o lagran.fppized.o
local.fppized.o loccd.fppized.o locpol.fppized.o mccas.fppized.o mcjac.o
mcpinp.fppized.o mcpint.fppized.o mcplib.o mcqdpt.fppized.o mcqdwt.o
mcqud.fppized.o mcscf.fppized.o mctwo.fppized.o morokm.fppized.o mp2.fppized.o
mp2ddi.fppized.o mp2grd.fppized.o mpcdat.o mpcgrd.fppized.o mpcint.fppized.o
mpcmol.fppized.o mpcmsc.fppized.o mthlib.fppized.o nameio.fppized.o
nmr.fppized.o olix.o ordint.fppized.o ormas1.fppized.o parley.fppized.o
pcm.fppized.o pcmcav.o pcmcv2.fppized.o pcmder.fppized.o pcmdis.fppized.o
pcmief.fppized.o pcmpol.fppized.o pcmvch.fppized.o prpel.fppized.o
prplib.fppized.o prppop.fppized.o qeigen.fppized.o qfmm.fppized.o
qmfm.fppized.o qmmm.fppized.o qrel.fppized.o raman.fppized.o rhfuhf.fppized.o
rxncrd.fppized.o ryspol.o scflib.fppized.o scfmi.fppized.o scrf.fppized.o
sobrt.fppized.o soffac.fppized.o solib.fppized.o sozeff.fppized.o
statpt.fppized.o surf.fppized.o symorb.fppized.o symslc.fppized.o
tdhf.fppized.o trans.fppized.o trfdm2.fppized.o trnstn.fppized.o
trudge.fppized.o umpddi.fppized.o unport.fppized.o vibanl.fppized.o
vscf.fppized.o zheev.fppized.o zmatrx.fppized.o -lm-o games
...
during GIMPLE pass: vect
grd2b.f: In function 'grdper.constprop':
grd2b.f:953: internal compiler error: in vect_build_slp_tree_2, at
tree-vect-slp.c:1128
0x6a9a06 vect_build_slp_tree_2
../../src-trunk/gcc/tree-vect-slp.c:1128
0xe3306c vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1057
0xe33ffd vect_build_slp_tree_2
../../src-trunk/gcc/tree-vect-slp.c:1208
0xe3306c vect_build_slp_tree
../../src-trunk/gcc/tree-vect-slp.c:1057
0xe39578 vect_analyze_slp_instance
../../src-trunk/gcc/tree-vect-slp.c:1940
0xe3aab0 vect_analyze_slp(vec_info*, unsigned int)
../../src-trunk/gcc/tree-vect-slp.c:2139
0xe23e76 vect_analyze_loop_2
../../src-trunk/gcc/tree-vect-loop.c:1881
0xe264e1 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
../../src-trunk/gcc/tree-vect-loop.c:2268
0xe3f98f try_vectorize_loop_1
../../src-trunk/gcc/tree-vectorizer.c:873
0xe40739 vectorize_loops()
../../src-trunk/gcc/tree-vectorizer.c:1097
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccA17T4q.mk:11: /tmp/gamess.EoWxwj.ltrans3.ltrans.o] Error 1

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
that gets us to a fail because of an ELF-specific section directive in atomic.d

 .section minfo

It looks like there's an OS_X-specific sections file there - but ISTM that the
configuration expansion of :

DRUNTIME_OS_MINFO_BRACKETING

doesn't have a Darwin version .. maybe there's code you can borrow from
elsewhere - I've not gone looking yet.

[Bug web/87803] New: GCC 6.5.0 release directory is misnamed

[ats-gccbugs at offog dot org]

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

Bug ID: 87803
   Summary: GCC 6.5.0 release directory is misnamed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ats-gccbugs at offog dot org
  Target Milestone: ---

I'm not sure this really counts as a bug in GCC as such, but...

Within ftp://ftp.gnu.org/gnu/gcc/, the subdirectory for each release is usually
named gcc-X.Y.Z - however, the subdirectory for GCC 6.5.0 is just called 6.5.0,
rather than gcc-6.5.0.

I spotted this because I have a packaging tool that scans for new releases, and
it wasn't picking up 6.5.0 because it didn't follow the usual pattern. I think
it'd be a good idea to rename the directory to match the others (but keep a
symlink called 6.5.0 in case anyone's already changed their packaging).

[Bug other/87802] New: [9 regression] g++.dg/vect/slp-pr87105.cc fails starting with r265522

[seurer at gcc dot gnu.org]

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

Bug ID: 87802
   Summary: [9 regression] g++.dg/vect/slp-pr87105.cc fails
starting with r265522
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am seeing this just on power 6 and 7 BE.


testgcc: Tried 265522
  testgcc: make -k check-gcc RUNTESTFLAGS=vect.exp=g++.dg/vect/slp-pr87105.cc


FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++14  scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++14  scan-tree-dump slp2
"vect_iftmp[^\rm]* = MIN"
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++17  scan-tree-dump-times slp2 "basic
block part vectorized" 1
FAIL: g++.dg/vect/slp-pr87105.cc  -std=c++17  scan-tree-dump slp2
"vect_iftmp[^\rm]* = MIN"

[Bug tree-optimization/87801] New: [9 Regression] CPU2006 454.calculix failed to build with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 87801
   Summary: [9 Regression] CPU2006 454.calculix failed to build
with LTO
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86-64, r265522 caused:

gfortran  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64CalculiX.o add_pr.o add_sm_ei.o
add_sm_st.o allocation.o amplitudes.o anisotropic.o beamsections.o bounadd.o
boundaries.o buckles.o calinput.o cfluxes.o changedepterm.o cloads.o
conductivities.o controlss.o couptempdisps.o creeps.o cychards.o cycsymmods.o
dasol.o datest.o datri.o defplasticities.o defplas.o densities.o depvars.o
deuldlag.o dfluxes.o dgesv.o diamtr.o dloads.o dot.o dredu.o dsort.o dynamics.o
dynsolv.o el.o elastics.o elements.o elprints.o envtemp.o equations.o
expansions.o extrapolate.o e_c3d.o e_c3d_th.o e_c3d_rhs.o fcrit.o films.o
finpro.o forcadd.o frd.fppized.o frdclose.o frequencies.o fsub.o fsuper.o
gen3delem.o genran.o getnewline.o graph.o headings.o heattransfers.o hyperel.o
hyperelastics.o hyperfoams.o ident.o ident2.o include.o incplas.o
initialconditions.o inputerror.o isorti.o isortid.o isortidc.o isortii.o
isortiid.o label.o linel.o lintemp.o lintemp_th.o loadadd.o loadaddt.o
mafillpr.o mafillsm.o mafillsmcs.o massflowrates.o matdata_co.o matdata_he.o
matdata_tg.o materialdata.o materials.o modaldampings.o modaldynamics.o mpcs.o
nident.o nident2.o near2d.o noanalysis.o nodalthicknesses.o nodeprints.o
nodes.o noelfiles.o noelsets.o nonlinmpc.o normals.o norshell.o number.o onf.o
op.o openfile.o orientations.o orthonl.o orthotropic.o out.o parser.o
physicalconstants.o planempc.o plastics.o plcopy.o plinterpol.o plmix.o
polynom.o profil.o radflowload.o radiates.o ranewr.o rearrange.o rectcyl.o
renumber.o restartread.o restarts.o restartshort.o restartwrite.o results.o
rhs.o rigidbodies.o rigidmpc.o rootls.o rubber.o saxpb.o selcycsymmods.o
shape3tri.o shape4q.o shape4tet.o shape6tri.o shape6w.o shape8h.o shape8q.o
shape10tet.o shape15w.o shape20h.o shellsections.o skip.o solidsections.o
spcmatch.o specificheats.o statics.o steps.o stiff2mat.o stop.o str2mat.o
straightmpc.o surfaces.o temperatures.o tempload.o ties.o transformatrix.o
transforms.o ucreep.o uhardening.o umat.o umat_aniso_creep.o umat_aniso_plas.o
umat_elastic_fiber.o umat_ideal_gas.o umat_lin_iso_el.o umat_single_crystal.o
umat_tension_only.o umat_user.o umpc_mean_rot.o umpc_user.o usermaterials.o
usermpc.o viscos.o wcoef.o writebv.o writeev.o writeevcs.o writempc.o
writesummary.o cascade.o frdcyc.o insert.o mastruct.o mastructcs.o nonlingeo.o
pcgsolver.o preiter.o prespooles.o profile.o remastruct.o spooles.o strcmp1.o
strcpy1.o u_calloc.o SPOOLES/A2/src/A2_IO.o SPOOLES/A2/src/A2_basics.o
SPOOLES/A2/src/A2_init.o SPOOLES/A2/src/A2_instance.o SPOOLES/A2/src/A2_norms.o
SPOOLES/A2/src/A2_sort.o SPOOLES/A2/src/A2_util.o SPOOLES/BKL/src/BKL_basics.o
SPOOLES/BKL/src/BKL_evalfcn.o SPOOLES/BKL/src/BKL_exhSearch.o
SPOOLES/BKL/src/BKL_fidmat.o SPOOLES/BKL/src/BKL_init.o
SPOOLES/BKL/src/BKL_util.o SPOOLES/BPG/src/BPG_IO.o
SPOOLES/BPG/src/BPG_basics.o SPOOLES/BPG/src/BPG_init.o
SPOOLES/BPG/src/BPG_makeGraphs.o SPOOLES/BPG/src/BPG_pseudo.o
SPOOLES/Chv/src/Chv_IO.o SPOOLES/Chv/src/Chv_assemble.o
SPOOLES/Chv/src/Chv_basics.o SPOOLES/Chv/src/Chv_copy.o
SPOOLES/Chv/src/Chv_factor.o SPOOLES/Chv/src/Chv_findPivot.o
SPOOLES/Chv/src/Chv_init.o SPOOLES/Chv/src/Chv_instance.o
SPOOLES/Chv/src/Chv_search.o SPOOLES/Chv/src/Chv_swap.o
SPOOLES/Chv/src/Chv_update.o SPOOLES/Chv/src/Chv_util.o
SPOOLES/ChvList/src/ChvList_basics.o SPOOLES/ChvList/src/ChvList_init.o
SPOOLES/ChvList/src/ChvList_util.o SPOOLES/ChvManager/src/ChvManager_basics.o
SPOOLES/ChvManager/src/ChvManager_init.o
SPOOLES/ChvManager/src/ChvManager_util.o SPOOLES/DSTree/src/DSTree_basics.o
SPOOLES/DSTree/src/DSTree_init.o SPOOLES/DSTree/src/DSTree_instance.o
SPOOLES/DSTree/src/DSTree_stages.o SPOOLES/DSTree/src/DSTree_util.o
SPOOLES/DV/src/DV_IO.o SPOOLES/DV/src/DV_basics.o SPOOLES/DV/src/DV_init.o
SPOOLES/DV/src/DV_instance.o SPOOLES/DV/src/DV_util.o
SPOOLES/DenseMtx/src/DenseMtx_IO.o SPOOLES/DenseMtx/src/DenseMtx_basics.o
SPOOLES/DenseMtx/src/DenseMtx_init.o SPOOLES/DenseMtx/src/DenseMtx_instance.o
SPOOLES/DenseMtx/src/DenseMtx_permute.o SPOOLES/DenseMtx/src/DenseMtx_util.o
SPOOLES/Drand/src/Drand_basics.o SPOOLES/Drand/src/Drand_init.o
SPOOLES/Drand/src/Drand_util.o SPOOLES/ETree/src/ETree_IO.o
SPOOLES/ETree/src/ETree_basics.o SPOOLES/ETree/src/ETree_compress.o
SPOOLES/ETree/src/ETree_init.o SPOOLES/ETree/src/ETree_instance.o
SPOOLES/ETree/src/ETree_permute.o SPOOLES/ETree/src/ETree_transform.o
SPOOLES/ETree/src/ETree_util.o 

[Bug d/87799] New: failure during bootstrap, fails to build d/filename.o

[rai...@emrich-ebersheim.de]

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

Bug ID: 87799
   Summary: failure during bootstrap, fails to build d/filename.o
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/./prev-gcc/xg++
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/./prev-gcc/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-9.0.0-test/x86_64-w64-mingw32/bin/
-nostdinc++
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs

-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32

-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/include
 -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/libstdc++-v3/libsupc++
-L/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/opt/devel/SCRATCH/tmp.I8jwTRKpzz/gcc-9.0.0-test/gcc-9.0.0-test/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-DHAVE_CONFIG_H -I. -Id
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../include
-I./../intl
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libcpp/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include 
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/../libbacktrace
-I/opt/devel/SCRATCH/tmp.I8jwTRKpzz/install/include  -o d/filename.o -MT
d/filename.o -MMD -MP -MF d/.deps/filename.TPo
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd
-Id
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static int FileName::exists(const char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:563:12:
warning: comparison of integer expressions of different signedness: 'DWORD'
{aka 'long unsigned int'} and 'long int' [-Wsign-compare]
  563 | if (dw == -1L)
  | ~~~^~
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static bool FileName::ensurePathExists(const
char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:589:51:
error: invalid const_cast from type 'const char*' to type 'void*'
  589 | {   mem.xfree(const_cast(p));
  |   ^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:
In static member function 'static const char* FileName::name(const char*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:280:34:
warning: this statement may fall through [-Wimplicit-fallthrough=]
  280 | if (e == str + 1 || e == str + len - 1)
  | ~^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/dmd/root/filename.c:283:13:
note: here
  283 | default:
  | ^~~
make[3]: ***
[../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-9.0.0-test/gcc/d/Make-lang.in:315:
d/filename.o] Error 1

[Bug libstdc++/59472] Many warnings "type of 'X' does not match original declaration" when linking with libstdc++ static library compiled with -flto

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I think it's worth keeping open for my suggestion in comment 3 (which I'd
forgotten about).

[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug c/87795] Excessive alignment permitted for functions and labels

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code
 Target||pdp11-aout
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-30
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
Confirmed.  I get the following output with a pdp11-aout configured
cross-compiler:

$ cat t.c && gcc -S -O2 -Wall t.c

int a2 __attribute__ ((aligned (2)));
int a4 __attribute__ ((aligned (4)));
int ag __attribute__ ((aligned (65536)));

void f2(void) __attribute__ ((aligned (2)));
void f4(void) __attribute__ ((aligned (4)));
void fg(void) __attribute__ ((aligned (65536)));

void f2(void) {}
void f4(void) {}
void fg(void) {}

t.c:2:5: error: alignment of ‘a4’ is greater than maximum object file alignment
2
2 | int a4 __attribute__ ((aligned (4)));
  | ^~
t.c:3:5: error: alignment of ‘ag’ is greater than maximum object file alignment
2
3 | int ag __attribute__ ((aligned (65536)));
  | ^~


After removing the variable declarations I get an ICE:

during RTL pass: final
t.c: In function ‘f4’:
t.c:6:1: internal compiler error: in assemble_start_function, at varasm.c:1801
6 | void f4(void) {}
  | ^~~~
0x1345817 assemble_start_function(tree_node*, char const*)
/ssd/src/gcc/svn/gcc/varasm.c:1801
0xaf2550 rest_of_handle_final
/ssd/src/gcc/svn/gcc/final.c:4645
0xaf28c2 execute
/ssd/src/gcc/svn/gcc/final.c:4723
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|mingw32-sjlj|x86 sjlj
 CC||hjl.tools at gmail dot com

--- Comment #18 from Uroš Bizjak  ---
Digging a bit deeper: the testcase from Comment #14:

__attribute__((__target__("rdrnd")))
void f(unsigned int * b) noexcept {
  __builtin_ia32_rdrand32_step(b);
}

also fails for all x86 targets when the compiler is configured with
--enable-sjlj-exceptions, so the failure is not mingw specific.

Following is x86_64-linux-gnu target:

cc1plus -O2 -mpreferred-stack-boundary=4 -quiet -fpreprocessed pr58372.C
during RTL pass: ira
pr58372.C: In function ‘void f(unsigned int*)’:
pr58372.C:4:5: internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11159
4 | }
  | ^
0x1821b24 ix86_compute_frame_layout
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:11159
0x128b447 set_initial_elim_offsets
...

-mpreferred-stack-boundary=3 (instead of 4) again "fixes" the ICE.

It looks that stack realignment doesn't work with SjLj exceptions. As shown in
Comment #15, building the call to _Unwind_SjLj_Register sets
crtl->preferred_stack_boundary to 128, but nothing updates
crtl->stack_alignment_needed. This leads to the shown assert failure.

HJ, do you have an idea what is going wrong with realignment here?

[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #6 from Harald Anlauf  ---
F2018 has the following:

8.2 Type declaration statement

A name that identifies a specific intrinsic function has a type as specified
in 16.8. An explicit type declaration statement is not  required; however, it
is permitted.   Specifying a type for a generic intrinsic function name in a
type declaration statement has no effect.


This coincides with what I see with Intel, NAG, PGI.

Thus: ICE on valid code.

[Bug c++/56856] -Wformat warnings don't show location *within* format string in C++ FE

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
Author: dmalcolm
Date: Mon Oct 29 23:44:10 2018
New Revision: 265609

URL: https://gcc.gnu.org/viewcvs?rev=265609=gcc=rev
Log:
Folding and check_function_arguments

This patch eliminates the arglocs array I introduced to build_over_call
in r264887, and eliminates the call to maybe_constant_value when building
"fargs" (thus retaining location wrapper nodes).

Instead, this patch requires that any checks within
check_function_arguments that need folded arguments do their own folding.

Of the various checks:
(a) check_function_nonnull already calls fold_for_warn,
(b) check_function_format doesn't need folding
(c) check_function_sentinel needs fold_for_warn in one place, which the
patch adds, and
(d) check_function_restrict needs per-argument folding, which the patch
adds.  Given that it scans before and after resetting TREE_VISITED on
each argument, it seemed best to make a copy of the array, folding each
argument from the outset, rather than repeatedly calling fold_for_warn;

gcc/c-family/ChangeLog:
PR c++/56856
* c-common.c (check_function_sentinel): Call fold_for_warn on the
argument.
(check_function_restrict): Rename param "argarray" to
"unfolded_argarray", and make a copy named "argarray", calling
fold_for_warn on each argument.
(check_function_arguments): Add note about responsibility for
folding the arguments.

gcc/cp/ChangeLog:
PR c++/56856
* call.c (build_over_call): Eliminate the "arglocs" array, and the
call to maybe_constant_value when building "fargs".


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/87721] [9 Regression] ICE in linemap_position_for_line_and_column at gcc/libcpp/line-map.c:842 since r265271

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r265611; marking as resolved.

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

[kugan at gcc dot gnu.org]

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

--- Comment #5 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Oct 29 22:02:45 2018
New Revision: 265605

URL: https://gcc.gnu.org/viewcvs?rev=265605=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2018-10-29  Kugan Vivekanandarajah  

PR middle-end/87469
* g++.dg/pr87469.C: New test.

gcc/ChangeLog:

2018-10-29  Kugan Vivekanandarajah  

PR middle-end/87469
* tree-ssa-loop-niter.c (number_of_iterations_popcount): Fix niter
max value.



Added:
trunk/gcc/testsuite/g++.dg/pr87469.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug web/87803] GCC 6.5.0 release directory is misnamed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Author: dmalcolm
Date: Mon Oct 29 23:58:34 2018
New Revision: 265611

URL: https://gcc.gnu.org/viewcvs?rev=265611=gcc=rev
Log:
Fix ICE in get_substring_ranges_for_loc on __FILE__ (PR c++/87721)

PR c++/87721 reports a crash in get_substring_ranges_for_loc introduced
by r265271, my fix for PR 87562.

The new issue occurs when attempting to get a location with a string
literal inside a macro in which the first token is __FILE__ (formed via
concatenation).  Attempting to get the spelling location of __FILE__
fails, leading to NULL for start_ord_map and final_ord_map, and thus
a NULL pointer dereference.

Given that our "on-demand" substring locations approach reparses the
string literals, there isn't a good way to access the locations inside
such string literals: attempting to reparse __FILE__ fails with a
"missing open quote".

This patch applies the easy fix by gracefully rejecting the case where
the spelling locations for the start or finish give us NULL maps.

gcc/ChangeLog:
PR c++/87721
* input.c (get_substring_ranges_for_loc): Detect if
linemap_resolve_location gives us a NULL map, and reject
this case.

gcc/testsuite/ChangeLog:
PR c++/87721
* c-c++-common/substring-location-PR-87721.c: New test.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Add test for
PR 87721.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
(test_string_literals): Fold the index arguments before checking
for INTEGER_CST.


Added:
trunk/gcc/testsuite/c-c++-common/substring-location-PR-87721.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_string_literals.c

[Bug c++/87721] [9 Regression] ICE in linemap_position_for_line_and_column at gcc/libcpp/line-map.c:842 since r265271

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Mon Oct 29 23:58:34 2018
New Revision: 265611

URL: https://gcc.gnu.org/viewcvs?rev=265611=gcc=rev
Log:
Fix ICE in get_substring_ranges_for_loc on __FILE__ (PR c++/87721)

PR c++/87721 reports a crash in get_substring_ranges_for_loc introduced
by r265271, my fix for PR 87562.

The new issue occurs when attempting to get a location with a string
literal inside a macro in which the first token is __FILE__ (formed via
concatenation).  Attempting to get the spelling location of __FILE__
fails, leading to NULL for start_ord_map and final_ord_map, and thus
a NULL pointer dereference.

Given that our "on-demand" substring locations approach reparses the
string literals, there isn't a good way to access the locations inside
such string literals: attempting to reparse __FILE__ fails with a
"missing open quote".

This patch applies the easy fix by gracefully rejecting the case where
the spelling locations for the start or finish give us NULL maps.

gcc/ChangeLog:
PR c++/87721
* input.c (get_substring_ranges_for_loc): Detect if
linemap_resolve_location gives us a NULL map, and reject
this case.

gcc/testsuite/ChangeLog:
PR c++/87721
* c-c++-common/substring-location-PR-87721.c: New test.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Add test for
PR 87721.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
(test_string_literals): Fold the index arguments before checking
for INTEGER_CST.


Added:
trunk/gcc/testsuite/c-c++-common/substring-location-PR-87721.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_string_literals.c

[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

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

[Bug libstdc++/87787] New: [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Bug ID: 87787
   Summary: [9 Regression] runtime error: null pointer passed as
argument 2, which is declared to never be null
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jwakely.gcc at gmail dot com
  Target Milestone: ---

Would be also a recent regression. I see following for ubsan-bootstrapped
compiler:

$ make check RUNTESTFLAGS="gcov.exp=gcov-pr86536.c"
...

Creating 'gcov-pr86536.c.gcov'
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:907:24:
runtime error: null pointer passed as argument 2, which is declared to never be
null
#0 0x460a82 in std::enable_if::value, char const**>::type std::__relocate_a_1(char const**, char const**, char const**, std::allocator&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:907
#1 0x460a82 in char const** std::__relocate_a >(char const**, char const**, char const**,
std::allocator&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_uninitialized.h:938
#2 0x460a82 in void std::vector
>::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:464
#3 0x41dae9 in void std::vector
>::emplace_back(char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/vector.tcc:122
#4 0x41dae9 in std::vector
>::push_back(char const*&&)
/home/mliska/Programming/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1164
#5 0x41dae9 in output_lines ../../gcc/gcov.c:2973
#6 0x4229a7 in output_gcov_file ../../gcc/gcov.c:1284
#7 0x4229a7 in generate_results ../../gcc/gcov.c:1389
#8 0x40e4f9 in main ../../gcc/gcov.c:813
#9 0x7ffa344f9724 in __libc_start_main (/lib64/libc.so.6+0x20724)
#10 0x410248 in _start
(/home/mliska/Programming/gcc/objdir/gcc/gcov+0x410248)

It's about pushing a 'const char *' into a vector, I hope the usage is fine in
gcov.c. Jonathan can you please take a look?

[Bug bootstrap/87788] New: [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[iains at gcc dot gnu.org]

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

Bug ID: 87788
   Summary: [9 Regression] Bootstrap fails for
x86_64-apple-darwin* with default languages selection
after D addition.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

bootstrap fails at stage #2 with:

../../src/gcc/d/dmd/constfold.c: In function 'UnionExp Cast(Loc, Type*, Type*,
Expression*)':
../../src/gcc/d/dmd/constfold.c:1162:50: error: conversion from 'real_t' {aka
'longdouble'} to 'sinteger_t' {aka 'long int'} is ambiguous
 1162 | result = (d_int8)(sinteger_t)r;
  |  ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1166:50: error: conversion from 'real_t' {aka
'longdouble'} to 'dinteger_t' {aka 'long unsigned int'} is ambiguous
 1166 | result = (d_uns8)(dinteger_t)r;
  |  ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1169:51: error: conversion from 'real_t' {aka
'longdouble'} to 'sinteger_t' {aka 'long int'} is ambiguous
 1169 | result = (d_int16)(sinteger_t)r;
  |   ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: note: candidate: 'longdouble::operator
uint32_t()'
   60 |   operator uint32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:63:3: note: candidate: 'longdouble::operator
uint64_t()'
   63 |   operator uint64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:66:3: note: candidate: 'longdouble::operator
bool()'
   66 |   operator bool (void)
  |   ^~~~
../../src/gcc/d/dmd/constfold.c:1173:51: error: conversion from 'real_t' {aka
'longdouble'} to 'dinteger_t' {aka 'long unsigned int'} is ambiguous
 1173 | result = (d_uns16)(dinteger_t)r;
  |   ^
In file included from ../../src/gcc/d/dmd/root/ctfloat.h:11,
 from ../../src/gcc/d/dmd/globals.h:14,
 from ../../src/gcc/d/dmd/errors.h:13,
 from ../../src/gcc/d/dmd/constfold.c:22:
../../src/gcc/d/longdouble.h:54:3: note: candidate: 'longdouble::operator
int32_t()'
   54 |   operator int32_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:57:3: note: candidate: 'longdouble::operator
int64_t()'
   57 |   operator int64_t (void)
  |   ^~~~
../../src/gcc/d/longdouble.h:60:3: 

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to David Grayson from comment #14)

> Does anyone have an idea of how to fix this bug for real?  What values
> should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> have  on Windows, and should they be controllable from the command-line? 
> Where do they get set?
> 
> --David

Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
(gdb) watch x_rtl.preferred_stack_boundary 

Hardware watchpoint 1: x_rtl.preferred_stack_boundary

(gdb) r
Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
Hardware watchpoint 1: x_rtl.preferred_stack_boundary

Old value = 0
New value = 32
0x00b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0 )
at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
6636  preferred_stack_boundary = STACK_BOUNDARY;

Hardware watchpoint 1: x_rtl.preferred_stack_boundary

Old value = 32
New value = 128
emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type, machine_mode,
int, std::pair*) ()
at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
4744  if (outmode != VOIDmode)

(gdb) list
4739  if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
4740crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
4741
4742  /* If this kind of value comes back in memory,
4743 decide where in memory it should come back.  */
4744  if (outmode != VOIDmode)
4745{
4746  tfom = lang_hooks.types.type_for_mode (outmode, 0);
4747  if (aggregate_value_p (tfom, 0))
4748{

This happen when building SjLj landing pads:

#0  emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
() at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
#1  0x00b9b36c in emit_library_call (arg1_mode=,
arg1=, outmode=E_VOIDmode, 
fn_type=LCT_NORMAL, fun=) at
/home/uros/gcc-svn/trunk/gcc/rtl.h:4123
#2  sjlj_emit_function_enter(rtx_code_label*) () at
/home/uros/gcc-svn/trunk/gcc/except.c:1202
#3  0x00b9f20a in sjlj_build_landing_pads () at
/home/uros/gcc-svn/trunk/gcc/except.c:1481
#4  finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510

Adding -mpreferred-stack-boundary=2 "fixes" compilation.

If you want to experiment, try the following patch:

Index: config/i386/mingw32.h
===
--- config/i386/mingw32.h   (revision 265582)
+++ config/i386/mingw32.h   (working copy)
@@ -251,6 +251,10 @@
 #undef  CHECK_EXECUTE_STACK_ENABLED
 #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable

+#undef PREFERRED_STACK_BOUNDARY_DEFAULT
+#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
+  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
+
 /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
 /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
 #if DWARF2_UNWIND_INFO

But I don't know the details of MS ABI, so I can't tell if the patch is
correct.

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

[tnfchris at gcc dot gnu.org]

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

--- Comment #40 from Tamar Christina  ---
> In most practical cases -B../../ is just redundant with $(CXX).  It's only 
> when you configure like Richard that you may run into issues, but then we can 
> assume that we're on Linux so the paths are OK I think.

Ah ok, I'll update to trunk and run a bootstrap today then and submit a patch
tomorrow. Thanks!

--- Comment #41 from Tamar Christina  ---
Author: tnfchris
Date: Mon Oct 29 09:45:50 2018
New Revision: 265583

URL: https://gcc.gnu.org/viewcvs?rev=265583=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:

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


Modified:
trunk/gnattools/ChangeLog
trunk/gnattools/Makefile.in

[Bug c++/87791] New: Unnecessary zero-initialization of constexpr unions in arrays

[widlundtobias at gmail dot com]

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

Bug ID: 87791
   Summary: Unnecessary zero-initialization of constexpr unions in
arrays
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: widlundtobias at gmail dot com
  Target Milestone: ---

Created attachment 44918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44918=edit
Preprocessed code

Given a type that uses a constexpr-enabled union to store either a value, or an
empty dummy struct as followed.


>struct Container
>{
>struct Dummy{};
>union Storage
>{   
>constexpr Storage(): dummy(Dummy())
>{   
>
>}   
>Dummy dummy;
>int value;
>};  
>
>Storage storage;
>};

This code is a legal way to initialise the union with nothing, meaning that
it's legal for the compiler to leave the data uninitialised, even in constexpr
contexts.

However, if the above Container type is used like so:

>using Arr = std::array;
>
>Arr makeA()
>{
>Arr a;
>return a;
>}

Then the compiled code fills the array with zeroes, using memset.

Excerpt from compiled code:

>_Z5makeAv:
>.LFB1099:
>.cfi_startproc
>subq$8, %rsp
>.cfi_def_cfa_offset 16
>movl$16000, %edx
>xorl%esi, %esi
>callmemset@PLT   addq$8, %rsp
>.cfi_def_cfa_offset 8
>ret 
>.cfi_endproc
>.LFE1099:
>.size   _Z5makeAv, .-_Z5makeAv
>.section.text.startup,"ax",@progbits
>.p2align 4,,15
>.globl  main
>.type   main, @function

This is unnecessary and problematic as it incurs runtime overhead when using
the union-based storage as a way to store items that can possibly be
uninitialised, as a constexpr-friendly alternative to placement-new.

Happens even with -O3 and only happens if the `constexpr` keyword is present.

Preprocessed code attached.

Godbolt CE link for illustrative purpose: https://godbolt.org/z/FPnEy3




Output of gcc -v -save-temps -O3 main.cpp:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20180831 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -O3 -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -O3 -version -o
main.s
GNU C++14 (GCC) version 8.2.1 20180831 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180831, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.2.1 20180831 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20180831, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a03a3250bc7a24a525a6f08bf70a1ad6
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic' '-march=x86-64'
 as -v --64 -o main.o main.s
GNU assembler version 2.31.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.31.1

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
The same can be seen on 526.blender_r with: -Ofast -g -flto=8 -march=znver1

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Marc Glisse from comment #1)
> That would be my recent commit. We will probably need to add if(size!=0) in
> front of the call to memmove...

That's what we already do in stl_algobase.h and fstream.tcc. I notice that we
do not do it in char_traits.h for the generic version (we do for each
specialization). I don't know if memcpy in locale_facets.h is safe either.

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0

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

[Bug fortran/87782] New: runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'[9 Regression]

[marxin at gcc dot gnu.org]

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

Bug ID: 87782
   Summary: runtime error: load of value 1818451807, which is not
a valid value for type 'expr_t'[9 Regression]
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

It's a recent regression I believe. Using ubsan compiler one can see:

$ UBSAN_OPTIONS=print_stacktrace=1 gcc
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-ubsan/build/gcc/testsuite/gfortran.dg/deferred_character_23.f90
../../gcc/fortran/frontend-passes.c:660:46: runtime error: load of value
1818451807, which is not a valid value for type 'expr_t'
#0 0xf0a979 in constant_string_length
../../gcc/fortran/frontend-passes.c:660
#1 0xf0c907 in create_var ../../gcc/fortran/frontend-passes.c:823
#2 0xf07b5c in realloc_string_callback
../../gcc/fortran/frontend-passes.c:299
#3 0xf32069 in gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*,
void*), int (*)(gfc_expr**, int*, void*), void*)
../../gcc/fortran/frontend-passes.c:5073
#4 0xf149e2 in realloc_strings ../../gcc/fortran/frontend-passes.c:1517
#5 0xf14b4c in realloc_strings ../../gcc/fortran/frontend-passes.c:1522
#6 0xf0709f in gfc_run_passes(gfc_namespace*)
../../gcc/fortran/frontend-passes.c:179
#7 0xbb8898 in gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16736
#8 0xae429f in gfc_parse_file() ../../gcc/fortran/parse.c:6266
#9 0xc59435 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
#10 0x2444c25 in compile_file ../../gcc/toplev.c:455
#11 0x244da89 in do_compile ../../gcc/toplev.c:2172
#12 0x244e1cf in toplev::main(int, char**) ../../gcc/toplev.c:2307
#13 0x4971b0e in main ../../gcc/main.c:39
#14 0x7608cfea in __libc_start_main ../csu/libc-start.c:308
#15 0x8669a9 in _start
(/home/marxin/bin/gcc2/lib/gcc/x86_64-pc-linux-gnu/9.0.0/f951+0x8669a9)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug tree-optimization/87785] New: [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[marxin at gcc dot gnu.org]

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

Bug ID: 87785
   Summary: [9 Regression] ICE in dr_misalignment, at
tree-vectorizer.h:1245 on 454.calculix with -Ofast and
-flto
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

I see following ICE on a Haswell machine:

during GIMPLE pass: vect
SPOOLES/SubMtx/src/SubMtx_solve.c: In function 'SubMtx_solve':
SPOOLES/SubMtx/src/SubMtx_solve.c:45:1: internal compiler error: in
dr_misalignment, at tree-vectorizer.h:1245
   45 | SubMtx_solve (
  | ^
0x783bf2 dr_misalignment(dr_vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vectorizer.h:1245
0x784cf4 dr_misalignment(dr_vec_info*)
/home/marxin/Programming/gcc/gcc/tree.h:3232
0x784cf4 aligned_access_p
/home/marxin/Programming/gcc/gcc/tree-vectorizer.h:1263
0x784cf4 vect_supportable_dr_alignment(dr_vec_info*, bool)
/home/marxin/Programming/gcc/gcc/tree-vect-data-refs.c:6324
0xe85f6d vect_get_load_cost(_stmt_vec_info*, int, bool, unsigned int*, unsigned
int*, vec*, vec*, bool)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:1231
0xe9f21d vect_model_load_cost
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:1205
0xe9f21d vectorizable_load
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:7595
0xea3ab2 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*,
vec*)
/home/marxin/Programming/gcc/gcc/tree-vect-stmts.c:9568
0xecc346 vect_slp_analyze_node_operations_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2457
0xecc346 vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2504
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xecc23d vect_slp_analyze_node_operations
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2495
0xed09ae vect_slp_analyze_operations(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2536
0xed3371 vect_slp_analyze_bb_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2844
0xed3371 vect_slp_bb(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.c:2931
0xed87c9 try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.c:926


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug debug/87772] Crash with variadic template, constexpr constructor for templated non-literal type, using declaration

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
  Component|c++ |debug
 Ever confirmed|0   |1
  Known to fail||7.3.1, 8.2.1, 9.0

--- Comment #1 from Richard Biener  ---
Confirmed.  GCC 7 fails the same way, GCC 6 doesn't like the testcase.

> g++-8 t.ii -std=c++17 -g -B /abuild/rguenther/gcc8-g/gcc
main.cpp: In instantiation of ‘struct
Parser, 1>, 1> >’:
main.cpp:24:53:   required from here
main.cpp:16:8: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in equate_type_number_to_die, at dwarf2out.c:5773
0x164f511 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/space/rguenther/src/svn/gcc-8-branch/gcc/tree.c:9384
0x848ea8 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/space/rguenther/src/svn/gcc-8-branch/gcc/tree.h:3262
0xd4bc9b equate_type_number_to_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:5773
0xd8099e gen_typedef_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:25197
0xd83ad7 gen_decl_die
/space/rguenther/src/svn/gcc-8-branch/gcc/dwarf2out.c:26215

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/87779] Extremely large expression causes segfault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
Version|unknown |8.2.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It simply runs out of stack (recursing).  Raising the process stack limit with
ulimit -s unlimited makes it work quickly:

> /usr/bin/time gcc-8 t.c
0.22user 0.18system 0:00.40elapsed 99%CPU (0avgtext+0avgdata
352956maxresident)k
0inputs+960outputs (0major+89197minor)pagefaults 0swaps


(gdb) bt
#0  0x01d72282 in LINEMAPS_MACRO_LOWEST_LOCATION (set=0x77fef000)
at
/space/rguenther/src/svn/gcc-8-branch/gcc/../libcpp/include/line-map.h:1004
#1  0x01d95d9e in linemap_location_from_macro_expansion_p (
set=0x77fef000, location=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:1256
#2  0x01d954a1 in linemap_lookup (set=0x77fef000, line=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:946
#3  0x01d94104 in pure_location_p (set=0x77fef000, loc=19837408)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:310
#4  0x01d93bd8 in get_combined_adhoc_loc (set=0x77fef000, 
locus=19837408, src_range=..., data=0x0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/line-map.c:177
#5  0x013d7e99 in COMBINE_LOCATION_DATA (set=0x77fef000, 
loc=19837408, src_range=..., block=0x0)
at
/space/rguenther/src/svn/gcc-8-branch/gcc/../libcpp/include/line-map.h:1054
#6  0x01d9269a in _cpp_lex_direct (pfile=0x2ba35a0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/lex.c:3161
#7  0x01d9106f in _cpp_lex_token (pfile=0x2ba35a0)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/lex.c:2597
#8  0x01d9c6ad in cpp_get_token_1 (pfile=0x2ba35a0, 
location=0x768871ec)
--Type  for more, q to quit, c to continue without paging--
at /space/rguenther/src/svn/gcc-8-branch/libcpp/macro.c:2718
#9  0x01d9caf7 in cpp_get_token_with_location (pfile=0x2ba35a0, 
loc=0x768871ec)
at /space/rguenther/src/svn/gcc-8-branch/libcpp/macro.c:2904
#10 0x0092be5a in c_lex_with_flags (value=0x768871f0, 
loc=0x768871ec, cpp_flags=0x768871f8 "", lex_flags=0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c-family/c-lex.c:403
#11 0x0088fbe4 in c_lex_one_token (parser=0x768871e0, 
token=0x768871e8)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:251
#12 0x00890014 in c_parser_peek_token (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:435
#13 0x0089f512 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7209
#14 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#15 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#16 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#17 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#18 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
--Type  for more, q to quit, c to continue without paging--
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#19 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#20 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
after=0x0) at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7104
#21 0x0089f533 in c_parser_unary_expression (parser=0x768871e0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:7210
#22 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
...
#41908 0x0089ed81 in c_parser_cast_expression (parser=0x768871e0, 
#41909 0x0089d3ae in c_parser_binary_expression (
parser=0x768871e0, after=0x0, omp_atomic_lhs=0x0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:6907
#41910 0x0089cb4d in c_parser_conditional_expression (
parser=0x768871e0, after=0x0, omp_atomic_lhs=0x0)
at /space/rguenther/src/svn/gcc-8-branch/gcc/c/c-parser.c:6645
...

I guess it's not easy to avoid this given the structure of the parser.

We are already trying to raise the stack limit to 64MB via stack_limit_increase
().  Maybe we should try 

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-10-29
  Known to work||8.2.0
 Blocks||63426
   Target Milestone|--- |9.0
  Known to fail||9.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug libstdc++/87787] [9 Regression] runtime error: null pointer passed as argument 2, which is declared to never be null

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That would be my recent commit. We will probably need to add if(size!=0) in
front of the call to memmove...

[Bug c++/58372] internal compiler error: ix86_compute_frame_layout

[ktietz at gcc dot gnu.org]

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

--- Comment #16 from Kai Tietz  ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to David Grayson from comment #14)
> 
> > Does anyone have an idea of how to fix this bug for real?  What values
> > should crtl->preferred_stack_boundary crtl->stack_alignment_needed really
> > have  on Windows, and should they be controllable from the command-line? 
> > Where do they get set?
> > 
> > --David
> 
> Reading symbols from /ssd/uros/gcc-build-xxx/gcc/cc1plus...done.
> (gdb) watch x_rtl.preferred_stack_boundary 
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> (gdb) r
> Starting program: /ssd/uros/gcc-build-xxx/gcc/cc1plus pr58372.C
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 0
> New value = 32
> 0x00b930dc in rtl_data::init_stack_alignment (this=0x23c8ac0
> ) at /home/uros/gcc-svn/trunk/gcc/emit-rtl.c:6636
> 6636  preferred_stack_boundary = STACK_BOUNDARY;
> 
> Hardware watchpoint 1: x_rtl.preferred_stack_boundary
> 
> Old value = 32
> New value = 128
> emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*) ()
> at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> 4744  if (outmode != VOIDmode)
> 
> (gdb) list
> 4739  if (crtl->preferred_stack_boundary < PREFERRED_STACK_BOUNDARY)
> 4740crtl->preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
> 4741
> 4742  /* If this kind of value comes back in memory,
> 4743 decide where in memory it should come back.  */
> 4744  if (outmode != VOIDmode)
> 4745{
> 4746  tfom = lang_hooks.types.type_for_mode (outmode, 0);
> 4747  if (aggregate_value_p (tfom, 0))
> 4748{
> 
> This happen when building SjLj landing pads:
> 
> #0  emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
> machine_mode, int, std::pair*)
> () at /home/uros/gcc-svn/trunk/gcc/calls.c:4744
> #1  0x00b9b36c in emit_library_call (arg1_mode=,
> arg1=, outmode=E_VOIDmode, 
> fn_type=LCT_NORMAL, fun=) at
> /home/uros/gcc-svn/trunk/gcc/rtl.h:4123
> #2  sjlj_emit_function_enter(rtx_code_label*) () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1202
> #3  0x00b9f20a in sjlj_build_landing_pads () at
> /home/uros/gcc-svn/trunk/gcc/except.c:1481
> #4  finish_eh_generation() () at /home/uros/gcc-svn/trunk/gcc/except.c:1510
> 
> Adding -mpreferred-stack-boundary=2 "fixes" compilation.
> 
> If you want to experiment, try the following patch:
> 
> Index: config/i386/mingw32.h
> ===
> --- config/i386/mingw32.h   (revision 265582)
> +++ config/i386/mingw32.h   (working copy)
> @@ -251,6 +251,10 @@
>  #undef  CHECK_EXECUTE_STACK_ENABLED
>  #define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
>  
> +#undef PREFERRED_STACK_BOUNDARY_DEFAULT
> +#define PREFERRED_STACK_BOUNDARY_DEFAULT   \
> +  (TARGET_64BIT ? 128 : MIN_STACK_BOUNDARY)
> +
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygming. */
>  /* This matches SHLIB_SONAME and SHLIB_SOVERSION in t-cygwin. */
>  #if DWARF2_UNWIND_INFO> 
> But I don't know the details of MS ABI, so I can't tell if the patch is
> correct.

The x64 ABI part is correct, as for x64 abit there is just 16-byte stack
alignment. For x86 ms abi things aren't that strict AFAIK. The common stack
alignment on function entry is the natural one, but there is in general no
strict requirement for it. So the patch looks fine, but should be commented in
the release notes, as there might be fallout seen caused by it.

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin*
   Target Milestone|--- |9.0

[Bug bootstrap/87789] New: D does not build on powerpc64-linux

[segher at gcc dot gnu.org]

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

Bug ID: 87789
   Summary: D does not build on powerpc64-linux
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

$HOME/src/gcc/libphobos/src/std/internal/math/gammafunction.d:259:5: error:
static assert  "missing MAXGAMMA for other real types"

[Bug c++/87663] using / typedef on recursive template leads to long compile time

[lumosimann at gmail dot com]

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

--- Comment #7 from Lukas Mosimann  ---
Thanks! I will do that.

First lets sum up state here such that it's not required to read through all
comments. I am playing around with integral constant and an "exponential
wrapper". First the "exponential wrapper":

```
template 
struct F : integral_constant::value -
  F::value> {};

template 
struct F : integral_constant {};

int main() {
F<0, 14>::value;
return 0;
}
```
I.e., we simply instantiate a huge set of integral constants. Now I play with
different integral_constants a measure compilation time.

=== V1 0.8s ===
template 
struct integral_constant {
static constexpr T value = v;
};


=== V2 4.4s === (used by type_traits)
template 
struct integral_constant {
static constexpr T value = v;
using value_type = T;
};

=== V3 4.2s ===
template 
struct integral_constant {
using value_type = T;
static constexpr T value = v;
};

=== V4 23 s === (!!)
template 
struct integral_constant {
using value_type = T;
static constexpr value_type value = v;
};

Currently I am working with a modified version of V2 (4.4s):

template 
struct integral_constant {
static constexpr T value = v;
using value_type = int;
};

In this case I see that we always create a new type variant of int (I guess one
per integral constant) through set_underlying type, and at another point we
iterate through large parts of the list to get the correct variant again (over
build_qualified_type). More precisely:
1) We first do build_qualified_type for value. This iterates through the whole
list and at some point finds "plain const int" (no typedef) - no new type
variant required.
2) We create a new type variant of int referring to the alias in this specific
integral_constant. This is prepended to the list of type variants, i.e., in the
next 1) we need to iterate over one additional entry than before to find "plain
const int".
Therefore, integral constant instantiation gets more expensive with each
instance.

I have seen the comment above set_underlying type, but my question is more
whether this is always needed (it is only talking about debugging and protoize
- so is it also required in a build without debugging information?).
And yes, it might also be possible to do it more efficient: Do all variants
need to be stored in this list? Is this the natural order for a list - and is a
list the right data structure for this?

I will post to the mailing list pointing to this comment.

[Bug fortran/87782] [9 Regression] runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
I see that at r265374.

[Bug fortran/87782] [9 Regression] runtime error: load of value 1818451807, which is not a valid value for type 'expr_t'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.0

[Bug tree-optimization/87790] New: [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

Bug ID: 87790
   Summary: [9 Regression] ICE in vect_get_vec_def_for_operand_1,
at tree-vect-stmts.c:1475
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following cases an ICE:

$ cat dfa.i
int a, b;
void c(int d[][8]) {
  int e, f;
  for (; b; b++) {
e = d[b][0] % 4 * 21;
if (e >= 21)
  e--;
a = d[b][0] - e;
f = 1;
for (; f != 8; f++)
  d[b][f] = a;
  }
}

$ gcc dfa.i -Ofast -fprofile-generate -c -march=znver1
during GIMPLE pass: vect
dfa.i: In function ‘c’:
dfa.i:2:6: internal compiler error: in vect_get_vec_def_for_operand_1, at
tree-vect-stmts.c:1475
2 | void c(int d[][8]) {
  |  ^
0xf7cdce vect_get_vec_def_for_operand_1(_stmt_vec_info*, vect_def_type)
../../gcc/tree-vect-stmts.c:1475
0xf7f2ad vect_get_vec_def_for_operand(tree_node*, _stmt_vec_info*, tree_node*)
../../gcc/tree-vect-stmts.c:1554
0xf86bb5 vectorizable_condition(_stmt_vec_info*, gimple_stmt_iterator*,
_stmt_vec_info**, tree_node*, int, _slp_tree*, vec*)
../../gcc/tree-vect-stmts.c:8916
0xf9af25 vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc/tree-vect-stmts.c:9676
0xf9cfd3 vect_transform_loop_stmt
../../gcc/tree-vect-loop.c:8146
0xfaf2f3 vect_transform_loop(_loop_vec_info*)
../../gcc/tree-vect-loop.c:8357
0xfceb85 try_vectorize_loop_1
../../gcc/tree-vectorizer.c:965
0xfcf636 vectorize_loops()
../../gcc/tree-vectorizer.c:1097
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-10-29
 CC||rguenth at gcc dot gnu.org
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Started with r265528.

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
With the right set of caching/failing events we miss loads for
slp_instance->loads.  I have a patch gathering loads after the fact which fixes
the issue but I don't have a nice testcase.

[Bug target/85035] nios2: adding -fdelete-null-pointer-checks with -O2 enabled

[rvdv at vandewiele dot com]

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

--- Comment #5 from rvdv at vandewiele dot com ---
Created attachment 44916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44916=edit
assembly output 7.3.0

This is the assembly output i get with 7.3.0 (and as early as 6.1.0)
I have tried it with 8.1.0 and then I get the same output as you did. 
So it seems like it was fixed in 8.1.0

[Bug c++/87781] New: template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier

[ensadc at mailnesia dot com]

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

Bug ID: 87781
   Summary: template disambiguator not after `::`, `.` or `->` is
incorrectly accepted in an elaborated-type-specifier
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/97lV1nw6gMGSDOct

template class A;

class template A *p;

GCC allows this with no warning or error. Both clang and MSVC reject this.

[Bug c++/87783] New: `class A;` is incorrectly accepted at namespace or class scope

[ensadc at mailnesia dot com]

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

Bug ID: 87783
   Summary: `class A;` is incorrectly accepted at namespace
or class scope
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://wandbox.org/permlink/L5JYCDnEfKmftRlr

template class A {};

class A;

Both Clang and MSVC appear to treat `class A;` as an invalid explicit
template specialization. GCC does the same at block scope, but incorrectly
accepts this declaration at namespace or class scope.

[Bug libstdc++/87784] New: A bug in tr2::dynamic_bitset::find_first

[yusemru at gmail dot com]

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

Bug ID: 87784
   Summary: A bug in tr2::dynamic_bitset::find_first
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yusemru at gmail dot com
  Target Milestone: ---

Created attachment 44917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44917=edit
source code

Consider the following code:

#include 
#include 

using namespace std;
using namespace tr2;

int main() {
dynamic_bitset b;
b.push_back(0);
b.push_back(1);
dynamic_bitset a;
a.push_back(0);
a.push_back(0);
cout << b.find_first() << ' ' << a.find_first() << endl;
return 0;
}

On my machine it prints 2 2, which is clearly wrong.
I'm using GCC 8.1.1 on Arch Linux x86-64

[Bug c++/87786] New: Failed to mangle sizeof...(ArgPack) with template-alias captured arguments

[xecycle at gmail dot com]

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

Bug ID: 87786
   Summary: Failed to mangle sizeof...(ArgPack) with
template-alias captured arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xecycle at gmail dot com
  Target Milestone: ---

Reproducing code (at https://godbolt.org/z/dbqZu7):

```
#include 

double g(int);

template 
struct M {};

template 
using make_M = M;

template 
auto f(T&&... x)
  -> make_M
{
  using _noop = int[];
  (void)_noop { ((void)x, 0)... };
  return {};
}

auto m = f(12, 34);
```

It fails to compile with versions >= 7.  At first it looks like a regression;
but it probably is not.  It's more like an incomplete attempt (in 7.x) to fix a
previous mangling bug.  6.x and earlier does compile, but the mangled output
used "sz" instead of "sP"; gcc/cp/mangle.c on trunk actually contains a line
`write_string ("sP");`, but seems it did not reach there in this example.

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
Fixed.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Fixed.

[Bug c++/87770] [8/9 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||7.3.0
   Target Milestone|--- |8.3
Summary|ICE in  |[8/9 Regression] ICE in
   |type_dependent_expression_p |type_dependent_expression_p
   |, at cp/pt.c:25230  |, at cp/pt.c:25230

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Author: segher
Date: Mon Oct 29 07:36:45 2018
New Revision: 265582

URL: https://gcc.gnu.org/viewcvs?rev=265582=gcc=rev
Log:
combine: Fix various shortcomings in make_more_copies (PR87701, PR87780)

This rewrites most of make_more_copies, in the process fixing a few PRs
and some other bugs, and working around a few target problems.  Certain
notes turn out to actually change the meaning of the RTL, so we cannot
drop them; and i386 takes subregs of hard regs.


PR rtl-optimization/87701
PR rtl-optimization/87780
* combine.c (make_more_copies): Rewrite.

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

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to work||7.3.1
   Target Milestone|--- |8.3
Summary|ICE in  |[8/9 Regression] ICE in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:19002 when using|cp/pt.c:19002 when using
   |concepts|concepts

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 CC||rguenth at gcc dot gnu.org
  Known to work||8.2.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Started with r265522.

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Target Milestone|--- |9.0
Summary|[9.0 Regression] aarch64|[9 Regression] aarch64
   |target testcases fail after |target testcases fail after
   |r265398 |r265398

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-10-29
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Please provide a testcase - usually preprocessed source, commandline-options
with -v appended.  See https://gcc.gnu.org/bugs.html

Note that GCC 5 and 6 are no longer supported so you need to update to GCC 7 or
newer.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Mon Oct 29 07:36:45 2018
New Revision: 265582

URL: https://gcc.gnu.org/viewcvs?rev=265582=gcc=rev
Log:
combine: Fix various shortcomings in make_more_copies (PR87701, PR87780)

This rewrites most of make_more_copies, in the process fixing a few PRs
and some other bugs, and working around a few target problems.  Certain
notes turn out to actually change the meaning of the RTL, so we cannot
drop them; and i386 takes subregs of hard regs.


PR rtl-optimization/87701
PR rtl-optimization/87780
* combine.c (make_more_copies): Rewrite.

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

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-29
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started to be slow with r264241.

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||segher at gcc dot gnu.org
  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #2 from Segher Boessenkool  ---
Mine.

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

--- Comment #7 from Donna Ory  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Donna Ory from comment #4)
> > I got the Master Tevo Flash files from here: 
> > 
> > https://www.facebook.com/groups/2058176381100233/files/
> 
> That's a closed group.
> 
> > 
> > I have the "Standard" version, so that's the only one that I kept out of the
> > zip file.
> > 
> > Since it has all the Marlin files in it, I didn't need to download a new
> > Marlin set up.
> > 
> > I got the U8glib files off of github. 
> 
> This one? https://github.com/olikraus/u8glib 
> 
> > I downloaded the zip file, to the folder where I have my 3D printer stuff,
> > and the followed the directions to add it to the library. I did not unzip 
> > it.
> > 
> > Since this, I even tried using the newest version U8glib 1.18.1, but it
> > still has the same errors.

How do I get the file to you?

[Bug other/79872] document placeholder %K in gcc-internal-format

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #3)
> %K is designed to print the inline stack, but I cannot see this documented
> anywhere (and as far as I know, only the C++ front-end uses it).

I think it's been put to use in more places recently; cc-ing people I remember
discussing bugs about modifying warnings to show the inlining stack

[Bug middle-end/87489] Spurious -Wnonnull warning

[achurch+gcc at achurch dot org]

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

--- Comment #5 from Andrew Church  ---
Simpler testcase (based on the testcase in bug 87041):

extern int strcmp(const char *a, const char *b) __attribute__((nonnull(1, 2)));
int foo(void) {
const char * const s = 0;
if (s)
return strcmp(s, "");
else
return 2;
}

foo.c: In function 'foo':
foo.c:5:16: warning: null argument where non-null required (argument 1)
[-Wnonnull]
 return strcmp(s, "");
^~

[Bug c++/79001] spurious "defined but not used" warning with explicit instantiation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Confirmed that g++ warns for "f" but not "g"

Diagnostics maintainers, is this the intended behavior?

[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code

[achurch+gcc at achurch dot org]

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

--- Comment #9 from Andrew Church  ---
Trunk r265614 with the patch from comment #8 no longer emits spurious warnings
from -Wformat for all of my cases which previously triggered such warnings.

Thanks for the patch.

[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Fixed.

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 13:31:28 2018
New Revision: 265588

URL: https://gcc.gnu.org/viewcvs?rev=265588=gcc=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87785
* tree-vect-slp.c (vect_build_slp_tree_2): Remove loads argument
and processing.
(vect_build_slp_tree): Likewise.
(vect_gather_slp_loads): New function.
(vect_analyze_slp_instance): Gather loads separately from the
SLP tree build.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

--- Comment #1 from Kevin Goodwin  ---
Created attachment 44920
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44920=edit
diff that fixes the problem: bugexe builds and runs successfully

[Bug rtl-optimization/87780] [9 regression] ICE error: unrecognizable insn

[romain.geissler at amadeus dot com]

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

--- Comment #5 from Romain Geissler  ---
Hi,

Trying with today's trunk with this patch included, my clang PGO+LTO bootstrap
goes further, but then the generated clang fails to compile itself. Just
putting here the clang error for reference:

fatal error: error in backend: Cannot select: 0x20c13f8: ch = fp_to_fp16
0x201f1d8, 0x20bccd8, FrameIndex:i64<0>
  0x20bccd8: f80,ch = CopyFromReg 0x201f1d8, Register:f80 %0
0x20bcc08: f80 = Register %0
  0x20c1bb0: i64 = FrameIndex<0>
In function: __divtc3
clang-7: error: clang frontend command failed with exit code 70 (use -v to see
invocation)

The only thing that I changed recently is binutils/gcc/glibc, not the clang
sources. So there might still have some code gen issue left in gcc trunk (which
I don't know how to investigate).

Cheers,
Romain

[Bug c++/87781] template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/87762] [9 Regression] extract_constrain_insn, at recog.c:2206 on s390x

[iii at linux dot ibm.com]

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com

--- Comment #2 from Ilya Leoshkevich  ---
This must have slipped through, because I tested the movdi patch on top of the
outdated trunk (r264877).

Candidate fix: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01793.html

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

[rguenth at gcc dot gnu.org]

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

Bug 87785 Summary: [9 Regression] ICE in dr_misalignment, at 
tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87785

   What|Removed |Added

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

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Mine.

[Bug c++/87750] [8/9 Regression] Failed compilation / parsing of template member call after 'using' declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||nathan at gcc dot gnu.org

--- Comment #4 from Jonathan Wakely  ---
We still insist on testcases being attached here regardless as stated at
https://gcc.gnu.org/bugs/ (which you were asked to read) so thanks for
attaching it.

This started to be rejected with r252005

Kill CLASSTYPE_SORTED_FIELDS.
* cp-tree.h (struct lang_type): Lose sorted_fields member.
(CLASSTYPE_SORTED_FIELDS): Delete.
* name-lookup.h (set_class_bindings): Add EXTRA arg.
* name-lookup.c (fields_linear_search): New, broken out of ...
(lookup_field_1): ... here.  Delete remainder of function.
(get_class_binding_direct): Reimplement without sorted_fields.
(get_class_binding): Rename TYPE arg to KLASS, for consistency.
(get_method_slot): Call set_class_binding when creating method_vec
on complete type.
(method_name_cmp): Order identically named slots.
(sorted_fields_type_new): Delete.
(field_vc_append_class_fields): Rename to ...
(method_vec_append_class_fields): ... here.  Adjust.
(field_vec_append_enum_values): Renme to ...
(method_vec_append_enum_values): ... here. Adjust.
(method_vec_dedup): New.
(set_class_bindings): Reimplement.
(insert_late_enum_def_bindings): Reimplement.

[Bug libstdc++/87784] A bug in tr2::dynamic_bitset::find_first

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like this patch fixes it:

--- a/libstdc++-v3/include/tr2/dynamic_bitset
+++ b/libstdc++-v3/include/tr2/dynamic_bitset
@@ -729,8 +729,7 @@ namespace tr2
   {
if (size_t __offset = this->size() % bits_per_block == 0)
  this->_M_do_append_block(block_type(0), this->_M_Nb);
-   ++this->_M_Nb;
-   this->_M_unchecked_set(this->_M_Nb, __bit);
+   this->_M_unchecked_set(this->_M_Nb++, __bit);
   }

   /**

[Bug c++/87663] using / typedef on recursive template leads to long compile time

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
I think the "variant" type set_underlying_type builds doesn't have to be in the
variant type list.  The only thing that is probably needed is that it has
TYPE_CANONICAL (tt) = TYPE_CANONICAL (TREE_TYPE (x));

Other than that this whole dance of set_underlying_type & friends should
probably be revisited in the light of early debug info generation (add a debug
hook to emit DIEs in whatever way this is supposed to happen through this
mechanism?).

That is, if the FE knows an object is of a type with name X then say so rather
than requiring this type copy that is just used to refer to the typedef.  That
is, it looks like a quite awkward and expensive way to communicate this to
dwarf2out.

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
One of usual fuzzer fake CVEs.

This is basically a similar "problem" like initially reported in
  https://sourceware.org/bugzilla/show_bug.cgi?id=23008
where I actually analyzed it.  The problem is that C++ mangled names
have a recursive structure.  For demonstration purposes let's assume that the
character 'F' in a mangled name means "here come nested template arguments,
described next", then you need to recurse down to decode those nested args,
and if the next character is 'F' as well, you just recurse down again.  So
a mangled "name" with a million 'F' characters in succession will need
a recursion depth of a million.

So, when you feed the demangler such a name a stack overflow is expected.
Exactly when the overflow occurs depends on how the demangler is compiled,
i.e. how much stack space is needed from one to the next recursion level
(sometimes the recursion is tail recursion, so in some compilation modes
can even be elided and so lead to non-exhaustion).

Many characters of the mangled names have this property, so there are multiple
variants of names that all lead to stack exhaustion, so the fuzzers were able
to create many different testcases:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 (aka bugzilla PR23008)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681

Unfortunately they now also started to submit fake CVEs for these, like this
one (CVE-2018-18701) or CVE-2018-18700 (aka bug 87681).

If libiberty ever implements a check for this (which essentially can only be an
arbitrary limit, which is frowned upon, especially as it must be very small, as
people might have their stack limit set very low) fine, if not, also fine.
Until then feeding such names to any demangling tool leads to stack exhaustion
and hence segfault.  Like any other memory exhaustion not a security bug.

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

--- Comment #3 from Kevin Goodwin  ---
aside: the exact same source code that triggers this internal error builds w/o
error using gcc version 4.8.1:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/users/kevin/appdata/local/programs/mingw/32/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.8.1/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/c/temp/gcc/dest
--with-gmp=/c/temp/gcc/gmp --with-mpfr=/c/temp/gcc/mpfr
--with-mpc=/c/temp/gcc/mpc --enable-languages=c,c++ --with-arch=i686
--with-tune=generic --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-sjlj-exceptions --disable-win32-registry --enable-checking=release
--enable-lto
Thread model: win32
gcc version 4.8.1 (GCC)

[Bug middle-end/87041] [8/9 Regression] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Testing a patch.

[Bug tree-optimization/87785] [9 Regression] ICE in dr_misalignment, at tree-vectorizer.h:1245 on 454.calculix with -Ofast and -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 15:43:08 2018
New Revision: 265596

URL: https://gcc.gnu.org/viewcvs?rev=265596=gcc=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87785
* tree-vect-slp.c (vect_gather_slp_loads): Only gather
internal defs.

* gcc.dg/torture/20181029-1.c: New testcase.
* gcc.dg/torture/20181029-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/torture/20181029-1.c
trunk/gcc/testsuite/gcc.dg/torture/20181029-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug c++/87783] `class A;` is incorrectly accepted at namespace or class scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug lto/87792] New: lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[fwmechanic at gmail dot com]

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

Bug ID: 87792
   Summary: lto1.exe: internal compiler error: in get_constructor,
at varpool.c:311
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fwmechanic at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44919=edit
contains minimized reproduction of error, all files

GCC "distro" I'm using is mingw-16.0-without-git.exe from
https://nuwen.net/mingw.html

Result: 

lto1.exe: internal compiler error: in get_constructor, at varpool.c:311
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error: g++ returned 1 exit status
compilation terminated.
[Leaving LTRANS bugexe.exe.ltrans0.o]
c:/users/kevin/appdata/local/programs/mingw/64/mingw/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

Because this is associated with -flto (apparently takes 2 g++ steps: compile,
link, to reproduce) I have included all further info in attached zip:

Archive:  lto1_internal_error_get_constructor_varpool.zip
  Length  DateTimeName
-  -- -   
26638  2018-10-29 06:28   err
  935  2018-10-29 06:28   out
38792  2018-10-29 06:28   bugexe_exe.map
 1608  2018-10-29 06:28   bugexe.exe.ltrans0.s
   22  2018-10-29 06:28   bugexe.exe.ltrans.out
17288  2018-10-29 06:28   bugexe.exe.ltrans0.o
  599  2018-10-29 06:28   -Bdynamic.res
14970  2018-10-29 06:28   bugsrc.o
34947  2018-10-29 06:28   bugsrc.s
   136444  2018-10-29 06:28   bugsrc.ii
- ---
   272243 10 files

File out is stdout, File err is stderr, respectively, from make.

[Bug lto/87792] lto1.exe: internal compiler error: in get_constructor, at varpool.c:311

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Looks the problematic line is:
  gcc_assert (DECL_INITIAL (decl) != error_mark_node);

so yes, it's somehow connected to __PRETTY_FUNCTION__ initialization.
Unfortunately I won't be able to help you as I can't reproduce that on Linux. I
don't have any access to mingw machine.

[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:13:56 2018
New Revision: 265590

URL: https://gcc.gnu.org/viewcvs?rev=265590=gcc=rev
Log:
2018-10-29  Richard Biener  

Backport from mainline
2018-09-26  Richard Biener  

PR debug/87428
PR debug/87362
* tree-inline.c (expand_call_inline): When the location
of the call is UNKNOWN_LOCATION use DECL_SOURCE_LOCATION
or BUILTINS_LOCATION for the BLOCK_SOURCE_LOCATION of
the inserted BLOCK to make inlined_function_outer_scope_p
recognize it.
* dwarf2out.c (add_call_src_coords_attributes): Do not add
coords for reserved locations.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/tree-inline.c

[Bug debug/87428] "Missed" inline instances cause bogus DWARF to be emitted

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:13:56 2018
New Revision: 265590

URL: https://gcc.gnu.org/viewcvs?rev=265590=gcc=rev
Log:
2018-10-29  Richard Biener  

Backport from mainline
2018-09-26  Richard Biener  

PR debug/87428
PR debug/87362
* tree-inline.c (expand_call_inline): When the location
of the call is UNKNOWN_LOCATION use DECL_SOURCE_LOCATION
or BUILTINS_LOCATION for the BLOCK_SOURCE_LOCATION of
the inserted BLOCK to make inlined_function_outer_scope_p
recognize it.
* dwarf2out.c (add_call_src_coords_attributes): Do not add
coords for reserved locations.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/dwarf2out.c
branches/gcc-8-branch/gcc/tree-inline.c

[Bug c/87793] New: GCC reports error when compiling with "-fpic -Os -g"

[bmeng.cn at gmail dot com]

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

Bug ID: 87793
   Summary: GCC reports error when compiling with "-fpic -Os -g"
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmeng.cn at gmail dot com
  Target Milestone: ---

Created attachment 44921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44921=edit
minimal test case (test.c) and the preprocessed file (test.i)

# Command line to call compiler 
$ /share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc -march=i386
-m32 -c test.c -o test.o -fpic -Os -g --save-temps -v

# Output
Using built-in specs.
COLLECT_GCC=/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/i386-linux-gcc
Target: i386-linux
Configured with: /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
: (reconfigured) /home/arnd/git/gcc/configure --target=i386-linux
--enable-targets=all
--prefix=/home/arnd/cross/x86_64/gcc-8.1.0-nolibc/i386-linux
--enable-languages=c --without-headers --disable-bootstrap --disable-nls
--disable-threads --disable-shared --disable-libmudflap --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libquadmath
--disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
Thread model: single
gcc version 8.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-E -quiet -v -iprefix
/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/
test.c -march=i386 -m32 -fpic -g -fworking-directory -Os -fpch-preprocess -o
test.i
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include"
ignoring duplicate directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/include-fixed"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/sys-include"
ignoring nonexistent directory
"/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/../../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../libexec/gcc/i386-linux/8.1.0/cc1
-fpreprocessed test.i -quiet -dumpbase test.c -march=i386 -m32 -auxbase-strip
test.o -g -Os -version -fpic -o test.s
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 8.1.0 (i386-linux)
compiled by GNU C version 5.4.1 20170519, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 5b6be85f431a859ca20ca7e588057ee0
COLLECT_GCC_OPTIONS='-march=i386' '-m32' '-c' '-o' 'test.o' '-fpic' '-Os' '-g'
'-save-temps' '-v'

/share/toolchains/gcc-8.1.0-nolibc/i386-linux/bin/../lib/gcc/i386-linux/8.1.0/../../../../i386-linux/bin/as
-v --32 -o test.o test.s
GNU assembler version 2.30 (i386-linux) using BFD version (GNU Binutils) 2.30
test.s: Assembler messages:
test.s:715: Error: junk at end of line, first unrecognized character is `@'
test.s:760: Error: junk at end of line, first unrecognized character is `@'
test.s:715: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.u_boot_list_2_fit_loadable_1 section}
test.s:760: Error: can't resolve `end.1561' {.u_boot_list_2_fit_loadable_3
section} - `start.1558' {.u_boot_list_2_fit_loadable_1 section}

# Workaround
Removing -fpic or -Os or -g will make the 

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

--- Comment #5 from Donna Ory  ---
Also, my "SanityCheck.h" is off the charts with all kinds of stuff that just
gives the the "Deer in the headlights" look!! lol!!

[Bug tree-optimization/87790] [9 Regression] ICE in vect_get_vec_def_for_operand_1, at tree-vect-stmts.c:1475

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 29 14:57:52 2018
New Revision: 265593

URL: https://gcc.gnu.org/viewcvs?rev=265593=gcc=rev
Log:
2018-10-29  Richard Biener  

PR tree-optimization/87790
* tree-vect-slp.c (vect_mark_slp_stmts): Simplify.
(vect_make_slp_decision): Adjust.
(vect_slp_analyze_bb_1): Likewise.
(vect_detect_hybrid_slp_stmts): Properly union SLP type over
edges.

* gcc.dg/pr87790.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87790.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Donna Ory from comment #4)
> I got the Master Tevo Flash files from here: 
> 
> https://www.facebook.com/groups/2058176381100233/files/

That's a closed group.

> 
> I have the "Standard" version, so that's the only one that I kept out of the
> zip file.
> 
> Since it has all the Marlin files in it, I didn't need to download a new
> Marlin set up.
> 
> I got the U8glib files off of github. 

This one? https://github.com/olikraus/u8glib 

> I downloaded the zip file, to the folder where I have my 3D printer stuff,
> and the followed the directions to add it to the library. I did not unzip it.
> 
> Since this, I even tried using the newest version U8glib 1.18.1, but it
> still has the same errors.

[Bug target/87627] GCC generates rube-goldberg machine for trivial tail call on 32-bit x86

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
FWIW the following CSE enhancement cleans this up, but I'm unhappy with this
patch because it's too narrowly targeted; in particular, won't clean up

void g(int a, int *b, int c);
void f(int a, int *b, int c)
{
  if (a) *b = c;
  g(a, b, c);
}

Had to special-case for PARM_DECL because, in general, automatic variables that
are not address-taken on GIMPLE can become addressable on RTL when ABI requires
passing a large argument by reference.

--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -2232,6 +2232,15 @@ hash_rtx_string (const char *ps)
   return hash;
 }

+static bool
+mem_escapes_p (const_rtx x)
+{
+  tree decl = MEM_EXPR (x);
+  if (!decl || TREE_CODE (decl) != PARM_DECL)
+return true;
+  return may_be_aliased (decl);
+}
+
 /* Same as hash_rtx, but call CB on each rtx if it is not NULL.
When the callback returns true, we continue with the new rtx.  */

@@ -2421,7 +2430,8 @@ hash_rtx_cb (const_rtx x, machine_mode mode,
  return 0;
}
   if (hash_arg_in_memory_p && !MEM_READONLY_P (x))
-   *hash_arg_in_memory_p = 1;
+   if (*hash_arg_in_memory_p != 1)
+ *hash_arg_in_memory_p = mem_escapes_p (x) ? 1 : 2;

   /* Now that we have already found this special case,
 might as well speed it up as much as possible.  */
@@ -6127,7 +6137,7 @@ invalidate_memory (void)
 for (p = table[i]; p; p = next)
   {
next = p->next_same_hash;
-   if (p->in_memory)
+   if (p->in_memory == 1)
  remove_from_table (p, i);
   }
 }

[Bug target/87771] My first 3d printer, and I messed up trying to update the .ini file. So, I'm trying to put the original software back in it, and I get this internal compiler error

[dory at satx dot rr.com]

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

Donna Ory  changed:

   What|Removed |Added

URL||https://www.youtube.com/wat
   ||ch?v=lAKyZd63_ns=559s

--- Comment #4 from Donna Ory  ---
I got the Master Tevo Flash files from here: 

https://www.facebook.com/groups/2058176381100233/files/

I have the "Standard" version, so that's the only one that I kept out of the
zip file.

Since it has all the Marlin files in it, I didn't need to download a new Marlin
set up.

I got the U8glib files off of github. I downloaded the zip file, to the folder
where I have my 3D printer stuff, and the followed the directions to add it to
the library. I did not unzip it.

Since this, I even tried using the newest version U8glib 1.18.1, but it still
has the same errors.

[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type

[gs...@t-online.de]

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

--- Comment #4 from G. Steinmetz  ---
(In reply to Thomas Koenig from comment #3)
> What is the expected output?  Does this declare a new variable "min"
> or "max", or should the result simply be 'c' (or 'b')?

As it makes not much sense (IMO) to "specialise" a generic intrinsic via
user provided declaration, it looks more like a type conflict / error.


But following example is accepted, character is not matching intrinsic sin :

$ cat z4.f90
program p
   character :: sin
   print *, sin(1.0)
end

$ gfortran-9-20181028 -Wall -Wextra -fcheck=all z4.f90
$ a.out
  0.841470957


On the other hand :

$ cat z5.f90
program p
   character :: sin = 'c'
   print *, sin(1.0)
end

$ gfortran-9-20181028 z5.f90
z5.f90:2:19:

2 |character :: sin = 'c'
  |   1
Error: Function 'sin' at (1) cannot have an initializer
z5.f90:2:19:

2 |character :: sin = 'c'
  |   1
Error: 'sin' at (1) is not a VALUE


$ cat z5b.f90
program p
   character :: sin
   print *, sin(1.0)
   sin = 'c'
   print *, sin
end

$ gfortran-9-20181028 z5b.f90
z5b.f90:4:6:

4 |sin = 'c'
  |  1
Error: 'sin' at (1) is not a variable
z5b.f90:5:15:

5 |print *, sin
  |   1
Error: Function 'sin' requires an argument list at (1)

[Bug fortran/85896] ICE in gfc_convert_constant(): Unexpected type

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---

Looking again at intrinsic "max" and a variant of z1/z2 :

$ cat z6.f90
program p
   character :: max
   print *, max(1.0, 2.0)
end

$ gfortran-9-20181028 z6.f90
f951: internal compiler error: gfc_convert_constant(): Unexpected type


$ cat z7.f90
program p
   character :: max = 'c'
   print *, max(1.0, 2.0)
end

$ gfortran-9-20181028 z7.f90
z7.f90:2:19:

2 |character :: max = 'c'
  |   1
Error: Function 'max' at (1) cannot have an initializer
z7.f90:2:19:

2 |character :: max = 'c'
  |   1
Error: 'max' at (1) is not a VALUE


$ cat z7b.f90
program p
   character :: max
   print *, max(1.0, 2.0)
   max = 'c'
   print *, max
end

$ gfortran-9-20181028 z7b.f90
z7b.f90:4:6:

4 |max = 'c'
  |  1
Error: 'max' at (1) is not a variable
z7b.f90:5:15:

5 |print *, max
  |   1
Error: Function 'max' requires an argument list at (1)


---

With a user-defined type instead of an intrinsic type this happens :


$ cat zm1.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max
   print *, max(1, 2)
end

$ gfortran-9-20181028 zm1.f90
f951: internal compiler error: gfc_convert_constant(): Unexpected type


$ cat zm2.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max(3)
   print *, max(1, 2)
end

$ gfortran-9-20181028 zm2.f90
zm2.f90:6:15:

6 |print *, max(1, 2)
  |   1
Error: Rank mismatch in array reference at (1) (2/1)


$ cat zm3.f90
program p
   type t
  character :: c = 'c'
   end type
   type(t) :: max(3, 3)
   print *, max(1, 2)
end

$ gfortran-9-20181028 -Wall -Wextra -fcheck=all zm3.f90
$ a.out
 c


BTW, thanks for working on this issue.

[Bug fortran/87796] New: ICE in gfc_conv_string_parameter, at fortran/trans-expr.c:8926

[gs...@t-online.de]

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

Bug ID: 87796
   Summary: ICE in gfc_conv_string_parameter, at
fortran/trans-expr.c:8926
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Might be related to pr85896.


$ cat z1.f90
program p
   character :: num_images
   print *, num_images()
end


$ cat z2.f90
program p
   character :: num_images
   print *, num_images(1)
end


$ gfortran-9-20181028 -c z2.f90 -fcoarray=single
$
$ gfortran-9-20181028 -c z2.f90 -fcoarray=lib
z2.f90:3:0:

3 |print *, num_images(1)
  |
internal compiler error: in gfc_conv_string_parameter, at
fortran/trans-expr.c:8926
0x6ebba0 gfc_conv_string_parameter(gfc_se*)
../../gcc/fortran/trans-expr.c:8926
0x7198e7 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2584
0x6bea57 trans_code
../../gcc/fortran/trans.c:2038
0x7173de build_dt
../../gcc/fortran/trans-io.c:2026
0x6bea37 trans_code
../../gcc/fortran/trans.c:2010
0x6e6054 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6505
0x673696 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673696 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bb28f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/87796] ICE in gfc_conv_string_parameter, at fortran/trans-expr.c:8926

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

$ cat z3.f90
program p
   character :: num_images = 'c'
   print *, num_images(1)
end

$ gfortran-9-20181028 -c z3.f90 -fcoarray=single
z3.f90:2:26:

2 |character :: num_images = 'c'
  |  1
Error: Function 'num_images' at (1) cannot have an initializer
z3.f90:2:26:

2 |character :: num_images = 'c'
  |  1
Error: 'num_images' at (1) is not a VALUE


$ cat z4.f90
program p
   character :: num_images
   print *, num_images()
   num_images = 'c'
   print *, num_images
end

$ gfortran-9-20181028 -c z4.f90 -fcoarray=single
z4.f90:4:13:

4 |num_images = 'c'
  | 1
Error: 'num_images' at (1) is not a variable
z4.f90:5:22:

5 |print *, num_images
  |  1
Error: Function 'num_images' requires an argument list at (1)