[Bug target/85744] Returning INT_FAST64_MIN become zero

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #3 from Andrew Pinski  ---
Can you provide the preprocessed source then?

[Bug c/85744] Returning INT_FAST64_MIN become zero

[cerlane at nscc dot sg]

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

--- Comment #2 from cerlane  ---
(In reply to Andrew Pinski from comment #1)
> Try 0x8000ULL

No unfortunately, it still returns 0x0.

[Bug c/85744] Returning INT_FAST64_MIN become zero

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Try 0x8000ULL

[Bug c/85744] New: Returning INT_FAST64_MIN become zero

[cerlane at nscc dot sg]

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

Bug ID: 85744
   Summary: Returning INT_FAST64_MIN become zero
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cerlane at nscc dot sg
  Target Milestone: ---

When returning the value 0x8000LL from a function (return type
int_fast64_t), the value becomes zero (0x0).
Is this a feature to guard against underflowing? If so, how can I return
0x8000LL?

[Bug c++/85743] New: Cannot call template member function inside a variadic lambda unless specifying `this`

[gufideg at gmail dot com]

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

Bug ID: 85743
   Summary: Cannot call template member function inside a variadic
lambda unless specifying `this`
   Product: gcc
   Version: 8.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: ---

When using a particular pattern to expand a variadic template inside a member
function, `this->` need to be specified before calling other member functions.

Here is the most reduced repro I can come with at the moment:

#include 
#include 

template
struct tuple_sequence;

template
struct tuple_sequence> {
using type = std::tuple...>;
};

template
constexpr auto apply_sequence_for(F function) -> decltype(auto) {
return std::apply(function, typename
tuple_sequence::type{});
}

template
struct Foo {
template
constexpr void boom(int i) const {}

constexpr auto foo(std::array data) const {
apply_sequence_for([this, ](auto... s) {
(boom(data[s]), ...);
});
}
};

int main() {
Foo f;
f.foo({0, 1, 2});
}


Notice the particular expansion pattern `boom(data[s])`. The bug won't
trigger if the pattern is replaced by `boom(data[s])` or even
`boom(data[0])`.


This code compiles under Clang 6.0.0
Live example: https://godbolt.org/g/n6wMUS

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

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

--- Comment #5 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Fri May 11 01:44:05 2018
New Revision: 260149

URL: https://gcc.gnu.org/viewcvs?rev=260149=gcc=rev
Log:
correct changelog!
2018-05-10  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83140 - assoc_legendre returns negated value when m is odd
* include/tr1/legendre_function.tcc (__assoc_legendre_p): Add __phase
argument defaulted to +1.  Doxy comments on same.
* testsuite/special_functions/02_assoc_legendre/
check_value.cc: Regen.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/check_value.cc: Regen.


Modified:
trunk/libstdc++-v3/ChangeLog

[Bug fortran/85742] New: sizeof allocatable arrays returning wrong value

[cesar at gcc dot gnu.org]

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

Bug ID: 85742
   Summary: sizeof allocatable arrays returning wrong value
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cesar at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44113
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44113=edit
sizeof test

As of trunk revision 257065, the sizeof function is returning incorrect results
on assume-sized allocated arrays and scalars. See the attached test case for
more details.

I hit this problem while rebasing openacc-gcc-7-branch Fortran changes to GCC
8. Basically, OpenACC provides a Fortran module which contains an
acc_is_present routine, which passes the sizeof an array along with the pointer
to the array to the runtime to determine if that array is resident on the
device. However, now sizeof is returning bogus results.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(a a) != 0

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> These functions are not functional equivalent.
>
> In the b.c, it records the max location but it is the last element which
> contains that value.  While in c.c, the first element which contains
> the value is recorded.
> (In reply to Andrew Pinski from comment #1)
> > These functions are not functional equivalent.
>
> To get them equivalent, you either need to use >= or <=.

Could you please elaborate?

The results seem to depend on the processor. On my Core i7 I get around 
43000 cycles for both tests and -O2 or above, except -Ofast -funroll-loops
which gives around 26000 cycles for the first test and 58000 cycles for
the second one.

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #8 from Jonathan Wakely  ---
I don't think we can do anything to fix this in libstdc++ so I've reported it
to glibc:
https://sourceware.org/bugzilla/show_bug.cgi?id=23164

[Bug c++/85363] Throwing exception from member constructor (brace initializer vs initializer list)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
P::P () is marked as TREE_NOTHROW because when we're processing X::X ((struct X
*) <<< Unknown tree: void_cst >>>, 20) (which can throw) in
set_flags_from_callee, cfun is null in this case, so we don't mark P::P() as
can_throw.

If struct P were
struct P {
P () : x {5} {}
X x;
};

it would work as expected, because when processing X::X(), cfun would be
non-null, so it would be marked as can_throw.

[Bug fortran/85687] ICE in gfc_sym_identifier, at fortran/trans-decl.c:351

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 10 22:49:44 2018
New Revision: 260141

URL: https://gcc.gnu.org/viewcvs?rev=260141=gcc=rev
Log:
2018-05-10  Steven G. Kargl  

PR fortran/85687
* check.c (gfc_check_rank): Check that the argument is a data object.

2018-05-10  Steven G. Kargl  

PR fortran/85687
* gfortran.dg/pr85687.f90: new test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr85687.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85521] [8/9 Regression] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2049

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 10 22:45:38 2018
New Revision: 260139

URL: https://gcc.gnu.org/viewcvs?rev=260139=gcc=rev
Log:
2018-05-10  Steven G. Kargl  

PR fortran/85521
* array.c (gfc_resolve_character_array_constructor): Substrings
with upper bound smaller than lower bound are zero length strings.

2018-05-10  Steven G. Kargl  

PR fortran/85521
* gfortran.dg/pr85521_1.f90: New test.
* gfortran.dg/pr85521_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr85521_1.f90
trunk/gcc/testsuite/gfortran.dg/pr85521_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70870] Segmentation violation in gfc_assign_data_value

[kargl at gcc dot gnu.org]

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

--- Comment #10 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu May 10 22:43:00 2018
New Revision: 260138

URL: https://gcc.gnu.org/viewcvs?rev=260138=gcc=rev
Log:
2018-05-10  Steven G. Kargl  

PR fortran/70870
* data.c (gfc_assign_data_value): Check that a data object does
not also have default initialization.

2018-05-10  Steven G. Kargl  

PR fortran/70870
* gfortran.dg/pr70870_1.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr70870_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirming that this is a useful meta-bug.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> These functions are not functional equivalent.

To get them equivalent, you either need to use >= or <=.

[Bug middle-end/85740] Non-optimal determining maximum in a loop

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
These functions are not functional equivalent.

In the b.c, it records the max location but it is the last element which
contains that value.  While in c.c, the first element which contains the value
is recorded.

[Bug tree-optimization/85741] New: [meta-bug] bogus/missing -Wformat-overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 85741
   Summary: [meta-bug] bogus/missing -Wformat-overflow
   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: ---

A meta-bug to group -Wstringop-overflow false positives and false negatives.

[Bug middle-end/85598] [7/8/9 Regression] Incorrect warning only at -O2 and -O3

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The problem is that the warning pass sees x as having the range of [0, 256]
rather than [0, 255].  The incorrect range can also be seen in EVRP.  There is
no warning at -O1 because the range determined at that level is that of
unsigned int which is considered to be the same as unknown.  The warning does
not trigger for such ranges.

[Bug middle-end/85740] New: Non-optimal determining maximum in a loop

[tkoenig at gcc dot gnu.org]

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

Bug ID: 85740
   Summary: Non-optimal determining maximum in a loop
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

There is a problem with loops determining the maximum (or minimum)
of a value. I noticed this when looking at inline code generated
by gfortran for maxloc/minloc.

Consider the two programs which select the position of a
maximum from a rather large integer array. They are identical,
except that b.c uses __builtin_expect in the inner loop:

$ cat b.c
#include 
#include 
#include 
#include 

#define N (1<<28)

int foo(int *a, int n)
{
  int m, nm;
  int i;

  m = -2;
  nm = -1;
  for (i=0; i m, 0))
{
  m = a[i];
  nm = i;
}
}
  return nm;
}

int 
main(int argc, char **argv) {
  unsigned long long t1, t2;

  int *p = malloc(N * sizeof(int));
  for (int i=0; i m)
{
  m = a[i];
  nm = i;
}
}
  return nm;
}

int 
main(int argc, char **argv) {
  unsigned long long t1, t2;

  int *p = malloc(N * sizeof(int));
  for (int i=0; i

[Bug c++/70693] valgrind error in get_visual_column

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-10
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #5 from David Malcolm  ---
Confirmed on trunk.

I believe it's trying to access column 8 of line 55, which I think is just 4
space characters.


(In reply to David Binderman from comment #2)
> Problem seems to have come back, somewhere between revisions 259747 and
> 259789

Probably r259768, which added some extra checking when accessing source lines.

[Bug target/85733] ARM -mbe8 behaviour doesn't match documentation

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
Sounds like a regression if this is the case, since bpabi.h in GCC 7 does 
include march=armv8-a in BE8_LINK_SPEC.

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
Created attachment 44112
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44112=edit
Untested patch

Something like this, but I haven't tested, and other calls to build_this_parm
need auditing to check if "being a constructor" is set before.

[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00509.html

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #10 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #9)
> The testcases from comment #6 and comment #7 are now (gcc-8) properly
> optimized. The original has lost one of the 2 calls to free, one remains:
> 
>  __old_val_4 = MEM[(void * &)a_2(D)];
>   MEM[(void * &)a_2(D)] = 0B;
>   __old_val_5 = MEM[(void * &)b_3(D)];
>   MEM[(void * &)b_3(D)] = 0B;
>   MEM[(void * &)a_2(D)] = __old_val_5;
>   _6 = MEM[(void * &)b_3(D)];
>   MEM[(void * &)b_3(D)] = __old_val_4;
>   if (_6 != 0B)
> 
> (whether a is the same as b or disjoint, _6 is always 0, but that's not easy
> to see)

Do to the above analysis, there is another bug which this is a dup of but I
can't find it right now.

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[glisse at gcc dot gnu.org]

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

--- Comment #9 from Marc Glisse  ---
The testcases from comment #6 and comment #7 are now (gcc-8) properly
optimized. The original has lost one of the 2 calls to free, one remains:

 __old_val_4 = MEM[(void * &)a_2(D)];
  MEM[(void * &)a_2(D)] = 0B;
  __old_val_5 = MEM[(void * &)b_3(D)];
  MEM[(void * &)b_3(D)] = 0B;
  MEM[(void * &)a_2(D)] = __old_val_5;
  _6 = MEM[(void * &)b_3(D)];
  MEM[(void * &)b_3(D)] = __old_val_4;
  if (_6 != 0B)

(whether a is the same as b or disjoint, _6 is always 0, but that's not easy to
see)

[Bug c++/85739] New: internal compiler error: in finish_member_declaration, at cp/semantics.c:3057

[freddie_chopin at op dot pl]

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

Bug ID: 85739
   Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:3057
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

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

Attached preprocessed source code.

Trying to build it:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-g++ -fno-use-cxa-atexit -fno-rtti -fno-exceptions
-mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -g -ggdb3 -O2
-ffunction-sections -fdata-sections -Wall -Wextra -Wshadow -std=gnu++17 -o
Scheduler.cpp.o -c Scheduler.ii
In file included from
../include/distortos/internal/scheduler/ThreadListNode.hpp:15,
 from
../include/distortos/internal/scheduler/ThreadControlBlock.hpp:17,
 from ../include/distortos/internal/scheduler/Scheduler.hpp:15,
 from ../source/scheduler/Scheduler.cpp:12:
../include/estd/IntrusiveList.hpp: In instantiation of 'class
estd::IntrusiveListConstIterator':
../source/scheduler/Scheduler.cpp:345:31:   required from here
../include/estd/IntrusiveList.hpp:650:1: internal compiler error: in
finish_member_declaration, at cp/semantics.c:3057
 {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ arm-none-eabi-g++ --version
arm-none-eabi-g++ (bleeding-edge-toolchain) 8.1.0
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.

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

The exact same thing happens for gcc 7.3.0 and 6.3.0. There is no error when
using `-std=gnu++11` or `-std=gnu++14`. Whether or not GNU extensions are
enabled makes no difference.

Let me know if I should try to narrow the problem down, as the preprocessed
test case is indeed a bit huge.

[Bug c++/80227] [6/7 Regression] SFINAE ambiguity with a pointer to array argument

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||dawid_jurek at vp dot pl

--- Comment #8 from Jason Merrill  ---
*** Bug 80169 has been marked as a duplicate of this bug. ***

[Bug c++/80169] G++ (cc1plus) hangs forever compiling template when size of array is enormous

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jason Merrill  ---
Fixed by patch for 80227.

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

[Bug c++/80227] [6/7 Regression] SFINAE ambiguity with a pointer to array argument

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
*** Bug 68280 has been marked as a duplicate of this bug. ***

[Bug c++/68280] dependent arrays of excessive size not diagnosed

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed by patch for 80227.

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

[Bug c++/80227] [6/7 Regression] SFINAE ambiguity with a pointer to array argument

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #6 from Jason Merrill  ---
*** Bug 82893 has been marked as a duplicate of this bug. ***

[Bug c++/82893] Bad diagnostic on negative sized array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed by patches for 80227.

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

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to Marc Glisse from comment #13)
> I have no idea what was changed in gcc-8 that
> helped the original testcase,

(optimization happens in FRE1)
It could be an optimization that says that either the objects don't alias and
we are writing _1, or they are the same object and we are writing _1, so just
write _1 without caring about aliasing. This was definitely discussed, but I
didn't remember that it had been committed (bug 80617 is still open).

Anyway, if you want to experiment, the function build_this_parm (in
gcc/cp/decl.c) seems like a good starting point.

[Bug fortran/85738] New: internal compiler error: verify_gimple failed

[mpolacek at gcc dot gnu.org]

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

Bug ID: 85738
   Summary: internal compiler error: verify_gimple failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

With this invalid code:

module test
contains
  function gx(l)
implicit none
integer, intent(in) :: l
integer, external :: fx
real(8) :: gx
gx=fx(l)**2/(2*(2*l + 1))
  end function gx
end module test

function fx(l)
  implicit none
  integer, intent(in) :: l
  real(8) :: fx
  fx = l
end function fx

I get
$ ./f951 -quiet z.f90
z.f90:3:0:

   function gx(l)

Error: type mismatch in binary expression
integer(kind=4)

real(kind=8)

integer(kind=4)

_5 = D.3778 / _4;
z.f90:3:0: internal compiler error: verify_gimple failed
0xf9791e verify_gimple_in_seq(gimple*)
/home/marek/src/gcc/gcc/tree-cfg.c:5021
0xc13c82 gimplify_body(tree_node*, bool)
/home/marek/src/gcc/gcc/gimplify.c:12715
0xc14162 gimplify_function_tree(tree_node*)
/home/marek/src/gcc/gcc/gimplify.c:12805
0x9d7e94 cgraph_node::analyze()
/home/marek/src/gcc/gcc/cgraphunit.c:670
0x9d9779 analyze_functions
/home/marek/src/gcc/gcc/cgraphunit.c:1131
0x9de439 symbol_table::finalize_compilation_unit()
/home/marek/src/gcc/gcc/cgraphunit.c:2691
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/85735] f951 crashes on empty input

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug fortran/85735] f951 crashes on empty input

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu May 10 18:33:22 2018
New Revision: 260120

URL: https://gcc.gnu.org/viewcvs?rev=260120=gcc=rev
Log:
PR fortran/85735
* options.c (gfc_post_options): Set main_input_filename.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c

[Bug fortran/85737] gfortran 8.1.0 false positive with -Wdo-subscript

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Thomas Koenig  ---
It is working as (currently) designed.

To quote from the description:

`-Wdo-subscript'
 Warn if an array subscript inside a DO loop could lead to an
 out-of-bounds access even if the compiler can not prove that the
 statement is actually executed, in cases like
real a(3)
do i=1,4
  if (condition(i)) then
a(i) = 1.2
  end if
end do
 This option is implied by `-Wextra'.

Some more extensive data flow analysis may be possible in
future versions of gfortran.

It is always possible to turn this off via -Wno-do-subscript.

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse  ---
Explicitly marking the constructor with __restrict lets it optimize also the
testcase in comment #12. I have no idea what was changed in gcc-8 that helped
the original testcase, but it wasn't equivalent to marking constructors with
__restrict :-(

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[gnu-org at bignm dot com]

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

--- Comment #7 from Tom Straub  ---
Hi Jonathan,

Thanks for really tracking that down. Looks like a really deep and subtle bug.
I hope somebody knows where to look to fix it in the glibc code.

Best, Tom

Dassault SIMULIA Accounts

[Kristen Robinson]

Hi,

 

I would like to know if you are interested in acquiring Dassault SIMULIA
Users List.

 

Information fields: Names, Title, Email, Phone, Company Name, Company URL,
Company physical address, SIC Code, Industry, Company Size (Revenue and
Employee).

 

We also have related technology users like: Altair Hyperworks, Altair
HyperMesh, Autodesk AutoCAD, Dassault Systemes, Dassault SolidWorks,
Dassault CATIA, Dassault DraftSight, Autodesk Revit, Siemens NX, PTC and
many more.

 

Let me know if you are interested and I will get back to you with the counts
and pricing.

 

Regards,
Kristen Robinson
Data Analyst

 

To opt out, please reply with 'Unsubscribe' in the Subject Line.

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
This isn't a libstdc++ bug, I get the same with a pure C program:

$ cat loc.c
#include 
#include 
#include 

int main()
{
  locale_t loc = newlocale(1 << LC_ALL, "en_US.UTF-8", 0);
  const char* ccurr = nl_langinfo_l(CURRENCY_SYMBOL, loc);
  printf("Currency symbol: %s\n", ccurr);
  return 0;
}
$ gcc -D_GNU_SOURCE loc.c
$ ./a.out
Currency symbol: $
$ gcc -D_GNU_SOURCE loc.c -static
$ ./a.out
Currency symbol: 

So this seems to be a glibc problem.

[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 10 17:40:28 2018
New Revision: 260119

URL: https://gcc.gnu.org/viewcvs?rev=260119=gcc=rev
Log:
PR c++/85662
* c-common.h (fold_offsetof_1): Removed.
(fold_offsetof): Add TYPE argument defaulted to size_type_node and
CTX argument defaulted to ERROR_MARK.
* c-common.c (fold_offsetof_1): Renamed to ...
(fold_offsetof): ... this.  Remove wrapper function.  Add TYPE
argument, convert the pointer constant to TYPE and use size_binop
with PLUS_EXPR instead of fold_build_pointer_plus if type is not
a pointer type.  Adjust recursive calls.

* c-fold.c (c_fully_fold_internal): Use fold_offsetof rather than
fold_offsetof_1, pass TREE_TYPE (expr) as TYPE to it and drop the
fold_convert_loc.
* c-typeck.c (build_unary_op): Use fold_offsetof rather than
fold_offsetof_1, pass argtype as TYPE to it and drop the
fold_convert_loc.

* cp-gimplify.c (cp_fold): Use fold_offsetof rather than
fold_offsetof_1, pass TREE_TYPE (x) as TYPE to it and drop the
fold_convert.

* g++.dg/ext/offsetof2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/offsetof2.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[antoshkka at gmail dot com]

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

--- Comment #12 from Antony Polukhin  ---
(In reply to Marc Glisse from comment #10)
> This seems fixed in 8.1 (at least we don't generate the extra mov anymore),
> can you check?

Actually it still does not work for subobjects. For example
https://godbolt.org/g/zPha3U

Code 

struct array {
int d[2];
};

struct test {
array data1;
array data2;

test(const array& t);
};

test::test(const array& t)
: data1{t}
, data2{t}
{}

produces assembly

test::test(array const&):
  mov rax, QWORD PTR [rsi]
  mov QWORD PTR [rdi], rax
  mov rax, QWORD PTR [rsi]   <== Not required. Could not alias
  mov QWORD PTR [rdi+8], rax
  ret

[class.ctor] paragraph 14 also covers this case:

"During the construction of an object, if the value of the object *or any of
its subobjects* is accessed through a glvalue that is not obtained, directly or
indirectly, from the constructor’s this pointer, the value of the object or
subobject thus obtained is unspecified."

Looks like not only `this` should be marked with __restrict, but also all the
subobjects of the type.

[Bug fortran/85737] New: gfortran 8.1.0 false positive with -Wdo-subscript

[spapanik21 at gmail dot com]

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

Bug ID: 85737
   Summary: gfortran 8.1.0  false positive with -Wdo-subscript
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spapanik21 at gmail dot com
  Target Milestone: ---

After the update to gcc-fortran 8.1.0 the following program:

program false_positive
integer, dimension(5, 5) :: matrix = reshape( &
(/ &
32, 63, 93, 53, 69, &
32, 40, 62, 76, 36, &
85, 74, 14, 36, 16, &
16, 23, 57, 15, 54, &
11, 89, 19, 67, 48  &
/), &
shape(matrix), &
order=(/ 2, 1 /) &
)
integer :: i, j, m, n

m = size(matrix, 1)
n = size(matrix, 2)
do i = 1, m
do j = 1, n
if (j > 4) then
print *, matrix(i, j - 3)
end if
end do
end do
end program false_positive

produces the following warning:
stephanos@darwin $ gfortran -Wdo-subscript -c fp.f90
fp.f90:20:35:

fp.f90:18:19:

 do j = 1, n
   2
fp.f90:20:35:

 print *, matrix(i, j - 3)
   1
Warning: Array reference at (1) out of bounds (-2 < 1) in loop beginning at (2)
[-Wdo-subscript]

The warning was not present in gcc-fortran 7.3.1

[Bug c++/85717] anonymous union in initializer list : do not handle the types correctly

[daffra.claudio at gmail dot com]

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

--- Comment #2 from claudio daffra  ---

if swap types, result of compilation changes :

   union {
uint64_tinteger ;   
double  real;   
} ;

   union {
double  real;   
uint64_tinteger ;   
} ;

link  stack overflow :

https://stackoverflow.com/questions/50260850/anonymous-union-in-initializer-list-do-not-handle-the-types-correctly

[Bug c++/85717] anonymous union in initializer list : do not handle the types correctly

[daffra.claudio at gmail dot com]

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

--- Comment #1 from claudio daffra  ---

if swap types, result of compilation changes :

   union {
uint64_tinteger ;   
double  real;   
} ;

   union {
double  real;   
uint64_tinteger ;   
} ;

link  stack overflow :

https://stackoverflow.com/questions/50260850/anonymous-union-in-initializer-list-do-not-handle-the-types-correctly

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[antoshkka at gmail dot com]

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

--- Comment #11 from Antony Polukhin  ---
Seems perfect https://godbolt.org/g/GX3GQd
The mov is not generated for any constructor and the following code:

extern struct A a;
struct A {
  int m, n;
  A(const A );
};

A::A(const A ) : m(v.m), n((a.m = 1, v.m)) {}

Is not optimized to "A::A(int, const A ) : m(v.m), n(v.m) { a.m = 1; }"
(which is a mistake).


Are there some tests to make sure that the `mov` won't appear again?

[Bug c++/85736] New: Support warn_unused or warn_unused_result on specific constructors

[redbeard0531 at gmail dot com]

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

Bug ID: 85736
   Summary: Support warn_unused or warn_unused_result on specific
constructors
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

It would be nice to get the benefits of those attributes on a per-constructor
basis, rather than requiring them on the whole type. The particular use case I
have in mind is for unique_lock's default constructor (or at least on our
wrapper around it). I recently did a code review where someone typed:

std::unique_lock myMutex;

where they meant to use:

std::unique_lock lk(myMutex);

There is currently no warning for this at -Wall -Wextra, although thankfully it
is at least caught when myMutex has parentheses around it, which is the more
common mistake. Clearly, it wouldn't make sense to put warn_unused on the whole
unique_lock since the second line is fine.

It would probably make sense on almost all default constructors actually, since
with the exception of a few specific types that alter global or thread-local
state, why are you declaring a default constructed variable then not using it
at all? But on a few types like unique_lock it seems actively dangerous rather
than just simply wasteful.

[Bug fortran/85735] f951 crashes on empty input

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-05-10
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I have a patch.

[Bug fortran/85735] New: f951 crashes on empty input

[mpolacek at gcc dot gnu.org]

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

Bug ID: 85735
   Summary: f951 crashes on empty input
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Entering ^D:

$ ./f951 -quiet
f951: Warning: Reading file ‘’ as free form
.file   ""
f951: internal compiler error: Segmentation fault
0xf41544 crash_signal
/home/marek/src/gcc/gcc/toplev.c:325
0xf39315 get_identifier(char const*)
/home/marek/src/gcc/gcc/stringpool.c:95
0x86d423 gfc_create_decls
/home/marek/src/gcc/gcc/fortran/f95-lang.c:195
0x86d45c gfc_be_parse_file
/home/marek/src/gcc/gcc/fortran/f95-lang.c:203
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This works though:

$ ./f951 -quiet -
f951: Warning: Reading file ‘’ as free form

[Bug c++/85728] strncpy -Wstringop-truncation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
Please review https://gcc.gnu.org/bugs to see what information GCC bug reports
are expected to include.  This one contains none of the requested information. 
As far as I can see the warning message reflects the effect of the strncpy call
in the function but the source code printed by the message doesn't correspond
to the source code so it's not clear how the diagnostic messages are related to
the code snippet, or even what it is you are trying to point out.  Thus this is
not a valid report.

If you can provide the requested information and explain what you think is
wrong with GCC's output feel free to reopen it.

[Bug libstdc++/85729] including c++ headers within extern "C" linkage specification

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #5 from Jonathan Wakely  ---
Great, fixed in trunk then. Let me know if you need it backported, it would be
safe for the branches.

[Bug c/85562] -Wsuggest-attribute=malloc misleads about "returning normally"

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #2 from Paul Eggert  ---
Also please see GCC bug 85734, which is about false alarms with
-Wsuggest-attribute=malloc.

[Bug c/85734] New: --suggest-attribute=malloc misdiagnoses static functions

[eggert at gnu dot org]

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

Bug ID: 85734
   Summary: --suggest-attribute=malloc misdiagnoses static
functions
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

GCC 8's --suggest-attribute=malloc diagnoses static functions, even though the
malloc attribute is useless for static functions (after all, the compiler has
deduced the property on its own). This is leading to my having to litter code
with '__attribute__ (malloc)' declarations merely to pacify GCC. GCC should
treat the malloc attribute like other attributes (e.g., const), and should
issue the diagnostic only for non-static functions where the attribute is in
fact useful.

This bug report differs from GCC bug 85562, in that this bug is about false
alarms whereas bug 85562 is about the wording of the diagnostics.

Here is an illustration of the bug. For this program:

#include 
   void *pe (void *x) { return x; }
static void *ps (void *x) { return x; }
   void *me (size_t n) { return malloc (n); }
static void *ms (size_t n) { return malloc (n); }
int main (void) { return !pe (me (1)) + !ps (ms (2)); }

gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1) x86-64, with the command:

gcc -Wsuggest-attribute=malloc -Wsuggest-attribute=const -O2 -S example.c

outputs the diagnostics at the end of this bug report. GCC correctly diagnoses
'pe' amd 'me', which are extern. GCC is correctly silent for the pure function
'ps', which is static. However, GCC mistakenly diagnoses 'ms', which is also
static.

example.c: In function ‘ms’:
example.c:5:14: warning: function might be candidate for attribute ‘malloc’ if
it is known to return normally [-Wsuggest-attribute=malloc]
 static void *ms (size_t n) { return malloc (n); }
  ^~
example.c: In function ‘pe’:
example.c:2:14: warning: function might be candidate for attribute ‘const’
[-Wsuggest-attribute=const]
void *pe (void *x) { return x; }
  ^~
example.c: In function ‘me’:
example.c:4:14: warning: function might be candidate for attribute ‘malloc’ if
it is known to return normally [-Wsuggest-attribute=malloc]
void *me (size_t n) { return malloc (n); }
  ^~

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #12 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #11)
> I've started to work on a new patch according to review feedbacks. I've
> reached the stage where I can compile without -fPIC with the stack protect
> test being an UNSPEC split after register allocation as suggested.
> 
> Next steps are:
> 
> 1) do the same for the stack protect set (ie setting the canari)

Done

> 3) include the conditional branch in the combined stack protect test to
> ensure the register holding the result of the comparison is not spilled
> before it's used for the conditional branch

Done

> 5) cleanup the patch

In progress

> 2) add support for PIC access to the guard
> 4) clear all registers involved before branching

TODO.

[Bug c++/85715] internal compiler error: in reshape_init_class ( in anonymous union )

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

--- Comment #2 from Marek Polacek  ---
Fixed by r258585.

[Bug c++/85715] internal compiler error: in reshape_init_class ( in anonymous union )

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed with G++ 7; fixed for 8 and 9.

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
This seems fixed in 8.1 (at least we don't generate the extra mov anymore), can
you check?

[Bug lto/48200] linking shared library with LTO results in different exported symbols

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #19 from Xi Ruoyao  ---
I think the best result would be like FMV, for e.g.

int foo(void) __attribute__((symver("@1.1")))
{
  return 0;
}

int foo(void) __attribute__((symver("@@1.2")))
{
  return 1;
}

Would produce two symbols "foo.symver.1.1" and "foo.symver.1.2", and

.symver foo.symver.1.1 foo@1.1
.symver foo.symver.1.2 foo@@1.2

And we can also use

int foo(void) __attribute__((symver("@1.0"), alias("foo_old")));

But this seems difficult in C FE, it tends to complain the "redefine" of foo -
note that FMV is still only for C++ until now.

[Bug libstdc++/85729] including c++ headers within extern "C" linkage specification

[nsz at gcc dot gnu.org]

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

--- Comment #4 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #3)
> Does that fix it?

yes, thanks.

[Bug tree-optimization/85693] Generation of SAD (Sum of Absolute Difference) instruction

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 10 14:50:59 2018
New Revision: 260117

URL: https://gcc.gnu.org/viewcvs?rev=260117=gcc=rev
Log:
PR target/85693
* config/i386/sse.md (usadv64qi): New expander.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug ipa/85655] [8/9 Regression] ICE with -flto and -O2 during IPA pass: cp lto1: internal compiler error: Segmentation fault

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I have posted a proposed fix to the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00468.html

[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Thu May 10 14:31:54 2018
New Revision: 260116

URL: https://gcc.gnu.org/viewcvs?rev=260116=gcc=rev
Log:
2018-05-10  Thomas Koenig  

PR fortran/54613
* intrinsic.texi: Document BACK for MINLOC and MAXLOC.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

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

--- Comment #4 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Thu May 10 13:59:52 2018
New Revision: 260115

URL: https://gcc.gnu.org/viewcvs?rev=260115=gcc=rev
Log:
2018-05-10  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83140 - assoc_legendre returns negated value when m is odd
* include/tr1/legendre_function.tcc (__assoc_legendre_p): Add __phase
argument defaulted to +1.  Doxy comments on same.
* testsuite/special_functions/02_assoc_legendre/
check_assoc_legendre.cc: Regen.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/check_tr1_assoc_legendre.cc: Regen.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/legendre_function.tcc
   
trunk/libstdc++-v3/testsuite/special_functions/02_assoc_legendre/check_value.cc
   
trunk/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/02_assoc_legendre/check_value.cc

[Bug target/85733] New: ARM -mbe8 behaviour doesn't match documentation

[rsandifo at gcc dot gnu.org]

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

Bug ID: 85733
   Summary: ARM -mbe8 behaviour doesn't match documentation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

The documentation for the ARM -mbe8 option says "For ARMv6 and later
architectures the default is BE8, for older architectures the default is
BE32.".  But in arm-cpus.in it looks like only the ARMv6 fgroup includes the
be8 feature, while ARMv7 and later are based on ARMv6m, which doesn't inherit
ARMv6 and doesn't specify be8 directly.  This means that -march=armv8-a (say)
selects BE32 by default.

[Bug target/84379] Problems with sol2.c GTY handling

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2018-05/msg00466.ht
   ||ml
   Last reconfirmed||2018-05-10
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Mine, patch posted.

[Bug target/85606] [8 regression] Assembly file generated for ARM Cortex-M0 should not specify `.arch armv6-m` at all or use `.arch armv6s-m`

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-10
   Target Milestone|--- |8.2
Summary|Assembly file generated for |[8 regression] Assembly
   |ARM Cortex-M0 should not|file generated for ARM
   |specify `.arch armv6-m` at  |Cortex-M0 should not
   |all or use `.arch armv6s-m` |specify `.arch armv6-m` at
   ||all or use `.arch armv6s-m`
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
This is the convergence of a number of niggly issues.

Initially Arm defined both ARMv6-M and ARMv6S-M.  The two differed only by
support for the SVC instruction in the latter.  Later, they dropped the name
ARMv6S-M but added support for SVC to ARMv6-M (in effect they made ARMv6-M
equivalent to ARMv6S-M).

To avoid massive churn on the assembler every time new CPU names are added, we
changed GCC-8 to not emit CPU names directly into the assembler files
(architecture names are much more stable and smaller in number); this makes it
far more likely that you won't have to update GAS each time a new CPU name is
added (a Good Thing TM).

Cortex-m0, cortex-m0plus and cortex-m1 are all ARMv6-M parts, but they are
really, in GCC/gas terminology ARMv6S-M parts.  Gas seems to treat these CPUs
as ARMv6S-M, but still distinguishes between v6-M and v6S-M, hence the failure
reported.

So I think the compiler should treat all these parts as ARMv6S-M going forward.
 That's a fairly simple change to arm-cpus.in.

I think GAS needs some changes as well, to make .arch armv6-m be treated in the
same way as armv6s-m, but that's a separate issue.

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[gnu-org at bignm dot com]

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

--- Comment #5 from Tom Straub  ---
Hi Johnathon,

Okay, thanks for confirming. I didn't realize it was such as old bug. You're
right, I just recently switched over to using -static (got tired of the library
mismatches with multiple gcc versions on my system).

Best, Tom

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Reduced:

#include 
#include 

using namespace std;

void test(std::locale loc)
{
  cout << "--> Setting locale '" << loc.name() << "'\n";
  const moneypunct & l_facMoneyIntl = use_facet >(loc);
  const moneypunct & l_facMoneyNatl = use_facet >(loc);
  cout << "Natl Currency Symbol = '"; cout << l_facMoneyNatl.curr_symbol();
cout << "'" << "\n";
  cout << "Intl Currency Symbol = '"; cout << l_facMoneyIntl.curr_symbol();
cout << "'" << "\n";
  cout << "\n";
}

int main(int argc, char** argv)
{
  locale global ("");
  // locale::global(global);
  test(locale(argc == 1 ? "pt_BR.utf8" : argv[1]));
  test(global);
  test(locale("C"));
}


Without -static this produces something like:

--> Setting locale 'pt_BR.utf8'
Natl Currency Symbol = 'R$'
Intl Currency Symbol = 'BRL '

--> Setting locale
'LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=en_GB.UTF-8;LC_TIME=en_GB.UTF-8;LC_COLLATE=C;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=en_GB.UTF-8;LC_ADDRESS=en_GB.UTF-8;LC_TELEPHONE=en_GB.UTF-8;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=en_GB.UTF-8'
Natl Currency Symbol = '£'
Intl Currency Symbol = 'GBP '

--> Setting locale 'C'
Natl Currency Symbol = ''
Intl Currency Symbol = ''

But with -static the fields are all blank:

--> Setting locale 'pt_BR.utf8'
Natl Currency Symbol = ''
Intl Currency Symbol = ''

--> Setting locale
'LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=en_GB.UTF-8;LC_TIME=en_GB.UTF-8;LC_COLLATE=C;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=en_GB.UTF-8;LC_ADDRESS=en_GB.UTF-8;LC_TELEPHONE=en_GB.UTF-8;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=en_GB.UTF-8'
Natl Currency Symbol = ''
Intl Currency Symbol = ''

--> Setting locale 'C'
Natl Currency Symbol = ''
Intl Currency Symbol = ''


I can reproduce this with any version tested (back to 4.3.6).

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[matthew.weber at rockwellcollins dot com]

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

Matt Weber  changed:

   What|Removed |Added

 CC||matthew.weber@rockwellcolli
   ||ns.com

--- Comment #20 from Matt Weber  ---
Another datapoint that libnss 3.35 fails to build on the microblaze arch
(uclibc) with any of the 6.x series and this bug's patch resolves that
(https://github.com/gcc-mirror/gcc/commit/df03ebc3574a0d7893127e3b9754a01abf2d8b70).
 

microblazeel-buildroot-linux-uclibc-gcc -o
Linux2.6_microblazeel_microblazeel-buildroot-linux-uclibc-gcc.br_real_glibc_PTH_OPT.OBJ/sslgrp.o
-c -O2 -fPIC   -pipe -ffunction-sections -fdata-sections -DHAVE_STRERROR
-DLINUX -Dlinux -Wall -Werror -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT
-DNSS_NO_INIT_SUPPORT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT
-DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -Isysroot/usr/include/nspr
-Ilibnss-3.35/dist/include -I../../../dist/public/nss
-I../../../dist/private/nss  sslgrp.c


However the libnss build works fine with the 7.x branch and master.  I've been
bisecting all 3 branches for a few days and figured I should just try this
patch before debugging the 6.x branch further.  I even went back and tried to
find common ancestors between the 6.x and 7.x and couldn't get a point where
the good/bad builds matched up.  Guessing backports on 6.x from master
introduced the libnss bug variant as the gcc/cse* and gcc/alias.x files had a
lot of updates from 5.x to 7.x.

Here's the stack trace on cc1 when its hung building a libnss sslgrp.c
file...
( A lot more find_base_terms() before this one)
#71 0x005ae67d in find_base_term(rtx_def*) ()
#72 0x005ae532 in find_base_term(rtx_def*) ()
#73 0x005ae67d in find_base_term(rtx_def*) ()
#74 0x005ae532 in find_base_term(rtx_def*) ()
#75 0x005ae67d in find_base_term(rtx_def*) ()
#76 0x005ae568 in find_base_term(rtx_def*) ()
#77 0x005b137d in write_dependence_p(rtx_def const*, rtx_def const*,
machine_mode, rtx_def*, bool, bool, bool) ()
#78 0x005b1585 in canon_anti_dependence(rtx_def const*, bool, rtx_def
const*, machine_mode, rtx_def*) ()
#79 0x0061c5e3 in cselib_invalidate_mem(rtx_def*) ()
#80 0x0061d32d in cselib_record_sets(rtx_insn*) ()
#81 0x0061e5c8 in cselib_process_insn(rtx_insn*) ()
#82 0x008774b8 in reload_cse_regs_1() ()
#83 0x008777dc in (anonymous
namespace)::pass_postreload_cse::execute(function*) ()
#84 0x0086714d in execute_one_pass(opt_pass*) ()

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Jonathan Wakely  ---
Oh I take it back, when I use -static I can reproduce the problem.

[Bug libstdc++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
It works fine for me with any version of GCC, including 6.4.0

Testing 'moneypunct' Facet:
--> Setting locale 'pt_BR.utf8'
Natl Currency Symbol = 'R$'
Intl Currency Symbol = 'BRL '
Natl Positive Sign   = ''
Intl Positive Sign   = ''
Natl Positive Format = { sign, symbol, space, value }
Intl Positive Format = { sign, symbol, space, value }
Natl Negative Sign   = '-'
Natl Negative Format = { sign, symbol, space, value }
Intl Negative Sign   = '-'
Intl Negative Format = { sign, symbol, space, value }
Natl Decimal Point   = ','
Intl Decimal Point   = ','
Natl Thousands Separator = '.'
Intl Thousands Separator = '.'
Natl Fractional Digits   = '2'
Intl Fractional Digits   = '2'
Natl Grouping Length [0] = 3 digits
Natl Grouping Length [1] = 3 digits
Intl Grouping Length [0] = 3 digits
Intl Grouping Length [1] = 3 digits

Are you sure something else didn't change on your system at the same time? The
C++ library just parses the locale definition data on your system, that data
comes from glibc not from GCC.

[Bug libstdc++/85729] including c++ headers within extern "C" linkage specification

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Does that fix it?

If not then we'll need a preprocessed reproducer.

[Bug libstdc++/85729] including c++ headers within extern "C" linkage specification

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Thu May 10 12:35:45 2018
New Revision: 260114

URL: https://gcc.gnu.org/viewcvs?rev=260114=gcc=rev
Log:
PR libstdc++/85729 add linkage specifications to headers

PR libstdc++/85729
* include/bits/c++config.h (__replacement_assert): Add linkage
specification.
* include/bits/std_abs.h: Add comment to closing brace of block.
* include/c_global/cstddef: Add linkage specification.
* include/c_global/cstring: Likewise.
* include/c_global/cwchar: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/include/bits/std_abs.h
trunk/libstdc++-v3/include/c_global/cstddef
trunk/libstdc++-v3/include/c_global/cstring
trunk/libstdc++-v3/include/c_global/cwchar

[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type

[antoshkka at gmail dot com]

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

--- Comment #9 from Antony Polukhin  ---
There's an identical issue for clang:
https://bugs.llvm.org/show_bug.cgi?id=37329

During review of that issue Richard Smith noted that the solution could be made
more generic by adding `__restrict` for `this` for any constructor (not just
copy and move constructors).

Does the violation of noalias in GCC could be treated as unspecified behavior
or is it undefined?

[Bug c++/70693] valgrind error in get_visual_column

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #4 from David Binderman  ---
svn blame seems to indicate that dmalcolm may be able to help.

[Bug c++/70693] valgrind error in get_visual_column

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Reduced code seems to be

  class a {
 public:typedef char b;
 };
 namespace {
   class c {
  enum  {
}
 d;
 bool e(a::b );  
};
   bool c::e(a::b ) {
  switch( d ) {
if( '>' ) ;
break;
   }
}
 }

[Bug c++/85732] use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[gnu-org at bignm dot com]

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

--- Comment #1 from Tom Straub  ---
Sorry, wrong compiler included in post, here is the right one:

$ g++ --version
g++ (Ubuntu 6.4.0-17ubuntu1~16.04) 6.4.0 20180424
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/85732] New: use_facet<moneypunct<char, true>>(mylocale) retrieving wrong locale information

[gnu-org at bignm dot com]

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

Bug ID: 85732
   Summary: use_facet>(mylocale) retrieving
wrong locale information
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnu-org at bignm dot com
  Target Milestone: ---

Created attachment 44110
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44110=edit
Source code and test output results showing error

Dear Bug Team,

I just recently upgraded using "apt" my Ubuntu 16.04 system and gcc was
upgraded from 6.2.0 to 6.4.0 which introduced the following bug.

In the attached archive is a program "testlocale.cpp" which requires only
gcc-supplied  header files. The command line to compile it and execute it is in
the comments at the top of the file.

In essence, it tests each facet of three locales (on my system "en_US.utf8",
"pt_BR.utf8" and "C" locales. All worked perfectly in g++ 6.2.0. As of g++
6.4.0, all of the facets, except the "moneypunct" facet work properly (see line
134).

Here is my information:

Linux version
$ uname -a
Linux asusubuntu16 4.13.0-41-generic #46~16.04.1-Ubuntu SMP Thu May 3 10:06:43
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Compiler version
$ gcc --version
gcc (Ubuntu 5.5.0-12ubuntu1~16.04) 5.5.0 20171010
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.

Compile command:
$ g++ -std=c++14 -m64 testlocale.cpp -static -o testlocale

Run command:
$ ./testlocale > testlocale.out

Attached is a test output generated by gcc 6.4.0 on my system. Of course, you
can test it on your system yourself and try to duplicate the error.

Best regards,
Tom Straub

[Bug c++/85731] New: [8/9 Regression] Inner class method declaration changes meaning of outer template class template method

[jaak at ristioja dot ee]

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

Bug ID: 85731
   Summary: [8/9 Regression] Inner class method declaration
changes meaning of outer template class template
method
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaak at ristioja dot ee
  Target Milestone: ---

The following code compiles with GCC 7.3.0 and earlier, but errors with GCC
8.1.0 and trunk.

template 
struct Outer {
struct Inner;
template  static void f();
};

template 
struct Outer::Inner {
decltype(Outer::f<42>()) f();
};

int main() { Outer::Inner().f(); }


: In instantiation of 'struct Outer::Inner':
:12:36:   required from here
:8:28: error: declaration of 'decltype (f<42>()) Outer::Inner::f()
[with T = int; decltype (f<42>()) = void]' [-fpermissive]
 struct Outer::Inner {
^
:4:38: error: changes meaning of 'f' from 'static void Outer::f()
[with int I = I; T = int]' [-fpermissive]
 template  static void f();
  ^

[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
François, I think you fixed this for GCC 7.1, so should we close the bug
report?

[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-10
  Component|tree-optimization   |target
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
At gimple, the difference is essentially
  BIT_FIELD_REF  = _6;
vs
  v_9 = BIT_INSERT_EXPR ;

Before combine, that translates to modifying a register directly

(insn 6 3 7 2 (set (reg:SI 93 [ v ])
(sign_extend:SI (subreg:QI (reg/v:SI 92 [ v ]) 0))) "v.c":6 155
{extendqisi2}
 (nil))
(insn 7 6 8 2 (parallel [ 
(set (reg:SI 94) 
(ashift:SI (reg:SI 93 [ v ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "v.c":6 550 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 93 [ v ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 8 7 13 2 (set (strict_low_part (subreg:QI (reg/v:SI 92 [ v ]) 0))
(subreg:QI (reg:SI 94) 0)) "v.c":6 101 {*movstrictqi_1}
 (expr_list:REG_DEAD (reg:SI 94)
(nil)))

or modifying a copy of it

(sign_extend:SI (subreg:QI (reg/v:SI 92 [ v ]) 0))) "v.c":12 155
{extendqisi2}
 (nil))
(insn 7 6 9 2 (parallel [
(set (reg:SI 94)
(ashift:SI (reg:SI 93 [ v ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "v.c":12 550 {*ashlsi3_1}
 (expr_list:REG_DEAD (reg:SI 93 [ v ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 9 7 10 2 (set (reg:SI 96 [ v ])
(reg/v:SI 92 [ v ])) "v.c":12 86 {*movsi_internal}
 (expr_list:REG_DEAD (reg/v:SI 92 [ v ])
(nil)))
(insn 10 9 15 2 (set (strict_low_part (subreg:QI (reg:SI 96 [ v ]) 0))
(subreg:QI (reg:SI 94) 0)) "v.c":12 101 {*movstrictqi_1}
 (expr_list:REG_DEAD (reg:SI 94)
(nil)))

and combine only manages to match in the first case

(insn 8 7 13 2 (parallel [
(set (strict_low_part (subreg:QI (reg/v:SI 92 [ v ]) 0)) 
(ashift:QI (subreg:QI (reg/v:SI 92 [ v ]) 0) 
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "v.c":6 556 {*ashlqi3_1_slp}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

Operations on partial registers are often not so fast, but in any case it seems
that we should generate the same code for both cases. Either target or
rtl-optimization.

[Bug tree-optimization/85730] New: complex code for modifying lowest byte in a 4-byte vector

[zsojka at seznam dot cz]

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

Bug ID: 85730
   Summary: complex code for modifying lowest byte in a 4-byte
vector
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 44109
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44109=edit
reduced testcase

The attached testcase has 3 implementations of the same function, yet the
compiled code differs: (@ -O3)

foo:
movsx   edx, dil
mov eax, edi
add edx, edx
mov al, dl
ret

bar:
mov eax, edi
add al, al
ret

baz:
movsx   edx, dil
mov eax, edi
add edx, edx
mov al, dl
ret

bar() has the shortest code and is also using fewer registers. I tried
benchmarking all 3 functions on a Skylake CPU; I could not find out which
function is the fastest (the jitter was too high).

The difference between foo() and bar() is that bar() is compiled with
-fno-tree-ccp -fno-tree-fre. baz() has one extra constant in the code, which
needs to be propagated in foor() and bar().

[Bug libstdc++/85729] including c++ headers within extern "C" linkage specification

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
See also PR 69386 where we had to workaround:

extern "C" {
#inclue 
}

which includes  which includes . Sigh.

[Bug libstdc++/85729] New: including c++ headers within extern "C" linkage specification

[nsz at gcc dot gnu.org]

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

Bug ID: 85729
   Summary: including c++ headers within extern "C" linkage
specification
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

some code does not include c++ headers in the top level but has

extern "C" {
#include 
}

this is invalid c++ (similar to bug 19373 where the include is under
namespace specification), but this can be made to work for c*
headers by adding explicit extern "C++" annotations where necessary
in libstdc++ headers. (currently it happens to work with a normal
gnu toolchain, because then glibc provides the string function
prototypes with explicit extern "C++", but with other setups it
can fail.)

alternatively gcc could try to warn about such header usage,
the relevant text in the spec is

[using.headers]:
 A translation unit shall include a header only outside of any external
 declaration or definition, and shall include the header lexically
 before the first reference in that translation unit to any of the
 entities declared in that header. No diagnostic is required.

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas  ---
I will backport as soon as I have time.

Paul

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
I will backport as soon as I have time.

Paul

[Bug fortran/68846] Pointer function as LValue doesn't work when the assignment regards a dummy argument.

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Thu May 10 10:48:50 2018
New Revision: 260113

URL: https://gcc.gnu.org/viewcvs?rev=260113=gcc=rev
Log:
2018-05-10  Paul Thomas  

PR fortran/68846
PR fortran/70864
* resolve.c (get_temp_from_expr): The temporary must not have
dummy or intent attributes.

2018-05-10  Paul Thomas  

PR fortran/68846
* gfortran.dg/temporary_3.f90 : New test.

PR fortran/70864
* gfortran.dg/temporary_2.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/temporary_2.f90
trunk/gcc/testsuite/gfortran.dg/temporary_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/70864] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1403

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Thu May 10 10:48:50 2018
New Revision: 260113

URL: https://gcc.gnu.org/viewcvs?rev=260113=gcc=rev
Log:
2018-05-10  Paul Thomas  

PR fortran/68846
PR fortran/70864
* resolve.c (get_temp_from_expr): The temporary must not have
dummy or intent attributes.

2018-05-10  Paul Thomas  

PR fortran/68846
* gfortran.dg/temporary_3.f90 : New test.

PR fortran/70864
* gfortran.dg/temporary_2.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/temporary_2.f90
trunk/gcc/testsuite/gfortran.dg/temporary_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug 64914 Summary: [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: 
runtime error: load of misaligned address  for type 'const md5_uint32', which 
requires 4 byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64914

   What|Removed |Added

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

[Bug bootstrap/64914] [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug bootstrap/64914] [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Author: marxin
Date: Thu May 10 10:15:42 2018
New Revision: 260112

URL: https://gcc.gnu.org/viewcvs?rev=260112=gcc=rev
Log:
Improve boostrap-ubsan config (PR bootstrap/64914).

2018-05-10  Martin Liska  

PR bootstrap/64914
* bootstrap-ubsan.mk: Define UBSAN_BOOTSTRAP.
2018-05-10  Martin Liska  

PR bootstrap/64914
* md5.c: Use strict alignment with UBSAN_BOOTSTRAP.

Modified:
trunk/config/ChangeLog
trunk/config/bootstrap-ubsan.mk
trunk/libiberty/ChangeLog
trunk/libiberty/md5.c

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[ro at gcc dot gnu.org]

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

--- Comment #3 from Rainer Orth  ---
Created attachment 44108
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44108=edit
i386-pc-solaris2.11 ipa-icf-38.exe.wpa.073i.icf

It's only one part that fails

FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not fixup_cfg4 "Function
bar"

which was introduced by

2018-05-02  Tom de Vries  

PR testsuite/85106
* gcc.dg/ipa/ipa-icf-38.c: Use scan-ltrans-tree-dump.
[...]

[Bug sanitizer/85389] posix_memalign() crash with address sanitizer when passing invalid arguments

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Martin Liška  ---
So it's nice what we do currently, this works for me:

$ gcc pr85329.c -fsanitize=address && ASAN_OPTIONS=allocator_may_return_null=1
./a.out 
rv = 22
ptr = 0x

[Bug target/85718] Incorrect name mangling for va_list on mipsel

[roliver at roku dot com]

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

--- Comment #5 from Richard Oliver  ---
(In reply to Jonathan Wakely from comment #4)
> So then this behaviour is correct and working as intended.

Even accepting the fact that 'void *' is a valid implementation for va_args,
surely the code generation is wrong in my original bug report for:
'log("Location of i: %p", )' as the '...' version should be selected in the
generated code?

'bl  _Z3logPKcz' is generated on ARM, and 'jal _Z3logPKcPv' is
generated on MIPS.

Surely this is independent of the internal implementation of 'va_args' as we're
not actually calling that function. Commenting out the va_list
forward-declaration results in the correct code being generated.

[Bug ipa/85656] gcc.dg/ipa/ipa-icf-38.c FAILs

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Martin Liška  ---
Can you please attach WPA ICF dump file. It should say why it's failing.
And do you know how long has been that failing?

[Bug c++/85728] New: strncpy -Wstringop-truncation

[evk55 at 126 dot com]

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

Bug ID: 85728
   Summary: strncpy -Wstringop-truncation
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evk55 at 126 dot com
  Target Milestone: ---

const char* Status::CopyState(const char* state) {
  const size_t cch = std::strlen(state) + 1; // +1 for the null terminator
  char* const result = new char[cch];
  result[cch - 1] = '\0';
#ifdef OS_WIN
  errno_t ret;
  ret = strncpy_s(result, cch, state, cch - 1);
  assert(ret == 0);
#else
  std::strncpy(result, state, cch - 1);
#endif
  return result;
}


error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before
terminating nul copying as many bytes from a string as its length
[-Werror=stringop-truncation]
   std::strncpy(result, state, cch);
   ^~~~
status.cc:18:33: note: length computed here
   const size_t cch = std::strlen(state);

[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
Fixed on the mainline.

[Bug tree-optimization/85699] [9 regression] gcc.dg/nextafter-2.c fail

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 10 07:38:24 2018
New Revision: 260107

URL: https://gcc.gnu.org/viewcvs?rev=260107=gcc=rev
Log:
PR tree-optimization/85699
* gcc.dg/nextafter-1.c (NO_LONG_DOUBLE): Define if not defined.  Use
!NO_LONG_DOUBLE instead of __LDBL_MANT_DIG__ != 106.
* gcc.dg/nextafter-2.c: Include stdlib.h.  For glibc < 2.24 define
NO_LONG_DOUBLE to 1 before including nextafter-1.c.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/nextafter-1.c
trunk/gcc/testsuite/gcc.dg/nextafter-2.c