[Bug debug/84776] Indefinite compile time w/ var-tracking

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
The max-vartrack-expr-depth=20 parameter is recursion depth, so for many
expressions it is exponential compile time for that number.  20 is much higher
than the default, so compile time that much exponentially higher...

Adding a hard limit on the param is not really a good idea, in some cases it
could be limiting people from doing what they want.  But if you use too high
value, you've asked for it.

[Bug debug/84776] New: Indefinite compile time w/ var-tracking

[asolokha at gmx dot com]

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

Bug ID: 84776
   Summary: Indefinite compile time w/ var-tracking
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180225 snapshot (r257975), 7.3, 6.3, 5.4, 4.9.4, 4.8.5, 4.7.4
all take indefinite time when compiling the following snippet w/ -g -O3
(-Ofast) -fno-tree-dce --param max-completely-peel-times=20 --param
max-vartrack-expr-depth=20:

int
vv (int ob)
{
  int hw = ob;
  int kh = hw;

  for (ob = 0; ob < 20; ++ob)
hw *= hw;

  return kh;
}

gcc 4.6.4 doesn't have param max-vartrack-expr-depth. -fno-var-tracking fixes
the issue.

% timeout 5 gcc-8.0.0-alpha20180225 -g -O3 -fno-tree-dce --param
max-completely-peel-times=20 --param max-vartrack-expr-depth=20 -c rogfdfw4.c
zsh: exit 124   timeout 5 gcc-8.0.0-alpha20180225 -g -O3 -fno-tree-dce --param 
--param  -c

perf top captures the following profile:

  27.96%  cc1  [.] simplify_binary_operation_1
  23.79%  cc1  [.] avoid_constant_pool_reference
  15.57%  cc1  [.] simplify_binary_operation
  13.21%  cc1  [.] commutative_operand_precedence
   8.49%  cc1  [.] simplify_associative_operation
   5.90%  cc1  [.] simplify_const_binary_operation
   2.59%  cc1  [.] swap_commutative_operands_p
   1.08%  cc1  [.] HONOR_NANS
   0.80%  cc1  [.] HONOR_SIGNED_ZEROS
   0.54%  cc1  [.] HONOR_SNANS
   0.05%  cc1  [.] ggc_internal_alloc

[Bug c++/84610] [6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aoliva at gcc dot gnu.org

--- Comment #2 from Alexandre Oliva  ---
Mine

[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||aoliva at gcc dot gnu.org

--- Comment #3 from Alexandre Oliva  ---
Mine

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-09
 Ever confirmed|0   |1

[Bug tree-optimization/84775] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-09
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||7.3.0
   Target Milestone|--- |8.0
Summary|ICE on valid code at -O3:   |[8 Regression] ICE on valid
   |in  |code at -O3: in
   |check_loop_closed_ssa_def,  |check_loop_closed_ssa_def,
   |at  |at
   |tree-ssa-loop-manip.c:709   |tree-ssa-loop-manip.c:709
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r258364.

[Bug rtl-optimization/84682] [6/7/8 Regression] internal compiler error: Segmentation fault (process_address_1)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Alexandre Oliva  ---
Improved patch posted
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00416.html

[Bug tree-optimization/84775] New: ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709

[su at cs dot ucdavis.edu]

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

Bug ID: 84775
   Summary: ICE on valid code at -O3: in
check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It appears to be a recent regression.

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180309 (experimental) [trunk revision 258374] (GCC) 
$ 
$ gcctk -O2 -c small.c
$ gcc-7.2.0 -O3 -c small.c
$ 
$ gcctk -O3 -c small.c
during GIMPLE pass: ifcvt
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: in check_loop_closed_ssa_def, at
tree-ssa-loop-manip.c:709
 void fn1 ()
  ^~~
0xe3b38c check_loop_closed_ssa_def
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:709
0xe3b4ed check_loop_closed_ssa_bb
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:735
0xe3d686 verify_loop_closed_ssa(bool, loop*)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:760
0xbb888b execute_function_todo
../../gcc-source-trunk/gcc/passes.c:2012
0xbb91a9 execute_todo
../../gcc-source-trunk/gcc/passes.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





int a, b, c, d, e, f;

void fn1 ()
{
  while (e)
for (f = 0; f < 4; f++)
  {
int h[1];
for (; c; c++)
  if (a)
break;
d = a - 4;
if (d)
  b = h[0];
  }
}

[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1

[kevinb at redhat dot com]

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

--- Comment #15 from Kevin Buettner  ---
I've been focusing my attention on dwarf2read.c (in GDB).  I have a patch which
fixes this problem, but which introduces a bunch of test suite regressions. 
(So it's not a very good patch.)  I'll be away on Friday, but will resume
looking at it when I return on Monday.

Anyway, with that not-very-good patch in place, this is what I see:

(gdb) b qux
Breakpoint 1 at 0x4005b0: file vau2.c, line 24.
(gdb) x/i 0x400460
   0x400460 <_Z3quxP1C.cold.0>: callq  0x400430 
(gdb) 
   0x400465:nopw   %cs:0x0(%rax,%rax,1)
(gdb) 
   0x40046f:nop
(gdb) run
Starting program: /mesquite2/.ironwood2/84550/vau2 

Breakpoint 1, qux (p=0x7fffe098) at vau2.c:24
24if (!p->c) __builtin_abort ();
(gdb) s
25a = p->c->b;
(gdb) s
27b = (a->a == 4)
(gdb) s
foo (p=0x7fffe08c) at vau2.c:8
8 return false;

Note that only one location is set for the breakpoint in qux.  Also, I'm now
able to step into foo().

[Bug tree-optimization/84774] New: [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

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

Bug ID: 84774
   Summary: [meta-bug] bogus/missing -Wrestrict
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This meta-bug groups -Wrestrict false positives and negatives.

[Bug tree-optimization/41647] Early Loop Unrolling control

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #2)
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00621.html

Even though this was just an RFC I'd say it's still worth the "patch" keyword

[Bug testsuite/41660] FAIL: gcc.dg/plugin/one_time-test-1.c -fplugin=./one_time_plugin.so (internal compiler error)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to Hans-Peter Nilsson from comment #3)
> Looks like Matz fixed this with r152669.

OK, closing as FIXED then.

[Bug debug/26475] tree-ssa loses line numbers for initializations (constants for PHIs)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Andrew Macleod from comment #5)
> I just checked in the code to track locations through PHI arguments.
> 
> Comments and patch is located:
> http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html

Thread said it was checked it as r150267 apparently?

[Bug target/29997] [meta-bug] various targets: GCC fails to encode epilogues in unwind-info

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=12990

--- Comment #7 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #2)
> (In reply to comment #1)
> > I think this is really a dup of bug 12990.
> > 
> 
> Sort of, but not quite.  12990 does no cover the exception handling aspects,
> but it claims that the problem persists target-independently for debug.
> But this is not a problem for ia64.  Since we have now the target-independent
> infrastructure and one target port that uses it to handle this problem,
> this has become a target problem; each target needs to be adjusted separately
> to create the proper epilogue information, so it makes sense to track
> progress (or lack thereof) for each target individually, while having
> one meta-bug to keep track of them all.
> 
> Should I mark 12990 as blocking 29997, and 29998 as blocking 12990?
> 
> OTOH, when you read the description of 12990, it sounds like the problem
> exists only for i[3456]86-*-*, so maybe we should add this to the target
> field of 12990 and only make 12990 as blocking 29997.

Sounds at least related even if not necessarily blocking.

[Bug target/32340] [arm] libjava build failure due to missing thread synchronization primitives

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #9 from Eric Gallager  ---
libjava has been removed from gcc.

[Bug libstdc++/84773] New: [7/8 Regression] Cross-compilers do not use aligned_alloc or _aligned_malloc for aligned-new

[redi at gcc dot gnu.org]

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

Bug ID: 84773
   Summary: [7/8 Regression] Cross-compilers do not use
aligned_alloc or _aligned_malloc for aligned-new
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Native compilers check for:

  AC_CHECK_FUNCS(aligned_alloc posix_memalign memalign _aligned_malloc)

but cross-compilers don't. This means that a cross-compiler for mingw32 will
use the internal definition of aligned_alloc added for PR libstdc++/79190 but a
native ming32 compiler will use _aligned_malloc instead. That means objects
compiled with the cross-compiler are not compatible with objects compiled with
the native one.

On FreeBSD the same problem prevents bootstrapping a cross-compiler:
https://gcc.gnu.org/ml/gcc-help/2017-11/msg00038.html
Which can be solved by making the cross-compiler check for the same functions
as the native one checks for:
https://gcc.gnu.org/ml/gcc-help/2018-02/msg00095.html

[Bug other/12955] Incorrect rounding of soft float denorm mul/div

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=14354

--- Comment #13 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #12)
> No progress for *years* now. Was bug 14354 the same issue?

I dunno but even if it's not the same maybe it's at least related

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #10 from David Malcolm  ---
Probable duplicate seen downstream here (compiling "tgif"):
  https://bugzilla.redhat.com/show_bug.cgi?id=1553505

I reduced it to:

# cat rhbz1553505.c 

struct NamesRec {
  char inbuf[512];
  char dir_name[256 + 1];
  char name[256 + 1];
};
static struct NamesRec namesInfo;
static void ParseFileName(char *FullName, char *DirName, char *Name)
{
  int i, len;
  len = __builtin_strlen(FullName);
  __builtin_strcpy(DirName, FullName);
  for (i = len - 1; i >= 0; i--) {
if (DirName[i] == '/') {
  __builtin_strcpy(Name, &(DirName[i + 1]));
}
  }
}
void BackUpOneWord(void)
{
  struct NamesRec *pni = (&namesInfo);
  ParseFileName(pni->inbuf, pni->dir_name, pni->name);
}


# gcc -O2 -Wrestrict rhbz1553505.c 

during GIMPLE pass: strlen
rhbz1553505.c: In function ‘BackUpOneWord’:
rhbz1553505.c:18:6: internal compiler error: Segmentation fault
 void BackUpOneWord(void)
  ^
(etc; looks like the same backtrace)

[Bug libstdc++/83662] std::aligned_alloc() not available

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
i.e. I think this is a dup of PR libstdc++/79190

[Bug libstdc++/78565] undefined reference to `aligned_alloc' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Jonathan Wakely  ---
Is this still a problem on the gcc-7-branch or trunk?

r244933 added a definition of aligned_alloc that should get used.

[Bug c++/84770] [8 Regression] ICE with parameter pack involving typedef

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The ICE is due the assert below failing:

gcc_assert (strip_typedefs_expr (arg, NULL) == arg);

arg is



arg:0 
constant
arg:0 
constant arg:0 >

but strip_typedefs_expr() returns



arg:0 
constant
arg:0 
constant arg:0 >

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

--- Comment #3 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Mar  9 01:10:02 2018
New Revision: 258376

URL: https://gcc.gnu.org/viewcvs?rev=258376&root=gcc&view=rev
Log:
PR libstdc++/84769 qualify std::get and std::get_if to avoid ADL

PR libstdc++/84769
* include/std/variant (get<_Tp, _Types...>, get_if<_Tp, _Types...>):
Qualify calls to get<_Np, Types...> and get_if<_Np, _Types...>.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/variant

[Bug c++/84770] [8 Regression] ICE with parameter pack involving typedef

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-09
 CC||jason at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
  Known to work||7.3.0
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r247842 (gcc 8.0.0):

r247842 | jason | 2017-05-10 11:56:09 -0400 (Wed, 10 May 2017) | 8 lines

PR c++/79549 - C++17 ICE with non-type auto template parameter pack

[Bug c++/84767] [6/7/8 Regression] ICE with pointer to VLA

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
At the point the "Local declaration from a different function" error is issued
in verify_expr(t) where t is PARAM_DECL for the argument to A's ctor, context
is:  while cfun->decl is .

[Bug fortran/82859] derived type character component, array comparison inconsistent

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
I suspect that patch to PR 70409 fixed this one as well.

 gfcx -o z a.f90 -fcheck=all && ./z
 A1 /A2  T T T
 SAP/SAA T T T
 SAP/A1  T T T
 SAA/A1  T T T
 SAP/A2  T T T
 SAA/A2  T T T

 A1 /SP  F T F
 A2 /SP  F T F
 SAP/SP  F T F
 SAA/SP  F T F
 A1 /SA  F T F
 A2 /SA  F T F
 SAP/SA  F T F
 SAA/SA  F T F

[Bug c++/84767] [6/7/8 Regression] ICE with pointer to VLA

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-09
 CC||msebor at gcc dot gnu.org
  Known to work||4.8.4
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.3.0, 7.3.0,
   ||8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced in r202647 (gcc 4.9.0).

[Bug target/84772] New: powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)

[zackw at panix dot com]

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

Bug ID: 84772
   Summary: powerpc-spe: Spurious "is used uninitialized" warning,
or possibly incorrect codegen for va_arg(long double)
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zackw at panix dot com
  Target Milestone: ---

The following test case is a mechanical reduction from the implementation of
vfprintf in GNU libc:

extern void *memset(void *, int, __SIZE_TYPE__);
void f(int *a, __builtin_va_list b)
{
  memset(a, 2, sizeof(int));
  for (;;)
__builtin_va_arg(b, long double);
}

I get a spurious uninitialized value warning on the __builtin_va_arg line with
a powerpc-spe compiler, but not with the exact same build targeting a different
architecture -- not even a different powerpc variant:

$ powerpc-glibc-linux-gnuspe-gcc -S -O -Wall -Werror vfp_min3.c; echo $?
vfp_min3.c: In function ‘f’:
vfp_min3.c:6:25: error: ‘va_arg_tmp.3’ is used uninitialized in this function
[-Werror=uninitialized]
 __builtin_va_arg(b, long double);
 ^~~~
cc1: all warnings being treated as errors
1
$ powerpc-glibc-linux-gnu-gcc -S -O -Wall -Werror vfp_min3.c; echo $?
0

$ powerpc-glibc-linux-gnuspe-gcc --version
powerpc-glibc-linux-gnuspe-gcc (GCC) 7.3.1 20180307 [gcc-7-branch revision
258338]
Copyright (C) 2017 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.

$ powerpc-glibc-linux-gnu-gcc --version
powerpc-glibc-linux-gnu-gcc (GCC) 7.3.1 20180307 [gcc-7-branch revision 258338]
Copyright (C) 2017 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.

This is an extra frustrating spurious-uninitialized bug because it's
complaining about a variable that doesn't even exist in the source code -- I
guess it's a  temporary used inside the expansion of __builtin_va_arg?  So it
might not even be *spurious*, I suppose, it might be telling me that that
expansion is wrong!

[Bug fortran/53296] Segfault on non-constant character array constructor containing kind spec

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
This seems to have morphed into a strange off-by-1
in the array constructor.  Consider this code,

 program chararrerr

   implicit none

   character(len=128) :: str(2)
   str = [ucase("abcde"), ucase("ghij")]

   contains

   function ucase(str)
  character(*) :: str
  character(len(str)) :: ucase
  intent(in) :: str
  ucase = str
  print *, '>' // trim(str) // '<', len(str)
   end function ucase

end program chararrerr

Trunk gives

% gfcx -o z a.f90 -fdump-tree-original && ./z
 >abcde<   5
 >abcde<   5
 >ghij<   4

For some reason, the first element is evaluated twice.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[ebotcazou at gcc dot gnu.org]

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

--- Comment #23 from Eric Botcazou  ---
> Where exactly is this documented? I can't find no references to
> __builtin_setjmp or __builtin_longjmp in
> https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc.pdf or
> https://gcc.gnu.org/onlinedocs/gccint.pdf.

__builtin_setjmp/__builtin_longjmp is not documented at all.  You can probably
find a discussion in the archives or bugzilla about this.

> Which documentation?

The internal manual, section Machine Description.

> Like you say, AArch64 doesn't need anything special, it's the mid-end 
> implementation that is broken here. I bet most of my examples fail on other
> targets too.

Well, the SJLJ exception handling scheme is piggybacked on this support and has
worked for the past 2 decades.  And, until very recently, the Ada compiler was
using another exception handling scheme even more directly piggybacked on it
and which had worked for the past 2 decades too.

[Bug libstdc++/84769] variant::get(): unscoped call to get

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It should indeed, thanks.

[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
oldelt is
  value
>
It has been created in:
  /* Add it to the list.  */
  if (parameter != error_mark_node)
parameter_list = process_template_parm (parameter_list,
parm_loc,
parameter,
is_non_type,
is_parameter_pack);
  else
   {
 tree err_parm = build_tree_list (parameter, parameter);
 parameter_list = chainon (parameter_list, err_parm);
   }
which looks like it is intentional that way (r116661), so probably need to
handle error_mark_node somewhere else, maybe in build_deduction_guide?

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #22 from Wilco  ---
(In reply to Eric Botcazou from comment #21)
> > You can use __builtin_setjmp and __builtin_longjmp in the same function,
> > only if they use a different buffer.  Otherwise it is invalid.
> 
> Yes, that's invalid.

Where exactly is this documented? I can't find no references to
__builtin_setjmp or __builtin_longjmp in
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc.pdf or
https://gcc.gnu.org/onlinedocs/gccint.pdf.

> > CCing Eric for the other __builtin_setjmp related issues.
> 
> I don't see anything special with Aarch64 that would make it impossible to
> support __builtin_setjmp/__builtin_longjmp properly.  You can parameterize a
> lot of things in the back-end with TARGET_BUILTIN_SETJMP_FRAME_VALUE and
> various patterns like:
>   save_stack_nonlocal
>   restore_stack_nonlocal,
>   nonlocal_goto_receiver,
>   builtin_setjmp_setup,
>   builtin_setjmp_receiver,
>   builtin_longjmp
> See the documentation and existing ports.

Which documentation? Like you say, AArch64 doesn't need anything special, it's
the mid-end implementation that is broken here. I bet most of my examples fail
on other targets too.

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #6 from Harald Anlauf  ---
The patch in comment #4 still applies (with some offset).

Is there anything left to do?

[Bug tree-optimization/84771] New: missing -Wrestrict passing the same address to restrict-qualified arguments of a user-defined function

[msebor at gcc dot gnu.org]

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

Bug ID: 84771
   Summary: missing -Wrestrict passing the same address to
restrict-qualified arguments of a user-defined
function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the test case below, -Wrestrict detects the first four instances of passing
the same address to restrict-qualified arguments but misses the last two in the
call to the user-defined function.

The reason for that is that the checker for user-defined functions is
implemented in the front-end and relies on operand_equal_p() to determine
whether the arguments are equal, which isn't equipped to do this kind of
analysis.  To do a better job this part of the checker (i.e., for user-defined
functions) should be moved to the gimple-ssa-warn-restrict pass.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c
struct S { char a[4]; };

void f (struct S *p)
{
  __builtin_strcpy ((char*)p, (char*)p);   // -Wrestrict (good)
  __builtin_strcpy ((char*)p, p->a);   // -Wrestrict (good)
  __builtin_strcpy ((char*)p, &p->a[0]);   // -Wrestrict (good)
}

void g (void* restrict, void* restrict);

void h (struct S *p)
{
  g (p, p);// -Wrestrict (good)
  g (p, p->a); // missing -Wrestrict
  g (p->a, &p->a[0]);  // missing -Wrestrict
}
x.c: In function ‘h’:
x.c:14:3: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 2 [-Wrestrict]
   g (p, p);// -Wrestrict (good)
   ^
x.c: In function ‘f’:
x.c:5:3: warning: ‘__builtin_strcpy’ source argument is the same as destination
[-Wrestrict]
   __builtin_strcpy ((char*)p, (char*)p);   // -Wrestrict (good)
   ^
x.c:6:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets 0 and 0
overlaps 1 byte at offset 0 [-Wrestrict]
   __builtin_strcpy ((char*)p, p->a);   // -Wrestrict (good)
   ^
x.c:7:3: warning: ‘__builtin_strcpy’ accessing 1 byte at offsets 0 and 0
overlaps 1 byte at offset 0 [-Wrestrict]
   __builtin_strcpy ((char*)p, &p->a[0]);   // -Wrestrict (good)
   ^

;; Function f (f, funcdef_no=0, decl_uid=1960, cgraph_uid=0, symbol_order=0)

f (struct S * p)
{
  char[4] * _1;

   [local count: 1073741825]:
  _1 = &p_2(D)->a;
  __builtin_strcpy (p_2(D), _1);
  __builtin_strcpy (p_2(D), _1); [tail call]
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1966, cgraph_uid=1, symbol_order=1)

h (struct S * p)
{
  char[4] * _1;

   [local count: 1073741825]:
  g (p_3(D), p_3(D));
  _1 = &p_3(D)->a;
  g (p_3(D), _1);
  g (_1, _1); [tail call]
  return;

}

[Bug c++/84770] New: [8 Regression] ICE with parameter pack involving typedef

[reichelt at gcc dot gnu.org]

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

Bug ID: 84770
   Summary: [8 Regression] ICE with parameter pack involving
typedef
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE on trunk:

=
typedef int T;

template struct A {};

int i;

A a;
=

bug.cc: In instantiation of 'struct A':
bug.cc:7:6:   required from here
bug.cc:3:26: internal compiler error: in verify_unstripped_args, at
cp/pt.c:1154
 template struct A {};
  ^
0x636980 verify_unstripped_args
../../gcc/gcc/cp/pt.c:1154
0x636980 retrieve_specialization
../../gcc/gcc/cp/pt.c:1194
0x97aadc tsubst_decl
../../gcc/gcc/cp/pt.c:13247
0x9740ef tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13812
0x98ce1a instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10806
0x98ce1a instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:11055
0x9d38fd complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x883867 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:5241
0x8a96af start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:5204
0x9391e9 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19598
0x940928 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13057
0x941738 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12882
0x945692 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12780
0x945aa1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12656
0x945d94 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4561
0x945d94 c_parse_file()
../../gcc/gcc/cp/parser.c:38995
0xa44906 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

The regression was introduced between 2017-05-06 and 2017-05-12.

[Bug c++/84768] [7/8 Regression] ICE with failed class template argument deduction because of invalid template parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |7.4
Summary|ICE with failed class   |[7/8 Regression] ICE with
   |template argument deduction |failed class template
   |because of invalid template |argument deduction because
   |parameter   |of invalid template
   ||parameter
 Ever confirmed|0   |1

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

[Bug libstdc++/84769] New: variant::get(): unscoped call to get

[duarte at scylladb dot com]

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

Bug ID: 84769
   Summary: variant::get(): unscoped call to get
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: duarte at scylladb dot com
  Target Milestone: ---

In the implementation of T& get(variant& v) and friends, the calls to
the size_t-templated overloads of get is unscoped, like in [1]. This can lead
to surprising situations if a similar function is available in the current
namespace (say, to provide a common interface between  and
). 

I'm not aware of the standard requiring get() to be an extension point, so
maybe the calls should be scoped?

[1]
https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/std/variant#L922

[Bug debug/84456] [8 regression] gcc.dg/guality/pr49888.c fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug debug/84456] [8 regression] gcc.dg/guality/pr49888.c fail

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  8 21:50:37 2018
New Revision: 258371

URL: https://gcc.gnu.org/viewcvs?rev=258371&root=gcc&view=rev
Log:
PR debug/84456
* dwarf2out.c (dw_loc_list): If list && loc_list->first->next, call
gen_llsym, otherwise call maybe_gen_llsym.

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

[Bug c++/84768] New: ICE with failed class template argument deduction because of invalid template parameter

[reichelt at gcc dot gnu.org]

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

Bug ID: 84768
   Summary: ICE with failed class template argument deduction
because of invalid template parameter
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet (compiled with "-std=c++1z") triggers
an ICE since 7.1.0 (when class template argument deduction was introduced):

=
template struct A {};

template struct B
{
  template B(A);
};

B b = A();
=

bug.cc:5:12: error: 'X' has not been declared
   template B(A);
^
bug.cc:8:15: internal compiler error: in get_template_parm_index, at
cp/pt.c:5086
 B b = A();
   ^
0x62ea67 get_template_parm_index
../../gcc/gcc/cp/pt.c:5086
0x9639fa rewrite_template_parm
../../gcc/gcc/cp/pt.c:25680
0x9639fa build_deduction_guide
../../gcc/gcc/cp/pt.c:25870
0x964d95 do_class_deduction
../../gcc/gcc/cp/pt.c:26019
0x964d95 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/gcc/cp/pt.c:26147
0x89d343 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6866
0x939523 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19723
0x940928 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13057
0x941738 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12882
0x945692 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12780
0x945aa1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12656
0x945d94 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4561
0x945d94 c_parse_file()
../../gcc/gcc/cp/parser.c:38995
0xa44906 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

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

[sje at gcc dot gnu.org]

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

--- Comment #9 from Steve Ellcey  ---

> Can you let me know if my workaround helped? If useful I could backport it
> to GCC7 as well.

Yes, the patch helped.  I ran spec 2017 fp rate and saw a small improvement
(0.7%).  Most of the speed up was in 508.namd_r, 526.blender_r, and 544.nab_r.
507.cactuBSSN_r and 511.povray_r slowed down a little bit.

[Bug c++/80598] [7 regression] -Wunused triggers for functions used in uninstantiated templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[7/8 regression] -Wunused   |[7 regression] -Wunused
   |triggers for functions used |triggers for functions used
   |in uninstantiated templates |in uninstantiated templates

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

[Bug c++/80598] [7/8 regression] -Wunused triggers for functions used in uninstantiated templates

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  8 21:18:50 2018
New Revision: 258370

URL: https://gcc.gnu.org/viewcvs?rev=258370&root=gcc&view=rev
Log:
PR c++/80598
* call.c (build_over_call): In templates set TREE_USED (first_fn) when
not calling mark_used for the benefit of -Wunused-function warning.

* g++.dg/warn/Wunused-function4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-function4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #8 from kargl at gcc dot gnu.org ---
*** Bug 68441 has been marked as a duplicate of this bug. ***

[Bug fortran/68441] ICE on using transfer with character parameter

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from kargl at gcc dot gnu.org ---
Closing as duplicate or at least fixed by patch for 70409

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

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||harper at msor dot vuw.ac.nz

--- Comment #7 from kargl at gcc dot gnu.org ---
*** Bug 61627 has been marked as a duplicate of this bug. ***

[Bug fortran/61627] specification expression ICE with version 4.7.1 and 4.8.2, incorrect output with 4.4.7 and 4.9.0

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #5)
> This one appears to have been solved along with the fix
> for pr64124/pr70409.
> 
> Close as duplicate?

Yes. Closing.

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

[Bug c++/84767] New: [6/7/8 Regression] ICE with pointer to VLA

[reichelt at gcc dot gnu.org]

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

Bug ID: 84767
   Summary: [6/7/8 Regression] ICE with pointer to VLA
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid testcase triggers an ICE since GCC 4.9.0:


struct A
{
  A(int);
};

A::A(int i)
{
  int (*x)[1][i];
  (*x)[0][0] = 0;
}


bug.cc: In constructor 'A::A(int)':
bug.cc:6:1: error: Local declaration from a different function
 A::A(int i)
 ^
i
bug.cc:8:16: note: in statement
   int (*x)[1][i];
^
_17 = (ssizetype) i;
during GIMPLE pass: cfg
bug.cc:6:1: internal compiler error: verify_gimple failed
 A::A(int i)
 ^
0xefdae3 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5579
0xde4f0f execute_function_todo
../../gcc/gcc/passes.c:1994
0xde5e5e execute_todo
../../gcc/gcc/passes.c:2048
Please submit a full bug report, [etc.]

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Mar  8 20:55:03 2018
New Revision: 258369

URL: https://gcc.gnu.org/viewcvs?rev=258369&root=gcc&view=rev
Log:
PR inline-asm/84742
* recog.c (asm_operand_ok): Return 0 if multi-character constraint
has ',' character inside of it.

* gcc.target/i386/pr84742-1.c: New test.
* gcc.target/i386/pr84742-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr84742-1.c
trunk/gcc/testsuite/gcc.target/i386/pr84742-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/recog.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init

[ebotcazou at gcc dot gnu.org]

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

--- Comment #2 from Eric Botcazou  ---
Ugh, I overlooked the special case in ix86_compute_frame_layout when there is a
call to __builtin_frame_address in the code...

[Bug fortran/61627] specification expression ICE with version 4.7.1 and 4.8.2, incorrect output with 4.4.7 and 4.9.0

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
This one appears to have been solved along with the fix
for pr64124/pr70409.

Close as duplicate?

[Bug fortran/68441] ICE on using transfer with character parameter

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Mar 08, 2018 at 07:39:14PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68441
> 
> --- Comment #5 from Dominique d'Humieres  ---
> > I believe the patch I just committed actually 
> > fixes this issue.
> 
> Confirmed.
> 

Thanks.  I'll close this later today.

[Bug libstdc++/84766] __verbose_terminate_handler mistakes parallel unhandled exceptions for recursive std::terminate() calls

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1

[Bug libstdc++/84766] New: __verbose_terminate_handler mistakes parallel unhandled exceptions for recursive std::terminate() calls

[anovak at soe dot ucsc.edu]

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

Bug ID: 84766
   Summary: __verbose_terminate_handler mistakes parallel
unhandled exceptions for recursive std::terminate()
calls
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anovak at soe dot ucsc.edu
  Target Milestone: ---

The default terminate handler, __gnu_cxx::__verbose_terminate_handler(), in 
gcc/libstdc++-v3/libsupc++/vterminate.cc, begins thusly:

  void __verbose_terminate_handler()
  {
static bool terminating;
if (terminating)
  {
fputs("terminate called recursively\n", stderr);
abort ();
  }
terminating = true;
  ...

The function uses a static bool flag, which it checks. If it is already set, it
knows std::terminate() has already been called, so it complains of a recursive
std::terminate() call and immediately aborts. If it isn't already set, it
continues with printing some exception info before calling abort().

However, this function doesn't seem to handle the case of multiple threads. It
is possible for one thread to have an unhandled exception, causing terminate
(and the handler) to be called, and then for a second thread to also have an
unhandled exception before abort() can stop the process. That second thread
will also call terminate, and the handler will report a "recursive" call to
terminate, even though the call really wasn't recursive. This also prevents the
second thread from outputting a nice formatted exception message.

Can the terminating flag be made thread local? Or can the message be changed to
describe "concurrent" or "reentrant" calls to terminate instead of "recursive"
ones?

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Can't reproduce when using gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)
as system compiler (gcc110).

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

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

--- Comment #5 from Will Schmidt  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Will Schmidt from comment #3)
> >   $ /home/willschm/gcc/trunk.svn/configure --with-cpu=power7
> > --with-long-double-128 --prefix=/home/willschm/gcc/install/gnc
> > --disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion
> 
> If it is --disable-bootstrap, then it matters what exact your system gcc is,
> perhaps it miscompiles something?

Ok.  Yeah, this is a somewhat vintage distro compiler here.

gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 

Let me see if I can try with a newer version.

[Bug fortran/68441] ICE on using transfer with character parameter

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> I believe the patch I just committed actually 
> fixes this issue.

Confirmed.

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Will Schmidt from comment #3)
>   $ /home/willschm/gcc/trunk.svn/configure --with-cpu=power7
> --with-long-double-128 --prefix=/home/willschm/gcc/install/gnc
> --disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion

If it is --disable-bootstrap, then it matters what exact your system gcc is,
perhaps it miscompiles something?

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

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

--- Comment #3 from Will Schmidt  ---
(In reply to Jakub Jelinek from comment #1)
> What configure flags for that specially configured gcc?
> Can you in a debugger pt whatever tree_operand_hash::hash is called on?
> I certainly can't reproduce this with a cross to powerpc64-linux, even under
> valgrind it is clear.

I just attached the config.log for reference.

This environment is .. Power7, BE.(i'll see if I can verify that this
does/does not occur in other Power envs shortly.)

willschm@bns:~/gcc/generic.noprereqs.noconfig.debug> head config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /home/willschm/gcc/trunk.svn/configure --with-cpu=power7
--with-long-double-128 --prefix=/home/willschm/gcc/install/gnc
--disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[willschm at gcc dot gnu.org]

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

--- Comment #2 from Will Schmidt  ---
Created attachment 43602
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43602&action=edit
config.log

[Bug fortran/68441] ICE on using transfer with character parameter

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |ASSIGNED
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Harald Anlauf from comment #3)
> (In reply to Harald Anlauf from comment #2)
> > There's a subtle wrong-code problem:
> 
> This wrong-code issue is discussed in pr70409.

I believe the patch I just committed actually 
fixes this issue.

% gfcx -o z a.f90 && ./z
   0
% gfcx -o z -Wall a.f90 && ./z
a.f90:3:30:

print *, transfer(transfer(0, x), 0)
  1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 <
result size 127 [-Wsurprising]
   0
t

Do others concur?

[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
This loop init stuff is created by the RTL loop optimisers; if those could see
0 cannot happen, they can optimise this.

[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures

[kargl at gcc dot gnu.org]

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

Bug 64124 Summary: [F95] Valid constant expr rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64124

   What|Removed |Added

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

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for bug report.

[Bug fortran/68441] ICE on using transfer with character parameter

[kargl at gcc dot gnu.org]

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

Bug 70409 Summary: Silent truncation of character parameters with len=huge()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70409

   What|Removed |Added

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

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for bug report.

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:06:57 2018
New Revision: 258368

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

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:06:57 2018
New Revision: 258368

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

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:01:23 2018
New Revision: 258367

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

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:01:23 2018
New Revision: 258367

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

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
Sorry.  vec_ld is direct access to the lvx instruction.

Given what you found, I think we should add signed and unsigned V1TImode
versions of vec_ld and remove this partial implementation of an undocumented
function.

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
__int128 is not an extended integer type in the C sense.  The main reason is
because intmax_t is not defined as __int128.

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[pascal_cuoq at hotmail dot com]

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

--- Comment #1 from Pascal Cuoq  ---
I meant "the warning implies that the constant is typed as unsigned long
long...".

[Bug c/84764] New: Wrong warning "so large that it is unsigned" for __int128 constant

[pascal_cuoq at hotmail dot com]

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

Bug ID: 84764
   Summary: Wrong warning "so large that it is unsigned" for
__int128 constant
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

According to the output of the following program, the type of the constant
1000 is __int128, which is a signed type:

Compiler Explorer link: https://godbolt.org/g/kFTNaz

#include 

#define prtype(X) \
  _Generic((X),   \
   int: "int",\
   long: "long",  \
   long long: "long long",\
   unsigned int: "unsigned int",  \
   unsigned long: "unsigned long",\
   unsigned long long: "unsigned long long",  \
   __int128: "__int128",  \
  default: "?")

int main(void) {
  printf("1 %s\n", prtype(1));
  printf("30 %s\n", prtype(30));
  printf("1000 %s\n", prtype(1000));
}

___
Output:

1 int
30 long
1000 __int128

However a warning is emitted on the last line for the constant
1000:

prtype.c:17:66: warning: integer constant is so large that it is unsigned

This warning implies that the constant is typed as long long, which has been
the case either historically or with other -std= settings. However, for the
compilation settings at hand, the warning is wrong. It should at most say that
the constant is typed with a type outside of the "int, long, long long"
hierarchy of standard types.

For reference the relevant clause of the C11 standard is 6.4.4:
https://port70.net/~nsz/c/c11/n1570.html#6.4.4

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  ---
> Otherwise this looks good:
> 
>   === acats Summary ===
> # of expected passes  2315
> # of unexpected failures  5
> *** FAILURES: c23003b c23003g c23003i c250002 c380004
> 
> That's on par with 7.3.0.

Wunderbar! :-) Danke schön.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #5 from Pat Haugen  ---
Created attachment 43601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43601&action=edit
ipa-cp dump (r256887)

(In reply to Martin Liška from comment #4)
> Thank you, may I please ask you for the IPA CP dump file for not affected
> revision (r256887). Do I understand the numbers right that version with
> .resid_.constprop.1 is slower?

Dump attached. And yes, the version with resid_.constprop.1 is slower.

Also, I tried the patch from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149#c5 and didn't see any
difference in execution time.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

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

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

--- Comment #17 from Rainer Emrich  ---
Otherwise this looks good:

=== acats Summary ===
# of expected passes2315
# of unexpected failures5
*** FAILURES: c23003b c23003g c23003i c250002 c380004

That's on par with 7.3.0.

The Hotel Show Saudi Arabia is Back!

[The Hotel Show Saudi Arabia]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlpsend3.com/zZdRJa



REGISTRATION FOR THE HOTEL SHOW SAUDI ARABIA IS NOW OPEN (
http://dmg-events.msgfocus.com/c/1a30BT5lE2es7wT )
View in browser

The Kingdom’s premier event for the hospitality and food industry is
back in Jeddah from 10th – 12th April for three days of inspiration,
innovation, education and networking opportunities.

Yes, that’s right, registration for THE HOTEL SHOW SAUDI ARABIA 2018
( http://dmg-events.msgfocus.com/c/1a30D5LfMNDmkyZ ) is now OPEN.
REGISTER FOR FREE NOW! (
http://dmg-events.msgfocus.com/c/1a30DH6cRbkOr52 )

The show is the only business event in the Kingdom which is dedicated
to the hospitality industry and promises a range of stunning features,
CPD seminars along with a gathering of industry experts to share
ideas, trends and insights. 100s of global brands will be on show,
giving you the best opportunity to source the very latest cutting-edge
supplies and products designed to create a truly unforgettable
experience for your customers.

Also, following the success of 2017’s live-cooking competition, the
INTER-HOTEL CULINARY COMPETITION (
http://dmg-events.msgfocus.com/c/1a30Eir9Vz2gxB5 ) is returning bigger
and better for 2018. A panel of highly experienced judges from the
endorsing bodies; World Association of Chefs Societies and the Saudi
Arabian Chefs Association will determine the winners after three-days
of tasting various unique dishes.

THE HOTEL SHOW SAUDI ARABIA is a must-attend on the list of industry
events. As an Owner, Developer, Architect, Engineer, Procurement
Manager, Distributor or Chef in the hospitality industry, you need to
be there. REGISTER NOW! (
http://dmg-events.msgfocus.com/c/1a30ETM6ZWJIE78 )

يعود الحدث
الرائد في
المملكة
لمجال
الضيافة
وخدمات
تقديم
الطعام في
جدة في
الفترة من 10
إلى 12 أبريل
لمدة ثلاثة
أيام من
الإلهام
والابتكار
والتعليم
وفرص
التواصل.

نعم، الأمر
صحيح؛ أصبح
باب
التسجيل
لحضور معرض
الفنادق
بالمملكة
العربية
السعودية (
http://dmg-events.msgfocus.com/c/1a30G6s18I8CR9e
)2018مفتوحًا
الآن. سجِّل
بياناتك
مجانًا
الآن! (
http://dmg-events.msgfocus.com/c/1a30GHMYd5Q4XFh )

هذا المعرض
هو حدث
الأعمال
الوحيد
المخصص
لمجال
الضيافة في
المملكة،
ويعد
بتقديم
مجموعة من
الفعاليات
المذهلة،
والندوات
المعتمدة
للتطوير
المهني
المستمر،
إضافةً إلى
تجمّع من
خبراء
المجال
لتبادل
الأفكار
والاتجاهات
والرؤى.
وستشارك في
المعرض
المئات من
العلامات
التجارية
العالمية؛
ما سيمنحك
أفضل فرصة
لاستعراض
أحدث
الإمدادات
والمنتجات
المتطورة
التي تهدف
إلى تزويد
عملائك
بتجربة لا
تُنسى حقًا.

علاوةً على
ذلك، بعد
نجاح دورة 2017
من مسابقة
الطهي
المباشر،
ستعودمسابقة
الطهي بين
الفنادق (
http://dmg-events.msgfocus.com/c/1a30Hj7Vhtxx4bk ) في
شكل أكبر
وأفضل لعام 2018.
وسيحدَّد
أسماء
الفائزين
بواسطة
فريق من
المحكمين
ذوي الخبرة
العالية من
الهيئات
المصادقة -
الرابطة
العالمية
لجمعيات
الطهاة
وجمعية
الطهاة
السعوديين -
بعد ثلاثة
أيام من
تذوق مختلف
الأطباق
الفريدة.

معرض
الفنادق
بالمملكة
العربية
السعودية
هو حدث لا
غنى عن
حضوره ضمن
قائمة
الأحداث
المتخصصة
في مجال
الضيافة.
وإذا كنت
أحد
المالكين
أو
المطوّرين
أو
المعماريين
أو
المهندسين
أو مديري
المشتريات
أو
الموزّعين
أو الطهاة
في مجال
الضيافة،
فإنه يتعين
عليك حضور
الفعاليات
بكل تأكيد.
سجِّل
بياناتك
الآن! (
http://dmg-events.msgfocus.com/c/1a30HUsSlReZaHn )

INDUSTRY SUPPORT

SUPPORTED BY

HOST VENUE

ENDORSED BY

ENDORSED BY

ORGANISER

CO - ORGANISER

HOTEL PARTNER

CULINARY PARTNER

OFFICIAL TABLEWARE SPONSOR

The Hotel Show Saudi Arabia
dmg events Middle East, Asia & Africa
T: +971 4 4380355
E: thehotelshow...@dmgeventsme.com
W: thehotelshowsaudiarabia.com (
http://dmg-events.msgfocus.com/c/1a30IvNPqeWrhdq )

(
http://www.dmg-eventsme.com/dmgdbms/UnSub.aspx?id=exam...@emailaddress.test,,12,Example
Sf Contact Id,Example Sf Show Id,Example Sf Edition Id,Example Sf
Campaignmember Id )

_
Unsubscribe / Change Profile: http://ymlpsend3.com/ugmwhmbhgsgmsbqmgyqwggubuhw
Powered by YourMailingListProvider

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
I don't argue either way on this, but it looks to me like we do not currently
have support for __int128 with vec_ld.

1. I can't fine it in the rs6000-c tables.

2. This test fails to compile:

#include 
#include 

static vector unsigned char uc;
static vector __int128 v;
static vector __int128 *pi;

void
doInitialization ()
{
  v[0] = -1;
  pi = &v;
}

int
main (int argc, char *argv)
{
  __int128 entry;
  int i;

  /* Apparent usage:
   *   result = vec_ld (int index, vector v)
   * is equivalent to:  
   *  result = v [index];   
   */
  doInitialization ();
  entry = vec_ld (0, pi);
  i = (int) entry;
  printf ("result of vec_ld is %d\n", i);
  return 0;
}

$GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc/ -O1 -o kelvin-1 kelvin-1.c
kelvin-1.c: In function ‘main’:
kelvin-1.c:36:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_ld’
   entry = vec_ld (0, pi);
   ^
Makefile:26: recipe for target 'kelvin-1' failed
make: *** [kelvin-1] Error 1


By the way, it's probably obvious everyone else what vec_ld is supposed to do,
but it's not documented anywhere that I can find...

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou  ---
> You can use __builtin_setjmp and __builtin_longjmp in the same function,
> only if they use a different buffer.  Otherwise it is invalid.

Yes, that's invalid.

> CCing Eric for the other __builtin_setjmp related issues.

I don't see anything special with Aarch64 that would make it impossible to
support __builtin_setjmp/__builtin_longjmp properly.  You can parameterize a
lot of things in the back-end with TARGET_BUILTIN_SETJMP_FRAME_VALUE and
various patterns like:
  save_stack_nonlocal
  restore_stack_nonlocal,
  nonlocal_goto_receiver,
  builtin_setjmp_setup,
  builtin_setjmp_receiver,
  builtin_longjmp
See the documentation and existing ports.

[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-08
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|[8 Regression] ICE in   |[8 regression] ICE in
   |i386_pe_seh_cold_init   |i386_pe_seh_cold_init
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Thanks, I'm going to have a look.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek  ---
You can use __builtin_setjmp and __builtin_longjmp in the same function, only
if they use a different buffer.  Otherwise it is invalid.  So, while we
shouldn't ICE on invalid code, not sure why you are listing 4 here.

CCing Eric for the other __builtin_setjmp related issues.

[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Started with my r204516 change aka
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00768.html
The changes in *.optimized dump look reasonable, fewer IVs:
   :
+  # RANGE [16, 4294967280]
+  _18 = _22 * 16;
+  # RANGE [0, 4294967295]
+  _9 = _18 + _6;
+  _3 = (void *) _9;

   :
   # PT = nonlocal 
   # ALIGN = 16, MISALIGN = 0
   # addr_23 = PHI 
-  # RANGE [0, 4294967295] NONZERO 0x00fff
-  # i_24 = PHI 
   __asm__ __volatile__("dcbf 0, %0" :  : "r" addr_23 : "memory");
-  # RANGE [0, 4294967295] NONZERO 0x00fff
-  i_14 = i_24 + 1;
   # PT = nonlocal 
   # ALIGN = 16, MISALIGN = 0
   addr_15 = addr_23 + 16;
-  if (i_14 != _22)
+  if (addr_15 != _3)

The * 16 is present in GIMPLE, but the right shift by 4 / division by 16 is
something added in the doloop pass later on, so this doesn't seem to be
something that can be optimized in GIMPLE.
On the trunk, we have in *.optimized:
  # RANGE [0, 268435455] NONZERO 268435455
  _20 = size_12 >> 4;
  if (_20 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119325]:
  # RANGE [16, 4294967280]
  _6 = _20 * 16;
  _4 = _1 + _6;
  _3 = (void *) _4;

   [local count: 955630224]:
  # PT = nonlocal null
  # ALIGN = 16, MISALIGN = 0
  # addr_21 = PHI 
  __asm__ __volatile__("dcbf 0, %0" :  : "r" addr_21 : "memory");
  # PT = nonlocal null
  # ALIGN = 16, MISALIGN = 0
  addr_15 = addr_21 + 16;
  if (_3 != addr_15)
goto ; [89.00%]
  else
goto ; [11.00%]
To optimize this on RTL we'd need to have accurate value range info, otherwise
optimizing (unsigned) (x << 4 + (cst << 4)) >> 4 into x + cst is not valid.
Before *.combine we have:
(insn 16 15 17 3 (set (reg:SI 135)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4]))) 269 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 128 [ _20 ])
(nil)))
(insn 17 16 42 3 (set (reg/f:SI 122 [ _3 ])
(plus:SI (reg:SI 135)
(reg/v/f:SI 127 [ addr ]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 135)
(nil)))
(insn 42 17 43 3 (set (reg:SI 138)
(minus:SI (reg/f:SI 122 [ _3 ])
(reg/v/f:SI 127 [ addr ]))) -1
 (expr_list:REG_DEAD (reg/f:SI 122 [ _3 ])
(nil)))
(insn 43 42 44 3 (set (reg:SI 139)
(plus:SI (reg:SI 138)
(const_int -16 [0xfff0]))) -1
 (expr_list:REG_DEAD (reg:SI 138)
(nil)))
(insn 44 43 45 3 (set (reg:SI 140)
(lshiftrt:SI (reg:SI 139)
(const_int 4 [0x4]))) -1
 (expr_list:REG_DEAD (reg:SI 139)
(nil)))
and only combine turns that into:
(insn 42 17 43 3 (set (reg:SI 138)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4]))) 269 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 128 [ _20 ])
(nil)))
(insn 43 42 44 3 (set (reg:SI 139)
(plus:SI (reg:SI 138)
(const_int -16 [0xfff0]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 138)
(nil)))
(insn 44 43 45 3 (set (reg:SI 140)
(lshiftrt:SI (reg:SI 139)
(const_int 4 [0x4]))) 279 {lshrsi3}
 (expr_list:REG_DEAD (reg:SI 139)
(nil)))
(insn 45 44 21 3 (set (reg:SI 137)
(plus:SI (reg:SI 140)
(const_int 1 [0x1]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 140)
(nil)))

While reg:SI 128 is set only once and thus in theory we could in theory use in
RTL the corresponding GIMPLE value ranges for that SSA_NAME, the SSA_NAME for
_20 is [0, 268435455] and thus only allows us to figure out that << 4 will not
shift away any bits out of it (i.e. that (r128 << 4) >> 4 is equal to r128.  We
need to know that it can't be zero as well, which on GIMPLE is present in the
value range of _6 - [16, 4294967280], but unfortunately that info is lost
during TER, pseudo 135 doesn't really have REG_EXPR set.

Maybe that would be fixable by some expander work.

Then the question is if we actually can use GIMPLE VRP info during RTL
optimizations, and whether all optimizations on RTL that would invalidate that
reset REG_EXPR or could in some other way signal that the VRP info can't be
trusted.

The combiner first optimizes:
Trying 17 -> 42:
   17: r122:SI=r135:SI+r127:SI
  REG_DEAD r135:SI
   42: r138:SI=r122:SI-r127:SI
  REG_DEAD r122:SI
Successfully matched this instruction:
(set (reg:SI 138)
(reg:SI 135))

and then:
Trying 16 -> 42:
   16: r135:SI=r128:SI<<0x4
  REG_DEAD r128:SI
   42: r138:SI=r135:SI
  REG_DEAD r135:SI
Successfully matched this instruction:
(set (reg:SI 138)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4])))
so if we had VRP info on _6 aka (reg:SI 135 [ _6 ]) we'd need to signal that it
is the same on r138.
And then have some way

[Bug target/84763] [8 Regression] ICE in i386_pe_seh_cold_init

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/84763] New: [8 Regression] ICE in i386_pe_seh_cold_init

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

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

Bug ID: 84763
   Summary: [8 Regression] ICE in i386_pe_seh_cold_init
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

Created attachment 43600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43600&action=edit
preprocessed source

Building binutils 2.29.1 there's an ICE in i386_pe_seh_cold_init.

make[2]: Entering directory '/opt/devel/SCRATCH/tmp/opcodes'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes  -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd  -I./../intl 
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
-o i386-dis.lo
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd -I./../intl
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c -o
i386-dis.o
during RTL pass: final
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c: In
function 'print_insn':
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c:13471:1:
internal compiler error: in i386_pe_seh_cold_init, at config/i386/winnt.c:913
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1005: i386-dis.lo] Error 1
make[2]: Leaving directory '/opt/devel/SCRATCH/tmp/opcodes'

Caused by r258338.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to sudi from comment #17)
> I looked up what other targets were doing and one thing found to be
> interesting was that a lot of them are defining the target hook
> TARGET_BUILTIN_SETJMP_FRAME_VALUE. In AArch64 case I am suggesting to define
> it to return the hard frame pointer. That seems to solve the issue with both
> the attached test case and the test that Wilco mentioned.
> 
> Does this look like it solves "mid-end versus back-end : who fixes this
> issue" problem?
> 
> I am still pretty new to knowing how the stack should actually look. So
> calling for some help!

This is not about stack layout but ensuring we don't corrupt the frame pointer
or the stack pointer. Any changes to SP/FP are inherently extremely risky and
need to be done exactly right or lots of things will fail.

There are too many issues to make a full list, but here are a few obvious ones:

1. The TARGET_BUILTIN_SETJMP_FRAME_VALUE only fixes the store of the frame
pointer, however it does not fix the landing pad, I see code like this:

str x29, [x3, #:lo12:.LANCHOR0]
mov x0, sp
stp x1, x0, [x2, 8]
bl  baz
.p2align 2
.L7:
sub x29, x29, #176
ldr w0, [x29, 172]
mov sp, x29

So now the store is correct, but when returning at L2 we corrupt the frame
pointer badly (and then the stack pointer as well)... This is basically the
same as pr60003.c but with an alloca added.

2. We still need to force the frame pointer to be saved,
TARGET_BUILTIN_SETJMP_FRAME_VALUE doesn't fix that.

3. __builtin_longjmp is still incorrect, like I showed in PR64242, it also
fails on AArch64:

#include 
#include 
void bug (jmp_buf buf)
{
  jmp_buf buf2;
  memcpy (buf2, buf, sizeof (jmp_buf));
  __builtin_longjmp (buf2, 1);
}

bug:
stp x29, x30, [sp, -336]!
mov x1, x0
mov x2, 312
mov x29, sp
add x0, x29, 24
bl  memcpy
ldr x0, [x29, 32]
ldr x29, [x29, 24]  // oops
ldr x1, [x29, 40]
mov sp, x1
br  x0

4. Trying to use setjmp and longjmp in the same function often gives this ICE:

during RTL pass: cse1
setjmp.c: In function ‘bug1’:
setjmp.c:86:1: internal compiler error: in mark_jump_label_1, at jump.c:1151
 }
 ^
0xa598f7 mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1151
0xa59a6b mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1211
0xa59a6b mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1211
0xa59e17 mark_all_labels
/home/wdijkstr/gcc/gcc/jump.c:305
0xa59e17 rebuild_jump_labels_1
/home/wdijkstr/gcc/gcc/jump.c:74
0x128ce23 rest_of_handle_cse
/home/wdijkstr/gcc/gcc/cse.c:7628
0x128ce23 execute
/home/wdijkstr/gcc/gcc/cse.c:7662

5. Things get really interesting on ARM and Thumb-2 where there are multiple
frame pointer registers. This shows again why it is wrong to change the sp/fp
in the longjmp - for it to work correctly it must be done in the landing pad in
the function that has the setjmp.

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1

--- Comment #6 from Bill Schmidt  ---
We should keep this issue open for a different problem, though.  When swap
optimization doesn't succeed on such a loop, we don't end up optimizing away
the xxlnand associated with the vperm on Power8.  Currently that is only done
as part of swap optimization.  It's a minor savings but worth doing.

[Bug target/84748] [6/7 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||6.4.1
Summary|[8 Regression] wrong code   |[6/7 Regression] wrong code
   |with u128 at aarch64 at -O  |with u128 at aarch64 at -O
   |and and above   |and and above

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. The testcase doesn't abort on the branches but the buggy
pattern is there so the fix is worth backporting. I'll do it once it's baked on
trunk for a bit

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Hm.  For this one I think I would recommend we just remove the partial
implementation, provided that vec_ld already supports vector __int128.

[Bug target/84748] [8 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar  8 15:50:25 2018
New Revision: 258366

URL: https://gcc.gnu.org/viewcvs?rev=258366&root=gcc&view=rev
Log:
[AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

In this wrong-code PR the combine pass ends up moving a CC-using instruction
past a *compare_cstore_insn
insn_and_split. After reload the *compare_cstore_insn splitter ends up
generating a SUBS instruction that
clobbers the condition flags, and things go bad.

The solution is simple, the *compare_cstore_insn pattern should specify
that it clobbers the CC register
so that combine (or any other pass) does not assume that it can move CC-using
patterns across it.

This patch does that and fixes the testcase.

The testcase FAILs on GCC 8 only, but the buggy pattern is in GCC 6 onwards, so
we should backport this as
a latent bug fix after it's had some time to bake in trunk.

Bootstrapped and tested on aarch64-none-linux-gnu.

PR target/84748
* config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
as clobbering CC_REGNUM.

* gcc.c-torture/execute/pr84748.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr84748.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug c/84762] New: GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

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

Bug ID: 84762
   Summary: GCC for PowerPC32 violates the SysV ABI spec for small
struct returns
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: powerpc-eabi

For an example like:

struct smallstruct { char a; char b; char c; };

struct smallstruct f(void)
{
  struct smallstruct s = { 0x11, 0x22, 0x33 };

  return s;
}

r3 should look like 0x11223300, but GCC returns 0x00112233 in r3 (with the '00'
part actually being undefined).

The relevant part of the spec
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf:

Aggregates or unions whose size is less than or equal to eight bytes shall be
returned in r3 and r4, as if they were first stored in memory area and then the
low-addressed word were loaded in r3 and the high-addressed word were loaded
into r4. Bits beyond the last member of the structure or union are not defined.

Or the older http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf says
nearly the same (with an additional alignment clause):

A structure or union whose size is less than or equal to 8 bytes shall be
returned in r3 and r4, as if it were first stored in an 8-byte aligned memory
area and then the low-addressed word were loaded into r3 and the high-addressed
word into r4. Bits beyond the last member of the structure or union are not
defined.

This was discovered during parameter passing tests as a difference to a
proprietary compiler.

As it is probably too late in the game to change GCC, this is more a
documentation request I guess.
Eventually -msvr4-struct-return could be extended to
-msvr4-struct-return={sysv,gnu} with 'gnu' as the (compile-time configurable?)
default.

[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory

[jorrit at jorrit dot de]

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

--- Comment #5 from Jö  ---
I can report that that indeed fixes the issue for us; the unit test now
compiles fine with gcc revision 258359.  Thanks a lot!

[Bug tree-optimization/84552] [6/7/8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  8 14:41:39 2018
New Revision: 258365

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

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

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

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr84552.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c

[Bug sanitizer/84761] New: AddressSanitizer is not compatible with glibc 2.27 on x86

[vincent-gcc at vinc17 dot net]

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

Bug ID: 84761
   Summary: AddressSanitizer is not compatible with glibc 2.27 on
x86
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

After an upgrade to glibc 2.27 on a Debian/unstable machine, on a program that
does nothing, the AddressSanitizer segfaults with the 32-bit x86 ABI.

I have the following gcc-snapshot script:

#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
rpath=""
OLD_IFS="$IFS"
IFS=:
for i in $LD_RUN_PATH
do
  rpath="$rpath -Wl,-rpath -Wl,$i"
done
IFS="$OLD_IFS"
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 $rpath "$@"

cventin:~> gcc-snapshot --version
gcc (Debian 20180216-1) 8.0.1 20180216 (experimental) [trunk revision 257720]
[...]
cventin:~> cat tst.c
int main (void)
{
  return 0;
}
cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
cventin:~> ./tst
AddressSanitizer:DEADLYSIGNAL
=
==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc
0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
==25032==The signal is caused by a WRITE memory access.
#0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0xf7ac147d  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
#2 0xf7aafd27  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
#3 0xf7fa591a  (/lib/ld-linux.so.2+0xf91a)
#4 0xf7f96cb9  (/lib/ld-linux.so.2+0xcb9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in
_dl_get_tls_static_info
==25032==ABORTING

My original bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892096

The explanations given by Aurelien Jarno:


The AddressSanitizer is using glibc internal functions though dlsym(), and such
functions have the right to change in new major versions:

From libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:
|  void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");

And on the glibc side:
| $ readelf -s /lib/ld-linux.so.2  | grep _dl_get_tls_static_info
|  4: 00011e7035 FUNCGLOBAL DEFAULT   12
_dl_get_tls_static_info@@GLIBC_PRIVATE

This has been discussed for example there:
https://www.sourceware.org/ml/libc-alpha/2018-02/msg00611.html

The AddressSanitizer people should discuss for a public API so that it doesn't
happen again. Otherwise it might break at every new glibc version.


In the mean time, it should at least be made compatible with glibc 2.27.

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[rguenther at suse dot de]

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

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

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
> 
> --- Comment #22 from Martin Liška  ---
> (In reply to Martin Liška from comment #21)
> > (In reply to Jakub Jelinek from comment #20)
> > > How would IPA-PTA work then?
> > 
> > Not having experience how that works, but I would expect a complete rebuild.
> > Similar to what the tree PTA does?
> 
> Note that the TREE PTA is just a TODO_rebuild_alias flag. Thus I would expect
> IPA PTA is also a rebuild of PTA information.

IPA PTA rebuilds everything (and with -fipa-pta we should be fine).  The 
issue is the time between IPA ICF and the late pass_build_alias,
we do the "invalid" folding in pass_ccp.

And yes, we do want to do some scalar cleanup before running PTA.

If we'd decide not to then the "proper" place would probably be
pass_ipa_pta which then either would do local PTA or IPA PTA based
on the flag.

But that's too much for GCC 8 or 7.

[Bug target/84760] New: Finish implementation of __builtin_altivec_lvx_v1ti

[kelvin at gcc dot gnu.org]

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

Bug ID: 84760
   Summary: Finish implementation of __builtin_altivec_lvx_v1ti
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

The gcc/config/rs6000/rs6000-builtin.def source file contains an entry that
introduces the enumeration constant ALTIVEC_BUILTIN_LVX_V1TI and the built-in
function __builtin_atlivec_lvx_v1ti:

BU_ALTIVEC_X (LVX_V1TI, "lvx_v1ti", MEM)

The remainder of the implementation, which is required to define the prototype
for this function and to connect the function with its implementation, is
missing.  This was an apparent oversight at the time that this definition was
introduced.  T