[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

--- Comment #6 from Peter Boyle  ---
Just a comment -- suggest a warning thrown if union access from
two views is made. AFAIK g++ is the only compiler not implementing the
defacto type pun use.

http://en.cppreference.com/w/cpp/language/union

"Many compilers implement, as a non-standard language extension, the ability to
read inactive members of a union."

i.e. warn on attempted use of the above behaviour.

[Bug tree-optimization/80652] [5 Regression] Union conversion between __m128d and double array does not work under 5.0 through 6.2

[paboyle at ph dot ed.ac.uk]

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

Peter Boyle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Peter Boyle  ---
Withdrawing bug report. 

I think this is my misunderstanding of union guarantees in C++ vs C.

I have my own views on the standards committee, but this is not a G++ bug.

[Bug target/80777] gdb sizeof(long int)=4 but gcc sizeof(long int)=8 on x86_64-pc-cygwin

[jrose.manila at gmail dot com]

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

Julian Rose  changed:

   What|Removed |Added

Summary|gdb reports incorrect   |gdb sizeof(long int)=4 but
   |sizeof(long int) on |gcc sizeof(long int)=8 on
   |x86_64-pc-cygwin|x86_64-pc-cygwin

--- Comment #4 from Julian Rose  ---
https://software.intel.com/en-us/articles/size-of-long-integer-type-on-different-architecture-and-os
states sizeof long int varies between architectures and operating systems; in
particular sizeof(long) on IA-64 in Linux is 8 whereas in windows it is 4.

Under Cygwin it appears gcc has been built with the "Linux" memory model, and
gdb has been built with the "Windows" model.

Obviously consistency between gcc and gdb is required for any given platform.
But as cygwin runs on a windows platform, it is not clear if the compiler or
the debugger is "wrong". 

Either way, perhaps a solution may be found in the specs configuration given to
the compiler for the x86_64-pc-cygwin platform.

[Bug rtl-optimization/80693] [6/7/8 Regression] wrong code with -O -fno-tree-coalesce-vars

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Created attachment 41371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41371=edit
patch I'm testing to fix the bug

The problem is that combine creates a single insn with the AND and the compare,
still modifying the same REG that is also an AND operand.  Later, it combines
that two-SETs insn with 2 other insns, an AND and a NOT, dropping the SET that
modified the REG but still referencing the earlier value of that REG.  Then, it
attempts to combine the AND and the NOT, but since it still believes the REG
held the result of an AND with 1, that simplifies to a XOR with 1.  The problem
is that the REG no longer holds the result of the AND, but combine failed to
detach the REG from the value of the dropped SET.  This patch does just that.

[Bug c++/80795] New: Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1

[gufideg at gmail dot com]

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

Bug ID: 80795
   Summary: Cannot take the address of call operator of a variadic
lambda when parameter pack length differs from 1
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gufideg at gmail dot com
  Target Milestone: ---

Hi there, I stumble across this error:

int main() {
auto test = [](auto, auto, auto...) {};
auto ash = (test)::operator();
}

In this case, I expect the pointer to the function to be the one this
expression would call:

[](auto, auto, auto...){}(1, 1);

Leaving the parameter pack empty.
But it fails with this error:

> main.cpp: In function 'int main()':
> main.cpp:3:30: error: unable to deduce 'auto' from '& operator()'
>   auto ash = (test)::operator();
>   ^~~~
> main.cpp:3:30: note:   couldn't deduce template parameter 'auto'

The same happen when Sending two parameter in the pack:

int main() {
auto test = [](auto, auto, auto...) {};
auto ash = (test)::operator();
}

Note that taking the pointer when exactly one parameter fits in the pack, it
compiles fine:

int main() {
auto test = [](auto, auto, auto...) {};
auto ash = (test)::operator();
}

All of the example above compiles fine under clang.

[Bug c/80793] three signed conversion warnings for the same expression

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think GCC is correct in warning about all three.
There are all different issues really with the single statement.

The first warning is most accurate warning for all 4 warnings that are produced
(that includes the clang warning).

The second warning is accurate also because of a?b:c where b and c are int and
unsigned are converted to int and the signed constant was a negative value.

The third and final gcc warning is correct because -__SCHAR_MAX__ - 1 converted
to unsigned int and then to unsigned char will truncate the value.

The warning that clang produces seems even worse and points to the wrong
problem.  Fixing one of GCC warnings might be the wrong thing to do.  And I
don't even understand what clang warning is trying to say because the lhs of
the ?: was of type unsigned int and not unsigned char originally.

[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Found the problem. As part of the DTIO patch we moved last_char from the dtp
structure to the gfc_unit structure so that the last character read would be
buffered across the parent-child procedure boundary.

The presence of a character in this single character buffer is signified
whenever it does not equal EOF-1. When finalizing reads or re-positioning the
file such as in REWIND, we did not clear this buffer and it was holding the
last character read which was EOF.

I will have a full patch soon. Basically we need to put the following in
strategic places:

  u->last_char = EOF - 1;

[Bug target/80777] gdb reports incorrect sizeof(long int) on x86_64-pc-cygwin

[jrose.manila at gmail dot com]

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

Julian Rose  changed:

   What|Removed |Added

Summary|long int structure members  |gdb reports incorrect
   |allocated incorrect 8 bytes |sizeof(long int) on
   ||x86_64-pc-cygwin

--- Comment #3 from Julian Rose  ---
(In reply to Julian Rose from comment #2)
> Hei,
> 
> Yes I thought that initially too. But if you start gdb and print sizeof(long
> int) you get 4, not 8. 
> 
> $ gdb
> GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-cygwin".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) print sizeof(long int)
> $1 = 4
> (gdb) print sizeof(unsigned long int)
> $2 = 4
> (gdb) print sizeof(long long int)
> $3 = 8
> (gdb) q

But I have changed the summary title of this bug to better reflect that a fault
appears to lie with the gdb build and not with gcc.

Would it be appropriate to close this bug report and raise a new one at
https://sourceware.org/bugzilla/?

[Bug tree-optimization/80794] New: constant objects can be assumed to be immutable

[msebor at gcc dot gnu.org]

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

Bug ID: 80794
   Summary: constant objects can be assumed to be immutable
   Product: gcc
   Version: 7.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: ---

Modifying a const object is undefined (1.9, p4 and 3.3, p1.1 of C++17). 
Therefore, valid C++ programs can be relied on not to modify const objects or
subobjects to improve the efficiency of accessing such objects.  For example,
in both function foo and bar in the test case below, GCC can assume that the
value of the s.i member after the call to s.f() is the same as its value before
the call, and eliminate the test for the inequality.

This should also hold for C but I suspect C programs more commonly violate this
constraint than C++ programs do.

$ cat t.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.C
struct S
{
  const int i;

  S (int x): i (x) { }

  void f () const;
};

const S s (123);

void foo ()
{
  int i = s.i;
  s.f ();
  int j = s.i;

  if (i != j) __builtin_abort ();
}

void bar (const S )
{
  int i = s.i;
  s.f ();
  int j = s.i;

  if (i != j) __builtin_abort ();
}


;; Function void foo() (_Z3foov, funcdef_no=3, decl_uid=2318, cgraph_uid=3,
symbol_order=4)

void foo() ()
{
  int j;
  int i;

   [100.00%]:
  i_2 = s.i;
  S::f ();
  j_4 = s.i;
  if (i_2 != j_4)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}



;; Function void bar(const S&) (_Z3barRK1S, funcdef_no=4, decl_uid=2323,
cgraph_uid=4, symbol_order=5)

void bar(const S&) (const struct S & s)
{
  int j;
  int i;

   [100.00%]:
  i_3 = s_2(D)->i;
  S::f (s_2(D));
  j_5 = s_2(D)->i;
  if (i_3 != j_5)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}



;; Function (static initializers for t.C) (_GLOBAL__sub_I__Z3foov,
funcdef_no=6, decl_uid=2332, cgraph_uid=6, symbol_order=7) (executed once)

(static initializers for t.C) ()
{
   [100.00%]:
  MEM[(struct  &)] ={v} {CLOBBER};
  s.i = 123;
  return;

}

[Bug c/80793] New: three signed conversion warnings for the same expression

[msebor at gcc dot gnu.org]

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

Bug ID: 80793
   Summary: three signed conversion warnings for the same
expression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In a review of an implementation of a new -Wenum-conversion warning
(https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00142.html) I brought up a
concern over the proliferation of warning options targeting closely related and
sometimes even overlapping problems.  This is an extreme example of one such
problem.  The following test case, extracted from the one on line 44 of
gcc.dg/Wsign-conversion.c, triggers three distinct yet closely related
warnings.  Also worth noting are the different ways of what boils down to the
same problem (but that's a separate issue, tracked in bug 80731).

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wconversion t.c
int f (int i)
{
  unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;
  return c;
}
t.c: In function ‘f’:
t.c:3:46: warning: signed and unsigned type in conditional expression
[-Wsign-compare]
   unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;
  ^
t.c:3:46: warning: negative integer implicitly converted to unsigned type
[-Wsign-conversion]
t.c:3:21: warning: conversion to ‘unsigned char’ alters ‘unsigned int’ constant
value [-Wconversion]
   unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;
 ^


In contrast, Clang issues the following:

$ clang -S -Wall -Wextra -Wpedantic -Weverything t.c
t.c:3:41: warning: operand of ? changes signedness: 'int' to 'unsigned char'
  [-Wsign-conversion]
  unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U;
~~~~^~~
t.c:1:5: warning: no previous prototype for function 'f' [-Wmissing-prototypes]
int f (int i)
^
2 warnings generated.

[Bug c/80777] long int structure members allocated incorrect 8 bytes

[jrose.manila at gmail dot com]

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

Julian Rose  changed:

   What|Removed |Added

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

--- Comment #2 from Julian Rose  ---
Hei,

Yes I thought that initially too. But if you start gdb and print sizeof(long
int) you get 4, not 8. 

$ gdb
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) print sizeof(long int)
$1 = 4
(gdb) print sizeof(unsigned long int)
$2 = 4
(gdb) print sizeof(long long int)
$3 = 8
(gdb) q

[Bug c/80692] _Decimal64 -0 != 0 unless optimization is turned off

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  The problem happens during ccp1 already:

===
Substituting values and folding statements

Folding statement: if (d64_1 != 0)
gimple_simplified to if (1 != 0)
which is likely CONSTANT
Folding predicate 1 != 0 to 1
Folded into: if (1 != 0)
===

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2017-05/msg01332.ht
   ||ml

--- Comment #9 from Peter Bergner  ---
Patch submitted.

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[babokin at gmail dot com]

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

--- Comment #8 from Dmitry Babokin  ---
Many failing tests are fixed, but quite few still failing. Should I add failing
test cases here or create a separate bug?

[Bug c++/80792] New: worse code generated compared to clang when using std::tuple

[dvd at gnx dot it]

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

Bug ID: 80792
   Summary: worse code generated compared to clang when using
std::tuple
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dvd at gnx dot it
  Target Milestone: ---

This code:

#include 

// mimic std facility
template 
struct index_sequence {};

// inferior tuple, used to rule out std::tuple
struct tuple {
  tuple(float v) : x{v} {}
  float x;
};

template 
auto make_tuple(T&&... args) {
  return tuple(std::forward(args)...);
}

template 
struct converter;

template <>
struct converter {
  static float convert(const char* t) {
return std::atof(t);
  }
};

template 
auto execute_helper(char* value) {
  return converter::convert(value);
}

template 
auto construct_tuple(char** values, index_sequence) {
 return std::make_tuple(execute_helper(values[Index])...);
 // return make_tuple(execute_helper(values[Index])...);
}

template 
auto construct_tuple(char** values) {
  return construct_tuple(values, index_sequence<0>());
}

template 
auto executex(char** values) {
return construct_tuple(values);
}

auto g(char** v) {
  return executex(v);
}

produces the following assembler (gcc 7.1):

g(char**):
mov rax, rsi
pushrbx
mov rbx, rdi
mov rdi, QWORD PTR [rax]
xor esi, esi
callstrtod
pxorxmm1, xmm1
mov rax, rbx
cvtsd2ssxmm1, xmm0
movss   DWORD PTR [rbx], xmm1
pop rbx
ret

while the clang output is shorter (clang trunk):

g(char**):
pushrax
mov rdi, qword ptr [rdi]
xor esi, esi
callstrtod
cvtsd2ssxmm0, xmm0
pop rax
ret

you can see it live on godbolt.org:
https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAKxAEZSBnVAV2OUxAHIBSAJgGY8AO2QAbZlgDU3fgGECzAA6jMM7NwAMAQU1aCmALbKAhvulyGeAF6YA%2BgQB0TgCprdDAsWbICk4VgAPWwZMAEdmTBFMaQB2ACFuGIARGQTtXX0jUVNomXkAT0VI4wNo1351bQ8vH0k0IQA3TGJ9YlTdd09vXwVlXPjdSUlelQgAM1FUU0kGgEpJEEkAxLiGxKTYhOTByQmp32X%2BNJ1to47tTJMzPIJC4tKnB0lyyq1jZiJJA2MAazsRzAQVy8ABsfBBj0kxmIwAY8xWO2ImAUxCEwyUKhWHnQIBAYxIAHdoeg8i8INDYbNHut2ultultENLtlrnI3FUurV6k0Ws08ntTGpNjsPKY8MhdpNptzmgQIPUPHUENCAFTDeEDRlDSRIlFo7G40yoMYQAizWlaIY0ukpM4MvSGK65OS3IpCEpldlvD6oSSYAKYZAfOwITCiIrEeXK4hqhrGcSYDXHIa61homW8tpyF64jNyuMJ812k4pe3MnLmApuj2Q2SocQGIQMUiSSw2eyQgCSQkCXvenwVnII9gxgOQ0ZVsfjEWbfh7/uCYQiUTy3cC1IqScRyLTrYIOJA3z%2BI76EH9geDtlD4b5cjrDabaggBZn3AArHE1/730kqU4i8mkgAPRAamqJfL8/yjmeAZBvoV5hhGeT3swjYME%2BL6YOhH5fssb6/o8AEdPSOgXI6LLOlW9yYLW9aoY%2BFS6P2vqDjUw4AlGqpTgmcLClqYHpqgTZDiemJ3nRaEbtgz7TlhLb%2BAuIThJE7B5BoT6zERNrnA6WQVjcdzug8TiSChaF9j6fqwcGAScTG3EzluWopju4Gsd0omqOJD4MFJMk8VpJY6cxkjAHZk4zE5lo6q5aLnnB35yAKBAYYF6ycLMpCiFwb6cKQQhcBoeWoFwsh8AkvBxK2LBsLkAi0HlBCFRlmU/CA/D8A4HXdT1vUgllXAACx5QVnBFaQJWcHlDAgBopBNWNGWkHAsBIGgRh4CoZAUPKqAbVtIDADE9BjJtrQzRAABGzWkOtpRCAQADyQiiPkN34EiPh4E0M2LeQD1hs1mWoIoBB4EJv0ALSPfwkiQ9iMhJMg5XlbQVjTTV7B0Jl2WcLl%2BU3ZNAQABwgpDIKDaFyASjEDi0JIEC4IQJDSPVLZ1vtzSs/wtCzI1QOte1nW9SL3X9bjw0E39k3TbN81A8tMCICge2KJtzTkJQ61qwdYjGEIwD2F4Qg/KQp2iOdlDXX9d2RE9L1vX9H2BmDP03cI%2Bi40VwOg%2BDTZcNDsPw/uiPI5VqPo4wmMcLzA14yNhNcCTZMU3U2QGwzXQm/MjP4EQxDc/Qpmq%2BrBd8PwvB8/Li2aaQbUdV1osi3HkujeNMuMHLC3ezjXC8An0tcPzNeZTylhCSAg1AA%3D%3D

If you comment the call to std::make_tuple and use my make_tuple both the
compiler produces the same output.

Moreover if you use the std::make_tuple but change the execute_helper to call
directly `std::atof`

template 
auto execute_helper(char* value) {
return std::atof(value);
}


The differences between the two compilers are even more greater

gcc output:

g(char**):
mov rax, rsi
pushrbx
mov rbx, rdi
mov rdi, QWORD PTR [rax]
xor esi, esi
callstrtod
mov rax, rbx
movsd   QWORD PTR [rbx], xmm0
pop rbx
ret

clang output

g(char**):# @g(char**)
mov rdi, qword ptr [rdi]
xor esi, esi
jmp strtod  # TAILCALL

[Bug fortran/80741] [Regression 7/8] DTIO wrong code causes incorrect behaviour of namelist READ

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

Summary|[Regression 7/8] DTIO wrong |[Regression 7/8] DTIO wrong
   |code causes incorrect   |code causes incorrect
   |behaviour of rewind with|behaviour of namelist READ
   |namelist|

--- Comment #4 from Jerry DeLisle  ---
REWIND is a distraction here. The rewind is working fine. The issue is the READ
right after. Still investigating.

[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126

[pthaugen at gcc dot gnu.org]

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

--- Comment #9 from Pat Haugen  ---
(In reply to Martin Liška from comment #8)
> 
> Can you please provide a test-case? Or can you dump the sreal values via
> .to_double() ? That can be also hint for us to fix that properly.

I'm trying to reduce the source, but it's proprietary so will see what it
reduces to before I can think about posting anything. In the meantime, here's
what things look like when the assert fails.

(gdb) p info->self_time
$7 = {m_sig = 1347786301, m_exp = -13}
(gdb) p info->self_time.to_double()
$8 = 164524.69494628906
(gdb) p info->time
$9 = {m_sig = 1347789465, m_exp = -13}
(gdb) p info->time.to_double()
$10 = 164525.08117675781

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

[keith.marshall at mailinator dot com]

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

Keith Marshall  changed:

   What|Removed |Added

 CC||keith.marshall at mailinator 
dot c
   ||om

--- Comment #2 from Keith Marshall  ---
Still broken in GCC-6.3, (and possibly later).

The issue, of course, is that feature test macros, such as UNICODE and
_UNICODE, are *supposed* to be defined *before any* header file -- or at least
before any system header, or any private header which may incidentally include
a system header -- is included; Ada's delegation of these defines, to the
private header "mingw32.h", which is included after other private headers which
themselves *do* include system headers, is a gross violation of, and
non-conformity with, this fundamental (and universal) requirement.

[Bug tree-optimization/80791] New: [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[seurer at gcc dot gnu.org]

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

Bug ID: 80791
   Summary: [8 regression] test case gcc.dg/sms-1.c fail2 starting
with r247885
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

With this revision SMS fails when compiling this test case.

With revision r247884 and earlier we get:

SMS SC already optimized.
SMS schedule branch at cycle ii-1
crr_insn->node=0 (insn id 16), crr_insn->cycle=-1, min_cycle=-1
crr_insn->node=5 (insn id 26), crr_insn->cycle=2, min_cycle=-1
crr_insn->node=3 (insn id 22), crr_insn->cycle=2, min_cycle=-1
crr_insn->node=6 (insn id 43), crr_insn->cycle=2, min_cycle=-1 (branch)
crr_insn->node=1 (insn id 18), crr_insn->cycle=0, min_cycle=-1
crr_insn->node=2 (insn id 21), crr_insn->cycle=0, min_cycle=-1
crr_insn->node=4 (insn id 25), crr_insn->cycle=1, min_cycle=-1
changing bb of uid 64
  unscanned insn
verify found no changes in insn with uid = 43.
Edge 6->6 redirected to 7
 /home/seurer/gcc/gcc-test3/gcc/testsuite/gcc.dg/sms-1.c:24 SMS succeeded 3 2
(with ii, sc)


Starting with revision r247885 we get:

SMS SC already optimized.
SMS schedule branch at cycle ii-1
crr_insn->node=1 (insn id 11), crr_insn->cycle=-1, min_cycle=-2
crr_insn->node=2 (insn id 14), crr_insn->cycle=-1, min_cycle=-2
crr_insn->node=4 (insn id 17), crr_insn->cycle=2, min_cycle=-2
crr_insn->node=7 (insn id 36), crr_insn->cycle=2, min_cycle=-2 (branch)
crr_insn->node=5 (insn id 18), crr_insn->cycle=0, min_cycle=-2
crr_insn->node=3 (insn id 16), crr_insn->cycle=0, min_cycle=-2
crr_insn->node=0 (insn id 9), crr_insn->cycle=-2, min_cycle=-2
crr_insn->node=6 (insn id 19), crr_insn->cycle=1, min_cycle=-2
Scheduling register move INSN 57; ii = 3, min cycle = -2

...more...

Scheduled w/o split in 0
SMS SC already optimized.
SMS schedule branch at cycle ii-1
SMS failed... 
SMS sched-failed (stage-count=1, loop-count=0, trip-count=0)


There is another SMS test with a similar failure but that one has been failing
for a while now:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69992

[Bug sanitizer/80659] [7/8 Regression] -fsanitize=address evokes ICE in in gimplify_switch_expr

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #8 from Paul Eggert  ---
(In reply to jim from comment #5)

Here's a simpler test case that illustrates the same bug (GCC 7.1.0, x86-64,
compiled via "gcc -O2 -S -fsanitize=address v2.i"):

  typedef struct Lisp_Object { long i; } Lisp_Object;
  struct Lisp_String { char *data; };

  Lisp_Object
  server_accept_connection (int sa_family)
  {
switch (sa_family)
  {
  default:;
Lisp_Object x = (Lisp_Object) { (long) &(struct Lisp_String) {">"} + 4
};
return x;
  }
  }

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bill Schmidt  ---
Fixed now.  Thanks, James!

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Tue May 16 20:18:05 2017
New Revision: 248130

URL: https://gcc.gnu.org/viewcvs?rev=248130=gcc=rev
Log:
[gcc]

2017-05-16  James Greenhalgh  
Bill Schmidt  

PR tree-optimization/80457
* tree-vect-stmts.c (vect_model_simple_cost): Model the cost
of all arguments to a statement as scalar_to_vec operations.
(vectorizable_call): Adjust call to vect_model_simple_cost for
new parameter.
(vectorizable_conversion): Likewise.
(vectorizable_assignment): Likewise.
(vectorizable_shift): Likewise.
(vectorizable_operation): Likewise.
(vectorizable_comparison): Likewise.
(vect_is_simple_cond): Record the def types for operands.
(vectorizable_condition): Likewise, call vect_model_simple_cost.
* tree-vectorizer.h (vect_model_simple_cost): Add new parameter
for statement argument count.

[gcc/testsuite]

2017-05-16  James Greenhalgh  
Bill Schmidt  

PR tree-optimization/80457
* gcc.target/powerpc/pr78604.c: Verify that vectorized COND_EXPRs
call vect_model_simple_cost.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr78604.c
trunk/gcc/tree-vect-stmts.c
trunk/gcc/tree-vectorizer.h

[Bug c++/80785] warning for static definitions inside extern "C"

[daniel.gutson at intel dot com]

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

--- Comment #4 from Daniel Gutson  ---
(In reply to Jonathan Wakely from comment #3)
> The usual reason a header has extern "C" is because it's intended for use by
> both C and C++ programs, and in that case restructuring it for the benefit
> of C++ only is probably not very likely. But then static variables in
> headers aren't terribly common anyway, so maybe it's not a problem.

I agree and acknowledge that a header having extern "C" is for including it
from C and C++ files.
I just ran into this issue from a real life situation, where the header file
was a mess mixing static data intended to be "private/local" declarations for
only one of the including files, which was exactly what had to be refactored. A
warning that detects static declarations inside an extern "C" would evidence
this messy situation, triggering the necessary refactor.
It could be, as mentioned, an opt-in warning for projects where this case would
be considered a design or implementation flaw.

[Bug fortran/80554] [f08] variable redefinition in submodule

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Tue May 16 20:09:02 2017
New Revision: 248129

URL: https://gcc.gnu.org/viewcvs?rev=248129=gcc=rev
Log:
2017-05-16  Paul Thomas  

PR fortran/80554
* decl.c (build_sym): In a submodule allow overriding of host
associated symbols from the ancestor module with a new
declaration.

2017-05-16  Paul Thomas  

PR fortran/80554
* gfortran.dg/submodule_29.f08: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_29.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80785] warning for static definitions inside extern "C"

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The usual reason a header has extern "C" is because it's intended for use by
both C and C++ programs, and in that case restructuring it for the benefit of
C++ only is probably not very likely. But then static variables in headers
aren't terribly common anyway, so maybe it's not a problem.

[Bug ada/80790] Symbol defined but should be referenced in ACATS 4.1 c732b02

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 41370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41370=edit
Reproducer

[Bug ada/80790] New: Symbol defined but should be referenced in ACATS 4.1 c732b02

[simon at pushface dot org]

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

Bug ID: 80790
   Summary: Symbol defined but should be referenced in ACATS 4.1
c732b02
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15

In the attached code, the symbol _f732b00__change_discriminated_typeInvariant
is generated as defined (T) in a code unit that should only reference it (U).

$ gnatmake -gnatws -O2 c732b02.adb 
gcc -c -gnatws -O2 c732b02.adb
gcc -c -gnatws -O2 f732b00.adb
gcc -c -gnatws -O2 report.adb
gnatbind -x c732b02.ali
gnatlink c732b02.ali -O2
duplicate symbol _f732b00__change_discriminated_typeInvariant in:
./f732b00.o
./c732b02.o
ld: 1 duplicate symbol for architecture x86_64
collect2: error: ld returned 1 exit status
gnatlink: error when calling /opt/gcc-7.1.0/bin/gcc
gnatmake: *** link failed.

The same failure occurs with GNAT GPL 2016, but not with GCC 6.1.0, 5.2.0 (for
which the test passes).

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 16 19:25:04 2017
New Revision: 248124

URL: https://gcc.gnu.org/viewcvs?rev=248124=gcc=rev
Log:
PR sanitizer/80536
PR sanitizer/80386
* cp-gimplify.c (cp_fold): Handle SAVE_EXPR.

* tree.c (save_expr): Don't fold the expression.

* c-c++-common/ubsan/pr80536.c: New test.
* g++.dg/ubsan/pr80386.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80536.c
trunk/gcc/testsuite/g++.dg/ubsan/pr80386.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[mpolacek at gcc dot gnu.org]

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

--- Comment #19 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 16 19:25:04 2017
New Revision: 248124

URL: https://gcc.gnu.org/viewcvs?rev=248124=gcc=rev
Log:
PR sanitizer/80536
PR sanitizer/80386
* cp-gimplify.c (cp_fold): Handle SAVE_EXPR.

* tree.c (save_expr): Don't fold the expression.

* c-c++-common/ubsan/pr80536.c: New test.
* g++.dg/ubsan/pr80386.C: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80536.c
trunk/gcc/testsuite/g++.dg/ubsan/pr80386.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug target/80782] Feature request: use the llvm/clang assembler on Mac

[rjvbertin at gmail dot com]

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

--- Comment #4 from René J.V. Bertin  ---
The current support apparently has its glitches but above all it has nothing to
do with gcc itself; it consists of using an existing `as` option to "Use  the 
clang(1) integrated assembler instead of the GNU based system assembler".
That's apparently the default for `as` so I don't understand why it doesn't
invoke clang when used through gcc.

> So, what is the correct configure option to let gcc use it by default?

Write a wrapper script that just prepends or appends `-q` to the arguments and
then calls the actual `as` command, and use that wrapper with the `--with-as`
option? Crossing fingers that GCC itself will build...

What I had in mind was calling `clang -cc1as` or even `llvm-as` directly, with
the proper arguments. That ought to give better control over the generated
object code than relying on a 3rd party (Apple) to implement the GNU -> clang
argument translation.

[Bug c++/80789] New: Better error for passing lambda with capture as function pointer

[denis.campredon at gmail dot com]

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

Bug ID: 80789
   Summary: Better error for passing lambda with capture as
function pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

With the following code:

-
void g(void (*)());

void f() {
int x;
g([x](){});
}
--
gcc produce this error:


main.cpp: In function 'void f()':

main.cpp:5:14: error: cannot convert 'f()::' to 'void (*)()' for
argument '1' to 'void g(void (*)())'

 g([x](){});

It is not clear why the lambda is not accepted since calling g with a lambda
with no capture produce no error.

A better error would say something like:
'cannot convert a lambda with capture to function pointer'.

And maybe a hint telling to use a "std::function" instead.

Regards,
Denis

[Bug tree-optimization/80788] New: [8 Regression] ICE in set_value_range, at tree-vrp.c:252

[asolokha at gmx dot com]

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

Bug ID: 80788
   Summary: [8 Regression] ICE in set_value_range, at
tree-vrp.c:252
   Product: gcc
   Version: 8.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-alpha20170514 snapshot ICEs when compiling the following snippet w/
-O2 (-Os, -O3, -Ofast) -fno-strict-overflow:

void
w3 (char yw)
{
  char pa = (yw + 1) ^ 128;

  yw &= !!pa;
  if (yw != 0)
for (;;)
  {
  }
}

% gcc-8.0.0-alpha20170514 -O2 -fno-strict-overflow -c p6zbu0i0.c
p6zbu0i0.c: In function 'w3':
p6zbu0i0.c:11:1: internal compiler error: in set_value_range, at tree-vrp.c:252
 }
 ^

[Bug c/80787] gcc -Wmaybe-uninitialized false negative when compiling Emacs

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
This is a DUP of many other PRs, -fno-tree-ccp -fno-tree-vrp gives you the
warning, but otherwise gcc optimises cond?value:undef to value.

[Bug c/80787] New: gcc -Wmaybe-uninitialized false negative when compiling Emacs

[eggert at gnu dot org]

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

Bug ID: 80787
   Summary: gcc -Wmaybe-uninitialized false negative when
compiling Emacs
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

I found this problem when compiling GNU Emacs with GCC 7.1.0 and with Clang
3.9.1.  GCC missed an uninitialized-variable bug that Clang correctly warned
about. To reproduce the problem with GCC 7.1.0 x86-64, compile the following
stripped-down test case:

  _Bool
  xg_update_scrollbar_pos (int a, int b)
  {
_Bool hidden;
if (a < b)
  hidden = 1;
return !hidden;
  }

using the command:

  gcc -O2 -Wall -S u.i

GCC does not warn, even though 'hidden' is a possibly-uninitialized variable.
With the same options, Clang warns about the bug.

[Bug c++/80785] warning for static definitions inside extern "C"

[daniel.gutson at intel dot com]

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

--- Comment #2 from Daniel Gutson  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Daniel Gutson from comment #0)
> > I don't see why one would want to do this.
> 
> You might have a header that encloses the entire contents in an extern "C"
> language linkage block, and it might contain static variables.
> 
> Variables with internal linkage don't have language linkage, so the extern
> "C" doesn't do anything, but isn't necessarily a mistake.

I still think that a warning would help. With this aid, the programmer may pull
the static definitions out of the extern"C" block, or more importantly,
refactor the organization of the header files structure. Opt-in -Wextern-static
or alike?

> 
> For function definitions it's not contradictory, and not redundant:
> 
> extern "C" static void f() { }
> static void g() { }
> 
> f() and g() both have internal linkage, but have different types. This
> matters if you want to pass  to a function that takes a pointer to a
> function with "C" language linkage (N.B. GCC and many other compilers don't
> implement this correctly, see PR 2316).

OK, didn't think about this use case.

[Bug c/80786] New: m68k: internal compiler error: in change_address_1

[ad...@tho-otto.de]

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

Bug ID: 80786
   Summary: m68k: internal compiler error: in change_address_1
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@tho-otto.de
  Target Milestone: ---

Created attachment 41369
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41369=edit
bla.c

When compiling the attached, small test program with

m68k-elf-gcc -O2 -mpcrel bla.c

i get

bla.c: In function 'dir_op':
bla.c:54:1: internal compiler error: in change_address_1, at emit-rtl.c:2150

The problem goes away when changing -O2 to a lower level, when omitting -mpcrel
or when changing the members of the DIRCOUNT structure to long.

[Bug c++/80785] warning for static definitions inside extern "C"

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Daniel Gutson from comment #0)
> I don't see why one would want to do this.

You might have a header that encloses the entire contents in an extern "C"
language linkage block, and it might contain static variables.

Variables with internal linkage don't have language linkage, so the extern "C"
doesn't do anything, but isn't necessarily a mistake.

For function definitions it's not contradictory, and not redundant:

extern "C" static void f() { }
static void g() { }

f() and g() both have internal linkage, but have different types. This matters
if you want to pass  to a function that takes a pointer to a function with
"C" language linkage (N.B. GCC and many other compilers don't implement this
correctly, see PR 2316).

[Bug libfortran/80602] Reduce stack usage for blocked matmul

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fallout seems to have been fixed.

Closing.

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #8 from Peter Bergner  ---
I'm testing a patch.  The special thing here, is that we try combining multiple
case statements that lead to the same block and that block contains a
__builtin_unreachable() call.  If we remove the edge//block for the first case
label, that causes a problem for the next case label that points to the same
block.

My "fix" is to first merge the case statements and then check whether the
resulting case label points to an unreachable block and delete it if it does,
which fixes the ICE.

[Bug c++/80785] New: warning for static definitions inside extern "C"

[daniel.gutson at intel dot com]

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

Bug ID: 80785
   Summary: warning for static definitions inside extern "C"
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at intel dot com
  Target Milestone: ---

The following code is contradictory, with some probability that the programmer
made is wrongly assuming something:

extern "C"
{
static int x = 1;
}

I don't see why one would want to do this.

Of course this could be filed as feature request or enhancement.

[Bug target/80782] Feature request: use the llvm/clang assembler on Mac

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #1)
> The support is already there ...

So, what is the correct configure option to let gcc use it by default?

[Bug c++/80781] Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[rjvbertin at gmail dot com]

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

--- Comment #4 from René J.V. Bertin  ---
Edit: my goal here was thus more to test the waters and see how likely or not
it is that G++ will one day have this kind of support for libc++.

[Bug c++/80781] Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[rjvbertin at gmail dot com]

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

--- Comment #3 from René J.V. Bertin  ---
Dumb because?

I don't think I'd use the term even if the official GCC standpoint were that
clang is the superior compiler anyway.

The simple reality on the Mac platform is that you cannot have libstdc++ and
libc++ in the same process if there's the slightest risk they'll be used on the
same objects. You can either make the most of that situation, or not. In the
latter case you could just as well drop the whole g++ build (= allow the other
compilers to build without wasting time building a crippled compiler).

I agree that a proper implementation would include a compiler argument like
clang does. But like clang the default on Mac should be libc++ because it makes
little to no sense to use another runtime.

Also, I'm not really in a situation where I can drive the full implementation
myself. I understood that feature requests are appropriate here and provided my
patch more as a proof of concept than as a reference implementation.

[Bug ada/80784] ICE in ACATS 4.1 c732b01 at -O1, -O2

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

  Known to work||6.1.0

--- Comment #2 from simon at pushface dot org ---
Also fails with GNAT GPL 2016.

[Bug ada/80784] ICE in ACATS 4.1 c732b01 at -O1, -O2

[simon at pushface dot org]

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

--- Comment #1 from simon at pushface dot org ---
Created attachment 41368
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41368=edit
Reproducer

[Bug ada/80784] New: ICE in ACATS 4.1 c732b01 at -O1, -O2

[simon at pushface dot org]

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

Bug ID: 80784
   Summary: ICE in ACATS 4.1 c732b01 at -O1, -O2
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15

Compiling the attached code, with the options used via "make check-acats",
results in

$ gnatmake -gnatws -O2 c732b01.adb 
gcc -c -gnatws -O2 c732b01.adb
+===GNAT BUG DETECTED==+
| 7.1.0 (x86_64-apple-darwin15) GCC error: |
| in begin_subprog_body, at ada/gcc-interface/utils.c:3297 |
| Error detected at f732b00.ads:153:9  |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

c732b01.adb
f732b00.ads
report.ads

compilation abandoned
gnatmake: "c732b01.adb" compilation error

-O1 gives the same ICE, -O0 or no -O flag results in

$ gnatmake -gnatws -O0 c732b01.adb 
gcc -c -gnatws -O0 c732b01.adb
gcc -c -gnatws -O0 f732b00.adb

raised CONSTRAINT_ERROR : erroneous memory access
gnatmake: "f732b00.adb" compilation error
lockheed:c732b01 simon$ gnatmake -gnatws c732b01.adb 
gcc -c -gnatws f732b00.adb

raised CONSTRAINT_ERROR : erroneous memory access
gnatmake: "f732b00.adb" compilation error

[Bug c++/80783] New: Inconsistent constexpr diagnostic for some cstdlib functions

[victor.nawothnig at gmail dot com]

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

Bug ID: 80783
   Summary: Inconsistent constexpr diagnostic for some cstdlib
functions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.nawothnig at gmail dot com
  Target Milestone: ---

A set of functions from cstdlib suffers from incorrect constexpr diagnostic
"call to non-constexpr function"

#include 
constexpr size_t f() { exit(0); return 1; }
/* Bad: Silently compiles */

When f() is being evaluated in a constant expression, the diagnostic properly
triggers again, this reduces the impact of this bug:

#include 
constexpr size_t f() { exit(0); return 1; }
int arr[f()];
/* Good: triggers diagnostic */

Interestingly the error seems to be tied to specific function signatures,
rather than the standard library headers. Given the following (without
including any headers):

extern "C" void free(int);
constexpr void f() { free(0); }
/* Good: triggers diagnostic, free has a non-standard signature */

extern "C" void free(void *);
constexpr void f() { free(0); }
/* Bad: silently compiles, free has a standard signature */

It also is limited to only a particular set of cstdlib functionsincluding but
not limited to: free, malloc, exit, atoi.  I have not found any other affected
headers yet, but I did not do an exhaustive search.

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rjvbertin at gmail dot com

--- Comment #59 from Andrew Pinski  ---
*** Bug 80782 has been marked as a duplicate of this bug. ***

[Bug target/80782] Feature request: use the llvm/clang assembler on Mac

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
.

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

[Bug c++/80781] Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Firstly, if you have a patch then it should be sent to gcc-patc...@gcc.gnu.org
not entered as a feature request in bugzilla. See
https://gcc.gnu.org/contribute.html for details on patch submission and other
prerequisites.

Patch review happens on the mailing list, not in bugzilla. That said, this
isn't really ready for review:

Obviously this functionality should be enabled via a -stdlib option (as Clang
has) rather than using environment variables. And the default should be
libstdc++, so you wouldn't need the BUILDING_ITSELF hack to allow
bootstrapping.

Instead of changing LIBSTDCXX to c++ you should add a different macro for
libc++ and libc++abi and leave the existing one alone. LIBSTDCXX is obviously
libstdc++. LIBCXX would be for libc++, and LIBCXXABI would be for libc++abi.

[Bug target/80782] Feature request: use the llvm/clang assembler on Mac

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The support is already there ...

[Bug target/80782] New: Feature request: use the llvm/clang assembler on Mac

[rjvbertin at gmail dot com]

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

Bug ID: 80782
   Summary: Feature request: use the llvm/clang assembler on Mac
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjvbertin at gmail dot com
  Target Milestone: ---

Created attachment 41367
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41367=edit
wrapper to make "clang-as" callable as [g]as

Apple provides an ageing GNU as fork as part of its cctools package: it's based
on gas 1.38 and thus lacks support for CPU instruction sets added after that
release.

As a result, GCC generates code that fails to assemble when using optimisation
for any CPU that has support for AVX or newer intrinsics. A pity and often
annoying because the failure can happen only late during a build process.

The easiest way around this would be to use the assembler that is actually used
by clang.

I'm attaching a wrapper script that I have been using to build boost, R and a
few KF5 applications with full optimisation for an i7 CPU on Mac OS X 10.9.5 .
(The resulting R binary is consistently a few percent faster than the same code
built with clang 4.0)

For some reason I fail to understand the GCC build process fails when using
this wrapper: the tconfig.h header file is not generated. I have worked around
that by providing a shunt in the wrapper that just hands off the command to the
regular as executable, but there must be a more elegant way.

[Bug fortran/80741] [Regression 7/8] incorrect behaviour of rewind with namelist

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
Regression testing completed. The offending patch is the DTIO changes on
8-31-2016.

Looking at the tree dump we see things like:

   dt_parm.4.common.iostat = 
dt_parm.4.namelist_name = &"test"[1]{lb: 1 sz: 1};
dt_parm.4.namelist_name_len = 4;
dt_parm.4.common.flags = 33056;
_gfortran_st_set_nml_dtio_var (_parm.4, , &"x"[1]{lb: 1 sz: 1}, 4, 0,
8, 0B, 0B);
_gfortran_st_set_nml_dtio_var (_parm.4, , &"y"[1]{lb: 1 sz: 1}, 4, 0,
8, 0B, 0B);
dt_parm.4.common.unit = io;
_gfortran_st_read (_parm.4);
_gfortran_st_read_done (_parm.4);
  }
  {

Where this case does not involve dtio.

[Bug c++/80781] Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I think this is a dumb idea really.

[Bug c++/80781] New: Feature request: build option to use libc++ instead of libstdc++ for increased usability on Mac

[rjvbertin at gmail dot com]

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

Bug ID: 80781
   Summary: Feature request: build option to use libc++ instead of
libstdc++ for increased usability on Mac
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rjvbertin at gmail dot com
  Target Milestone: ---

Created attachment 41366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41366=edit
prototype use-libcxx.diff

Using G++ as a full-featured and generally usable C++ compiler on Mac OS X 10.9
and newer (and potentially other systems) requires using the libc++ runtime
instead of libstdc++. Instructions can be found online (e.g.
http://stackoverflow.com/questions/8208/using-g-with-libc) on how to get
G++ to build code doing just that. The principle works fine but the method is a
bit too convoluted to use in anything but smallish projects.

I have thus been working on a patch for GCC 6.3.0 (latest release when I
started) that makes G++ behave according to those online instructions:
- use the /path/to/llvm-$version/include/c++/v1 include directory for the
standard C++ headers
- emit `-lc++ -lc++abi` instead of -lstdc++

This turned out far less hairy than I feared it might be though, a few details
aside. Not all system libc++ versions have `operator delete(void*, unsigned
long)` for instance, but it has turned out to be safe to use GCC's libsupc++ as
a source for that and possibly other methods.

The hairiest detail was probably figuring out the best way to build GCC itself
(also the costliest detail: each trial cost up to 1.5 hours rebuilding
everything from scratch). I'm now at a point where I can present a prototype
patch: it provides a few hooks (environment variables) to switch back to using
libstdc++ which are used during the GCC build process. The compiler itself is
thus built "as usual".

I have been able to build a few quite complex projects with the resulting
compiler; boost, KDevelop and digiKam (boost with a patch to remove the
presumption that only clang uses libc++). The resulting binaries function as if
they were built using clang++ and not with a compiler that normally uses
libstdc++.

The patch is a typical "distribution" patch, i.e. it is applied in a package
install variant and does not currently add a configure option to the build
system. When selected, GCC is configured and built with
`GCC_IS_BUILDING_ITSELF=1 GCC_FORCE_LIBSTDCPP=1` set in the environment.

Would there be any interest in incorporating this functionality properly, thus
making G++ officially an alternative C++ compiler on Mac (and possibly other
BSD systems)? Or are there too many pitfalls which I just haven't discovered
yet?

[Bug libfortran/80602] Reduce stack usage for blocked matmul

[pthaugen at gcc dot gnu.org]

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

--- Comment #7 from Pat Haugen  ---
(In reply to Thomas Koenig from comment #6)
> I just committed r248074 which I suspect is the same problem
> (the fix for PR 80765).
> 
> If you could just upgrade to the most recent trunk (only
> need to upgrade libgfortran, really) an check if the fix
> also works for you, that would be great.

Yes, both are fixed with r248704. Thanks.

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

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
This is introduced by r236012 with a different ICE:

pr80763.cc:27:14: internal compiler error: in inline_small_functions, at
ipa-inline.c:1881
 void n::o() {}
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

r236271 changed ICE to

pr80763.cc:27:14: error: inline clone in same comdat group list
 void n::o() {}
  ^
_ZThn8_N1n1fE.artificial_thunk.2/42 () @0x7f2be1015e60
  Type: function definition analyzed
  Visibility: comdat_group:_ZN1iI1lE1dEjj artificial
  Same comdat group as: _ZN1iI1lE1dEjj/25
  References: 
  Referring: 
  Function /42 is inline copy in unsigned int i::d(unsigned int,
unsigned int) [with e = l]/25
  Availability: local
  First run: 0
  Function flags: local nonfreeing_fn
  Thunk fixed offset -8 virtual value 0 has virtual offset 0)
  Called by: _ZN1iI1lE1dEjj.part.0/35 (speculative) (inlined) (0.31 per call)
(can throw external) 
  Calls: _ZN1n1fE.constprop.1/41 (call_stmt_cannot_inline_p) (0.31 per
call) 
pr80763.cc:27:14: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
gnu-ivb-1:pts/1[63]> ./gcc-test-run 236267
Testing /export/gnu/import/git/gcc-regression/master/236267/usr/bin/gcc:
pr80763.cc:27:14: internal compiler error: in inline_small_functions, at
ipa-inline.c:1881
 void n::o() {}
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
We don't instrument such expressions because
v_3 = _2->i;
is not gimple_assign_load_p:

1997   if (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT))
1998 {
1999   if (gimple_store_p (stmt))
2000 instrument_null (gsi, true);
2001   if (gimple_assign_load_p (stmt))
2002 instrument_null (gsi, false);
2003 }

[Bug c++/80780] Front-end support needed for experimental::source_location

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Martin Sebor from comment #2)
> When I made the built-ins constexpr in bug 66561 I thought (assumed) the
> intent was for the source_location default ctor and current() member to make

N.B. my current impl doesn't do that for the default ctor, only the current()
function. I could move the default arguments to the ctor and then change it to:

struct source_location {
  static constexpr source_location current(source_location c = {})
  { return c; }

  constexpr source_location(const char* __file = __builtin_FILE(), ...) ...
};

This makes the current() function redundant, except for being more explicit
about the intent and so more readable.

> use of default arguments to populate the members.  That's a nice, general
> solution.  Treating the class as special seems like a hack to me.  Why do
> you think it would be nice to do that?

I didn't mean an ugly hack would be nice, just that having the signature match
what the TS says would be nice. But it's not very important. It only matters if
somebody tries to make use of _location::current and the result of using
that is unspecified (and in practice won't be useful).

> My own preference would be to change the TS to both make the intent clear,
> and make it possible to set the parameters of the location.

I'd be OK with that.

> Adding __builtin_PRETTY_FUNCTION is easy but I don't know about
> __builtin_COLUMN().  The latter is also so underspecified that I'm not sure
> how it could be relied on for anything useful.

Agreed. The only use for it I thought of is if you have a macro that expands to
something huge and complex on a single line, it would let you distinguish
different positions within the expansion. But even that seems not terribly
useful. Returning 0 for the column is conforming, and if users are happy with
that then we can give useful feedback to WG21 that the column function isn't
needed.

[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
It's not completely fixed yet.  The warning passes do run with LTO but LTO
still runs with warnings disabled unless they are explicitly enabled on the
command line.  -Walloca-larger-than is not in -Wall or -Wextra so it looks like
it works, but -Wformat-overflow is in -Wall and it's not issued when -Wall
alone is specified.

Richard had a suggestion for how to fix it on gcc-patches but I haven't gotten
around to looking into it yet.

$ (set -x && cat t.c && for lto in '' '-flto'; do /ssd/build/gcc-git/gcc/xgcc
-B /ssd/build/gcc-git/gcc -O2 -Wall -Walloca-larger-than=1 $lto -c t.c &&
/ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -Wall
-Walloca-larger-than=1  $lto t.o; done)
+ cat t.c
int main (void)
{
  char *d = (char*)__builtin_alloca (2);
  __builtin_sprintf (d, "%i", 123);
  __builtin_puts (d);
}
+ for lto in ''\'''\''' ''\''-flto'\'''
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -Wall
-Walloca-larger-than=1 -c t.c
t.c: In function ‘main’:
t.c:3:9: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   char *d = (char*)__builtin_alloca (2);
 ^
t.c:3:9: note: limit is 1 bytes, but argument is 2
t.c:4:26: warning: ‘%i’ directive writing 3 bytes into a region of size 2
[-Wformat-overflow=]
   __builtin_sprintf (d, "%i", 123);
  ^~
t.c:4:3: note: ‘__builtin_sprintf’ output 4 bytes into a destination of size 2
   __builtin_sprintf (d, "%i", 123);
   ^~~~
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -Wall
-Walloca-larger-than=1 t.o
+ for lto in ''\'''\''' ''\''-flto'\'''
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -Wall
-Walloca-larger-than=1 -flto -c t.c
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -Wall
-Walloca-larger-than=1 -flto t.o
t.c: In function ‘main’:
t.c:3:9: warning: argument to ‘alloca’ is too large [-Walloca-larger-than=]
   char *d = (char*)__builtin_alloca (2);
 ^
t.c:3:9: note: limit is 1 bytes, but argument is 2

[Bug c++/80780] Front-end support needed for experimental::source_location

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
When I made the built-ins constexpr in bug 66561 I thought (assumed) the intent
was for the source_location default ctor and current() member to make use of
default arguments to populate the members.  That's a nice, general solution. 
Treating the class as special seems like a hack to me.  Why do you think it
would be nice to do that?

My own preference would be to change the TS to both make the intent clear, and
make it possible to set the parameters of the location.

Adding __builtin_PRETTY_FUNCTION is easy but I don't know about
__builtin_COLUMN().  The latter is also so underspecified that I'm not sure how
it could be relied on for anything useful.

[Bug c++/79092] template: type ignored if value already instantiated

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-01-15 00:00:00 |2017-5-16

--- Comment #1 from Jonathan Wakely  ---
template struct X
{
  int* f() { static int i; return  }
};

int main()
{
  X<1> x;
  X<1u> xx;
  if ( x.f() == xx.f() )
throw 1;
}

[Bug c++/61355] gcc doesn't normalize type in non-type template parameters

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2014-05-29 00:00:00 |2017-5-16

--- Comment #1 from Jonathan Wakely  ---
With fewer warnings:

template struct X { };

int test() {
X x;
return 0;
}

[Bug lto/79062] -Walloca-larger-than and -Wformat-overflow warnings disabled by -flto

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #6 from Wilco  ---
This looks fixed now, gcc.dg/pr78768.c XPASSes on ARM/AArch64 in all
configurations. Is this expected so we can fix the test?

[Bug c++/80651] Non-type template argument deduction fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 Ever confirmed|0   |1

[Bug c++/80771] GCC ignores default template argument declaration in the template definition

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|wrong-code  |rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
template struct enable_if { using type = void; };

struct Foo { };

// This is a template function declaration, where second template argument
declared without a default
template 
void foo(const Foo &, T);

// This is a template function definition; second template argument now has a
default declared
template ::type>
void foo(const Foo &, T)
{
}

int main()
{
foo(Foo{}, 1);
}

[Bug c/80778] [7/8 Regression] gcc.dg/auto-type-1.c ICEs with -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 CC||marxin at gcc dot gnu.org
Summary|gcc.dg/auto-type-1.c ICEs   |[7/8 Regression]
   |with -flto  |gcc.dg/auto-type-1.c ICEs
   ||with -flto
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with your commit r235817.

[Bug bootstrap/80779] MPX bootstrap does not work on real hardware supporting that

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 Ever confirmed|0   |1

[Bug c++/80780] Front-end support needed for experimental::source_location

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The spec is at
https://rawgit.com/cplusplus/fundamentals-ts/v2/fundamentals-ts.html#reflection.src_loc

[Bug c/50584] No warning for passing small array to C99 static array declarator

[fredrik.hederstie...@securitas-direct.com]

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

Fredrik Hederstierna  changed:

   What|Removed |Added

 CC||fredrik.hederstierna@securi
   ||tas-direct.com

--- Comment #14 from Fredrik Hederstierna 
 ---
Still present in GCC-7.1.0

Simple test code:

-
int s[1] = { 1 };

void test(int v[static 2])
{
  printf("%d\n", v[1]);
  v[1] = 0;
}

int main(void)
{
  test(s);
  return 0;
}

-
No warnings by GCC:

> gcc -c test.c -W -Wall -Wextra -Warray-bounds -O2 -std=c99

-
But with CLANG-3.8.0 we get warnings:

> clang -c test.c

test.c:13:3: warning: array argument is too small; contains 1 elements, callee
  requires at least 2 [-Warray-bounds]
  test(s);
  ^~
test.c:5:15: note: callee declares array parameter as static here
void test(int v[static 2])
  ^~~
1 warning generated.

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner  ---
I have it recreated.  Digging into it.

[Bug fortran/80768] NULL pointer dereferenced in gfc_check_num_images at fortran/check.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 CC||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, I'm wondering why >where expression is not checked by
-fsanitize=null. Adding Marek.

[Bug c++/80780] New: Front-end support needed for experimental::source_location

[redi at gcc dot gnu.org]

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

Bug ID: 80780
   Summary: Front-end support needed for
experimental::source_location
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I've just added a partial implementation of  to
trunk (r248110).

The missing pieces need some FE help.

1) because the location info returned by source_location::current() should be
the location of the caller the current implementation uses default arguments:

  struct source_location
  {
// 14.1.2, source_location creation
static constexpr source_location
current(const char* __file = __builtin_FILE(),
const char* __func = __builtin_FUNCTION(),
int __line = __builtin_LINE(),
int __col = 0) noexcept
{
  source_location __loc;
  __loc._M_file = __file;
  __loc._M_func = __func;
  __loc._M_line = __line;
  __loc._M_col = __col;
  return __loc;
}

This works OK, but means the signature of the function doesn't match the one in
the TS (which has no parameters). The standard does allow us to add parameters
with default arguments to member functions, but it might be nice if it wasn't
needed. I'm not sure how best to do that. Maybe make the FE recognise
std::experimental::fundamentals_v2::source_location::current() as magic, so
that location info inside the function uses the location of the caller? Maybe
add a new attribute to perform said magic for any inline function? (If
current() is called indirectly, e.g. through a function pointer, the result is
unspecified so the magic doesn't need to work when the function isn't inlined).

2) source_location::current().function_name() uses __func__ which is not very
descriptive in C++. It would be nice to have a __builtin_PRETTY_FUNCTION to get
a better function name than __builtin_FUNCTION provides.

3) source_location::column().column() always returns zero, because there's no
"__builtin_column" to get a column number, the way __builtin_LINE gives a line
number.


I mistakenly though that calling current() in a default member initializer gave
the wrong locations, but it does the right thing (giving the location of the
constructor body that initializes the member).

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[bergner at gcc dot gnu.org]

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

--- Comment #6 from Peter Bergner  ---
I'll have a look.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Daniel Santos  ---
> Actually, I just realized that it won't help to move do_test.S into ms-sysv.c
> as inline asm because each test still needs a unique ms-sysv-generated.h 
> header
> that's generated by the output of gen.cc.  Although I suppose it's possible to
> generate all of the headers in advance (with unique names) and then set the
> header name in the options with -DGEN_HEADER_NAME=name.h -- that will have its
> own set of issues.

Exactly: I'd avoid that if you can.  It will only complicate things.

Rainer

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Daniel Santos  ---
> (In reply to Rainer Orth from comment #0)
>> It seems to me that ms-sysv.exp is seriously misguided in trying to do all
>> its compilations manually instead of using
>> dg-test/dg-runtest/gcc_target_compile
>> which whould nicely avoid all those issues.
>
> Well, this was my introduction to DejaGnu and the test harness.  I found that
> none of these support doing a build when there is more than one object file --
> in my case, I'm linking the output of both ms-sysv.c and do_test.S.  However,

Huh?  What about dg-additional-sources, which seems to be exactly what
you need and is even documented in sourcebuild.texi ;-)

> this test started out with multiple .c files and I was able to reduce it down
> to one.  I'm going to see if there's a way to cleanly do my assembly inline 
> and

I wouldn't go that way unless absolutely necessary: unless you need
something from gcc inline assembly, this makes the testcase only harder
to read.

> If I'm wrong about the single object file thing, please point me in the right
> direction.

I believe you are, but it's admittedly hard finding your way around in
the testsuite once you leave the trodden paths.

>> The new gcc.target/x86_64/abi/ms-sysv tests FAIL in various e.g. on
>> i386-pc-solaris2.*
>> and i686-pc-linux-gnu:
>> 
>> * In those 32-bit-default configurations, the 32-bit multilib is skipped as
>>   unsupported as expected (although the UNSUPPORTED entry in gcc.sum occurs
>>   e.g. 45 times for -j48 testing instead of only once),
>
> Sadly, I discovered that by not using the standard test functions that I had 
> to
> cook up my own parallelism scheme, otherwise all of my tests would run once 
> for
> each -j!  I think that this issue is fixable though.

I'd hope so.  E.g. you get the usual PASS and FAIL lines in gcc.sum for
free by using the standard infrastructure instead of cooking up your
own.

Rainer

[Bug libstdc++/80285] `std::make_shared` performs two separate allocations with `-fno-rtti`

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue May 16 13:16:34 2017
New Revision: 248109

URL: https://gcc.gnu.org/viewcvs?rev=248109=gcc=rev
Log:
Fix forward declaration of std::type_info for versioned-namespace

PR libstdc++/80285
* include/bits/shared_ptr_base.h [!__cpp_rtti] (type_info): Declare
outside versioned namespace.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h

[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So right after RTL expansion loop state is corrupt.

[Bug bootstrap/80779] MPX bootstrap does not work on real hardware supporting that

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Created attachment 41365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41365=edit
Semi-working patch for bootstrap

[Bug bootstrap/80779] New: MPX bootstrap does not work on real hardware supporting that

[marxin at gcc dot gnu.org]

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

Bug ID: 80779
   Summary: MPX bootstrap does not work on real hardware
supporting that
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41364=edit
MPX bootstrap config file patch

Running ../configure --disable-multilib --with-build-config=bootstrap-mpx
--enable-languages=c,c++

and make does not work on real hardware. I tested that on my laptop some time
ago and with following 2 patches, I was able to bootstrap quite part of
compiler.

However, currently there's a failure:

__mpx_wrapper_strcpy (dst=dst@entry=0x66a08d "", src=src@entry=0x44a76b
"../../gcc/gengtype.c") at ../../../../libmpx/mpxwrap/mpx_wrappers.c:614
614 ../../../../libmpx/mpxwrap/mpx_wrappers.c: No such file or directory.
(gdb) bt
#0  __mpx_wrapper_strcpy (dst=dst@entry=0x66a08d "", src=src@entry=0x44a76b
"../../gcc/gengtype.c") at ../../../../libmpx/mpxwrap/mpx_wrappers.c:614
#1  0x00413077 in input_file_by_name(char const*) [clone .chkp]
(name=name@entry=0x44a76b "../../gcc/gengtype.c") at ../../gcc/gengtype.c:5106
#2  0x004268f6 in main (argc=7, argv=0x7fffe0a8) at
../../gcc/gengtype.c:5152
(gdb) bt
#0  0x004456eb in htab_hash_string (p=0x66a08d) at
../../libiberty/hashtab.c:838
#1  0x00411af7 in htab_hash_inputfile (p=) at
../../gcc/gengtype.c:5126
#2  0x00445fef in htab_find_slot (htab=0x668010, element=0x66a080,
insert=INSERT) at ../../libiberty/hashtab.c:703
#3  0x0041309d in input_file_by_name(char const*) [clone .chkp]
(name=name@entry=0x44a76b "../../gcc/gengtype.c") at ../../gcc/gengtype.c:5107
#4  0x004268f6 in main (argc=7, argv=0x7fffe0a8) at
../../gcc/gengtype.c:5152

build/gengtype  -S ../../gcc -I gtyp-input.list -w
tmp-gtype.state

One can see many 'Saw a #BR failures'.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #27 from Jerry DeLisle  ---
> (In reply to Rainer Orth from comment #15)
>> The new testcase FAILs on 64-bit Solaris/SPARC:
>> 
>> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
>
> See if fixed on trunk now after commit to fix 80767.

I've now completed sparc-sun-solaris2.12 (and i386-pc-solaris2.12 for
good measure) bootstraps: the 64-bit sparc failures are gone and no
regressions on either sparc or x86.

It would be nice to backport the patch to the gcc-7 branch after some
soak time on mainline.

Thanks.
Rainer

[Bug tree-optimization/79920] [6 Regression] Incorrect floating point results when compiling with -O3

[andrey.y.guskov at intel dot com]

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

--- Comment #7 from Andrey Guskov  ---
(In reply to Mikael Pettersson from comment #6)
> (In reply to Andrey Guskov from comment #5)
> > The revision 245968 breaks compilation of 465.tonto from SPEC2006 with these
> > options:
> > 
> > -m32 -Ofast -flto -march=core-avx2
> 
> Was this regression fixed, and if so by which revision?  I don't have
> immediate access to SPEC2006 so I cannot check for myself.

Nope. As of 2017-05-16 it still persists.

[Bug c/80778] New: gcc.dg/auto-type-1.c ICEs with -flto

[rguenth at gcc dot gnu.org]

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

Bug ID: 80778
   Summary: gcc.dg/auto-type-1.c ICEs with -flto
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Looks like

#0  0x00c16e6c in lto_input_tree_ref (ib=0x7fffd880, 
data_in=0x2715700, fn=0x0, tag=LTO_ssa_name_ref)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:332
#1  0x00c19eaf in lto_input_tree_1 (ib=0x7fffd880, 
data_in=0x2715700, tag=LTO_ssa_name_ref, hash=0)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1440
#2  0x00c1a0de in lto_input_tree (ib=0x7fffd880, data_in=0x2715700)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1486
#3  0x010bc16b in lto_input_ts_exp_tree_pointers (ib=0x7fffd880, 
data_in=0x2715700, expr=)
at /space/rguenther/src/svn/trunk/gcc/tree-streamer-in.c:875
#4  0x010bcac4 in streamer_read_tree_body (ib=0x7fffd880, 
data_in=0x2715700, expr=)
at /space/rguenther/src/svn/trunk/gcc/tree-streamer-in.c:1061
#5  0x00c19b85 in lto_read_tree_1 (ib=0x7fffd880, 
data_in=0x2715700, expr=)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1333
#6  0x00c19c5e in lto_read_tree (ib=0x7fffd880, data_in=0x2715700, 
tag=71, hash=1088263761)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1357
#7  0x00c1a075 in lto_input_tree_1 (ib=0x7fffd880, 
data_in=0x2715700, tag=71, hash=1088263761)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1469
#8  0x00c19cd8 in lto_input_scc (ib=0x7fffd880, data_in=0x2715700, 
len=0x7fffd6a8, entry_len=0x7fffd6a4)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1381
#9  0x00c1a0a9 in lto_input_tree (ib=0x7fffd880, data_in=0x2715700)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1484
#10 0x00c18d77 in input_function (
fn_decl=, data_in=0x2715700, 
ib=0x7fffd880, ib_cfg=0x7fffd860)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-in.c:1042

1041  /* Read the tree of lexical scopes for the function.  */
1042  DECL_INITIAL (fn_decl) = stream_read_tree (ib, data_in);

looks like some variable has un-gimplified VLA bounds, aka DECL_EXPRs are
missing.

[Bug c++/80773] Internal Compiler error on template parameter pack expansion

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r238558, before that it was rejected:

pr80773.cpp: In substitution of ‘template  requires
predicate((FCallable)()) and predicate((FCallable)()...) static void
Test1::g() [with P = A; Pp = {}]’:
pr80773.cpp:19:26:   required from here
pr80773.cpp:10:17: error: invalid use of pack expansion expression
 static void g() {
 ^

[Bug fortran/80774] [7/8 Regression] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-05-16
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in  |[7/8 Regression] ICE in
   |gfc_conv_descriptor_data_ge |gfc_conv_descriptor_data_ge
   |t, at fortran/trans-array.c |t, at fortran/trans-array.c
  Known to fail||7.1.0, 8.0

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

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Started with r247844.

[Bug rtl-optimization/80770] suboptimal code negating a 1-bit _Bool field

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The reason is that we (have to) expand the bitfield load to

(insn 7 5 8 (set (reg:QI 93)
(mem:QI (reg/v/f:DI 89 [ s ]) [1 *s_4(D)+0 S1 A8])) "t.c":8 -1
 (nil))

(insn 8 7 9 (parallel [
(set (reg:QI 92)
(and:QI (reg:QI 93)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "t.c":8 -1

and similar the store has to use a read-modify-write cycle.  Now, for this
case this is all moot since the xor doesn't change the bits of the padding.

But at the point we are expanding

  _1 = s_4(D)->b1;
  _2 = ~_1;
  s_4(D)->b1 = _2;

this isn't easily visible.

The general idea is to lower bitfields loads/stores earlier on GIMPLE,
see various (partial) approaches posted over the last 10 years.

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|7.0 |8.0
   Last reconfirmed||2017-05-16
  Component|c   |middle-end
 CC||bergner at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|-O3 produces ice in |[8 Regression] -O3 produces
   |group_case_labels_stmt  |ice in
   ||group_case_labels_stmt
   Target Milestone|--- |8.0

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

[Bug tree-optimization/80776] -Wformat-overflow false positive for %d on integer bounded by __builtin_unreachable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-16
 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Possibly the walk in remove_range_assertions visits the latter before the
former block but in principle we do have code to handle this there.

Confirmed also as missed VRP optimization.

[Bug ipa/79849] diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug ipa/79850] diagnostics: typo in "fields has different layout"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk, so far.

[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-05-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I'll have a look.  Probably "caused" by more aggressively verifying loops.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||ice-checking
   Last reconfirmed||2017-05-16
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|-O3 causes error: inline|[7/8 Regression] -O3 causes
   |clone in same comdat group  |error: inline clone in same
   |list|comdat group list
   Target Milestone|--- |7.2
  Known to fail||7.1.0

--- Comment #5 from Richard Biener  ---
Confirmed.  Fails on the branch with -fchecking.

[Bug ipa/79849] diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue May 16 08:57:05 2017
New Revision: 248089

URL: https://gcc.gnu.org/viewcvs?rev=248089=gcc=rev
Log:
Fix 2 typos in ipa-devirt.c.

2017-05-16  Martin Liska  

PR ipa/79849.
PR ipa/79850.
* ipa-devirt.c (warn_types_mismatch): Fix typo.
(odr_types_equivalent_p): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug ipa/79850] diagnostics: typo in "fields has different layout"

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue May 16 08:57:05 2017
New Revision: 248089

URL: https://gcc.gnu.org/viewcvs?rev=248089=gcc=rev
Log:
Fix 2 typos in ipa-devirt.c.

2017-05-16  Martin Liska  

PR ipa/79849.
PR ipa/79850.
* ipa-devirt.c (warn_types_mismatch): Fix typo.
(odr_types_equivalent_p): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c

[Bug c/80777] long int structure members allocated incorrect 8 bytes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
long is 64 bits on x86_64, uint32_t is (obviously) 32 bits. This is not a bug.

[Bug c/80775] -O3 produces ice in group_case_labels_stmt

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Bug seems to be between revision 247833 and 247844.

[Bug c/80777] New: long int structure members allocated incorrect 8 bytes

[jrose.manila at gmail dot com]

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

Bug ID: 80777
   Summary: long int structure members allocated incorrect 8 bytes
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrose.manila at gmail dot com
  Target Milestone: ---

Created attachment 41363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41363=edit
source file describing bug

Problem: long int structure members are allocated incorrect 8 bytes (as if long
long), whereas retyping them with __uint32_t results in correct 4 bytes


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.4.0 (GCC)

running on cygwin64 for windows 10:
$ uname -a
CYGWIN_NT-10.0 Caroline-2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin


Source: gcc5.4.0.bug.c (attached)
See definition of struct ProductId, members len, format, u.v3.edition.id


How to test:
1. Edit ProductId structure members len, format declarations to either
__uint32_t or unsigned long int
2. gcc -g -Wall -Wextra gcc5.4.0.bug.c -o gcc5.4.0.bug.exe
3. gdb ./gcc5.4.0.bug.exe
b main
b 142
run
c
n
print *pId

and you will see incorrect 8-byte values for pId->len and pId->format if you
declare as unsigned long int, or you will see correct 4-byte values if you
declare with __uint32_t

Further tests within gdb:
print sizeof(long int)
print sizeof(pId->len)
print sizeof(ii)