[Bug fortran/83746] Errors using the max intrinsic in a PDT length parameter expression for a function result

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
*** Bug 83747 has been marked as a duplicate of this bug. ***

[Bug fortran/83747] Errors using the max intrinsic in a PDT length parameter expression for a function result

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug target/83748] Local variables not aligned to word boundary

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||powerpc
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-09
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Can you specify the exact target triplet?  And attach the preprocessed source.

Also 4.8.x is no longer supported, Can you try a newer compiler like say GCC 5
or GCC 6?

Also what is PACK_SUFFIX_ALWAYS_PACK defined to?

Can you try adding -mstrict-align because GCC for powerpc defaults to allowing
unaligned accesses?

[Bug c/83748] Local variables not aligned to word boundary

[sbansal at ciena dot com]

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

--- Comment #2 from Sumit  ---
(In reply to Andrew Pinski from comment #1)
> What target is this for?
> 
> Also what type is ome_CardCfgPxfp_t ?


The target is powerpc.

Structure definition is :

typedef PACK_PREFIX_ALWAYS_PACK struct ome_CardCfgPxfp_t
{
float txPwrMin;
float txPwrMax;
float rxPwrMin;
float rxPwrMax;
float wavelengthMin;
float wavelengthMax;
uint32 wvlgthSpacing;
SupportedObjects_l SupportedObjects;
SupportedRates_l SupportedRates;
} PACK_SUFFIX_ALWAYS_PACK ome_CardCfgPxfp_t;

The code being accessed is :

806   wvlgthMin = &(cfpPecInfo.wavelengthMin);
807   wvlgthMax = &(cfpPecInfo.wavelengthMax);

Alignment exception at below line :
829   if ((*wvlgthMin) == (*wvlgthMax))

[Bug c/83748] Local variables not aligned to word boundary

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
What target is this for?

Also what type is ome_CardCfgPxfp_t ?

[Bug c/83748] New: Local variables not aligned to word boundary

[sbansal at ciena dot com]

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

Bug ID: 83748
   Summary: Local variables not aligned to word boundary
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

While migrating from 3.4.5 to 4.8.1 tool chain, seeing issues with unaligned
address.

The same code did not produce unaligned address in 3.4.5 but in 4.8.1 seeing
such an issue.

Below variables are declared in a function body :

377   FACOTMn_parms_t   *OTMnData = (FACOTMn_parms_t * )data;
378   TSM_desc_tnvsFacData;
379   CS_result_t   rc = CS_SSTP_rc;  
380   uint8 *otmn_ptr = NULL, *sc_ptr = NULL;
381   uint8 *tr_ptr = NULL, *och_ptr = NULL,
*faccfg_ptr = NULL;
382   uint8 slot = 0;
383   uint8 port = 0;
384   ALA_obj_t object = ALA_nil_obj;
385   uint16index = 0;
386   GBB_rc_t  gbbrc = GBB_SUCCESS_rc;
387   GBB_FAC_ROLE_tfacRole = GBB_FAC_ROLE_UNKNOWN;
388   ALA_eqpt_tplug_type, otm_eqpt;
389   GBB_DISP_BasicPortInfoList_t  portInfoList;
390   CFGM_PecInfo_tPecInfo;
391   ome_CardCfgPxfp_t xfpPecInfo;
392   ome_CardCfgPsfp_t sfpPecInfo;
393   ome_CardCfgPcfp_t cfpPecInfo;
394   float *wvlgthMin, *wvlgthMax;
395   OCH_wavelength_t  *wvlgthSpacing;
396   TSM_service_mgr_t tsam;
397   CS_internal_AID_t slotAID;
398   uint8 numObj;
399   uint8 indx;
400   uint8 scIndx = 0; 
401   CS_AID_t  tempAID;
402   uint8 assignedTS = 0;
403   ODUn_sbf_parms_t  FwParms;
404   TSM_desc_toduFacData;  
405   TSM_featInfo_tfeatInfo;
406   GBB_SERV_TYPE_t   servType;
407   boolean   isQSFP = FALSE;

Seeing issues when accessing elements of xfpPecInfo, sfpPecInfo and cfpPecInfo
and deference them.

However, when forcefully aligned the addresses to 4 byte boundary for all these
three, there was no unaligned addresses created such as :
  ome_CardCfgPxfp_t xfpPecInfo __attribute__((aligned(4)));
  ome_CardCfgPsfp_t sfpPecInfo __attribute__((aligned(4)));
  ome_CardCfgPcfp_t cfpPecInfo __attribute__((aligned(4)));



Please suggest.

Let me know if more information is needed.

[Bug fortran/83747] New: Errors using the max intrinsic in a PDT length parameter expression for a function result

[berke.durak at gmail dot com]

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

Bug ID: 83747
   Summary: Errors using the max intrinsic in a PDT length
parameter expression for a function result
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: berke.durak at gmail dot com
  Target Milestone: ---

Found another one.  When a length parameter for a function
result is dynamically computed from argument parameters,
the max() intrinsic causes spurious warnings and the parameter
is set incorrectly, possibly uninitialized at run time:

module pdt_m
  implicit none
  type :: vec(k)
 integer, len :: k=0
 integer :: foo(k)
  end type vec
contains
  elemental function diy_max(a,b) result(c)
integer, intent(in) :: a,b
integer :: c
c=max(a,b)
  end function diy_max

  function add(a,b) result(c)
type(vec(k=*)), intent(in) :: a,b
type(vec(k=max(a%k,b%k))) :: c  ! Fails
!type(vec(k=diy_max(a%k,b%k))) :: c ! Works with diy_max
!type(vec(k=a%k+b%k)) :: c  ! Works with +

c%foo=0
c%foo(1:a%k)=a%foo
c%foo(1:b%k)=c%foo(1:b%k)+b%foo

print *,'c%k=',c%k
  end function add
end module pdt_m

program test_pdt
  use pdt_m
  implicit none
  type(vec(k=2)) :: u
  type(vec(k=3)) :: v,w

  print *,'w%k=',w%k
  print *,'size(w%foo)=',size(w%foo)

  u%foo=[1,2]
  v%foo=[10,20,30]
  w=add(u,v)

  print *,'w%k=',w%k
  print *,'size(w%foo)=',size(w%foo)
end program test_pdt

% /usr/local/gfortran-bin/bin/gfortran pdt.f90 -o pdt -Wall -Wextra -g
pdt.f90:25:0:

   end function add

Warning: ‘M.4’ is used uninitialized in this function [-Wuninitialized]
pdt.f90:25:0:

   end function add

note: ‘M.4’ was declared here
pdt.f90:25:0:

   end function add

Warning: ‘M.5’ is used uninitialized in this function [-Wuninitialized]
pdt.f90:25:0:

   end function add

note: ‘M.5’ was declared here

% ./pdt
 w%k=   3
 size(w%foo)=   3
 c%k=   329917520
 w%k=   329917520
 size(w%foo)=   0

And with -fcheck=all:

 w%k=   3
 size(w%foo)=   3
At line 21 of file pdt.f90
Fortran runtime error: Index '1' of dimension 1 of array 'c' outside of
expected range (1:0)

Error termination. Backtrace:
#0  0x400ded in __pdt_m_MOD_add
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:21
#1  0x40183d in test_pdt
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:39
#2  0x401a61 in main
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:29

Version:

% /usr/local/gfortran-bin/bin/gfortran --version
GNU Fortran (GCC) 8.0.0 20180109 (experimental) [trunk revision 256361]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/83746] New: Errors using the max intrinsic in a PDT length parameter expression for a function result

[berke.durak at gmail dot com]

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

Bug ID: 83746
   Summary: Errors using the max intrinsic in a PDT length
parameter expression for a function result
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: berke.durak at gmail dot com
  Target Milestone: ---

Found another one.  When a length parameter for a function
result is dynamically computed from argument parameters,
the max() intrinsic causes spurious warnings and the parameter
is set incorrectly, possibly uninitialized at run time:

module pdt_m
  implicit none
  type :: vec(k)
 integer, len :: k=0
 integer :: foo(k)
  end type vec
contains
  elemental function diy_max(a,b) result(c)
integer, intent(in) :: a,b
integer :: c
c=max(a,b)
  end function diy_max

  function add(a,b) result(c)
type(vec(k=*)), intent(in) :: a,b
type(vec(k=max(a%k,b%k))) :: c  ! Fails
!type(vec(k=diy_max(a%k,b%k))) :: c ! Works with diy_max
!type(vec(k=a%k+b%k)) :: c  ! Works with +

c%foo=0
c%foo(1:a%k)=a%foo
c%foo(1:b%k)=c%foo(1:b%k)+b%foo

print *,'c%k=',c%k
  end function add
end module pdt_m

program test_pdt
  use pdt_m
  implicit none
  type(vec(k=2)) :: u
  type(vec(k=3)) :: v,w

  print *,'w%k=',w%k
  print *,'size(w%foo)=',size(w%foo)

  u%foo=[1,2]
  v%foo=[10,20,30]
  w=add(u,v)

  print *,'w%k=',w%k
  print *,'size(w%foo)=',size(w%foo)
end program test_pdt

% /usr/local/gfortran-bin/bin/gfortran pdt.f90 -o pdt -Wall -Wextra -g
pdt.f90:25:0:

   end function add

Warning: ‘M.4’ is used uninitialized in this function [-Wuninitialized]
pdt.f90:25:0:

   end function add

note: ‘M.4’ was declared here
pdt.f90:25:0:

   end function add

Warning: ‘M.5’ is used uninitialized in this function [-Wuninitialized]
pdt.f90:25:0:

   end function add

note: ‘M.5’ was declared here

% ./pdt
 w%k=   3
 size(w%foo)=   3
 c%k=   329917520
 w%k=   329917520
 size(w%foo)=   0

And with -fcheck=all:

 w%k=   3
 size(w%foo)=   3
At line 21 of file pdt.f90
Fortran runtime error: Index '1' of dimension 1 of array 'c' outside of
expected range (1:0)

Error termination. Backtrace:
#0  0x400ded in __pdt_m_MOD_add
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:21
#1  0x40183d in test_pdt
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:39
#2  0x401a61 in main
at /home/alpha/src/fortran/23_Parametrized_derived_types/pdt.f90:29

Version:

% /usr/local/gfortran-bin/bin/gfortran --version
GNU Fortran (GCC) 8.0.0 20180109 (experimental) [trunk revision 256361]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug fortran/83731] PDT length parameter incorrectly rejected at run-time with -fcheck=bounds

[berke.durak at gmail dot com]

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

--- Comment #6 from Berke Durak  ---
(In reply to Paul Thomas from comment #3)
> Hi Berke,
> 
> The fix for this turns out to be so trivial that I will roll it in to the
> patch for pr83611.
> 
> I know that this must be frustrating but please keep trying out PDTs. The
> bug reports that you are generating are invaluable at this stage.
> 
> Thanks
> 
> Paul

Hi Paul,

It worked.

Thanks to you and the others for the hard work!
Hopefully PDTs will be usable soon.  I will keep reporting
problems as I bump into them.

[Bug fortran/83742] [8 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5323

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from kargl at gcc dot gnu.org ---
Same problem of referencing a NULL pointer.
I have patch.

[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes

[emsr at gcc dot gnu.org]

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

--- Comment #2 from emsr at gcc dot gnu.org ---
Created attachment 43067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43067&action=edit
Changing logical to integer works...

Changing logical to integer works...

[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes

[emsr at gcc dot gnu.org]

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

--- Comment #1 from emsr at gcc dot gnu.org ---
Created attachment 43066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43066&action=edit
module with logical that ices.

I have problems with logical too.
ed@bad-horse:~/ARAPP/diffraction$ $HOME/bin/bin/gfortran -c -fc-prototypes
badplot.f95 
f951: internal compiler error: in write_proc, at fortran/dump-parse-tree.c:3177
0x5ce31a write_interop_decl
../../gcc/gcc/fortran/dump-parse-tree.c:3177
0x922232 do_traverse_symtree
../../gcc/gcc/fortran/symbol.c:4157
0x8950c3 gfc_dump_c_prototypes(gfc_namespace*, _IO_FILE*)
../../gcc/gcc/fortran/dump-parse-tree.c:2987
0x8ee5c7 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6251
0x933cdf gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
void do_plot (

[Bug fortran/83744] New: ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes

[emsr at gcc dot gnu.org]

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

Bug ID: 83744
   Summary: ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093
while using -fc-prototypes
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: emsr at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43065&action=edit
The little molule that iCEs

I'm getting ICEs whe I run 'gfortran -fc-prototypes' sometimes.
Otherwise it's a *very* nice feature.

Warning: I may not have the Fortran knowledge.

For one of the files that's troubling me I run

$ $HOME/bin/bin/gfortran -fc-prototypes bugerr.f95

And get this output:

typedef struct utderror_t {
int projectid;
int txantennaid;
int rxantennaid;
int pathid;
int frequencysetid;
int frequencyid;
int errornumber;
int nerrorloc;
double errorstartloc[3];
double errorendloc[3];
f951: internal compiler error: in write_decl, at fortran/dump-parse-tree.c:3093
0x5ce2a2 write_decl
../../gcc/gcc/fortran/dump-parse-tree.c:3093
0x8903c5 write_type
../../gcc/gcc/fortran/dump-parse-tree.c:3118
0x8903c5 write_interop_decl
../../gcc/gcc/fortran/dump-parse-tree.c:3221
0x922232 do_traverse_symtree
../../gcc/gcc/fortran/symbol.c:4157
0x8950c3 gfc_dump_c_prototypes(gfc_namespace*, _IO_FILE*)
../../gcc/gcc/fortran/dump-parse-tree.c:2987
0x8ee5c7 gfc_parse_file()
../../gcc/gcc/fortran/parse.c:6251
0x933cdf gfc_be_parse_file
../../gcc/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


I'm running a pretty recent build of gcc:

ed@bad-horse:~/ARAPP/diffraction$ $HOME/bin/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/home/ed/bin/bin/gfortran
COLLECT_LTO_WRAPPER=/home/ed/bin/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ed/bin --enable-lto
--enable-languages=c,c++,fortran,go,lto,objc,obj-c++
Thread model: posix
gcc version 8.0.0 20180104 (experimental) (GCC)

[Bug fortran/83741] [8 Regression] ICE in gfc_match_allocate, at fortran/match.c:4074

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch committed in r256364.  Testcase committed separately.

[Bug fortran/83741] [8 Regression] ICE in gfc_match_allocate, at fortran/match.c:4074

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan  9 01:26:17 2018
New Revision: 256366

URL: https://gcc.gnu.org/viewcvs?rev=256366&root=gcc&view=rev
Log:
2018-01-08  Steven G. Kargl  

PR Fortran/83741
* gfortran.dg/allocate_assumed_charlen_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/allocate_assumed_charlen_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83741] [8 Regression] ICE in gfc_match_allocate, at fortran/match.c:4074

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-09
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
I have patch.

[Bug c/83559] [8 regression] -Wsuggest-attribute=const conflicts with -Wattributes warning about const attribute on function returning void

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
One other note: The goal is that new warning will expose opportunities to
improve code (if not fix bugs).  I don't know of a valid use case for a
function to be const and return void but if there is one I'd be interested in
hearing about it.

[Bug target/83743] New: -mcpu=native causes gcc to exit in error if cpu is not recognized

[bergner at gcc dot gnu.org]

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

Bug ID: 83743
   Summary: -mcpu=native causes gcc to exit in error if cpu is not
recognized
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Running an "old" gcc with "-mcpu=native" that's doesn't have basic support for
the processor it is running on, causes gcc to exit in error.

For example, using an old gcc with -mcpu=native on a POWER9 system gives:

cc1: error: unrecognized argument in option '-mcpu=power9'
cc1: note: valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464
464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821
823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500
e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8
powerpc powerpc64 powerpc64le rs64 titan

My $0.02 worth is that we should still error out, but have a slightly more
useful error message, since the user didn't actually type "-mcpu=power9".

[Bug tree-optimization/71361] [7 Regression] Changes in ivopts caused perf regression on x86

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-08
 CC||law at redhat dot com
Summary|[7/8 Regression] Changes in |[7 Regression] Changes in
   |ivopts caused perf  |ivopts caused perf
   |regression on x86   |regression on x86
 Ever confirmed|0   |1

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/81740] [6/7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P2  |P1
 CC||law at redhat dot com

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at redhat dot com

[Bug tree-optimization/83438] [8 Regression] 435.gromacs miscompares

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/83677] PPC: The xxpermr instruction is not generated correctly

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

  Known to fail|8.0 |

--- Comment #3 from Bill Schmidt  ---
Fixed in trunk so far.

[Bug target/83677] PPC: The xxpermr instruction is not generated correctly

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Jan  8 23:08:34 2018
New Revision: 256358

URL: https://gcc.gnu.org/viewcvs?rev=256358&root=gcc&view=rev
Log:
[gcc]

2018-01-08  Bill Schmidt  

PR target/83677
* config/rs6000/altivec.md (*altivec_vpermr__internal):
Reverse order of second and third operands in first alternative.
* config/rs6000/rs6000.c (rs6000_expand_vector_set): Reverse order
of first and second elements in UNSPEC_VPERMR vector.
(altivec_expand_vec_perm_le): Likewise.

[gcc/testsuite]

2018-01-08  Bill Schmidt  

PR target/83677
* gcc.target/powerpc/pr83677.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr83677.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83707] memcmp inline expansion causing g++.dg/eh/simd-3.C to fail on power7 -m32

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
OK, this has nothing to do with memcmp builtin expansion. Also fails with just
-m32 -O1 -fno-builtin-memcmp. Passes with -O0. I checked in gdb and when it
fails the v2 and vt being compared are actually different.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner  ---
Created attachment 43064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43064&action=edit
Proposed fix

I'm testing the attached patch.

[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Confirmed als on on trunk (GCC 8) with the reduced test case below.  As the
warning indicates, the range gets reset to that of short.

$ cat pr83733.c && gcc -O2 -S -Wall pr83733.c
struct S { char a[9], b; };

static void f (struct S *p, int i)
{
  if (i < 0 || i >= 32)
return;

  __builtin_sprintf (p->a, "CMPRT%02d", i);
}

void g (struct S *p, int i, short j)
{
  if (i < 0 || i >= 32)
return;

  if (i == 0)
i = j;

  f (p, i);
}
pr83733.c: In function ‘g’:
pr83733.c:8:34: warning: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Wformat-overflow=]
   __builtin_sprintf (p->a, "CMPRT%02d", i);
  ^~~~
pr83733.c:8:28: note: directive argument in the range [-32768, 32767]
   __builtin_sprintf (p->a, "CMPRT%02d", i);
^~~
pr83733.c:8:3: note: ‘__builtin_sprintf’ output between 8 and 12 bytes into a
destination of size 9
   __builtin_sprintf (p->a, "CMPRT%02d", i);
   ^~~~

[Bug libstdc++/83709] Inserting duplicates into an unordered associative containers causes the container to invalidate iterators

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-08
 Ever confirmed|0   |1

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #7 from Vladimir Makarov  ---
  Thanks your for providing the small test.  I've reproduce the bug.  I will
work on it.  I guess it will be fixed on this week.

[Bug target/82066] #pragma GCC target documentation does not say it is implemented for aarch64

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sje at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #4 from Steve Ellcey  ---
Yes, this is fixed for 8.0.

[Bug target/83726] [8 Regression] ICE: in final_scan_insn, at final.c:3063

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #4 from Steve Ellcey  ---
This looks like the same thing as PR 83632.

[Bug target/83285] non-atomic stores can removed with seq_cst (and store release) on AArch64

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

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

--- Comment #3 from Steve Ellcey  ---
This was fixed for 8.0 with this patch:

commit 31d7a9b35fef974dad13881df6d319b7b08600e8
Author: amonakov 
Date:   Mon Sep 4 10:16:37 2017 +

optabs: ensure atomic_load/stores have compiler barriers

PR rtl-optimization/57448
PR target/67458
PR target/81316
* optabs.c (expand_atomic_load): Place compiler memory barriers if
using atomic_load pattern.
(expand_atomic_store): Likewise.
testsuite/
* gcc.dg/atomic/pr80640-2.c: New testcase.
* gcc.dg/atomic/pr81316.c: New testcase.

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
And to drop the includes:

template  void f()
{
  int x[2];
  auto delegate = [](auto & foo)
  {
for (auto bar : foo);
  };
  delegate(x);
}
int main() {
  f();
}

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
Without fancy tools, looking at the last few lines of the file:

#include 
template  void f()
{
  std::set x;
  auto delegate = [](auto & foo)
  {
for (auto bar : foo);
  };
  delegate(x);
}
int main() {
  f();
}

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[bugzilla at cpockrandt dot de]

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

--- Comment #5 from Chris  ---
(In reply to Chris from comment #4)
> This is the intermediate file of the most simplified code that I came up
> with that reproduces the error (1.9 MB)
> 
> http://www.inf.fu-berlin.de/users/cpockrandt/test_find2_index_approx2.ii

(In reply to Andrew Pinski from comment #3)
> (In reply to Jonathan Wakely from comment #2)
> > There's no way all that code is relevant to the problem.
> > 
> > https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
> 
> Note one method which is not mentioned here when there is a regression in
> rejecting valid code is to test the older working compiler too.
> 
> So a testing "bash" script (which returns 0 when the test should be accepted
> but is not currently, and non zero otherwise) would look something like:
> 
> if old-gcc $1; then
>   exit 1
> fi
> 
> if gcc $1; then
>   exit 0
> fi
> 
> exit 1
>  CUT ---
> And then you use that with delta or otherwise.

Thanks! I'll apply this for reducing the code at the end of the week when I got
more time!

[Bug preprocessor/83063] [8 Regression] ICE on an invalid preprocessor snippet

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
More complete testcase:

#define f1(...) int b##__VA_OPT__(c)
#define f2(...) int __VA_OPT__(c)##d
#define f3(...) int e##__VA_OPT__()
#define f4(...) int __VA_OPT__()##f
#define f5(...) int g##__VA_OPT__(h)##i
#define f6(...) int j##__VA_OPT__()##k
#define f7(...) int l##__VA_OPT__()
#define f8(...) int __VA_OPT__()##m
#define f9(...) int n##__VA_OPT__()##o
f1 (1, 2, 3);
f1 ();
f2 (1, 2);
f2 ();
f3 (1);
f4 (2);
f5 (6, 7);
f5 ();
f6 (8);
f7 ();
f8 ();
f9 ();

int
main ()
{
  return bc + b + cd + d + f + ghi + gi + jk + l + m + no;
}


I have so far following patch:
--- libcpp/macro.c.jj   2018-01-03 10:42:55.938763447 +0100
+++ libcpp/macro.c  2018-01-08 20:36:52.733255700 +0100
@@ -105,6 +105,7 @@ class vaopt_state {
 : m_pfile (pfile),
 m_allowed (any_args),
 m_variadic (is_variadic),
+m_any_tokens (false),
 m_state (0),
 m_last_was_paste (false),
 m_paste_location (0),
@@ -116,7 +117,8 @@ class vaopt_state {
   {
 ERROR,
 DROP,
-INCLUDE
+INCLUDE,
+PADDING
   };

   /* Given a token, update the state of this tracker and return a
@@ -191,9 +193,10 @@ class vaopt_state {
return ERROR;
  }

-   return DROP;
+   return m_any_tokens ? DROP : PADDING;
  }
  }
+m_any_tokens |= m_allowed;
return m_allowed ? INCLUDE : DROP;
   }

@@ -220,6 +223,8 @@ class vaopt_state {
   bool m_allowed;
   /* True if the macro is variadic.  */
   bool m_variadic;
+  /* True if any tokens inside of __VA_OPT__ content were INCLUDE.  */
+  bool m_any_tokens;

   /* The state variable:
  0 means not parsing
@@ -1839,8 +1844,22 @@ replace_args (cpp_reader *pfile, cpp_has
   const cpp_token **tmp_token_ptr;

   /* __VA_OPT__ handling.  */
-  if (vaopt_tracker.update (src) != vaopt_state::INCLUDE)
-   continue;
+  vaopt_state::update_type vaopt_state = vaopt_tracker.update (src);
+  if (vaopt_state != vaopt_state::INCLUDE)
+   {
+ if (vaopt_state == vaopt_state::PADDING)
+   {
+ const cpp_token *t = padding_token (pfile, src);
+ unsigned index = expanded_token_index (pfile, macro, src, i);
+ /* Allocate a virtual location for the padding token and
+append the token and its location to BUFF and
+VIRT_LOCS.   */
+ tokens_buff_add_token (buff, virt_locs, t,
+t->src_loc, t->src_loc,
+map, index);
+   }
+ continue;
+   }

   if (src->type != CPP_MACRO_ARG)
{

and while it fixes the ICEs, it doesn't still preprocess it properly.

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[bugzilla at cpockrandt dot de]

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

--- Comment #4 from Chris  ---
This is the intermediate file of the most simplified code that I came up with
that reproduces the error (1.9 MB)

http://www.inf.fu-berlin.de/users/cpockrandt/test_find2_index_approx2.ii

[Bug fortran/83742] New: [8 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5323

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

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

Bug ID: 83742
   Summary: [8 Regression] ICE in gfc_is_simply_contiguous, at
fortran/expr.c:5323
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With this testcase :

$ cat z1.f90
program p
   real, target :: a
   real, pointer, contiguous :: b => a
end


$ gfortran-8-20170924 -c z1.f90
z1.f90:3:33:

real, pointer, contiguous :: b => a
 1
Error: 'b' at (1) has the CONTIGUOUS attribute but is not an array pointer or
an assumed-shape or assumed-rank array


$ gfortran-8-20171008 -c z1.f90
f951: internal compiler error: Segmentation fault
#...


$ gfortran-8-20180107 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb8c1ef crash_signal
../../gcc/toplev.c:325
0x6aa5ec gfc_is_simply_contiguous(gfc_expr*, bool, bool)
../../gcc/fortran/expr.c:5323
0x6ab4ce gfc_check_pointer_assign(gfc_expr*, gfc_expr*)
../../gcc/fortran/expr.c:3916
0x6ab8fa gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
../../gcc/fortran/expr.c:4005
0x68dd1c add_init_expr_to_sym
../../gcc/fortran/decl.c:1693
0x697193 variable_decl
../../gcc/fortran/decl.c:2589
0x697193 gfc_match_data_decl()
../../gcc/fortran/decl.c:5692
0x6f1d39 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f542e match_word
../../gcc/fortran/parse.c:376
0x6f542e decode_statement
../../gcc/fortran/parse.c:376
0x6f7264 next_free
../../gcc/fortran/parse.c:1226
0x6f7264 next_statement
../../gcc/fortran/parse.c:1458
0x6f8b4c parse_spec
../../gcc/fortran/parse.c:3836
0x6fb003 parse_progunit
../../gcc/fortran/parse.c:5649
0x6fc5e4 gfc_parse_file()
../../gcc/fortran/parse.c:6189
0x742cef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug middle-end/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

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

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

--- Comment #2 from G. Steinmetz  ---
plain vanilla x86_64 with linux

[Bug fortran/83741] New: [8 Regression] ICE in gfc_match_allocate, at fortran/match.c:4074

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

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

Bug ID: 83741
   Summary: [8 Regression] ICE in gfc_match_allocate, at
fortran/match.c:4074
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With following invalid testcases :


$ cat z1.f90
program p
   allocate (character(*) :: x)
end

$ cat z2.f90
module m
   allocate (character(*) :: x)
end


$ gfortran-8-20171203 -c z1.f90
z1.f90:2:29:

allocate (character(*) :: x)
 1
Error: Allocate-object at (1) is neither a data pointer nor an allocatable
variable


$ gfortran-8-20171210 -c z1.f90
f951: internal compiler error: Segmentation fault
#...


$ gfortran-8-20180107 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb8c1ef crash_signal
../../gcc/toplev.c:325
0x6d46ee gfc_match_allocate()
../../gcc/fortran/match.c:4074
0x6f1d39 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f5ba9 match_word
../../gcc/fortran/parse.c:439
0x6f5ba9 decode_statement
../../gcc/fortran/parse.c:439
0x6f7264 next_free
../../gcc/fortran/parse.c:1226
0x6f7264 next_statement
../../gcc/fortran/parse.c:1458
0x6f906c parse_spec
../../gcc/fortran/parse.c:3652
0x6fb003 parse_progunit
../../gcc/fortran/parse.c:5649
0x6fc5e4 gfc_parse_file()
../../gcc/fortran/parse.c:6189
0x742cef gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/82975] [6/7 Regression] ICE in baseness at rtlanal.c:6220

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Fixed on GCC 7 too.

[Bug middle-end/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
  Component|fortran |middle-end
   Target Milestone|--- |8.0

--- Comment #1 from Andrew Pinski  ---
What target is this for?

[Bug target/82975] [6/7 Regression] ICE in baseness at rtlanal.c:6220

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Mon Jan  8 18:42:50 2018
New Revision: 256350

URL: https://gcc.gnu.org/viewcvs?rev=256350&root=gcc&view=rev
Log:
[arm] PR target/82975: Guard against reg_renumber being NULL in arm.h

Backport from mainline
2017-12-20  Kyrylo Tkachov  

PR target/82975
* config/arm/arm.h (TEST_REGNO): Adjust comment as expected in r255830.

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


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr82975.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-reduction,
   ||rejects-valid
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-08
   Target Milestone|--- |8.0
Summary|error: range-based 'for'|[8 Regression] error:
   |expression of type 'auto'   |range-based 'for'
   |has incomplete type |expression of type 'auto'
   ||has incomplete type
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> There's no way all that code is relevant to the problem.
> 
> https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

Note one method which is not mentioned here when there is a regression in
rejecting valid code is to test the older working compiler too.

So a testing "bash" script (which returns 0 when the test should be accepted
but is not currently, and non zero otherwise) would look something like:

if old-gcc $1; then
  exit 1
fi

if gcc $1; then
  exit 0
fi

exit 1
 CUT ---
And then you use that with delta or otherwise.

[Bug fortran/83740] New: [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140

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

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

Bug ID: 83740
   Summary: [8 Regression] ICE in maybe_legitimize_operand, at
optabs.c:7140
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With testfiles array_constructor_17.f90 or string_array_constructor_3.f90
from ./gcc/testsuite/gfortran.dg, and with -fcheck=all or -fcheck=bounds.

Simplified testcase :

$ cat z1.f90
program p
   print *, [(f(3), i = 1, 2)]
contains
   function f(n) result(z)
  integer :: n
  character(n) :: z
  z = 'abc'
   end
end


$ gfortran-8-20171217 -c z1.f90 -fcheck=all
$
$ gfortran-8-20180107 -c z1.f90
$
$ gfortran-8-20180107 -c z1.f90 -fcheck=all
during RTL pass: expand
z1.f90:2:0:

print *, [(f(3), i = 1, 2)]

internal compiler error: in maybe_legitimize_operand, at optabs.c:7140
0xaa9174 maybe_legitimize_operand
../../gcc/optabs.c:7139
0xaa9174 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../gcc/optabs.c:7211
0xaa9399 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.c:7229
0xaaba8a maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/optabs.c:7272
0xaaba8a emit_conditional_move(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/optabs.c:4348
0x8fb7e5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9173
0x7fd05d expand_gimple_stmt_1
../../gcc/cfgexpand.c:3729
0x7fd05d expand_gimple_stmt
../../gcc/cfgexpand.c:3790
0x7fe43b expand_gimple_basic_block
../../gcc/cfgexpand.c:5810
0x803846 execute
../../gcc/cfgexpand.c:6416

[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Both instances fixed on the trunk.

[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan  8 18:20:21 2018
New Revision: 256349

URL: https://gcc.gnu.org/viewcvs?rev=256349&root=gcc&view=rev
Log:
PR rtl-optimizatin/81308
* tree-switch-conversion.c (cfg_altered): New file scoped static.
(process_switch): If group_case_labels makes a change, then set
cfg_altered.
(pass_convert_switch::execute): If a switch is converted, then
set cfg_altered.  Return TODO_cfg_cleanup if cfg_altered is true.

PR rtl-optimizatin/81308
* g++.dg/pr81308-1.C: New test.
* g++.dg/pr81308-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr81308-1.C
trunk/gcc/testsuite/g++.dg/pr81308-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-switch-conversion.c

[Bug rtl-optimization/81308] [8 regression] ICE in calc_dfs_tree, at dominance.c:458

[law at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey A. Law  ---
Author: law
Date: Mon Jan  8 18:17:51 2018
New Revision: 256348

URL: https://gcc.gnu.org/viewcvs?rev=256348&root=gcc&view=rev
Log:
PR rtl-optimization/81308
* recog.c (split_all_insns): Conditionally cleanup the CFG after
splitting insns.

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

[Bug c++/83739] error: range-based 'for' expression of type 'auto' has incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
There's no way all that code is relevant to the problem.

https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
A better test case which "looks" valid to me and still ICEs with -O1
-mabi=elfv2 -S (on LE):

typedef __attribute__((altivec(vector__))) int v4si_t;
int
foo (void)
{
  v4si_t a, u, v, y;
  u = __builtin_altivec_lvx (32, ((void *) &a) - 32);
  v = __builtin_altivec_lvx (64, ((void *) &a) - 32);
  y = u + v;
  return y[0];
}

[Bug c++/83739] error: range-based 'for' expression of type 'auto' has incomplete type

[bugzilla at cpockrandt dot de]

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

--- Comment #1 from Chris  ---
Sorry, the ii-file is too large to post it here, I uploaded it instead
somewhere else (7.7 MB):

www.inf.fu-berlin.de/users/cpockrandt/test_find2_index_approx.ii

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
That last testcase needs -mabi=elfv2 to fail (but doesn't need that -O3).

[Bug c++/83739] New: error: range-based 'for' expression of type 'auto' has incomplete type

[bugzilla at cpockrandt dot de]

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

Bug ID: 83739
   Summary: error: range-based 'for' expression of type 'auto' has
incomplete type
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla at cpockrandt dot de
  Target Milestone: ---

Compiler/OS information:

g++8 (FreeBSD Ports Collection) 8.0.0 20171224 (experimental)

Error-Message (see below for complete output):

/home/mi/user/seqan/tests/index/test_find2_index_approx.h:478:9: error:
range-based 'for' expression of type 'auto' has incomplete type
 for (auto occ : getOccurrences(iter))
 ^~~

Command:

/usr/local/bin/g++8  -DSEQAN_DISABLE_VERSION_CHECK -DSEQAN_ENABLE_TESTING=1
-DSEQAN_HAS_BZIP2=1 -DSEQAN_HAS_EXECINFO=1 -DSEQAN_HAS_OPENMP=1
-DSEQAN_HAS_ZLIB=1 -D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99=1
-D_LARGEFILE_SOURCE -I/home/mi/user/seqan/include -save-temps  -W -Wall
-pedantic  -fno-omit-frame-pointer -fopenmp -g -DSEQAN_ENABLE_DEBUG=1   
-DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_find2_index_approx.dir/test_find2_index_approx.cpp.o -c
/home/mi/user/seqan/tests/index/test_find2_index_approx.cpp

It works with the latest versions of g++4, 5, 6 and 7 and clang.

---

Complete output:

[user@celegans ~/seqan-build]$ make VERBOSE=1 test_find2_index_approx
/usr/local/bin/cmake -H/home/mi/user/seqan -B/home/mi/user/seqan-build
--check-build-system CMakeFiles/Makefile.cmake 0
make -f CMakeFiles/Makefile2 test_find2_index_approx
/usr/local/bin/cmake -H/home/mi/user/seqan -B/home/mi/user/seqan-build
--check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start
/home/mi/user/seqan-build/CMakeFiles 0
make -f CMakeFiles/Makefile2
tests/index/CMakeFiles/test_find2_index_approx.dir/all
make -f CMakeFiles/seqan_library.dir/build.make
CMakeFiles/seqan_library.dir/depend
cd /home/mi/user/seqan-build && /usr/local/bin/cmake -E cmake_depends "Unix
Makefiles" /home/mi/user/seqan /home/mi/user/seqan /home/mi/user/seqan-build
/home/mi/user/seqan-build
/home/mi/user/seqan-build/CMakeFiles/seqan_library.dir/DependInfo.cmake
--color=
Dependee
"/home/mi/user/seqan-build/CMakeFiles/seqan_library.dir/DependInfo.cmake" is
newer than depender
"/home/mi/user/seqan-build/CMakeFiles/seqan_library.dir/depend.internal".
Dependee "/home/mi/user/seqan-build/CMakeFiles/CMakeDirectoryInformation.cmake"
is newer than depender
"/home/mi/user/seqan-build/CMakeFiles/seqan_library.dir/depend.internal".
Scanning dependencies of target seqan_library
make -f CMakeFiles/seqan_library.dir/build.make
CMakeFiles/seqan_library.dir/build
Built target seqan_library
make -f tests/index/CMakeFiles/test_find2_index_approx.dir/build.make
tests/index/CMakeFiles/test_find2_index_approx.dir/depend
cd /home/mi/user/seqan-build && /usr/local/bin/cmake -E cmake_depends "Unix
Makefiles" /home/mi/user/seqan /home/mi/user/seqan/tests/index
/home/mi/user/seqan-build /home/mi/user/seqan-build/tests/index
/home/mi/user/seqan-build/tests/index/CMakeFiles/test_find2_index_approx.dir/DependInfo.cmake
--color=
Dependee
"/home/mi/user/seqan-build/tests/index/CMakeFiles/test_find2_index_approx.dir/DependInfo.cmake"
is newer than depender
"/home/mi/user/seqan-build/tests/index/CMakeFiles/test_find2_index_approx.dir/depend.internal".
Dependee
"/home/mi/user/seqan-build/tests/index/CMakeFiles/CMakeDirectoryInformation.cmake"
is newer than depender
"/home/mi/user/seqan-build/tests/index/CMakeFiles/test_find2_index_approx.dir/depend.internal".
Scanning dependencies of target test_find2_index_approx
make -f tests/index/CMakeFiles/test_find2_index_approx.dir/build.make
tests/index/CMakeFiles/test_find2_index_approx.dir/build
Building CXX object
tests/index/CMakeFiles/test_find2_index_approx.dir/test_find2_index_approx.cpp.o
cd /home/mi/user/seqan-build/tests/index && /usr/local/bin/g++8 
-DSEQAN_DISABLE_VERSION_CHECK -DSEQAN_ENABLE_TESTING=1 -DSEQAN_HAS_BZIP2=1
-DSEQAN_HAS_EXECINFO=1 -DSEQAN_HAS_OPENMP=1 -DSEQAN_HAS_ZLIB=1
-D_FILE_OFFSET_BITS=64 -D_GLIBCXX_USE_C99=1 -D_LARGEFILE_SOURCE
-I/home/mi/user/seqan/include -save-temps  -W -Wall -pedantic 
-fno-omit-frame-pointer -fopenmp -g -DSEQAN_ENABLE_DEBUG=1   
-DSEQAN_GLOBAL_EXCEPTION_HANDLER=1 -o
CMakeFiles/test_find2_index_approx.dir/test_find2_index_approx.cpp.o -c
/home/mi/user/seqan/tests/index/test_find2_index_approx.cpp
In file included from
/home/mi/user/seqan/tests/index/test_find2_index_approx.cpp:37:
/home/mi/user/seqan/tests/index/test_find2_index_approx.h: In instantiation of
'void SEQAN_TEST_test_find2_index_approx_small_test() [with bool
speed_up_dummy_to_prevent_compilation_of_unused_tests_ = true]':
/home/mi/user/seqan/tests/index/test_find2_index_approx.cpp:44:135:   required
from here
/home/mi/user/seqan/tests/index/test

[Bug c++/83732] wrong warning about non-POD field

[stsp at users dot sourceforge.net]

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

--- Comment #5 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #3)
> warning_at
>   (DECL_SOURCE_LOCATION (x), 0,
>"ignoring packed attribute because of unpacked non-POD field 
> %q#D",
>x);
> cant_pack = 1;

I wonder why this "cant_pack" is getting
ignored somewhere later? The things are still
packed.

[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #4 from Peter Bergner  ---
Smaller test case:

bergner@genoa:~/gcc/BUGS/PR83399$ cat pr83399.i 
int
foo (const int *a)
{
  __attribute__((altivec(vector__))) int u, v, y;
  u = __builtin_altivec_lvx (32, ((void *) &a) - 32);
  v = __builtin_altivec_lvx (64, ((void *) &a) - 32);
  y = u + v;
  return y[0];
}
bergner@genoa:~/gcc/BUGS/PR83399$
/home/bergner/gcc/build/gcc-fsf-mainline-pr83399-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pr83399-debug/gcc -O3 -S pr83399.i 
during RTL pass: reload
pr83399.i: In function ‘foo’:
pr83399.i:9:1: internal compiler error: in lra_set_insn_recog_data, at
lra.c:998
 }
 ^
0x10bbe853 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr83399/gcc/lra.c:996
0x10bbb6d3 lra_get_insn_recog_data
/home/bergner/gcc/gcc-fsf-mainline-pr83399/gcc/lra-int.h:491
0x10bc10af lra_update_insn_regno_info(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-pr83399/gcc/lra.c:1622
...

[Bug lto/83720] [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems this is caused by mismatch between type_with_linkage_p in the middle-end,
which for this lambda type says that the __lambda* type in question has
linkage, and the mangler, which has:
3846  gcc_assert (TREE_CODE (decl) != TYPE_DECL
3847  || !no_linkage_check (TREE_TYPE (decl), true));
and in this case, no_linkage_check returns non-NULL (the TREE_TYPE (decl)
itself).

SO, shall type_with_linkage_p use a langhook and the C++ FE call
no_linkage_check in that case?

[Bug middle-end/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  ---
...and this is a middle-end flaw because POINTERS_EXTEND_UNSIGNED states:

[...] You need not define this macro [which is the case for avr] if the
ptr_mode, Pmode and word_mode are all the same width [which is also true for
avr]. 

https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gccint/Storage-Layout.html#index-POINTERS_005fEXTEND_005fUNSIGNED

Actually I don't see any readon for why an extension should be needed here as
both targetm.addr_space.pointer_mode (__memx) and
targetm.addr_space.address_mode (__memx) are PSImode.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
I have noticed that accidental change and plan to deal with it while retuning
inliner now.

I think overall the problem is caused by the fact that old code capped time to
1. This means that most larger functions was estimated to have time 1
and inlining seemed to produce no speedup.

With sreals we keep the ratios more realistic and see more benefits from
inlining and thus get big speedup more often.  I will see what I can do with
the default value wrt code size.

Thanks for bisecting this!

[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||matthew.fortune at imgtec dot 
com

--- Comment #9 from Tom de Vries  ---
(In reply to Tom de Vries from comment #8)
> (In reply to Tom de Vries from comment #7)
> > (In reply to Tom de Vries from comment #6)
> > > Submitted: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01030.html
> > 
> > Approved. Todo: testing.
> 
> Bootstrap and reg-test on x86_64 done.
> 
> Todo: mips testing.

Asked Matthew to help us out with the testing:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00503.html .

[Bug target/83663] [8 regression] aarch64_be regressions after r255946

[vp at gcc dot gnu.org]

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

--- Comment #2 from Vidya Praveen  ---
Author: vp
Date: Mon Jan  8 16:24:49 2018
New Revision: 256346

URL: https://gcc.gnu.org/viewcvs?rev=256346&root=gcc&view=rev
Log:
gcc/

2018-01-08  Vidya Praveen  

PR target/83663 - Revert r255946
* config/aarch64/aarch64.c (aarch64_expand_vector_init): Modify code
generation for cases where splatting a value is not useful.
* simplify-rtx.c (simplify_ternary_operation): Simplify vec_merge
across a vec_duplicate and a paradoxical subreg forming a vector
mode to a vec_concat.

gcc/testsuite/

2018-01-08  Vidya Praveen  

PR target/83663 - Revert r255946
* gcc.target/aarch64/vect-slp-dup.c: New.


Removed:
trunk/gcc/testsuite/gcc.target/aarch64/vect-slp-dup.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 43063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43063&action=edit
gcc8-pr83507.patch

Untested fix.

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org

--- Comment #12 from Jan Hubicka  ---
Sorry, attached incorrect path.
Index: ipa-comdats.c
===
--- ipa-comdats.c   (revision 256232)
+++ ipa-comdats.c   (working copy)
@@ -211,8 +211,11 @@ set_comdat_group (symtab_node *symbol,
   symtab_node *head = (symtab_node *)head_p;

   gcc_assert (!symbol->get_comdat_group ());
-  symbol->set_comdat_group (head->get_comdat_group ());
-  symbol->add_to_same_comdat_group (head);
+  if (symbol->real_symbol_p ())
+{
+  symbol->set_comdat_group (head->get_comdat_group ());
+  symbol->add_to_same_comdat_group (head);
+}
   return false;
 }

[Bug target/83738] [avr] Don't save registers in main

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-08
 Ever confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  ---
Currently we are saving all used callee-saved registers in main which is
overhead.  It can be mitigated by attribute OS_main, but we could skip saving
them per default.  Not even the test suite (where flow drops out of main) needs
saving these regs.

[Bug target/83738] New: [avr] Don't save registers in main

[gjl at gcc dot gnu.org]

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

Bug ID: 83738
   Summary: [avr] Don't save registers in main
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist

[clyon at gcc dot gnu.org]

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

--- Comment #13 from Christophe Lyon  ---
On x86_64 target, the test passes alone, but fails when using proot.

So the problem is fully on my side, sorry for the noise.

[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||ktkachov at gcc dot gnu.org
Summary|"Unable to find a register  |[6/7/8 Regression] "Unable
   |to spill" when compiling|to find a register to
   |for thumb1  |spill" when compiling for
   ||thumb1
  Known to fail||4.8.5, 4.9.4, 5.4.1, 6.4.1,
   ||7.2.1, 8.0

--- Comment #3 from ktkachov at gcc dot gnu.org ---
I've reproduced it on every version from 4.8 onward.
My configuration for my arm-none-linux-gnueabi compiler are:
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp
--with-arch=armv7-a 

Compiling with -mfloat-abi=softfp -mthumb -march=armv5t -O2 ICEs

[Bug c++/83716] tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_inner_reference

[uruwi at protonmail dot com]

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

--- Comment #3 from uruwi at protonmail dot com ---
Confirmed that running g++ on the preprocessed file produces the assertion
failure instead.

[Bug target/83712] "Unable to find a register to spill" when compiling for thumb1

[mikulas at artax dot karlin.mff.cuni.cz]

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

--- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz ---
I can reproduce it with
gcc-4.8.4 on Ubuntu 14.04 on native armhf (it doesn't reproduce with gcc-4.9 on
the same machine)
arm-linux-gnueabi-gcc-6 cross-compiler on Debian Stretch
arm-linux-gnueabi-gcc-7 cross-compiler on Debian Sid

If you have x86-64 Debian Stretch or Sid, install the package
"gcc-arm-linux-gnueabi" to reproduce this bug.

[Bug middle-end/83653] [6/7/8 Regression] GCC fails to remove a can't-happen call on ia64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[6 Regression] GCC fails to |[6/7/8 Regression] GCC
   |remove a can't-happen call  |fails to remove a
   |on ia64 |can't-happen call on ia64
  Known to fail||4.9.4, 5.5.0, 6.2.0, 7.2.0

--- Comment #3 from Richard Biener  ---
So I just assume trunk fails as well.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Mon, 8 Jan 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665
> 
> --- Comment #6 from Martin Liška  ---
> Ok, for the gromacs
> 
> r255102: .text size: 737B
> r255103 + fix for sreal (r256072): .text size: 752B (+2.03%).
> 
> Honza can you please take a look?

suspicous chage:

@@ -1151,7 +1118,7 @@ edge_badness (struct cgraph_edge *edge,
overall_growth += 256 * 256 - 256;
  denominator *= overall_growth;
 }
-  denominator *= inlined_time;
+  /*denominator *= inlined_time;*/

   badness = - numerator / denominator;


does uncommenting fix that?

[Bug middle-end/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-08
  Component|target  |middle-end
Summary|AVR ICE on  |[8 Regression] AVR ICE on
   |convert_memory_address_addr |convert_memory_address_addr
   |_space_1 at explow.c:300|_space_1 at explow.c:300
 Ever confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  ---
Confirmed for v8 with a reduced test case and -O for:

const __memx char ascdays[] = "SunMonTueWedThuFriSat";

void
asctime_r (int a, char *buffer)
{
buffer[0] = ascdays[a];
}

v7 and v6 are ok.

[Bug rtl-optimization/83629] [7/8 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-08
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
I have a fuller patch; it's testing (your variant 1).

[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Andrey Guskov  ---
Just checked again. Both tests pass now, so this ticket should be closed.

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #11 from Jan Hubicka  ---
The reduced testcase does not reproduce anymore so I assumed this to be fixed,
sorry for that.  The problem is that comdats pass privatizes inlined thunk.
This is bid odd side case of for_symbol_thunk_and_aliases - honestly i am not
sure if it should consider inlined thunk to be thunk anymore, but given the
name it probably should.

Honza

Index: ipa-comdats.c
===
--- ipa-comdats.c   (revision 256232)
+++ ipa-comdats.c   (working copy)
@@ -341,7 +341,7 @@ ipa_comdats (void)
   if (!symbol->get_comdat_group ()
  && !symbol->alias
  && (!(fun = dyn_cast  (symbol))
- || !fun->thunk.thunk_p)
+ || (!fun->thunk.thunk_p && !fun->global.inlined_to))
  && symbol->real_symbol_p ())
{
  tree *val = map.get (symbol);

[Bug rtl-optimization/83629] [7/8 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Needs e.g. -mcpu=603 to fail.

[Bug tree-optimization/83572] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 7 should be 15, not 13)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> The issue here is we have a non SESE-region to start with.

Related to post-dominators not being meaningful in infinite loop context. 
Connecting infinite loops to exit "causes", so some more fiddling needed.

FAIL: gfortran.dg/graphite/pr68453.f90   -O  (internal compiler error)
FAIL: gfortran.dg/graphite/pr68453.f90   -O  (test for excess errors)

[Bug tree-optimization/83563] [8 Regression] [graphite] ICE: Segmentation fault (in instantiate_scev_r)

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Jan  8 15:04:53 2018
New Revision: 256343

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

PR tree-optimization/83563
* graphite.c (canonicalize_loop_closed_ssa_form): Reset the SCEV
cache.

* gcc.dg/graphite/pr83563.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83563.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83563] [8 Regression] [graphite] ICE: Segmentation fault (in instantiate_scev_r)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Yes, but those saves should be to slots chosen earlier by
ix86_compute_frame_layout, shouldn't they.  And then the question is why it
chose a frame size that isn't multiple of the needed alignment.

[Bug target/83712] "Unable to find a register to spill" when compiling for thumb1

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
I can't reproduce this.  My compilers build the testcase without problems. 
I've tried various releases of GCC as well.  Exactly how was your compiler
configured?  What is the output of "gcc -v"?

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
push comes from

13174 if (!int_registers_saved)
13175   {
13176 /* If saving registers via PUSH, do so now.  */
13177 if (!frame.save_regs_using_mov)
13178   {
13179 ix86_emit_save_regs ();
13180 int_registers_saved = true;
13181 gcc_assert (m->fs.sp_offset == frame.reg_save_offset);
13182   }
13183   
(gdb)

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Another experiment:

r255024: 741B
r255024 + patch r255103 + patch r256072: 752B

[Bug middle-end/83653] [6 Regression] GCC fails to remove a can't-happen call on ia64

[matthew at wil dot cx]

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

--- Comment #2 from Matthew Wilcox  ---
7.2, 6.2, 5.5 and 4.9 fail.  4.6.3 succeeds.

[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist

[clyon at gcc dot gnu.org]

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

--- Comment #12 from Christophe Lyon  ---
Running the test manually with qemu only works, so it looks like there is a bad
interaction between proot and qemu. I'll try to investigate this more.

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
In main (), various RTL passes generate

(insn/f 461 460 462 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8]) 
(reg:DI 3 bx)) "x.i":17 61 {*pushdi2_rex64}
 (expr_list:REG_DEAD (reg:DI 3 bx)
(nil)))

It destroys stack alignment. It doesn't happen in non-main functions.

[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Ok, for the gromacs

r255102: .text size: 737B
r255103 + fix for sreal (r256072): .text size: 752B (+2.03%).

Honza can you please take a look?

[Bug testsuite/83737] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Tom de Vries  ---
> The missing macro is available in ./gcc/ginclude/stdint-gcc.h, but the used
> stdint.h is from newlib.

Joseph, do you know whether this is an error in installation? Should the gcc
stdint.h be installed instead of the newlib one?

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
BTW, -O3 -mavx512bw ins't needed, e.g. -O3 -mavx reproduces it too.

The function doesn't really need DRAP or stack realignment, but because
stack_alignment_needed is 128, better should make sure that sp is properly
aligned.  Can't reproduce with a function other than main though, even with
-fno-omit-frame-pointer.

[Bug testsuite/83737] New: FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h

[vries at gcc dot gnu.org]

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

Bug ID: 83737
   Summary: FAIL: gcc.dg/stdint-width-1.c (test for excess errors)
for with newlib stdint.h
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Fox nvptx, I see the following failure:
...
FAIL: gcc.dg/stdint-width-1.c (test for excess errors)
...

In more detail:
...
gcc/testsuite/gcc.dg/stdint-width-1.c:20:4: error: #error "missing INT8_WIDTH"
...

The missing macro is available in ./gcc/ginclude/stdint-gcc.h, but the used
stdint.h is from newlib.

Tentatively setting component to testsuite.

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The n variable is 128-bit aligned and lives on the stack, so it is unclear why
the stack realignment code misses that.

[Bug c++/83713] [6/7 Regression] ICE in do_narrow at gcc/convert.c:474

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |do_narrow at|do_narrow at
   |gcc/convert.c:474   |gcc/convert.c:474
  Known to fail|8.0 |

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

[Bug c++/83713] [6/7/8 Regression] ICE in do_narrow at gcc/convert.c:474

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Jan  8 13:24:38 2018
New Revision: 256341

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

PR middle-end/83713
* convert.c (do_narrow): Properly guard TYPE_OVERFLOW_WRAPS checks.

* g++.dg/torture/pr83713.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr83713.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/convert.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jan  8 13:22:56 2018
New Revision: 256339

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

PR tree-optimization/83685
* tree-ssa-pre.c (create_expression_by_pieces): Do not insert
references to abnormals.

* gcc.dg/torture/pr83685.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr83685.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
But again succeeds with -mno-stv, so likely dup of PR83330.

[Bug target/83735] [8 Regression] generating unaligned store to stack with vmovaps

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-08
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r250084.

[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining

[tim.vanholder at anubex dot com]

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

--- Comment #2 from Tim Van Holder  ---
Created attachment 43062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43062&action=edit
Testcase

Testcase attached.

Compiling with "gcc -c -Wall -Wextra -Werror -O3 gcc83733.c" yields:

gcc83733.c: In function ‘caller1’:
gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Werror=format-overflow=]
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
^~~~
gcc83733.c:33:38: note: directive argument in the range [-32768, 32767]
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
  ^~~
gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a
destination of size 9
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
   ^~~~
gcc83733.c: In function ‘caller2’:
gcc83733.c:33:44: error: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Werror=format-overflow=]
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
^~~~
gcc83733.c:33:38: note: directive argument in the range [-32768, 32767]
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
  ^~~
gcc83733.c:33:7: note: ‘sprintf’ output between 8 and 12 bytes into a
destination of size 9
   sprintf (r->definition.ddname, "CMPRT%02d", foo);
   ^~~~


There seem to be several subtleties involved.
For example, dropping the 'definition' struct (making 'ddname' a field directly
in 'foo_t') changes the diagnostic, claiming there's 11 bytes in the target
(slack space in the struct?).

[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/83719] [8 Regression] ICE (segfault) in hash_table::elements()

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jan  8 13:13:48 2018
New Revision: 256338

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

PR lto/83719
* dwarf2out.c (output_indirect_strings): Handle empty
skeleton_debug_str_hash.
(dwarf2out_early_finish): Index strings for -gsplit-dwarf.

* gcc.dg/lto/pr83719_0.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/lto/pr83719_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #4)
> This must be with -flto at least too.

Even with -flto I can't reproduce. Can you please attach SPEC build log file?