[Bug fortran/84189] Internal procedure allowed as type bound procedure

[neil.n.carlson at gmail dot com]

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

Neil Carlson  changed:

   What|Removed |Added

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

--- Comment #1 from Neil Carlson  ---
Sorry, this is completely bogus -- lack of sleep is my only excuse.

[Bug fortran/84189] New: Internal procedure allowed as type bound procedure

[neil.n.carlson at gmail dot com]

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

Bug ID: 84189
   Summary: Internal procedure allowed as type bound procedure
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

C465 (F08) prohibits an internal procedure from being a type bound procedure,
but gfortran mistakenly allows it when the TPB has the NOPASS attribute.

The following invalid example should fail to compile, but gfortran compiles it
without error.

module foobar
type :: foo
contains
  procedure, nopass :: bar
end type
contains
  subroutine bar
  end subroutine
end module

Note that the func_result_6.f90 testsuite problem, and perhaps others, use this
type of invalid code.

[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-03
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
A solution for this bug is necessary to fix pr83503 and pr84158.  I'm working
on a patch.

[Bug tree-optimization/84188] assume non-null malloc pointers are distinct

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Another test case for the guarantee that "...and moreover no pointers to valid
objects occur in any storage addressed by P."

void* __attribute__ ((malloc, returns_nonnull))
f (unsigned);

void g3 (unsigned n)
{
  void *p = f (n);
  void **q = f (n);

  if (p == *q)// must be false
__builtin_abort ();   // can be eliminated but isn't
}

[Bug tree-optimization/84188] New: assume non-null malloc pointers are distinct

[msebor at gcc dot gnu.org]

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

Bug ID: 84188
   Summary: assume non-null malloc pointers are distinct
   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: ---

The manual documents the effect of the malloc attribute like so:

This tells the compiler that a function is malloc-like, i.e., that the
pointer P returned by the function cannot alias any other pointer valid when
the function returns, and moreover no pointers to valid objects occur in any
storage addressed by P.

The following test case shows that GCC doesn't take advantage of this property
nearly to the extent it could.  (To enable GCC to make full use of this
property implementations of malloc functions would of course have to avoid such
comparisons internally, but presumably they do that already since that's the
documentation makes it clear that such comparisons must be false.)

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void* __attribute__ ((malloc, returns_nonnull))
f (unsigned);

void g0 (unsigned n)
{
  extern char a[];

  void *p = f (n);// p is non-null
  if (p == a) // must be false
__builtin_abort ();   // can be eliminated but isn't
}

void g1 (unsigned n)
{
  char a[1];

  void *p = f (n);
  if (p == a) // folded into false
__builtin_abort ();   // eliminated (good)
}

void g2 (unsigned n, void *p)
{
  // here, p must be valid when f() returns regardless what
  // it points to otherwise the equality would be undefined
  // therefore p cannot equal q

  void *q = f (n);
  if (p == q) // must be false
__builtin_abort ();   // can be eliminated but isn't
}

void g3 (unsigned n)
{
  void *p = f (n);
  void *q = f (n);

  // the relationship between p and q is the same as in g2

  if (p == q) // must be false
__builtin_abort ();   // can be eliminated but isn't
}

;; Function g0 (g0, funcdef_no=0, decl_uid=1952, cgraph_uid=0, symbol_order=0)

g0 (unsigned int n)
{
  void * p;

   [local count: 1073741825]:
  p_4 = f (n_2(D));
  if (p_4 == )
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}



;; Function g1 (g1, funcdef_no=1, decl_uid=1958, cgraph_uid=1, symbol_order=1)

g1 (unsigned int n)
{
   [local count: 1073741825]:
  f (n_2(D)); [tail call]
  return;

}



;; Function g2 (g2, funcdef_no=2, decl_uid=1964, cgraph_uid=2, symbol_order=2)

g2 (unsigned int n, void * p)
{
  void * q;

   [local count: 1073741825]:
  q_4 = f (n_2(D));
  if (q_4 == p_5(D))
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}



;; Function g3 (g3, funcdef_no=3, decl_uid=1968, cgraph_uid=3, symbol_order=3)

g3 (unsigned int n)
{
  void * q;
  void * p;

   [local count: 1073741825]:
  p_4 = f (n_2(D));
  q_6 = f (n_2(D));
  if (p_4 == q_6)
goto ; [0.00%]
  else
goto ; [99.96%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073312327]:
  return;

}

[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays

[slyfox at inbox dot ru]

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

--- Comment #10 from Sergei Trofimovich  ---
Oh, I have forgot to ask another question:

In attached reloc-bug.c there is seemingly two functionally identical samples:

  extern char glo_u64_middle_hidden[] __attribute__((visibility("hidden")));
  static u64 __attribute__((noinline)) val_u64_hidden(void) {
const u64 * m = (const u64 *)glo_u64_middle_hidden;
return m[-1];
  }

and

  extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));
  struct s { u64 a; };
  static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
  }

Why those are handled differently? First looks like it works, second does not.
It was my main signal to file a bug against gcc as asymmetry looked fishy.

$ ./reloc-bug
val/global = 100
val/hidden = 100
Segmentation fault

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
Prospective patch posted at
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00137.html.

[Bug c/84187] -O0 fails inline assembly compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Can you provide the preprocessed source?
This might be a bug in the linux kernel headers really.

[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays

[slyfox at inbox dot ru]

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

--- Comment #9 from Sergei Trofimovich  ---
Aha, makes sense! Proposed kernel tweak upstream as:
https://lkml.org/lkml/2018/2/2/914

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[rlcamp.pdx at gmail dot com]

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

--- Comment #49 from Campbell  ---
I can confirm that the latest gcc 8 snapshot still fails by default, but it
works with 8 cores using Chris's fix above of replacing ln -s with cp. This in
my mind pretty conclusively points to it not being a makefile logic error, but
rather a filesystem error. However, regardless of whose fault it is, Chris's
patch represents an actual viable solution to the problem, and is simple to
understand, and does not unduly penalize other platforms. This situation has
persisted for far too long and it makes GCC look bad and lose actual users,
regardless of whether Apple or GCC caused the problem.

[Bug c++/84036] [8 Regression] ICE on valid code in C++14, variadic lambda capture in a template function

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

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

--- Comment #7 from Benjamin Buch  ---
I have to reopen this with an extended test case. Its still an ICE as soon as I
access the captured pack:


template < typename T > void sink(T ...){}

template < typename T >
auto f(T){
[](auto ... i){
[i ...]{ sink(i ...); };
};
}

int main(){
f(0);
}


$ g++ -std=c++14 main2.cpp  
main2.cpp: In instantiation of 'auto f(T) [with T = int]':
main2.cpp:11:5:   required from here
main2.cpp:6:16: internal compiler error: in retrieve_specialization, at
cp/pt.c:1191
   [i ...]{ sink(i ...); };
^~~
0x603f91 retrieve_specialization
../../gcc/gcc/cp/pt.c:1188  
0x942e53 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) 
../../gcc/gcc/cp/pt.c:11524 
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)   
../../gcc/gcc/cp/pt.c:17684 
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)   
../../gcc/gcc/cp/pt.c:17100 
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) 
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b7b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b7b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927478 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b7b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b7b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
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 c/84187] New: -O0 fails inline assembly compile

[rong2.liu at intel dot com]

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

Bug ID: 84187
   Summary: -O0 fails inline assembly compile
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rong2.liu at intel dot com
  Target Milestone: ---

Hi,

When I use -O0 flag to compile a kernel module, compile fails with following
error message.  The same code compiles fine if not using -O0 flag.

make -C /lib/modules/4.12.0+/build M=/home/bob/GccCompileError
make[1]: Entering directory '/home/bob/kernel/v4.12/linux'
  CC [M]  /home/bob/GccCompileError/GccCompileError.o
In file included from ./include/linux/compiler.h:62:0,
 from ./include/linux/init.h:4,
 from /home/bob/GccCompileError/GccCompileError.c:1:
./arch/x86/include/asm/cpufeature.h: In function ‘GccCompileError_init’:
./include/linux/compiler-gcc.h:264:38: warning: asm operand 0 probably doesn’t
match constraints
 #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
  ^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
   asm_volatile_goto("1: jmp 6f\n"
   ^
./include/linux/compiler-gcc.h:264:38: warning: asm operand 2 probably doesn’t
match constraints
 #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
  ^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
   asm_volatile_goto("1: jmp 6f\n"
   ^
./include/linux/compiler-gcc.h:264:38: error: impossible constraint in ‘asm’
 #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
  ^
./arch/x86/include/asm/cpufeature.h:146:3: note: in expansion of macro
‘asm_volatile_goto’
   asm_volatile_goto("1: jmp 6f\n"
   ^
scripts/Makefile.build:308: recipe for target
'/home/bob/GccCompileError/GccCompileError.o' failed
make[2]: *** [/home/bob/GccCompileError/GccCompileError.o] Error 1
Makefile:1512: recipe for target '_module_/home/bob/GccCompileError' failed
make[1]: *** [_module_/home/bob/GccCompileError] Error 2
make[1]: Leaving directory '/home/bob/kernel/v4.12/linux'
Makefile:16: recipe for target 'all' failed
make: *** [all] Error 2

Here is the very simple source code to demonstrate the error:
  1 #include 
  2 #include 
  3 #include 
  4 #include 
  5
  6 MODULE_LICENSE("Proprietary");
  7
  8 static int __init GccCompileError_init(void)
  9 {
 10 bool invPcid = false;
 11
 12 invPcid = static_cpu_has(X86_FEATURE_INVPCID);
 13 printk(KERN_ERR "<1> INVPCID = %s\n", invPcid == true ? "true" :
"false");
 14
 15 //printk("GccCompileError: Hello, world!\n");
 16 return 0;
 17 }
 18
 19 static void __exit GccCompileError_exit(void)
 20 {
 21  printk("GccCompileError: Goodbye, world!\n");
 22 }
 23
 24 module_init(GccCompileError_init);
 25 module_exit(GccCompileError_exit);

And the following is Makefile:
  1 KERNEL_MODULE_NAME := GccCompileError
  2
  3 KERNELDIR:=/lib/modules/$(shell uname -r)/build
  4 PWD=$(shell pwd)
  5
  6 INCLUDES = -I.
  7
  8 ccflags-y += $(INCLUDES) -ggdb -O0
  9 #ccflags-y += $(INCLUDES) -ggdb
 10
 11 obj-m += GccCompileError.o
 12
 13 switch-y := GccCompileError.o
 14
 15 all:
 16 $(MAKE) -C $(KERNELDIR) M=$(PWD)
 17
 18 clean:
 19 $(MAKE) -C $(KERNELDIR) M=$(PWD) clean
 20
 21 install:
 22 $(MAKE) -C $(KERNELDIR) M=$(PWD) modules_install

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

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

Jens-S. Vöckler  changed:

   What|Removed |Added

 CC||jens4303 at me dot com

--- Comment #48 from Jens-S. Vöckler  ---
The consensus of this thread is that APFS has a bug that HFS+ does not. I also
remember that last autumn I was able to build gcc-7.2.0 from source on Sierra.
Two weeks later, after upgrading to High Sierra, the same build failed.

I just compiled gcc-7.3.0 on 10.13.3 using fink's build mechanism and a large
empty non-encrypted HFS+ formatted image file that I created with Disk Utility,
and then attached (mounted) at the root of the directory tree where gcc will be
unpacked and the "objdir" resides. In fink's case that means mounting the HFS+
image as /sw/fink/src/fink.build after stashing the original "fink.build" to
the side. 

The build utilized all 8 HT cores of the i7, and successfully compiled and
installed gcc-7.3.0 (gcc, g++, gfortran) on my machine. I have not tried to
compile gcc from source, without fink, using the HFS+ image file work-around,
though I don't see why it should not work.

[Bug c/83390] valgrind error in lra_eliminate_regs_1

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #7 from David Malcolm  ---
Can you reproduce it with a specific source file and specific compilation
flags?  Thanks.

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[benni.buch at gmail dot com]

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

--- Comment #6 from Benjamin Buch  ---
Yet another version:


template < typename T >
auto var = [](auto ... i){ [i ...]{}; }();

int main(){
var< int >;
}


$ g++ -std=c++14 main4.cpp
main4.cpp: In instantiation of '<lambda(auto:1 ...)> [with auto:1 = {}]':
main4.cpp:2:40:   required from 'auto var'
main4.cpp:5:5:   required from here
main4.cpp:2:31: internal compiler error: Segmentation fault
 auto var = [](auto ... i){ [i ...]{}; }();
   ^~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x941bc8 tsubst_decl
../../gcc/gcc/cp/pt.c:12858
0x92571d tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:16970
0x927478 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x932751 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16045
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental) 
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 c++/84186] nested template qualified-id not parsed correctly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-02
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It accepts it with 'template' added:

int a[sizeof(typename N::template S2::X*)];

I'm not sure if that's needed there or not.

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|gcc generates wrong |gcc generates wrong
   |relocations with negative   |relocations with negative
   |offsets in struct arrays|offsets in struct arrays
   |(but not integral arrays)   |

--- Comment #7 from Eric Botcazou  ---
Investigating about the warning.

[Bug middle-end/84184] gcc generates wrong relocations with negative offsets in struct arrays

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #8 from Eric Botcazou  ---
Recategorizing.

[Bug c++/84186] New: nested template qualified-id not parsed correctly

[smw at gcc dot gnu.org]

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

Bug ID: 84186
   Summary: nested template qualified-id not parsed correctly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

OK, bear with me on this one, but it appears like a nested qualified-id that is
a simple-template-id confuses the parser, or something.

Here's some code.

template struct N {
struct S1 { // not a template class
typedef short X;

template struct S11 {
int a[sizeof(typename N::S1::X*)]; // OK
};
};

template struct S2 { // woah, a class template
typedef short X;

template struct S21 {
int a[sizeof(typename N::S2::X*)]; // not OK
};
};
};

That snippet gets accepted by ICC, MSVC, clang, and pretty much every other
compiler I tested on, bug GCC (all versions, up to and including 8.0.1
20180202) reject it [-std=c++14 -O0 -Wall -pedantic
-fdiagnostics-generate-patch] with the following diagnostic output.

:14:45: error: 'typename N::S2' names 'template
template struct N::S2', which is not a type
 int a[sizeof(typename N::S2::X*)]; // not OK
 ^
:14:41: error: 'typename N::S2' names 'template
template struct N::S2', which is not a type
 int a[sizeof(typename N::S2::X*)]; // not OK
 ^
:14:46: error: expected '(' before '::' token
 int a[sizeof(typename N::S2::X*)]; // not OK
  ^~
  (
:14:46: error: expected ')' before '::' token
 int a[sizeof(typename N::S2::X*)]; // not OK
 ~^~
  )
:14:52: error: expected ']' before ';' token
 int a[sizeof(typename N::S2::X*)]; // not OK
^
]
--- 
+++ 
@@ -11,7 +11,7 @@
 typedef short X;

 template struct S21 {
-int a[sizeof(typename N::S2::X*)]; // not OK
+int a[sizeof(typename N::S2()::X*)]]; // not OK
 };
 };
 };
Compiler returned: 1

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

[juergen.reuter at desy dot de]

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

--- Comment #33 from Jürgen Reuter  ---
Mea culpa. I had to recompile the external libraries again. Then those tests
depending on the external libraries did also work (headbang).

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[benni.buch at gmail dot com]

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

--- Comment #5 from Benjamin Buch  ---
I'm not completely sure anymore whether this is related, another version of the
new bug is:


template < typename ... T >
void sink(T ...){}

template < typename T >
auto var = [](auto ... i){ sink(i + 0 ...); }();

int main(){
var< int >;
}


$ g++ -std=c++14 main3.cpp
main3.cpp: In instantiation of ' [with auto:1 = {}]':
main3.cpp:5:46:   required from 'auto var'
main3.cpp:8:5:   required from here
main3.cpp:5:32: internal compiler error: Segmentation fault
 auto var = [](auto ... i){ sink(i + 0 ...); }();
^~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
0x7f5f1c build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4596
0x970075 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2506
0x92849e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17874
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Could gcc generate warning without much of additional effort (or even better
> an error) when it knows it is about to generate broken code?

Generating broken code from invalid C is perfectly OK, but we could indeed
warn.

> For this code I guess the pattern is  + .

The key is really the misalignment, which forces the bitfield path.  Other
paths in the compiler handle the negative literal just fine.

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

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

--- Comment #7 from Benjamin Buch  ---
I've checked it again and this bug seems not to be related, I do a separate
report.

[Bug c++/84126] [8 Regression] ICE in variadic generic lambda inside a template function calling a function with arguments by reference

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

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

--- Comment #6 from Benjamin Buch  ---
Thanks for fixing!

Found a variable template version that is still broken:


template 
void sink(Ts...){}

template 
int bar(T&){} // ICE with reference, work with just T

template 
auto var = [](auto ... k){
sink(bar(k) ...);
}(0);


int main() {
var;
}


$ g++ -std=c++14 main2.cpp
main2.cpp: In function 'int bar(T&)':
main2.cpp:5:13: warning: no return statement in function returning non-void
[-Wreturn-type]
 int bar(T&){} // ICE with reference, work with just T
 ^
main2.cpp: In instantiation of '<lambda(auto:1 ...)> [with auto:1 = {int}]':
main2.cpp:10:6:   required from 'auto var'
main2.cpp:14:5:   required from here
main2.cpp:9:13: internal compiler error: Segmentation fault
 sink(bar(k) ...);
 ^~~~
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x927dcd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933950 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
0x7f5f1c build_op_call_1
../../gcc/gcc/cp/call.c:4567
0x7f5f1c build_op_call(tree_node*, vec<tree_node*, va_gc, vl_embed>**, int)
../../gcc/gcc/cp/call.c:4596
0x970075 finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2506
0x92849e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17874
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
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 tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
The commentary for r248678 reads in part: "Compute costs for doing no peeling
at all, compare to the best peeling costs so far and avoid peeling if cheaper."
 Indeed, if you look at the vect dump for r248677, you see that the vectorizer
decides to force alignment using peeling, even though the target processor has
efficient unaligned memory access.  Peeling proved to be barely unprofitable:

/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Cost model analysis:
  Vector inside of loop cost: 1
  Vector prologue cost: 7
  Vector epilogue cost: 6
  Scalar iteration cost: 1
  Scalar outside cost: 0
  Vector outside cost: 13
  prologue iterations: 2
  epilogue iterations: 2
  Calculated minimum iters for profitability: 17
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note:   Runtime profitability threshold = 16
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note:   Static estimate profitability threshold = 16
/home/wschmidt/gcc/gcc-mainline-base/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: not vectorized: vectorization not profitable.

In the vect dump for r248678, the vectorizer isn't overly focused on peeling,
and determines that it can use the efficient unaligned storage accesses.  This
leads to the more reasonable cost calculation:

/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: Cost model analysis:
  Vector inside of loop cost: 1
  Vector prologue cost: 1
  Vector epilogue cost: 0
  Scalar iteration cost: 1
  Scalar outside cost: 0
  Vector outside cost: 1
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 2
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note:   Runtime profitability threshold = 3
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note:   Static estimate profitability threshold = 3
/home/wschmidt/gcc/gcc-mainline-test/gcc/testsuite/g++.dg/vect/slp-pr56812.cc:1\
6:18: note: loop vectorized

For this processor, we vectorized the code in "vect" rather than in "slp".  For
other processors, the choice could be different because of cost model
differences.  But I think in general we should always vectorize.  In both cases
the "optimized" dump produces:

void mydata::Set(float) (struct mydata * const this, float x)
{
  vector(4) float vect_cst__10;

   [11.11%]:
  vect_cst__10 = {x_5(D), x_5(D), x_5(D), x_5(D)};
  MEM[(float *)this_4(D)] = vect_cst__10;
  MEM[(float *)this_4(D) + 16B] = vect_cst__10;
  return;

}

So I think perhaps it would be better to change the test to examine the
"optimized" dump for one definition and two uses of a vect_cst__*.  The point
of the original complaint in PR56812 was that this test case was not vectorized
(by SLP at the time), but so long as it is vectorized, that should be good
enough for everyone.

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[benni.buch at gmail dot com]

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

Benjamin Buch  changed:

   What|Removed |Added

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

--- Comment #4 from Benjamin Buch  ---
Thanks for your fast patching!

I found another variant of this bug if you use a variable template instead of a
function:


template < int ... I >
struct A{};

template < typename T >
auto var = [](auto ... i){
return A< decltype(i)::x ... >{};
};

int main(){
var< int >();
}

$ g++ -std=c++14 main3.cpp
main3.cpp: In instantiation of ' [with auto:1 = {}]':
main3.cpp:10:16:   required from here
main3.cpp:6:40: internal compiler error: Segmentation fault
 return A< decltype(i)::x ... >{};
^
0xe79ecf crash_signal
../../gcc/gcc/toplev.c:325
0x916d50 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x916d50 enclosing_instantiation_of
../../gcc/gcc/cp/pt.c:12694
0x942a7e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11450
0x94452a tsubst_template_args
../../gcc/gcc/cp/pt.c:11836
0x944438 tsubst_template_args
../../gcc/gcc/cp/pt.c:11854
0x940d15 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12067
0x93b25e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926df4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e29 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e29 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932e80 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f41 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x9311d8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9311d8 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23384
0x87aeeb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5178
0x87ccf8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5273
0x7e7c90 build_over_call
../../gcc/gcc/cp/call.c:8201
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Created attachment 43330
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43330=edit
Patch tested on x86_64-linux.

GCC 9 patch regression-tested on x86_64-linux.

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|acsawdey at gcc dot gnu.org|wschmidt at gcc dot 
gnu.org

--- Comment #7 from Bill Schmidt  ---
I'm looking at this one.

[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2018-02-02
 CC||msebor at gcc dot gnu.org
 Resolution|INVALID |---
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
(In reply to Paul Eggert from comment #4)
> Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
> attribute?

GCC silently drops it, without validating it.  For instance, this is accepted
as well:

  struct s { char mem; };

  struct __attribute__ ((foobar))
  s b;

I view it as a bug.  At a minimum, GCC should point out that it's ignoring the
attribute like other compilers do, such as Clang:

  warning: unknown attribute 'foobar' ignored [-Wunknown-attributes]

I happened to notice this bug while testing a fix for pr84108.  It seems that a
simple fix is fairly straightforward so hopefully Richard won't be offended if
I reopen this bug, assign it to myself, and submit my patch in stage 1 of GCC
9.

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[slyfox at inbox dot ru]

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

--- Comment #5 from Sergei Trofimovich  ---
Good suggestion! I will do it.

Could gcc generate warning without much of additional effort (or even better an
error) when it knows it is about to generate broken code?

For this code I guess the pattern is  + .

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
I'd suggest fixing the code instead:

extern struct s glo_s_middle_hidden[] __attribute__((visibility("hidden")));

which makes it valid C and generates correct code.

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Calling this standard C is really questionable.  This goes awry on 64-bit RISC
architectures with strict-alignment requirement because get_inner_reference
returns a negative bit position and passes it down to the bitfield extraction
machinery, which expects only non-negative bit positions.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #32 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #31)
> Unfortunately, the problem with our external libraries still persist. Don't
> know how to provide you with a test case for this without providing our
> complete code and their external complete code. :(

How does the error manifest itself? Internal library error, segfault, ... ?

If it is an internal error, you could compile everything with -g
(including the external libraries), start under a debugger,
then set a breakpoint at _gfortrani_internal_error, and then run.

A backtrace could be quite illuminating.

Similar for a segfault - run under a debugger and look at
a backtrace.

[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Confirmed with trunk and gcc 7.

There seem to be two issues here; the differences seen between trunk and gcc 7
appear to be due to trunk currently defaulting to
  --enable-checking=yes,extra
and 7 defaulting to
  --enable-checking=release
and thus gcc_assert is a no-op by default for gcc 7.

Checked builds of trunk and gcc 7 both fail this assertion inside "ifcvt":

283   if (flag_checking)
284 for (gimple_stmt_iterator i = gsi_start (stmts);
285  !gsi_end_p (i); gsi_next ())
286   gcc_assert (! gimple_use_ops (gsi_stmt (i)));

#1  0x010b98ff in release_bb_predicate (bb=) at ../../src/gcc/tree-if-conv.c:286
#2  0x010b994c in free_bb_predicate (bb=) at ../../src/gcc/tree-if-conv.c:300
#3  0x010c091f in tree_if_conversion (loop=0x71a09ee0) at
../../src/gcc/tree-if-conv.c:2897
#4  0x010c0aa2 in (anonymous namespace)::pass_if_conversion::execute
(this=0x2abab80, fun=0x71a00160)
at ../../src/gcc/tree-if-conv.c:2962
#5  0x00ec11b2 in execute_one_pass (pass=) at ../../src/gcc/passes.c:2497
[...]

on this GIMPLE_ASSIGN:

_175 = (signed char) _117;


Release builds of trunk and of gcc 7 fail later, reading through a NULL
basic_block in VRP:

(gdb) bt
#0  mark_block_for_update(basic_block_def*) () at
../../src/gcc/tree-into-ssa.c:447
#1  0x00af1c10 in mark_use_interesting (insert_phi_p=false,
bb=, stmt=, 
var=) at ../../src/gcc/tree-into-ssa.c:2540
#2  prepare_use_sites_for (insert_phi_p=false, name=)
at ../../src/gcc/tree-into-ssa.c:2705
#3  prepare_names_to_update (insert_phi_p=false) at
../../src/gcc/tree-into-ssa.c:2773
#4  update_ssa(unsigned int) () at ../../src/gcc/tree-into-ssa.c:3339
#5  0x00c39fd0 in insert_range_assertions () at
../../src/gcc/tree-vrp.c:6849
#6  execute_vrp (warn_array_bounds_p=false) at ../../src/gcc/tree-vrp.c:11724
#7  (anonymous namespace)::pass_vrp::execute(function*) () at
../../src/gcc/tree-vrp.c:11833
#8  0x009df329 in execute_one_pass (pass=pass@entry=) at ../../src/gcc/passes.c:2465
[...]

again on a GIMPLE_ASSIGN:
_177 = (signed char) _26;

due to it having a NULL bb:

(gdb) p stmt->bb
$5 = 

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

[juergen.reuter at desy dot de]

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

--- Comment #31 from Jürgen Reuter  ---
Unfortunately, the problem with our external libraries still persist. Don't
know how to provide you with a test case for this without providing our
complete code and their external complete code. :(

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[slyfox at inbox dot ru]

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

--- Comment #2 from Sergei Trofimovich  ---
> - large amount of code

Jason pointed out the blowup happens due to byte-level reads (caused by 'char*'
-> 'u64*' required alignment increase) thus it's expected. Only correctness
issue is left.

[Bug fortran/68560] [6/7/8 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto

[tkoenig at gcc dot gnu.org]

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

--- Comment #27 from Thomas Koenig  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00071.html

[Bug bootstrap/56750] [6/7/8 Regression] static -lstdc++ logic bleeds into all subdirs

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #13 from Aldy Hernandez  ---
(In reply to Eric Botcazou from comment #4)
> > Well, if you can link dynamically, you should, if say libstdc++ contains
> > some security bug and gdb isn't built in the combined tree with gcc, then
> > I'd say it is highly undesirable to link it statically.
> 
> Your point of view is clearly too Linux-centric here. :-)  I can assure you
> that the last thing people want on Solaris on HP-UX is to have to install
> shared libraries to run GDB.

Hi folks.  It's been 4 years with no progress here.

Is this becoming a WONTFIX or should we add a toplevel configure flag to give
the user an option to opt out of -static-libstdc++ -static-libgcc?

The the original patch has a work around, just specify --with-stage1-libs=" "
and you won't get the offending behavior :):

 # In stage 1, default to linking libstdc++ and libgcc statically with GCC
 # if supported.  But if the user explicitly specified the libraries to use,
 # trust that they are doing what they want.
 if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
   stage1_ldflags="-static-libstdc++ -static-libgcc"
 fi])

Should we make an explicit configury flag for this behavior instead of the
above work around?

Should we instead close this as a WONTFIX with a pointer to the following in
our docs:

--with-stage1-ldflags=flags
This option may be used to set linker flags to be used when linking stage 1 of
GCC. These are also used when linking GCC if configured with
--disable-bootstrap. If --with-stage1-libs is not set to a value, then the
default is ‘-static-libstdc++ -static-libgcc’, if supported.

Any input would be great.

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
This starts to fail with r249850 (don't know yet what the problem is).

[Bug c/84183] internal compiler error: in initialize, at alloc-pool.h:257

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug report.

Looks like it's failing in "s-selftest", running the selftests within cc1. 
These ought to be a no-op for a release build, so presumably it's just
happening to fail the first time that the newly built cc1 is run.

Line 257 of alloc-pool.h is:

  gcc_checking_assert (m_name);

within base_pool_allocator ::initialize (), so presumably
m_name is NULL  ...somehow.

[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00125.html

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #11)
> There was another test case that I submitted for #84141. It still failed
> after the first preliminary fix.

This one also works with the patch from comment #8 (and without
the trans-io.c patch).

Looking very good, I think.

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

[juergen.reuter at desy dot de]

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

--- Comment #30 from Jürgen Reuter  ---
Yep, that looks good. Paul's fix is now the change in trans-array.c only, or
still the change in trans-io.c ? I guess only the trans-array.c patch. I'll try
it out later tonight.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #24)
> Created attachment 43322 [details]
> Additional failing test case (after the prelim. fix)
> 
> This is still lengthy, and I can reduce it further but maybe the error helps
> you when you run it in the debugger. I get 
> Running test: resonance_insertion_2seg_prod(64951,0x7fff9ae91340) malloc:
> *** mach_vm_map(size=9223372036854779904) failed (error code=3)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
> 
> Backtrace for this error:
> #0  0x10900d64c
> #1  0x10900c9f3
> #2  0x7fff620bcf59

With Paul's fix for PR84155, the output of the test now is

| 
| Running self-test: resonance_insertion
| 
Running test: resonance_insertion_2 ... success.
*** Test Summary ***
  Success:
resonance_insertion_2: resonance color mismatch
Total   = 1
Success = 1
Failure = 0
*** End of test Summary ***
| WHIZARD run finished.
|=|

which looks like success.

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

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter  ---
There was another test case that I submitted for #84141. It still failed after
the first preliminary fix.

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

[juergen.reuter at desy dot de]

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

--- Comment #28 from Jürgen Reuter  ---
Created attachment 43329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43329=edit
Shortened test case (after prelim. fix)

This is a shortened test case that still failed after the first preliminary fix
by Paul Thomas with the special care for the allocatables. Just compile and
run, it seg faults.

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

[pault at gcc dot gnu.org]

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

--- Comment #27 from Paul Thomas  ---
Please see PR84155 for a fix that looks somewhat cleaner but note the caveat
associated with it.

Paul

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

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Created attachment 43328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43328=edit
Patch for the bug

This patch fixes the PR and PR84141. The dejagnuified version of the reproducer
will appear with submission to the list - it reads back the scratch file and
checks that the value recorded is correct.

There is an important caveat to this fix, which has me very worried: On top of
removal of uncalled code making the bug disappear, I cannot see any difference
in the tree dump between the working testcase and the failing version.

I am going to have to call in the cavalry tomorrow.

Paul

[Bug middle-end/84185] New: missing warning when ignoring attribute aligned on a member

[msebor at gcc dot gnu.org]

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

Bug ID: 84185
   Summary: missing warning when ignoring attribute aligned on a
member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As mentioned in bug 84108 comment 2, GCC warns about variable declarations that
specify both attribute aligned and packed, yet it requires both attributes to
reduce the alignment of a struct member and doesn't indicate that a sole
aligned attribute has no such effect (i.e., doesn't reduce the member's
alignment).

The limitation/requirement of the aligned attribute is documented in the
manual:

  When used on a struct, or struct member, the aligned attribute can only
increase the alignment; in order to decrease it, the packed attribute must be
specified as well.

but because it is subtle and inconsistent with how the attribute is treated for
non-members, it's easy to miss.  See also bug 82914 for another example of
confusion this has lead to.

Assuming it's too risky to make the attribute behave consistently for both
members and non-members, GCC could help reduce the confusion (and bugs) by
issuing a warning when the attribute is specified alone on a member and known
to have no effect.

$ cat t.c && gcc -S -Wall -Wextra t.c
#define ASSERT(e) _Static_assert (e, #e)

struct {
  int a __attribute__ ((aligned (2)));   // attribute ignored, missing warning
} a;

ASSERT (_Alignof (a.a) == 2);// assertion failure

struct {
  int b __attribute__ ((packed));
} b;

ASSERT (_Alignof (b.b) == 1);// passes

struct {
  int c __attribute__ ((aligned (2), packed));
} c;

ASSERT (_Alignof (c.c) == 2);// passes
t.c:1:19: error: static assertion failed: "_Alignof (a.a) == 2"
 #define ASSERT(e) _Static_assert (e, #e)
   ^~
t.c:7:1: note: in expansion of macro ‘ASSERT’
 ASSERT (_Alignof (a.a) == 2);// assertion failure
 ^~

[Bug lto/83954] [6/7 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Feb  2 18:09:32 2018
New Revision: 257343

URL: https://gcc.gnu.org/viewcvs?rev=257343=gcc=rev
Log:
PR lto/83954
* lto-symtab.c (warn_type_compatibility_p): Do not recurse into the
component type of array types with non-aliased component.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-symtab.c

[Bug c/84184] gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #1 from Sergei Trofimovich  ---
Dumping 'val_s_hidden':

extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));
static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
}

$ cat reloc-bug.c.227t.optimized

;; Function val_s_hidden (val_s_hidden, funcdef_no=23, decl_uid=2082,
cgraph_uid=23, symbol_order=24) (executed once)

__attribute__((noinline))
val_s_hidden ()
{
  u64 _2;

   [100.00%]:
  _2 = MEM[(const struct s *)_s_middle_hidden + -8B].a;
  return _2;
}

Still looks ok, right? I guess RTL is doing funny things here (+Eric).

$ cat reloc-bug.c.229r.expand

;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 6 2 (set (reg/f:DI 342)
(symbol_ref:DI ("glo_s_middle_hidden") [flags 0x42]  )) "reloc-bug.c":17 -1
 (nil))
(insn 6 5 7 2 (set (reg:DI 343)
(reg/f:DI 342)) "reloc-bug.c":17 -1
 (nil))
(insn 7 6 8 2 (set (reg:DI 345)
(const_int 2305843009213693944 [0x1ff8]))
"reloc-bug.c":17 -1
 (nil))
...

Surprisingly large amount of code is generated here:

$ cat reloc-bug.S

val_s_hidden:
.prologue
.body
.mlx
nop 0
movl r14 = @gprel(glo_s_middle_hidden#)
.mlx
nop 0
movl r16 = 2305843009213693945 ; 0x1ff9
;;
.mlx
add r14 = r1, r14
movl r15 = 2305843009213693944 ; 0x1ff8
.mlx
nop 0
movl r17 = 2305843009213693946 ; 0x1ffa
;;
.mmi
add r15 = r14, r15
add r17 = r14, r17
add r16 = r14, r16
;;
.mmi
ld1 r8 = [r15]
ld1 r16 = [r16]
nop 0
;;
.mlx
ld1 r15 = [r17]
movl r17 = 2305843009213693947 ; 0x1ffb
.mib
nop 0
shl r16 = r16, 8
nop 0
;;
.mmi
add r17 = r14, r17
or r16 = r8, r16
shl r15 = r15, 16
;;
.mlx
ld1 r8 = [r17]
movl r17 = 2305843009213693948 ; 0x1ffc
.mmi
or r15 = r16, r15
;;
add r17 = r14, r17
shl r8 = r8, 24
;;
.mlx
ld1 r16 = [r17]
movl r17 = 2305843009213693949 ; 0x1ffd
.mmi
or r8 = r15, r8
;;
add r17 = r14, r17
shl r16 = r16, 32
;;
.mlx
ld1 r15 = [r17]
movl r17 = 2305843009213693950 ; 0x1ffe
.mmi
or r16 = r8, r16
;;
add r17 = r14, r17
shl r15 = r15, 40
;;
.mlx
ld1 r8 = [r17]
movl r17 = 2305843009213693951 ; 0x1fff
.mmi
or r15 = r16, r15
;;
add r14 = r14, r17
shl r8 = r8, 48
;;
.mii
ld1 r16 = [r14]
or r15 = r15, r8
;;
shl r8 = r16, 56
;;
.mib
nop 0
or r8 = r15, r8
br.ret.sptk.many b0
.endp val_s_hidden#

I hoped to see here single load (something like that):

mov  = @gprel64(glo_s_middle_hidden#)

add   = gp, 

ld8 r8 = []

I see 2 issues here:
- code is invalid
- large amount of code

[Bug c/84184] New: gcc generates wrong relocations with negative offsets in struct arrays (but not integral arrays)

[slyfox at inbox dot ru]

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

Bug ID: 84184
   Summary: gcc generates wrong relocations with negative offsets
in struct arrays (but not integral arrays)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at inbox dot ru
  Target Milestone: ---

Created attachment 43327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43327=edit
reloc-bug.c

It's a trimmed-down version of linux kernel miscompilation on ia64:
https://bugs.gentoo.org/518130

Minimal reproducer:

// cat reloc-bug.c
#include 

typedef unsigned long long u64;

struct s { u64 a; };
struct s glo_s[] = {
{ 100, },
// glo_s_middle_hidden:
// ; Injected as LDFLAGS="-Wl,--defsym=glo_s_middle=glo_s+8
-Wl,--defsym=glo_s_middle_hidden=glo_s+8"
{ 700, },
{ 800, },
};

extern char glo_s_middle_hidden[] __attribute__((visibility("hidden")));

static u64 __attribute__((noinline)) val_s_hidden(void) {
const struct s * m = (const struct s *)glo_s_middle_hidden;
return m[-1].a;
}

int main() {
printf ("val/hidden = %lld\n", val_s_hidden());
}

+ ia64-unknown-linux-gnu-gcc-7.2.0 -c -O2 reloc-bug.c -o reloc-bug.o
+ ia64-unknown-linux-gnu-gcc-7.2.0 -O2 reloc-bug.o -o reloc-bug
-Wl,--defsym=glo_s_middle=glo_s+8 -Wl,--defsym=glo_s_middle_hidden=glo_s+8
+ ./reloc-bug
./mk.sh: line 12: 12418 Segmentation fault  ./reloc-bug

Note a few things:

Note 1: 
it's not trivial to write the code in standard C. I had to synthesise symbol
with --defsym. I tried a few targets where this sample crashes instead of
returning 100:

# fails
CC=sparc64-unknown-linux-gnu-gcc
CC=ia64-unknown-linux-gnu-gcc
CC=alpha-unknown-linux-gnu-gcc

# works
CC=sparc-unknown-linux-gnu-gcc
CC=x86_64-pc-linux-gnu-gcc
CC=aarch64-unknown-linux-gnu-gcc
CC=armv5tel-softfloat-linux-gnueabi-gcc
CC=hppa-unknown-linux-gnu-gcc
CC=hppa2.0-unknown-linux-gnu-gcc
CC=m68k-unknown-linux-gnu-gcc
CC=mips-unknown-linux-gnu-gcc
CC=nios2-unknown-linux-gnu-gcc
CC=powerpc-unknown-linux-gnu-gcc
CC=powerpc64-unknown-linux-gnu-gcc
CC=powerpc64le-unknown-linux-gnu-gcc
CC=s390x-unknown-linux-gnu-gcc
CC=sh4-unknown-linux-gnu-gcc

Note 2:

If we change
struct s { u64 a; };
struct s glo_s[] = {
to
u64 glo_s[] = {
gcc will generate correct code.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #16 from Andrew Jenner  ---
I have committed a patch to the .opt files:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00114.html

I have also submitted a patch to the documentation:
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00115.html

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[alexander.nesterovskiy at intel dot com]

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

--- Comment #24 from Alexander Nesterovskiy  ---
Yes, it looks like more time is being spent in synchronizing.
r256990 really changes the way autopar works:
For r253679...r256989 the most of work was in main thread0 mostly (thread0
~91%, threads1-3 ~3% each one).
For r256990 there is the same distribution as for r253678 (thread0 ~34%,
threads1-3 ~22% each one) but a lot of time is being spent spinning.
I've attached a chart comparing r253678 and r256990 in the same time scale
(~0.5 sec).
libgomp.so.1.0.0 code executed in thread1 for both cases is wait functions, and
for r256990 they are called more often.

Setting OMP_WAIT_POLICY doesn't change a lot:
for ACTIVE - performance is nearly the same as default
for PASSIVE - there is a serious performance drop for r256990 (looks reasonable
because of a lots of threads sleeps/wake-ups)

Changing parloops-schedule also have no positive effect:
r253678 performance is mostly the same for static, guided and dynamic
r256990 performance is best with static, which is default

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[alexander.nesterovskiy at intel dot com]

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

--- Comment #23 from Alexander Nesterovskiy  ---
Created attachment 43326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43326=edit
r253678 vs r256990

[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load

[ebotcazou at gcc dot gnu.org]

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

--- Comment #22 from Eric Botcazou  ---
> So MIPS fundamentally needs this feature to work correctly; whether AArch64
> needs it or may just benefit from it depends on a lot of detailed knowledge
> of the ISA and architecture. Given Richard Sandiford is currently working on
> ARM ports but also fully understands the MIPS arch then he may be a good
> person to consult.

If "this feature" is WORD_REGISTER_OPERATIONS, then I don't think that any
target, including MIPS, really needs it.  Defining the macro is only an
optimization and a way to convey multiple properties of the target with only
one setting.  And, for MIPS, the implementation of the sign-extension invariant
is done by other means.

[Bug c++/84182] [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-02-02
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |8.0

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c/84108] [8 Regression] incorrect -Wattributes warning for packed/aligned conflict on struct members

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Feb  2 16:42:46 2018
New Revision: 257339

URL: https://gcc.gnu.org/viewcvs?rev=257339=gcc=rev
Log:
PR c++/84181 - ICE with lambda parm in template argument.

* tree.c (strip_typedefs_expr): Use cp_tree_operand_length.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-targ1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c

[Bug c++/77712] int() is incorrectly treated as a null pointer constant in C++11 and later

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-09-23 00:00:00 |2018-2-2

--- Comment #1 from Jonathan Wakely  ---
This should be accepted in C++03 mode but rejected in C++11 and later (as I
think we treat DR 903 as a DR against C++11)

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |8.0

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/84169] [8 Regression] wrong code with u128 multiplication result at aarch64 -O

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Confirmed.  Does not happen with a compiler a few months old.

[Bug testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #16 from Georg-Johann Lay  ---
Author: gjl
Date: Fri Feb  2 15:07:37 2018
New Revision: 257333

URL: https://gcc.gnu.org/viewcvs?rev=257333=gcc=rev
Log:
PR testsuite/52641
* gcc.c-torture/execute/pr83362.c: Make work for int16.
* gcc.dg/Wsign-conversion.c: Dito.
* gcc.dg/attr-alloc_size-4.c: Dito.
* gcc.dg/pr81020.c: Dito.
* gcc.dg/pr81192.c: Dito.
* gcc.dg/pr83463.c (dg-options): Add -Wno-pointer-to-int-cast.
* gcc.dg/attr-alloc_size-11.c: Also special-case avr.
* gcc.dg/pr83844.c: Restrict to int32plus.
* gcc.dg/attr-alloc_size-3.c: Restrict to size32plus.
* gcc.dg/tree-ssa/ldist-25.c: Dito.
* gcc.dg/tree-ssa/ldist-27.c: Dito.
* gcc.dg/tree-ssa/ldist-28.c: Dito.
* gcc.dg/tree-ssa/ldist-29.c: Dito.
* gcc.dg/tree-ssa/ldist-30.c: Dito.
* gcc.dg/tree-ssa/ldist-31.c: Dito.
* gcc.dg/tree-ssa/ldist-32.c: Dito.
* gcc.dg/tree-ssa/ldist-33.c: Dito.
* gcc.dg/tree-ssa/ldist-34.c: Dito.
* gcc.dg/tree-ssa/ldist-35.c: Dito.
* gcc.dg/tree-ssa/ldist-36.c: Dito.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr83362.c
trunk/gcc/testsuite/gcc.dg/Wsign-conversion.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
trunk/gcc/testsuite/gcc.dg/pr81020.c
trunk/gcc/testsuite/gcc.dg/pr81192.c
trunk/gcc/testsuite/gcc.dg/pr83463.c
trunk/gcc/testsuite/gcc.dg/pr83844.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-25.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-27.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-28.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-29.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-30.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-31.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-32.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-33.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-34.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-35.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-36.c

[Bug c++/82734] -Wignored-qualifiers is maybe too strict when using decltype

[sylvestre at debian dot org]

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

--- Comment #3 from Sylvestre Ledru  ---
For people who are getting these error, we fixed it with:
static_cast::type>(INT32_MAX)

[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning

[gcc at gmch dot uk]

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

--- Comment #6 from Chris Hall  ---
Created attachment 43325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43325=edit
Summary of results using Compiler Explorer: for v5.4.0, 6.3.0 and 7.2.0.

Setting -O2 or -O3 on the command line appears to imply -falign-functions=16
and -falign-loops=n, where n is at least 10 but less than 14.

Setting -falign-functions=32 on the command line does the requested alignment,
plus the implied -falign-loops=n for -O2 and -O3 -- except for -Os, which does
no alignment

Setting both -falign-functions=32 and -falign-loops=32 on the command line does
both requested alignments -- except for -Os which does neither and -O0 which
does only the function alignment.

So far, so good.

One might hope that using _Pragma() would have the same effect as the command
line -falign-functions=32 and -falign-loops=32.  Sadly, this is not the case. 
As reported, v7 rejects the pragmas.  But I find that v5.4.0 and v6.3.0, (a)
don't always do the same thing and (b) don't always align loops as requested.

In particular: for -O2 and -O3, setting both align-functions=32 and
align-loops=32 by _Pragma() will: align functions as requested, BUT loops are
aligned to 8 (which is less than useful) !!  

The last set of results looks at compiling with command line -O0 through to -O3
(including -Og and -Os), with _Pragma() for -O3, align-functions=32 and
align-loops=32.  The _Pragma() for -O3 seems to override the command line as
far as this small test is concerned, except for -fomit-frame-pointer.  Sadly,
align-loops=32 is still broken.

[Bug bootstrap/84153] Bootstrap failure when using dependency libraries in non-system location

[bneumeier at gmail dot com]

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

--- Comment #4 from Brett Neumeier  ---
Created attachment 43324
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43324=edit
Patch to add rpath for GMP, MPC, MPFR, ISL when needed

OK. I'm just going to leave this patch here -- tested and verified to resolve
my issues I'm having -- for anyone else who runs across this problem and
happens to check the gcc bugzilla to see if it's a known problem.

I was interested to see that the GMP, MPC, MPFR, and ISL configure scripts all
have logic to add RPATHs as well, although the logic there is a good deal more
complicated than this. So at least I'm in good company thinking it's The Right
Thing to do.

Cheers!

[Bug target/59865] gnu multiversion calculates wrong target

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Eric Gallager from comment #3)
> > 
> > I can't reproduce this bug due to my target lacking ifunc support. Someone
> > with a more capable target will need to test to be able to move this bug out
> > of WAITING.
> 
> Now that I have access to the gcc compile farm, I have been able to test on
> x86_64-pc-linux-gnu, and I get an assemble failure instead of an executable:
> 
> egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -S -Wall -Wextra
> egallager@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc 59865.C -o 59865.exe
> /tmp/cc2p5hY8.s: Assembler messages:
> /tmp/cc2p5hY8.s:158: Error: unrecognized symbol type "gnu_indirect_function"
> egallager@gcc12:~$ grep movl 59865.s | grep foov
>   movl$_Z3foov.popcnt, %eax
>   movl$_Z3foov.arch_corei7, %eax
>   movl$_Z3foov, %eax
> egallager@gcc12:~$

Closing since it's been in WAITING for so long with no response

[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #34 from Eric Gallager  ---
So, since backports were requested for 5 and 6, and the 5 branch is closed now,
and the backport for 6 is already done, I'm going to close this as FIXED now.

[Bug c/84173] Support glibc multiarch interpreter names

[adconrad at 0c3 dot net]

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

--- Comment #7 from Adam Conrad  ---
(In reply to Javier Serrano Polo from comment #6)
> 
> > the discussion about names is probably more appropriate on the libc side
> 
> Adam, do you agree?

I agree with this statement, sure.  But I don't agree that there's any point in
having the discussion.  Essentially, you're asking for one of two possible
things here, as I see it:

1) We come up with a new set of interpreter paths, and have a
--break-abi-with-alternate-paths build option, or

2) We don't come up with any list, and have a
--break-abi-with-arbitrary-interpreter=/path option.

I don't see how providing options that encourage users to shoot themselves so
readily in their feet is a useful thing to do.   Sure, 99% of users never build
either gcc or glibc, and thus this is entirely hidden to them, but I still
don't see why the 0.0001% that deeply care about moving the interpreter on
their system can't just patch glibc and gcc in the two places necessary to make
that happen, rather than publishing a config interface that makes it look like
a supportable option in the toolchains that define those ABIs.

[Bug tree-optimization/39612] [6/7/8 Regression] LIM inserts loads from uninitialized local memory

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #29 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #11)
> Re-confirmed on trunk with the testcase in comment #4 and -Os:
> 
> > ./cc1 -quiet t.c -Os -Wall -fdump-tree-all
> t.c: In function 'f2':
> t.c:4:11: warning: 'inter[0]' is used uninitialized in this function
> [-Wuninitialized]
> t.c:4:11: warning: 'inter[1]' is used uninitialized in this function
> [-Wuninitialized]
> 
> There is also a store data-race introduced by LIM when the loop header
> is not copied.  I suppose the real fix is to disable SM if the loop
> header is not copied.

The warning is gone for the testcase in comment #4:

abulafia:/build/t/gcc$ ./cc1 b.c -Os -Wall -quiet -fdump-tree-all
abulafia:/build/t/gcc$ ./cc1 b.c -O2 -Wall -quiet -fdump-tree-all

But the load from maybe-uninitialized memory is still there.  This is lim2:

f2 (int * dst, int R)
{
  _Bool inter_I_lsm.3;
  int inter_I_lsm.2;
  _Bool inter_I_lsm.1;
  int inter_I_lsm.0;
  int inter[2];
  int i;

   [local count: 118111601]:
  inter_I_lsm.0_16 = inter[0]; // unconditional load outside loop
  inter_I_lsm.1_17 = 0;
  inter_I_lsm.2_18 = inter[1]; // unconditional load outside loop
  inter_I_lsm.3_19 = 0;
  goto ; [100.00%]

Reconfirmed, I guess?

[Bug target/84124] FAIL: gcc.target/i386/pr80969-4.c execution test

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
[hjl@gnu-skx-1 gcc]$ make check-gcc
RUNTESTFLAGS="--target_board='unix{-march=native}' i386.exp=pr80969-4*.c"
rm -rf testsuite/gcc-parallel
make[1]: Entering directory '/export/build/gnu/gcc-test/build-x86_64-linux/gcc'
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd /export/gnu/import/git/sources/gcc/gcc; ${PWDCMD-pwd}` ; export
srcdir ; \
if [ -n "" ] \
   && [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] \
   && [ -f testsuite/gcc-parallel/finished ]; then \
  rm -rf testsuite/gcc; \
else \
  cd testsuite/gcc; \
  rm -f tmp-site.exp; \
  sed '/set tmpdir/ s|testsuite$|testsuite/gcc|' \
< ../../site.exp > tmp-site.exp; \
  /bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
  EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
  if [ -f ${rootme}/../expect/expect ] ; then  \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; \
  fi ; \
  `if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gcc
--target_board='unix{-march=native}' i386.exp=pr80969-4*.c; \
  if [ -n "$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch ${rootme}/testsuite/gcc-parallel/finished; \
  fi ; \
fi )
WARNING: Couldn't find the global config file.
Test run by hjl on Fri Feb  2 05:44:49 2018
Native configuration is x86_64-pc-linux-gnu

=== gcc tests ===

Schedule of variations:
unix/-march=native

Running target unix/-march=native
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /export/gnu/import/git/sources/gcc/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/i386.exp ...
FAIL: gcc.target/i386/pr80969-4.c execution test
FAIL: gcc.target/i386/pr80969-4a.c execution test
FAIL: gcc.target/i386/pr80969-4b.c execution test

=== gcc Summary ===

# of expected passes3
# of unexpected failures3
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc  version 8.0.1 20180202
(experimental) (GCC) 

make[1]: Leaving directory '/export/build/gnu/gcc-test/build-x86_64-linux/gcc'
[hjl@gnu-skx-1 gcc]$

[Bug c/84173] Support glibc multiarch interpreter names

[javier--1JjCLmwH3DOs1h35RYKsyJrkQzDNHN at jasp dot net]

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

--- Comment #6 from Javier Serrano Polo  ---
> As long as the new behavior is optional (not the default), the patch stands a 
> chance of being accepted.
Thank you. I will change the status of the report if you do not mind.

> the discussion about names is probably more appropriate on the libc side
Adam, do you agree?

[Bug c++/82711] -Wignored-qualifiers could be moved into -Wextra

[sylvestre at debian dot org]

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

--- Comment #3 from Sylvestre Ledru  ---
Jonathan, if I write a patch to implement the change, will you accept it?

[Bug middle-end/46989] Mixing "-fprofile-arcs -ftest-coverage" and OpenMP triggers a bug

[sylvestre at debian dot org]

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

Sylvestre Ledru  changed:

   What|Removed |Added

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

--- Comment #3 from Sylvestre Ledru  ---
Open for 7 years, no action but no duplicate, I think I can close it.

[Bug c/84183] New: internal compiler error: in initialize, at alloc-pool.h:257

[tplank at gmx dot at]

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

Bug ID: 84183
   Summary: internal compiler error: in initialize, at
alloc-pool.h:257
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tplank at gmx dot at
  Target Milestone: ---

Created attachment 43323
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43323=edit
config log

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-cygwin/7.2.0/lto-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../gcc-7.2.0/configure --enable-threads
--enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-sjlj-exceptions
--with-mpc=/usr/local --with-isl=/usr/local --with-mpfr=/usr/local
--with-gmp=/usr/local
Thread model: posix
gcc version 7.2.0 (GCC)


I'm trying to build GCC 7.3.0 on the same platform as above (7.2.0 worked).

I'm getting the following error:

cc1: internal compiler error: in initialize, at alloc-pool.h:257
Please submit a full bug report,
with preprocessed source if appropriate.

This is my first attempt to file such a report.


==

Here's the make log:

[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/cygdrive/f/buildgcc730'
make[2]: Entering directory '/cygdrive/f/buildgcc730'
make[3]: Entering directory '/cygdrive/f/buildgcc730'
rm -f stage_current
make[3]: Leaving directory '/cygdrive/f/buildgcc730'
make[2]: Leaving directory '/cygdrive/f/buildgcc730'
make[2]: Entering directory '/cygdrive/f/buildgcc730'
make[3]: Entering directory '/cygdrive/f/buildgcc730/libiberty'
make[3]: Entering directory '/cygdrive/f/buildgcc730/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/f/buildgcc730/intl'
make[3]: Entering directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty'
make[4]: Entering directory '/cygdrive/f/buildgcc730/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/cygdrive/f/buildgcc730/libiberty/testsuite'
make[3]: Leaving directory '/cygdrive/f/buildgcc730/libiberty'
make[4]: Entering directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty/testsuite'
make[3]: Entering directory '/cygdrive/f/buildgcc730/zlib'
true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g" "CXXFLAGS=-g"
"CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install
-c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install
-c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-static-libstdc++
-static-libgcc -Wl,--stack,12582912" "LIBCFLAGS=-g -O2"
"LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo
--split-size=500 --split-size=500 --split-size=500 " "PICFLAG="
"PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/share/info"
"libdir=/usr/local/lib" "prefix=/usr/local"
"tooldir=/usr/local/x86_64-unknown-cygwin" "AR=ar" "AS=as" "CC=gcc" "CXX=g++
-std=gnu++98"
"LD=/usr/local/lib/gcc/x86_64-unknown-cygwin/7.2.0/../../../../x86_64-unknown-cygwin/bin/ld.exe"
"LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all
multi-do # make
make[3]: Leaving directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libiberty'
make[3]: Leaving directory '/cygdrive/f/buildgcc730/zlib'
make[3]: Entering directory '/cygdrive/f/buildgcc730/libbacktrace'
make[3]: Entering directory '/cygdrive/f/buildgcc730/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/cygdrive/f/buildgcc730/libdecnumber'
make  all-am
make[4]: Entering directory '/cygdrive/f/buildgcc730/libbacktrace'
true  DO=all multi-do # make
make[4]: Leaving directory '/cygdrive/f/buildgcc730/libbacktrace'
make[3]: Leaving directory '/cygdrive/f/buildgcc730/libbacktrace'
make[3]: Entering directory '/cygdrive/f/buildgcc730/lto-plugin'
make  all-am
make[3]: Entering directory '/cygdrive/f/buildgcc730/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[4]: Entering directory '/cygdrive/f/buildgcc730/lto-plugin'
make[3]: Leaving directory '/cygdrive/f/buildgcc730/libcpp'
make[3]: Entering directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/fixincludes'
make[4]: Leaving directory '/cygdrive/f/buildgcc730/lto-plugin'
make[3]: Leaving directory '/cygdrive/f/buildgcc730/lto-plugin'
make[3]: Entering directory
'/cygdrive/f/buildgcc730/build-x86_64-unknown-cygwin/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory

[Bug c/84179] New: -save-temps breaks implicit-fallthrough comment heuristic

[Patrick.Schluter at ec dot europa.eu]

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

Bug ID: 84179
   Summary: -save-temps breaks implicit-fallthrough comment
heuristic
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Patrick.Schluter at ec dot europa.eu
  Target Milestone: ---

The -Wimplicit-fallthrough heuristic to suppress the warning by analyzing
comments does not work when -save-temps is specified. Observed with any level
of the warning.

__attribute__((fallthrough)); is not affected by it.

[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load

[ebotcazou at gcc dot gnu.org]

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

--- Comment #20 from Eric Botcazou  ---
> How is this any different from 32-bit operations in say MIPS? The only
> difference seems to be that MIPS sign-extends 32-bit operations to 64 bit
> while AArch64 zero-extends. If that's correct for MIPS it seems that
> WORD_REGISTER_OPERATIONS only applies to types smaller than SImode.

Interesting question.  One indeed could argue that, if 64-bit MIPS defines it,
then Aarch64 could do it too since they are symmetric wrt sign/zero-extension
but I don't have a definitive answer as I don't really know the history of
WORD_REGISTER_OPERATIONS on MIPS.  Maybe worth a try if this brings measurable
benefits, typically elimination of redundant 32->64 zero-extensions.

[Bug c++/84182] New: [8 Regression] ICE in variadic lambda inside a template when calling a captured lambda

[benni.buch at gmail dot com]

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

Bug ID: 84182
   Summary: [8 Regression] ICE in variadic lambda inside a
template when calling a captured lambda
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

template < typename ... T > void sink(T ...){}

template < typename >
void f(){
auto const lambda = [](int){ return 1; };

[lambda](auto ... i){
sink(lambda(i) ...);
}(1);
}

int main(){
f< int >();
}


$ g++ -std=c++14 main.cpp   
main.cpp: In instantiation of 'f() [with  =
int]::<lambda(auto:1 ...)> [with auto:1 = {int}]':
main.cpp:9:6:   required from 'void f() [with  = int]'
main.cpp:13:14:   required from here
main.cpp:7:24: internal compiler error: in lookup_template_class_1, at
cp/pt.c:8957
 [lambda](auto ... i){
^
0x612f6a lookup_template_class_1
../../gcc/gcc/cp/pt.c:8957  
0x612f6a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)   
../../gcc/gcc/cp/pt.c:9167  
0x940d5a tsubst_aggr_type   
../../gcc/gcc/cp/pt.c:12073 
0x93873f tsubst_copy
../../gcc/gcc/cp/pt.c:14845 
0x92711d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18059
0x93a8e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14365
0x93a8e4 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:14365
0x941873 tsubst_decl
../../gcc/gcc/cp/pt.c:13111
0x939eef tsubst_copy
../../gcc/gcc/cp/pt.c:14890
0x925ee0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18266
0x9275de tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17663
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x9436b2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x9436b2 gen_elem_of_pack_expansion_instantiation
../../gcc/gcc/cp/pt.c:11175
0x9436b2 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11683
0x927ded tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17684
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x933970 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16059
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
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.



Known to work with GCC 6.3 and 5.4:

$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 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.

$ g++-5 --version
g++-5 (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
Copyright (C) 2015 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 target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug c/84173] Support glibc multiarch interpreter names

[adconrad at 0c3 dot net]

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

--- Comment #5 from Adam Conrad  ---
(In reply to Javier Serrano Polo from comment #1)
> Adam, if you had to come up with multiarch interpreter names for traditional
> architectures, which would be the proper place to discuss?

As Andrew says, the ABI is fixed.  I understand that you run a kernel
patch/module to alias interpreters to other paths, but this isn't something we
can or should support upstream.

If I had a time machine, I could give you a list of interpreter names I would
have argued for two decades ago.  I don't have a time machine and, thus, such a
discussion is pointless and, frankly, now that you've dragged me into this in
three different forums, tiresome.

[Bug rtl-optimization/84071] [7/8 regression] wrong elimination of zero-extension after sign-extended load

[mpf at gcc dot gnu.org]

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

mpf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mpf at gcc dot gnu.org

--- Comment #21 from mpf at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #20)
> > How is this any different from 32-bit operations in say MIPS? The only
> > difference seems to be that MIPS sign-extends 32-bit operations to 64 bit
> > while AArch64 zero-extends. If that's correct for MIPS it seems that
> > WORD_REGISTER_OPERATIONS only applies to types smaller than SImode.
> 
> Interesting question.  One indeed could argue that, if 64-bit MIPS defines
> it, then Aarch64 could do it too since they are symmetric wrt
> sign/zero-extension
> but I don't have a definitive answer as I don't really know the history of
> WORD_REGISTER_OPERATIONS on MIPS.

I believe the critical part for MIPS is that our 32-bit instructions do care
what the upper 32-bits of a 64-bit register contain. It is undefined if they
operate on a non-canonical 32-bit form and the instructions that are width
agnostic (conditional branch and logical ops) rely on canonical forms to work
correctly with 32-bit values.

So MIPS fundamentally needs this feature to work correctly; whether AArch64
needs it or may just benefit from it depends on a lot of detailed knowledge of
the ISA and architecture. Given Richard Sandiford is currently working on ARM
ports but also fully understands the MIPS arch then he may be a good person to
consult.

[Bug target/83370] [AARCH64]Tailcall register may be corrupted by epilogue code

[renlin at gcc dot gnu.org]

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

Renlin Li  changed:

   What|Removed |Added

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

--- Comment #6 from Renlin Li  ---
(In reply to Richard Earnshaw from comment #3)
> Doesn't this need backporting?


Yes, it is needed. The same problem happens in gcc-6 and gcc-7.
The backporting is approved and committed now.

[Bug c++/84181] [8 Regression] ICE in variadic lambda inside a template when accessing any member after decltype

[benni.buch at gmail dot com]

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

--- Comment #1 from Benjamin Buch  ---
Same with:


template < int ... I >
struct A{};

template < typename T >
void f(){
[](auto ... i){
return A< decltype(i)::x ... >{};
};
}

int main(){
f< int >();
}


$ g++ -std=c++14 main2.cpp 
main2.cpp: In instantiation of 'void f() [with T = int]':
main2.cpp:12:14:   required from here
main2.cpp:7:40: internal compiler error: in strip_typedefs_expr, at
cp/tree.c:1690
 return A< decltype(i)::x ... >{};
^
0x63696d strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1690
0x997709 strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1795
0x90f33c canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7489
0x9477db canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7486
0x9477db convert_template_argument
../../gcc/gcc/cp/pt.c:7823
0x945ada coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7971
0x945ada coerce_template_parms
../../gcc/gcc/cp/pt.c:8191
0x93f2b6 lookup_template_class_1
../../gcc/gcc/cp/pt.c:8818
0x93f2b6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9167
0x940d5a tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12073
0x93b27e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926e14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b9b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b9b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927498 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/84181] New: [8 Regression] ICE in variadic lambda inside a template when constructing a decltype type

[benni.buch at gmail dot com]

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

Bug ID: 84181
   Summary: [8 Regression] ICE in variadic lambda inside a
template when constructing a decltype type
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benni.buch at gmail dot com
  Target Milestone: ---

This is a very serious regression because it affects Boost.Hana directly.


template < int ... I >
struct A{};

template < typename T >
void f(){
[](auto ... i){
return A< decltype(i){} ... >{};
};
}

int main(){
f< int >();
}


$ g++ -std=c++14 main.cpp 
main.cpp: In instantiation of 'void f() [with T = int]':
main.cpp:12:14:   required from here
main.cpp:7:39: internal compiler error: in strip_typedefs_expr, at
cp/tree.c:1690
 return A< decltype(i){} ... >{};
   ^
0x63696d strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1690
0x997709 strip_typedefs_expr(tree_node*, bool*)
../../gcc/gcc/cp/tree.c:1795
0x90f33c canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7489
0x9477db canonicalize_expr_argument
../../gcc/gcc/cp/pt.c:7486
0x9477db convert_template_argument
../../gcc/gcc/cp/pt.c:7823
0x945ada coerce_template_parameter_pack
../../gcc/gcc/cp/pt.c:7971
0x945ada coerce_template_parms
../../gcc/gcc/cp/pt.c:8191
0x93f2b6 lookup_template_class_1
../../gcc/gcc/cp/pt.c:8818
0x93f2b6 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:9167
0x940d5a tsubst_aggr_type
../../gcc/gcc/cp/pt.c:12073
0x93b27e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13706
0x926e14 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x934e49 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17100
0x934e49 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16838
0x932ea0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16055
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x931f61 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16322
0x925b9b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16030
0x925b9b tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:17056
0x927498 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18346
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ g++ --version
g++ (GCC) 8.0.1 20180202 (experimental)
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.


Known to work with GCC 6.3 and 5.4:

$ g++-6 --version
g++-6 (Ubuntu/Linaro 6.3.0-18ubuntu2~16.04) 6.3.0 20170519
Copyright (C) 2016 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.

$ g++-5 --version
g++-5 (Ubuntu 5.4.1-2ubuntu1~16.04) 5.4.1 20160904
Copyright (C) 2015 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 testsuite/52641] Test cases fail for 16-bit int targets

[gjl at gcc dot gnu.org]

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

--- Comment #15 from Georg-Johann Lay  ---
Author: gjl
Date: Fri Feb  2 11:36:54 2018
New Revision: 257327

URL: https://gcc.gnu.org/viewcvs?rev=257327=gcc=rev
Log:
PR testsuite/52641
* gcc.c-torture/execute/pr81913.c: Use types that also work for int16.
* gcc.c-torture/execute/20180112-1.c: Dito.
* gcc.c-torture/execute/pr81503.c: Dito.
* gcc.dg/store_merging_12.c: Dito.
* gcc.dg/tree-ssa/loop-niter-1.c: Dito.
* gcc.dg/tree-ssa/loop-niter-2.c: Dito.
* gcc.dg/tree-ssa/pr80898.c: Dito.
* gcc.dg/tree-ssa/pr82363.c: Dito.
* gcc.dg/utf16-4.c: Also allow "short unsigned int" in dg-warning.
* gcc.dg/tree-ssa/pr81346-5.c: Special-case int16.
* gcc.dg/tree-ssa/ssa-sink-11.c: Dito.
* gcc.dg/tree-ssa/ssa-sink-12.c: Dito.
* gcc.dg/torture/pr81814.c: Restrict to int32plus.
* gcc.dg/tree-ssa/pr80803.c: Dito.
* gcc.dg/tree-ssa/pr80898-2.c: Dito.
* gcc.dg/tree-ssa/pr81346-4.c: Dito.
* gcc.dg/tree-ssa/vrp114.c: Dito.
* gcc.dg/tree-ssa/pr82574.c: Restrict to size32plus.
* gcc.dg/tree-ssa/ssa-dom-thread-13.c: Dito.
* gcc.dg/tree-ssa/ssa-sink-15.c: Dito.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/20180112-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr81503.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr81913.c
trunk/gcc/testsuite/gcc.dg/store_merging_12.c
trunk/gcc/testsuite/gcc.dg/torture/pr81814.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-niter-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80803.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr80898.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81346-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82363.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82574.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-13.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-11.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-15.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp114.c
trunk/gcc/testsuite/gcc.dg/utf16-4.c

[Bug c/84180] New: -Wimplicit-fallthrough=2 heuristic fails when condition in the case

[Patrick.Schluter at ec dot europa.eu]

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

Bug ID: 84180
   Summary: -Wimplicit-fallthrough=2 heuristic fails when
condition in the case
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Patrick.Schluter at ec dot europa.eu
  Target Milestone: ---

A case containing a condition recognizes that it may fall through but the
heuristic to suppress the warning doesn't work at level 2. IMO it should.

Simple example to trigger the behaviour

case OPEN_FILE:
  if( !access(name, F_OK)) {
...
break;
  }
  /* fallthrough */
case CREATE_FILE:
  ...

The warning is suppressed only at level 1 of the -Wimplicit-fallthrough=
option.

[Bug target/84066] Wrong shadow stack register size is saved for x32

[itsimbal at gcc dot gnu.org]

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

--- Comment #8 from itsimbal at gcc dot gnu.org ---
Author: itsimbal
Date: Fri Feb  2 10:06:39 2018
New Revision: 257326

URL: https://gcc.gnu.org/viewcvs?rev=257326=gcc=rev
Log:
PR84066 Wrong shadow stack register size is saved for x32

x32 is a 64-bit process with 32-bit software pointer and kernel may
place x32 shadow stack above 4GB.  We need to save and restore 64-bit
shadow stack register for x32. builtin jmp buf size is 5 pointers.  We
have space to save 64-bit shadow stack pointers: 32-bit SP, 32-bit FP,
32-bit IP, 64-bit SSP for x32.

PR target/84066
* gcc/config/i386/i386.md: Replace Pmode with word_mode in
builtin_setjmp_setup and builtin_longjmp to support x32.
* gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c: New test.
* gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6a.c
trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug web/84167] bugzilla should have a "next bug" button

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On February 1, 2018 8:05:26 PM GMT+01:00, LpSolit at netscape dot net
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84167
>
>Frédéric Buclin  changed:
>
>   What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> Resolution|--- |WORKSFORME
>
>--- Comment #1 from Frédéric Buclin  ---
>(In reply to Richard Biener from comment #0)
>> I'm currently using the web gcc-bug mailinglist archive to cycle
>through all
>> new bugs each morning.
>
>Instead of doing this, you should click the "Bugs reported in the last
>24
>hours" link on the Bugzilla home page. This will generate a list, and
>the
>Prev/Next link will automatically appear on each bug page.

That does not work reliably in case there are more than 24 hours between
invocations or when you just want to poll 'next'. 

I guess I'll try to look into doing some Greasemonkey script hacking then...

[Bug tree-optimization/84178] New: [7/8 Regression] ICE in release_bb_predicate

[asolokha at gmx dot com]

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

Bug ID: 84178
   Summary: [7/8 Regression] ICE in release_bb_predicate
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180128 snapshot (r257131) and gcc 7.3.0 ICE when compiling the
following snippet w/ -O3 -fno-tree-forwprop:

int zy, h4;

void
r8 (long int mu, int *jr, int *fi, short int dv)
{
  do
{
  int tx;

  tx = !!h4 ? (zy / h4) : 1;
  mu = tx;
  *jr = (((unsigned char) mu > (254 >> dv)) ? 0 : (unsigned char) tx) +
*fi;
} while (*jr == 0);

  r8 (mu, jr, fi, 1);
}

% gcc-8.0.0-alpha20180128 -O3 -fno-tree-forwprop -c rhoqpgf1.c
during GIMPLE pass: ifcvt
rhoqpgf1.c: In function 'r8.constprop':
rhoqpgf1.c:4:1: internal compiler error: in release_bb_predicate, at
tree-if-conv.c:286
 r8 (long int mu, int *jr, int *fi, short int dv)
 ^~
0x664d68 release_bb_predicate
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:286
0x664d68 free_bb_predicate
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:300
0x664d68 tree_if_conversion(loop*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:2897
0xd092e5 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/tree-if-conv.c:2962

gcc 7 ICEs w/ different backtrace, though.

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

[juergen.reuter at desy dot de]

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

--- Comment #26 from Jürgen Reuter  ---
Paul, let me know whether you want me to reduce the "Additional failing test
case" any further. Really have to go to sleep now.