[Bug other/79885] --with-build-sysroot= does not get honored throughout the build (fix-includes, CPP, CXXCPP, configure-stage2)

[jeremyhu at macports dot org]

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

--- Comment #13 from Jeremy Huddleston Sequoia  
---
1. clang honors $SDKROOT from the environment if it is not passed via -isysroot
on the command line.  That's all gcc needs to do, and then users running 'xcrun
gcc' would ge this behavior automatically.

2. xcrun is not OSS, but the primary functionality that you asked for was
provided in libxcselect in macOS 10.15, so you wouldn't need to exec xcrun to
find the path to the SDK.

3. I cannot decipher your comment "when clang is using a "different" SDK to
target a version of MacOS, it is using the runtimes provided by the target
MacOS version."  ... that doesn't quite make sense, so please be a bit more
specific about which runtime you are referring to (the compiler runtime, the OS
runtime)... either way I try to interpret it, it makes no sense, so I'm not
sure how to address this comment, sorry.

4. macOS deprecates APIs but will almost never remove them (unless we change
architectures ... such as when we removed a bunch of deprecated API when moving
from ppc to intel).  Internal / private SPI is subject to removal, but we aim
to never remove API as that breaks binary compatibility.

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[jeremyhu at macports dot org]

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

Jeremy Huddleston Sequoia  changed:

   What|Removed |Added

 CC||jeremyhu at macports dot org

--- Comment #7 from Jeremy Huddleston Sequoia  ---
There's no reason to replicate call out to xcrun or replicate xcrun's behavior.
 We added an API to libxcselect for GCC's use.  Look in usr/include/xcselect.h
in the 10.15 SDK.

[Bug c/91980] No diagnostic for type "complex"

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think the problem is the define for complex is in a system header which
causes the error not to happen due to -Wno-system-headers being the default.
This is a known issue in newer versions of GCC.  There might be another bug for
the similar issue.

[Bug libstdc++/61601] C++11 regex resource exhaustion

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Tim Shen from comment #7)
> (In reply to Maksymilian Arciemowicz from comment #6)
> > > Do you have any other testcases?
> > 
> > for trunk? maybe you have to use ::regex_match
> 
> std::regex_match("findme", std::regex("(.*{100}{200}findme)"));
> 
> there's no memory problem, it just takes exponentially long time to run
> (which is expected when using backtracking).
> 
> To avoid it, you can use Thompson NFA:
> 
> #define _GLIBCXX_REGEX_USE_THOMPSON_NFA
> #include 
> 
> int main (int argc, char *argv[])
> {
>   std::regex_match("findme", std::regex("(.*{100}{200}findme)",
> std::regex_constants::extended));
> 
>   return 0;
> 
> }
> 
> Notice that for now Thompson NFA doesn't support ECMAScript.

Are you still working on this?

[Bug c/91980] New: No diagnostic for type "complex"

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 91980
   Summary: No diagnostic for type "complex"
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

"gcc -std=c11 -pedantic-errors" does not issue a required
diagnostic for a declaration using type "complex". The
C standard requires "float _Complex", "double _Complex", or
"long double _Complex" (or equivalent; the keywords can be
in any order and "_Complex" can be replaced by "complex"
if  is included).
See C11/N1570 6.7.1 "Type specifiers"

Test case "complex-bug.c":

#include 
complex x;
// _Complex y;


The command
gcc -std=c11 -pedantic-errors -c complex-bug.c
produces no diagnostics for this source file.

Further experiments, not shown here, indicate that
x is of type double _Complex.

If the declaration of "y" is uncommented, a diagnostic
is issued:

complex-bug.c:3:1: error: ISO C does not support plain ‘complex’ meaning
‘double complex’ [-Wpedantic]
 _Complex y;
 ^~~~


("complex" and "_Complex" should be treated identically.)

I've reproduced this problem with gcc 8.3.0 on Ubuntu 19.04
and with 10.0.0 20190916 (experimental) (built from source)
on Ubuntu 18.04.3.

[Bug c++/91979] New: Incorrect mangling for non-template-argument nullptr expression

[jrtc27 at jrtc27 dot com]

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

Bug ID: 91979
   Summary: Incorrect mangling for non-template-argument nullptr
expression
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrtc27 at jrtc27 dot com
  Target Milestone: ---

Consider the mangling for the following code:

```
template 
struct enable_if {};

template 
struct enable_if { typedef T type; };

template 
void foo(typename enable_if::type* = 0) {}

template void foo<(void *)0>(void *);
```

This is one way of exposing how the expression `nullptr` is mangled when of
type
nullptr_t. Currently, GCC produces:

_Z3fooILPv0EEvPN9enable_ifIXeqT_LDn0EEvE4typeE

whereas Clang produces:

_Z3fooILPv0EEvPN9enable_ifIXeqT_LDnEEvE4typeE

Note the difference between LDn0E and LDnE for representing the nullptr inside
the
boolean expression for the enable_if. Based on the specification in cxx-abi,
Clang is
correct:

> The pointer literal expression nullptr is encoded as "LDnE". In contrast, a 
> template
> argument which happens to be a null pointer (an extension made standard in 
> C++11) is
> mangled as if it were a literal 0 of the appropriate pointer type; for 
> example,
> "LPi0E" or "LDn0E". This inconsistency is an unfortunate accident.

The bug is in cp/mangle.c write_expression:

```
  /* Handle literals.  */
  else if (TREE_CODE_CLASS (code) == tcc_constant
   || code == CONST_DECL)
write_template_arg_literal (expr);
```

This is correct for literal expressions, which are mangled identically to
template
argument literals, with the exception of nullptr.

Note also that c++filt (and thus GCC's/libiberty's demangler) does not Clang's
compliant
mangling, only GCC's current incorrect mangling.

[Bug fortran/91978] New: Unresolved associate target containing defined operation

[pault at gcc dot gnu.org]

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

Bug ID: 91978
   Summary: Unresolved associate target containing defined
operation
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

Noted by "FortranFan" on
https://groups.google.com/forum/#!topic/comp.lang.fortran/EtGmIRqvF2E

module my_type_old
   implicit none
   type :: my_type
  real :: r = 1.0
   contains
  procedure, pass(lhs) :: sum_my_types
  procedure, pass(this), public :: output => output_my_types
  generic, public :: operator(+) => sum_my_types
   end type my_type
contains
   function sum_my_types (lhs, rhs)  result (t_sum)
  class(my_type), intent(in) :: lhs
  type(my_type), intent(in)  :: rhs
  type(my_type) :: t_sum
  t_sum%r = lhs%r + rhs%r
  return
   end function sum_my_types
   subroutine output_my_types( this )
  class(my_type), intent(in) ::  this
  print *, "t%r = ", this%r
   end subroutine
end module my_type_old

program p
   blk7: block
  use my_type_old, only : my_type
  type(my_type) :: foo, bar
  print *, "Block 7"
  associate ( foobar => foo + bar) !<-- not supported by gfortran
 call foobar%output()
 print *, "Expected is r = 2.0"
  end associate
   end block blk7
   blk8: block
  use my_type_old, only : my_type
  type(my_type) :: foo, bar
  print *, "Block 8"
  associate ( foobar => foo%sum_my_types(bar)) ! This is OK
 call foobar%output()
 print *, "Expected is r = 2.0"
  end associate
   end block blk8
end program

[pault@pc30 pr91926]$ ~/irun9/bin/gfortran -static-libgfortran
-fdump-tree-original ../fortranfan.f90 
../fortranfan.f90:30:20:

   30 |  call foobar%output()
  |1
Error: VARIABLE attribute of ‘foobar’ conflicts with PROCEDURE attribute at (1)

The reason that I used 9-branch is that I have a partial fix on trunk :-) The
TKR of 'foobar' is not being determined by the parsing of the ASSOCIATE
statement in blk7. 

Paul

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|build   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
  Component|other   |bootstrap
 Ever confirmed|0   |1

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 06:25:15PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91963
> 
> --- Comment #7 from Steve Kargl  ---
> On Wed, Oct 02, 2019 at 06:10:48PM +, tkoenig at gcc dot gnu.org wrote:
> > 
> > You're right, Steve, the problem lies in the simplification
> > of the implied DO loop (the error message is a catch-all
> > which is somewhat misleading here).
> > 
> 
> I've looked at this a long time ago.  Never came up with a fix.
> 
> In the original code or the conforming example I posted, gfortran
> ends up in check.c(kind_check).  If we look at lines 630 and following
> we have
> 
>   if (!gfc_check_init_expr (k))
> {
>   gfc_error ("%qs argument of %qs intrinsic at %L must be a constant",
>   gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
>   >where);
>   return false;
> }
> 
> gfc_check_init_exp() returns ok, so gfortran knows it has an
> intialization expression.

Uing this testcase, one ends up in check.c(kind_check).

   use, intrinsic :: iso_fortran_env, only : logical_kinds
   integer :: i
   integer, parameter :: n = size(logical_kinds)
   logical, parameter :: m(*) = [(logical(.true.,logical_kinds(i)), i = 1, n)]
   print *, "logical_kinds = ", logical_kinds
   print *, "minkind = ", minkind
   end

(gdb) b gfc_check_logical
Breakpoint 1 at 0x756fa0: file ../../gccx/gcc/fortran/check.c, line 3529.
(gdb) run a.f90
Starting program:
/safe/sgk/work/x/libexec/gcc/x86_64-unknown-freebsd13.0/10.0.0/f951 a.f90

Breakpoint 1, gfc_check_logical (a=0x202de50a0, kind=0x202de5180)
at ../../gccx/gcc/fortran/check.c:3529
3529  if (!type_check (a, 0, BT_LOGICAL))
(gdb) n
3531  if (!kind_check (kind, 1, BT_LOGICAL))
(gdb) s
kind_check (k=0x202de5180, n=1, type=BT_LOGICAL)
at ../../gccx/gcc/fortran/check.c:612
612   int kind = 0;
 (gdb) n
614   if (k == NULL)
(gdb) n
620   if (!scalar_check (k, n))
(gdb) n
623   if (!gfc_check_init_expr (k))
(gdb) n
631   if (gfc_extract_int (k, )
(gdb) call debug(k)
MAIN__:logical_kinds(MAIN__:i) (INTEGER 4)
(gdb) p *k->shape
Cannot access memory at address 0x0
(gdb) p *k->ref
$5 = {type = REF_ARRAY, u = {ar = {type = AR_ELEMENT, dimen = 1, codimen = 0, 
  in_allocate = false, team = 0x0, stat = 0x0, where = {
nextc = 0x202323418, lb = 0x202323300}, as = 0x202debb40, c_where = {{
  nextc = 0x20232341c, lb = 0x202323300}, {nextc = 0x0, 
  lb = 0x0} }, start = {0x202de5260, 
0x0 }, end = {0x0 }, stride = {
0x0 }, dimen_type = {DIMEN_ELEMENT, 
0 }}, c = {component = 0x10002, sym = 0x0}, 
ss = {start = 0x10002, end = 0x0, length = 0x0}, i = INQUIRY_KIND}, 
  next = 0x0}
(gdb) p *k->value->constructor

k->ref seems to know we have an array element, but the constructor
is empty.

(gdb) call debug(k->symtree->n.sym->value)
(/ 1 , 2 , 4 , 8 , 16 /) (INTEGER 4)

So the information is in the symtree.

(gdb) p *k->symtree->n.sym->value
$6 = {expr_type = EXPR_ARRAY, ts = {type = BT_INTEGER, kind = 4, u = {
  derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, 
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false, 
interop_kind = 0x0}, rank = 1, shape = 0x203706a10, symtree = 0x0, 
  ref = 0x0, where = {nextc = 0x0, lb = 0x0}, base_expr = 0x0, is_snan = 0, 
  error = 0, user_operator = 0, mold = 0, must_finalize = 0, 
  no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0, 
  do_not_warn = 0, representation = {length = 0, string = 0x0}, boz = {
len = 0, rdx = 0, str = 0x0}, value = {logical = 48213696, 
iokind = 48213696, integer = {{_mp_alloc = 48213696, _mp_size = 2, 
_mp_d = 0x0}}, real = {{_mpfr_prec = 8638148288, _mpfr_sign = 0, 
_mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 8638148288, _mpfr_sign = 0, _mpfr_exp = 0, 
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, 
_mpfr_exp = 0, _mpfr_d = 0x0, op = {op = 48213696, uop = 0x0, 
  op1 = 0x0, op2 = 0x0}, function = {actual = 0x202dfaec0, name = 0x0, 
  isym = 0x0, esym = 0x0}, compcall = {actual = 0x202dfaec0, name = 0x0, 
  base_object = 0x0, tbp = 0x0, ignore_pass = 0, assign = 0}, character = {
  length = 8638148288, string = 0x0}, constructor = 0x202dfaec0}, 
  param_list = 0x0}

(gdb) p k->symtree->n.sym->attr.flavor
$9 = FL_PARAMETER

We have shape and constrcutor here, so we should be able to 
retrieve the array element value.

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Oct  2 22:33:39 2019
New Revision: 276495

URL: https://gcc.gnu.org/viewcvs?rev=276495=gcc=rev
Log:
PR rtl-optimization/91976
* expr.c (emit_block_move_hints): Don't call can_move_by_pieces if
size is not CONST_INT_P, set pieces_ok to false in that case.  Simplify
CONST_INT_P (size) && pieces_ok to pieces_ok.  Formatting fix.

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

[Bug c/91973] gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #5)
> We're talking about the sequence of pp-tokens in the expansion of bar(foo, 
> addr), which is (foo) (addr), where foo is followed by ), not about the 
> definition.
okay, now I understand and agree.
> 
> Please take any further questions on this to gcc-help; this question is 
> not appropriate for Bugzilla since it does not involve a bug or any other 
> kind of deficiency in GCC.
Okay.

[Bug c/91973] gcc failed for Multiple level macro expansion

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
We're talking about the sequence of pp-tokens in the expansion of bar(foo, 
addr), which is (foo) (addr), where foo is followed by ), not about the 
definition.

Please take any further questions on this to gcc-help; this question is 
not appropriate for Bugzilla since it does not involve a bug or any other 
kind of deficiency in GCC.

[Bug preprocessor/91961] __has_attribute expands macro argument

[ndesaulniers at google dot com]

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

--- Comment #4 from Nick Desaulniers  ---
Thanks for the report.  I noticed we had
https://bugs.llvm.org/show_bug.cgi?id=38653 on file, so I cc'ed Clang folks who
might have some thoughts.

[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Wed Oct  2 22:00:42 2019
New Revision: 276491

URL: https://gcc.gnu.org/viewcvs?rev=276491=gcc=rev
Log:
PR tree-optimization/80936 - bcmp, bcopy, and bzero not declared nonnull

gcc/testsuite/ChangeLog:

PR tree-optimization/80936
* gcc.dg/Wnonnull-2.c: New test.
* gcc.dg/Wnonnull-3.c: New test.
* gcc.dg/nonnull-3.c: Expect more warnings.

gcc/ChangeLog:

PR tree-optimization/80936
* builtins.def (bcmp, bcopy, bzero): Declare nonnull.

Added:
trunk/gcc/testsuite/gcc.dg/Wnonnull-2.c
trunk/gcc/testsuite/gcc.dg/Wnonnull-3.c
Modified:
trunk/gcc/builtins.def
trunk/gcc/testsuite/gcc.dg/nonnull-3.c

[Bug c/91973] gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #3)
> Macro replacement for function-like macros is defined in C17 6.10.3.  
> Note in paragraph 10 the words "the function-like macro name followed by a 
> ( as the next preprocessing token".  In your example foo ends up followed 
> by ) not ( as the next preprocessing token.
could you please explain a little more of the above, for the following macro
definition:

#define  foo(addr) \
  boo (addr)

foo is followed by ( but not ), right? do I miss anything here?

[Bug middle-end/91977] missing -Wstringop-overflow on memcpy into a pointer plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-02
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/91977] New: missing -Wstringop-overflow on memcpy into a pointer plus offset

[msebor at gcc dot gnu.org]

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

Bug ID: 91977
   Summary: missing -Wstringop-overflow on memcpy into a pointer
plus offset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In GCC 8 and above, -Wstringop-overflow detects the first buffer overflow but
not the second in the test program below.

$ cat b.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout b.c
char a[7];

void f (const void *s)
{
  __builtin_memcpy (a + 4, s, 4);   // -Wstringop-overflow
}

void g (const void *s)
{
  char *d = a + 4;
  __builtin_memcpy (d, s, 4);   // no warning
}


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

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
f (const void * s)
{
   [local count: 1073741824]:
  __builtin_memcpy (  [(void *) + 4B], s_2(D), 4);
  return;

}


b.c: In function ‘f’:
b.c:5:3: warning: ‘__builtin_memcpy’ forming offset 7 is out of the bounds [0,
7] of object ‘a’ with type ‘char[7]’ [-Warray-bounds]
5 |   __builtin_memcpy (a + 4, s, 4);   // -Wstringop-overflow
  |   ^~
b.c:1:6: note: ‘a’ declared here
1 | char a[7];
  |  ^

;; Function g (g, funcdef_no=1, decl_uid=1928, cgraph_uid=2, symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }
g (const void * s)
{
  unsigned int _3;

   [local count: 1073741824]:
  _3 = MEM  [(char * {ref-all})s_2(D)];
  MEM  [(char * {ref-all}) + 4B] = _3;
  return;

}

[Bug tree-optimization/88814] transform snprintf into memccpy

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #2 from Dávid Bolvanský  ---
You cannot [0] do this general transformation..

Runtime variable n = 10.

d[9] = 'A';
snprintf(d, n, "%s", s) // s is "str"
assert(d[9] == 'A');
=>
d[9] = 'A';
memccpy(d, s, 0, 9);
d[9] = 0;
assert(d[9] == 'A');

[0] https://reviews.llvm.org/D67986

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #26 from Dominique d'Humieres  ---
> Can the bug be marked as resolved?

AFAICT yes.

[Bug c++/91974] function not sequenced before function argument

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-02
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jakub Jelinek  ---
I think we need something like:
--- gcc/cp/cp-gimplify.c.jj 2019-09-27 22:13:18.365903348 +0200
+++ gcc/cp/cp-gimplify.c2019-10-02 22:42:41.878588998 +0200
@@ -818,6 +818,20 @@ cp_gimplify_expr (tree *expr_p, gimple_s

 case CALL_EXPR:
   ret = GS_OK;
+  if (flag_strong_eval_order == 2
+ && CALL_EXPR_FN (*expr_p)
+ && cp_get_callee_fndecl_nofold (*expr_p) == NULL_TREE)
+   {
+ enum gimplify_status t
+   = gimplify_expr (_EXPR_FN (*expr_p), pre_p, NULL,
+is_gimple_call_addr, fb_rvalue);
+ if (t == GS_ERROR)
+   ret = GS_ERROR;
+ else if (TREE_CODE (CALL_EXPR_FN (*expr_p)) != SSA_NAME)
+   CALL_EXPR_FN (*expr_p)
+ = get_initialized_tmp_var (CALL_EXPR_FN (*expr_p), pre_p,
+NULL);
+   }
   if (!CALL_EXPR_FN (*expr_p))
/* Internal function call.  */;
   else if (CALL_EXPR_REVERSE_ARGS (*expr_p))

[Bug c++/91974] function not sequenced before function argument

[barry.revzin at gmail dot com]

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

--- Comment #4 from Barry Revzin  ---
Yes, sorry if that wasn't clear, this is with -std=c++17.

[Bug testsuite/27221] g++.dg/ext/alignof2.C fails on powerpc-darwin (and powerpc-aix)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #10 from Iain Sandoe  ---
fixed on open branches

[Bug target/82920] cet test failures on darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #24 from Iain Sandoe  ---
fixed on open branches

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe  ---
other than the desire to locate /usr/local/include in some automatic way, is
this still a current issue?

I've built (with the workaround for missing __has_x()) on 10.14 using the
10.15 XC11.0 command line tools, without any issues [other than the missing
__has_x()].

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe  ---
I'm testing regularly on macOS 10.14 (darwin18) - which I assume is the version
you meant?

Also on 8.3 and 9.2 .. (the results are posted to @testresults).

There was a PCH fixed (but that only manifested with -save-temps, so I don't
expect it to be directly relevant).

Right now, I can find no indication (or repeat) of this report - are you still
seeing it anywhere?

[Bug gcov-profile/91087] g++.dg/gcov/pr16855.C fails everywhere on Darwin.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Sandoe  ---
fixed on open branches

[Bug c/91973] gcc failed for Multiple level macro expansion

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Macro replacement for function-like macros is defined in C17 6.10.3.  
Note in paragraph 10 the words "the function-like macro name followed by a 
( as the next preprocessing token".  In your example foo ends up followed 
by ) not ( as the next preprocessing token.

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

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

--- Comment #20 from joseph at codesourcery dot com  ---
The only case where the newly built GCC should be overridden is the 
Canadian cross case, and while that does use a pre-installed tool from the 
PATH, it's best to use "make all-host" in that case to avoid rebuilding 
target libraries and instead copy them from the build system.  (The 
identically-configured build-x-target tools still need to be in the PATH 
in that case because the GCC build wants to run the target compiler with 
-dumpspecs.)

Your problem as originally described was with finding non-sysroot headers.  
A plausible approach to fixing that if you can't use sysroots is to add a 
a new configure option whose purpose is to point to the build-time 
non-sysroot location of headers that should be used in building target 
libraries.  Maybe you don't want --with-headers because of the side-effect 
of copying into a sys-include directory, but something quite similar to 
that but without that side-effect might work.

[Bug c/91973] gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #1)
> This is not a bug in GCC, it's how the preprocessor is defined to work.
So, this is an user error? is there any C language rules on this?
why icc works on this?

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #19 from Stas Sergeev  ---
OK, but the setup when you want to override
the newly-built gcc, is also needed. Like, when
you want to build the "destdir" gcc with the one
installed directly into prefix (and therefore
working fine on host).
Would you suggest a new option for that?
I've seen the variables CC_FOR_TARGET and alike,
but they do not work that way too. So I think
currently there is no way of doing that, and
so some patch should be created. How should it
look like?

[Bug c/91973] gcc failed for Multiple level macro expansion

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #1 from Joseph S. Myers  ---
This is not a bug in GCC, it's how the preprocessor is defined to work.

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
The libgcc2.c functions for conversions that get used by default on most 
architectures should respect the rounding mode if the underlying 
single-word-to-floating-point instruction does so.  (They have more 
complicated logic to handle the __floatdisf case and other such cases 
where a single word is wider than the precision of the floating-point 
type.)

The libgcc2.c __fix* functions may raise spurious "inexact" exceptions, 
but that's a different matter.

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I think
--- gcc/expr.c.jj   2019-10-02 16:35:20.977451346 +0200
+++ gcc/expr.c  2019-10-02 21:47:54.900724874 +0200
@@ -1624,16 +1624,18 @@ emit_block_move_hints (rtx x, rtx y, rtx
   set_mem_size (y, const_size);
 }

-  bool pieces_ok = can_move_by_pieces (INTVAL (size), align);
+  bool pieces_ok = false;
+  if (CONST_INT_P (size))
+pieces_ok = can_move_by_pieces (INTVAL (size), align);
   bool pattern_ok = false;

-  if (!CONST_INT_P (size) || !pieces_ok || might_overlap)
+  if (!pieces_ok || might_overlap)
 {
-  pattern_ok = 
-   emit_block_move_via_pattern (x, y, size, align,
-expected_align, expected_size,
-min_size, max_size, probable_max_size,
-might_overlap);
+  pattern_ok
+   = emit_block_move_via_pattern (x, y, size, align,
+  expected_align, expected_size,
+  min_size, max_size, probable_max_size,
+  might_overlap);
   if (!pattern_ok && might_overlap)
{
  /* Do not try any of the other methods below as they are not safe
@@ -1645,7 +1647,7 @@ emit_block_move_hints (rtx x, rtx y, rtx

   if (pattern_ok)
 ;
-  else if (CONST_INT_P (size) && pieces_ok)
+  else if (pieces_ok)
 move_by_pieces (x, y, INTVAL (size), align, RETURN_BEGIN);
   else if (may_use_call && !might_overlap
   && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
should fix this.

[Bug other/91879] --with-build-time-tools doesn't work as expected

[joseph at codesourcery dot com]

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

--- Comment #18 from joseph at codesourcery dot com  ---
No, --with-build-time-tools definitely should not override newly built 
tools.

For example, in some bootstrap configurations you have to build GCC more 
than once.  If you're also installing into a DESTDIR rather than directly 
into the configured prefix, you need to use --with-build-time-tools so 
that binutils for the target can be found.  But when building the second 
GCC, the newly built GCC *must* be used to compile its own shared 
libraries, not the first-stage GCC that might be installed alongside 
binutils in the directory pointed to with --with-build-time-tools.  (For 
example, the second GCC might be configured --enable-shared, with that 
being needed to build shared libgcc and libstdc++, where the first GCC was 
configured --disable-shared.)

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-02
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Most likely caused by r276461.

[Bug c++/91974] function not sequenced before function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Just to make sure, you are using -std=c++17 or -std=gnu++17 (or
-fstrong-eval-order)?  Because it is not obvious from this report.

[Bug rtl-optimization/91976] [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
FAIL: configure --enable-checking=yes,rtl --enable-languages=c,c++,lto
--disable-multilib

PASS: configure --enable-checking=yes --enable-languages=c,c++,lto
--disable-multilib

[Bug rtl-optimization/91976] New: [10 regression] RTL check: expected code 'const_int', have 'reg' in emit_block_move_hints, at expr.c:1627

[dimhen at gmail dot com]

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

Bug ID: 91976
   Summary: [10 regression] RTL check: expected code 'const_int',
have 'reg' in emit_block_move_hints, at expr.c:1627
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

gcc bootstrap
r276439 PASS
r276476 FAIL

Fedora 30 x86_64

/home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native

make
...
/home/dimhen/build/gcc_current/./gcc/xgcc
-B/home/dimhen/build/gcc_current/./gcc/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/bin/
-B/usr/local/gcc_current/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/include -isystem
/usr/local/gcc_current/x86_64-pc-linux-gnu/sys-include   -fno-checking -g -O2
-O2  -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection
-mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc
-I/home/dimhen/src/gcc_current/libgcc -I/home/dimhen/src/gcc_current/libgcc/.
-I/home/dimhen/src/gcc_current/libgcc/../gcc
-I/home/dimhen/src/gcc_current/libgcc/../include
-I/home/dimhen/src/gcc_current/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT
-DHAVE_CC_TLS  -DUSE_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov
-c /home/dimhen/src/gcc_current/libgcc/libgcov-driver.c
during RTL pass: expand
In file included from /home/dimhen/src/gcc_current/libgcc/libgcov-driver.c:214:
/home/dimhen/src/gcc_current/libgcc/libgcov-driver-system.c: In function
'gcov_do_dump':
/home/dimhen/src/gcc_current/libgcc/libgcov-driver-system.c:252:26: internal
compiler error: RTL check: expected code 'const_int', have 'reg' in
emit_block_move_hints, at expr.c:1627
  252 |   char *p = (char *) memcpy (gf->prefix, gcov_prefix,
prefix_length);
  | 
^~~
0x1218bf6 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/home/dimhen/src/gcc_current/gcc/rtl.c:879
0xc8346e emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long, bool, bool*,
bool)
/home/dimhen/src/gcc_current/gcc/expr.c:1627
0xa441ae expand_builtin_memory_copy_args
/home/dimhen/src/gcc_current/gcc/builtins.c:3936
0xa439da expand_builtin_memcpy
/home/dimhen/src/gcc_current/gcc/builtins.c:3793
0xa50c08 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/dimhen/src/gcc_current/gcc/builtins.c:7644
0xcb582d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:11108
0xca7170 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:8327
0xc9ab8d store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:5723
0xc98ed0 expand_assignment(tree_node*, tree_node*, bool)
/home/dimhen/src/gcc_current/gcc/expr.c:5485
0xa9ecd9 expand_call_stmt
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:2729
0xaa2d2d expand_gimple_stmt_1
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:3710
0xaa3471 expand_gimple_stmt
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:3875
0xaace9b expand_gimple_basic_block
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:5914
0xaae9eb execute
/home/dimhen/src/gcc_current/gcc/cfgexpand.c:6554
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/91975] New: worse code for small array copy using pointer arithmetic than array indexing

[msebor at gcc dot gnu.org]

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

Bug ID: 91975
   Summary: worse code for small array copy using pointer
arithmetic than array indexing
   Product: gcc
   Version: 9.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: ---

When the contents of one small array is copied into another, GCC with -O2
generates more or less optimal code depending on whether the source array is
statically initialized, and also depending on whether the copying takes place
using pointer arithmetic and dereferencing or using array indexing.  Some
copies are transformed into series of assignments while others remain as loops,
while others still into a single MEM_REF statement.

The emitted assembly is also more or less efficient.

-O3 is required to get the same optimally efficient code.

Clang emits optimally efficient code for all forms at -O2.

It seems that since GCC can make some of the functions below optimally
efficient it should be able to do it for all of them.

$ cat b.c && gcc -DT=int -O2 -S -fdump-tree-optimized=/dev/stdout b.c
const T a[] = { 0, 1, 2, 3, 4, 5, 6, 7 };
T b[sizeof a / sizeof *a];

void f0 (void)   // near optimal
{
  const T *s = a;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
d[i] = s[i];
}

void g0 (void)   // suboptimal
{
  const T *s = a;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
*d++ = *s++;
}

extern const T c[sizeof a / sizeof *a];

void f1 (void)   // optimal
{
  const T *s = c;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
d[i] = s[i];
}

void g1 (void)   // optimal
{
  const T *s = c;
  T *d = b;
  for (unsigned i = 0; i != sizeof a / sizeof *a; ++i)
*d++ = *s++;
}


;; Function f0 (f0, funcdef_no=0, decl_uid=1926, cgraph_uid=1, symbol_order=2)

f0 ()
{
   [local count: 119292717]:
  MEM  [(int *)] = 4294967296;
  MEM  [(int *) + 8B] = 12884901890;
  MEM  [(int *) + 16B] = 21474836484;
  MEM  [(int *) + 24B] = 30064771078;
  return;

}



;; Function g0 (g0, funcdef_no=1, decl_uid=1935, cgraph_uid=2, symbol_order=3)

g0 ()
{
  sizetype ivtmp.25;
  int prephitmp_4;
  int pretmp_5;

   [local count: 119292716]:

   [local count: 954449108]:
  # prephitmp_4 = PHI <0(2), pretmp_5(4)>
  # ivtmp.25_2 = PHI <0(2), ivtmp.25_15(4)>
  MEM[symbol: b, index: ivtmp.25_2, offset: 0B] = prephitmp_4;
  ivtmp.25_15 = ivtmp.25_2 + 4;
  if (ivtmp.25_15 != 32)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 835156388]:
  pretmp_5 = MEM[symbol: a, index: ivtmp.25_15, offset: 0B];
  goto ; [100.00%]

   [local count: 119292717]:
  return;

}



;; Function f1 (f1, funcdef_no=2, decl_uid=1945, cgraph_uid=3, symbol_order=4)

f1 ()
{
   [local count: 119292717]:
  MEM  [(char * {ref-all})] = MEM 
[(char * {ref-all})];
  return;

}



;; Function g1 (g1, funcdef_no=3, decl_uid=1954, cgraph_uid=4, symbol_order=5)

g1 ()
{
   [local count: 119292717]:
  MEM  [(char * {ref-all})] = MEM 
[(char * {ref-all})];
  return;

}

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
(In reply to Marc Glisse from comment #2)
> What exact transformation do you want? Canonicalize the constant C to
> something like C % (1 << (bitsize - N))?

I'm thinking (C << N) >>> N where '>>>' is sign-extending right shift. In other
words, duplicate the bit at position (bitsize - 1 - N) to the left. In the
opening example, I want to go from

  (0xf - a) << 44

to

  (-1 - a) << 44

> For unsigned only... didn't we use to canonicalize in the reverse direction,
> i.e. from x*4 to x<<2?

For unsigned - because we promise not to use undefined overflow for signed left
shifts? Can we canonicalize to a wrapping multiplication?

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
(In reply to Dmitrij Pochepko from comment #2)
> aarch64 won't be necessarily faster with such fix.
> 531.deepsjeng_r on ThunderX2 shows about 0.5% slower numbers with 31-clz(a).

This sounds like we only pass 0 or 1 to this function in deepsjeng_r?
Have you figured out the values that deepsjeng_r uses for these loops?

Because 31-clz would be:
clz w0, w0
mov w1, 31
sub w0, w1, w0
--- CUT ---
While the loop version would be:
asr w1, w0, 1
mov w0, 0
cbz w1, .L3
.p2align 2
.L5:
add w0, w0, 1
asr w1, w1, 1
cbnzw1, .L5
.L3:

If the first branch was predicted as being taken (and it was actually taken;
that is skip the loop), it would be a few cycles faster than the non-loop based
one.  This would also mean the value of w0 is either 0 or 1.

Did you anlaysis why it was worse for TX2?

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 06:10:48PM +, tkoenig at gcc dot gnu.org wrote:
> 
> You're right, Steve, the problem lies in the simplification
> of the implied DO loop (the error message is a catch-all
> which is somewhat misleading here).
> 

I've looked at this a long time ago.  Never came up with a fix.

In the original code or the conforming example I posted, gfortran
ends up in check.c(kind_check).  If we look at lines 630 and following
we have

  if (!gfc_check_init_expr (k))
{
  gfc_error ("%qs argument of %qs intrinsic at %L must be a constant",
  gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
  >where);
  return false;
}

gfc_check_init_exp() returns ok, so gfortran knows it has an
intialization expression.  It simply hasn't reduced it to a
constant.  The next section of code fails, because extraction
of the kind value fails.

  if (gfc_extract_int (k, )
  || gfc_validate_kind (type, kind, true) < 0)
{
  gfc_error ("Invalid kind for %s at %L", gfc_basic_typename (type),
   >where);
  return false;
}

This is were I'm stuck.  I think we need to rummage through
gfc_reduce_init_expr().

[Bug c++/91974] function not sequenced before function argument

[barry.revzin at gmail dot com]

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

--- Comment #2 from Barry Revzin  ---
C++17 does change this rule. expr.call/8:

The postfix-expression is sequenced before each expression in the
expression-list and any default argument. The initialization of a parameter,
including every associated value computation and side effect, is
indeterminately sequenced with respect to that of any other parameter.

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Alexander Monakov from comment #0)
> Do we want to handle this early on via match.pd? Perhaps also applies to
> simplifying (a +- C) << N.

What exact transformation do you want? Canonicalize the constant C to something
like C % (1 << (bitsize - N))?

(In reply to Alexander Monakov from comment #1)
> On a related thought, I wonder if we can canonicalize (x << CST) to (x *
> CST') where CST' is 1<

[Bug fortran/91963] Logical function does not simplify

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Somewhat reduced:

program main
  integer, dimension(2), parameter :: n=[1,4]
  logical, parameter :: a = logical(.true.,minval([(n(i),i=1,4)]))
end program main

Even more reduced, without LOGICAL:

program main
  integer, dimension(2), parameter :: n=[1,4]
  integer, parameter :: m = minval([(n(i),i=1,4)],1)
end program main

log.f90:3:27:

3 |   integer, parameter :: m = minval([(n(i),i=1,4)],1)
  |   1
Error: transformational intrinsic 'minval' at (1) is not permitted in an
initialization expression

You're right, Steve, the problem lies in the simplification
of the implied DO loop (the error message is a catch-all
which is somewhat misleading here).

[Bug c++/91974] function not sequenced before function argument

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I dont think this is well defined.  A call and its arguments are not sequence
points.  Yes there is a sequence point between the assignment and 0 but nothing
else.  Note c++17 does change the rules and I have not read them yet.

[Bug fortran/91784] ICE in gfc_real2complex, at fortran/arith.c:2208

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:17:55 2019
New Revision: 276474

URL: https://gcc.gnu.org/viewcvs?rev=276474=gcc=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91784
* simplify.c (gfc_convert_constant): Simplify expression if the
expres  ion type is EXPR_OP.

2019-10-02  Steven G. Kargl  

PR fortran/91784
* gfortran.dg/pr91784.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91784.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #2)
> Don't you need #pragma STDC FENV_ACCESS?

yes, for iso c conformance you need it, but gcc does not
handle it anyway, instead it requires -frounding-math.

however if double prec instructions are available, using them
may be even faster in the difficult inexact case, e.g.

double uconv64(uint64_t x)
{
double lo = uconv32(x); // single instruction, always exact
double hi = uconv32(x>>32);
return lo + hi*0x1p32;
}

so i would not make the fix depend on -frounding-math,
just always use hardfloat instructions on hardfloat targets
to do the conv.

(i suspect it affects more than just armhf)

[Bug target/91816] [7/8/9/10 Regression] Arm generates out of range conditional branches in Thumb2

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||sudi at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |sudi at gcc dot gnu.org
Summary|Arm generates out of range  |[7/8/9/10 Regression] Arm
   |conditional branches in |generates out of range
   |Thumb2  |conditional branches in
   ||Thumb2

[Bug fortran/91785] ICE in check_assumed_size_reference, at fortran/resolve.c:1601

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:09:45 2019
New Revision: 276473

URL: https://gcc.gnu.org/viewcvs?rev=276473=gcc=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91785
* primary.c (gfc_match_varspec): Ensure an inquiry parameter has
it locus set.

2019-10-02  Steven G. Kargl  

PR fortran/91785
* gfortran.dg/pr91785.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91785.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91965] missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

--- Comment #1 from Alexander Monakov  ---
On a related thought, I wonder if we can canonicalize (x << CST) to (x * CST')
where CST' is 1<

[Bug fortran/91942] ICE in match_vtag, at fortran/io.c:1485

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:04:57 2019
New Revision: 276472

URL: https://gcc.gnu.org/viewcvs?rev=276472=gcc=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91942
* io.c (match_vtag): Check for non-NULL result->symtree.
(match_out_tag): Check for invalid constant due to inquiry parameter.
(match_filepos): Instead of a syntax error, go to cleanup to get better
error messages.

2019-10-02  Steven G. Kargl  

PR fortran/91942
* gfortran.dg/pr91587.f90: Update dg-error regex.
* gfortran.dg/pr91942.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91942.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr91587.f90

[Bug fortran/91943] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct  2 17:01:30 2019
New Revision: 276471

URL: https://gcc.gnu.org/viewcvs?rev=276471=gcc=rev
Log:
2019-10-02  Steven G. Kargl  

PR fortran/91943
* match.c (gfc_match_call): BOZ cannot be an actual argument in
a subroutine reference.
* resolve.c (resolve_function): BOZ cannot be an actual argument in
a function reference.

2019-10-02  Steven G. Kargl  

PR fortran/91943
gfortran.dg/pr91943.f90

Added:
trunk/gcc/testsuite/gfortran.dg/pr91943.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
Don't you need #pragma STDC FENV_ACCESS?

[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
(In reply to Rich Felker from comment #9)
> I think it's actually just a matter of removing the patterns for generating
> bsrf, but I may be mistaken. Generating jsr should be what happens "by
> default" in some sense if GCC just has to load the address, no?

I think so, yes.

> Of course 
> that would also explicitly load the GOT pointer for the callee which we
> don't need since it's local.

Can you make an example?  Maybe it can get optimized away afterwards, if it's
not used?

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
floating-point exceptions are also missing for the same reason.

[Bug c++/91974] New: function not sequenced before function argument

[barry.revzin at gmail dot com]

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

Bug ID: 91974
   Summary: function not sequenced before function argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

>From StackOverflow (https://stackoverflow.com/q/58204296/2069064), reduced:

extern void call(int);

void a(int) {
call(0);
}

void b(int) {
call(1);
}

int main() {
using T = void(*)(int);

T f = a;
f((f=b,0));
}

This is a well-defined (if weird) program that should a - that is call(0). With
gcc, it invokes call(1) (that is, the assignment that happens in the
initialization of the function parameter happens before the load of the
function itself). On -O2, the codegen is:

main:
sub rsp, 8
mov edi, 1
callcall(int)
xor eax, eax
add rsp, 8
ret

[Bug tree-optimization/90839] Detect lsb ones counting loop (final value replacement?)

[dpochepk at gmail dot com]

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

Dmitrij Pochepko  changed:

   What|Removed |Added

 CC||dpochepk at gmail dot com

--- Comment #2 from Dmitrij Pochepko  ---
aarch64 won't be necessarily faster with such fix.
531.deepsjeng_r on ThunderX2 shows about 0.5% slower numbers with 31-clz(a).

[Bug c/91973] New: gcc failed for Multiple level macro expansion

[qinzhao at gcc dot gnu.org]

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

Bug ID: 91973
   Summary: gcc failed for Multiple level macro expansion
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

GCC cannot compile the following small testing case:

[qinzhao@localhost]$ cat t1.c
extern void boo (void *addr);

#define  foo(addr) \
  boo (addr)

#define bar(instr, addr)  \
  (instr) (addr)

void check (void *addr)
{
  bar(foo, addr);
}

[qinzhao@localhost]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O -S t1.c
t1.c: In function ‘check’:
t1.c:11:7: error: ‘foo’ undeclared (first use in this function); did you mean
‘boo’?
   11 |   bar(foo, addr);
  |   ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 |   (instr) (addr)
  |^
t1.c:11:7: note: each undeclared identifier is reported only once for each
function it appears in
   11 |   bar(foo, addr);
  |   ^~~
t1.c:7:4: note: in definition of macro ‘bar’
7 |   (instr) (addr)
  |^

However, if I delete the parantheses from the macro bar as following:

#define bar(instr, addr)  \
  instr (addr)

The compilation succeed. 

also icc can successfully compile the original small testing case.

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 07:07:08AM -0700, Steve Kargl wrote:
> On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> > --- Comment #3 from kargl at gcc dot gnu.org ---
> > (In reply to Richard Biener from comment #1)
> > > But is it valid fortran?
> > 
> > Yes.  It's valid.  gfortran has poor handling of implied-do loops
> > in initialization expression.
> > 
> 
> Actually, the testcase submitted here in BZ is the
> one of three posted in c.l.f that is invalid.  C_BOOL
> is the only interoperable type for ISO BIND C, so the
> use of C_SIZEOF is invalid.
> 

Here's valid code that shows the same problem

   use, intrinsic :: iso_fortran_env, only : logical_kinds
   integer :: i
   integer, parameter :: minkind = logical_kinds(minloc([( storage_size( &
   &   a=[ logical(.false., logical_kinds(i))] ), &
   &   i = 1, size(logical_kinds) )], dim=1))
   print *, "logical_kinds = ", logical_kinds
   print *, "minkind = ", minkind
end

[Bug other/91972] New: Bootstrap should use -Wmissing-declarations

[amonakov at gcc dot gnu.org]

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

Bug ID: 91972
   Summary: Bootstrap should use -Wmissing-declarations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

In the good old days when gcc was written in C, bootstrap stage2/3 enabled
-Wmissing-prototypes and so it caught attempted definitions of functions that
should be static, but were not declared so.

Transition to C++ did not change -Wmissing-prototypes to
-Wmissing-declarations, so over time several violations crept in. In particular
this penalizes optimization during non-LTO bootstrap (the compiler has to
assume the function might be used in another TU, even though in reality all
uses are in current file and it simply misses the 'static' keyword).

[Bug gcov-profile/91971] New: Profile directory concatenated with object file path

[qinzhao at gcc dot gnu.org]

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

Bug ID: 91971
   Summary: Profile directory concatenated with object file path
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

we noticed that the profile directory will be concatenated with object file
path.

the following small example explain this behavior:

[qinzhao@localhost small]$ cat t
#! /bin/bash
CC=/home/qinzhao/Install/latest/bin/gcc
opt="-O3 -fprofile-generate"
opt="$opt -fprofile-dir=/home/qinzhao/prof_dir" 
opt="$opt -c -o /home/qinzhao/obj_dir/t.o"
tf="t.c"

echo $CC $opt $tf
$CC $opt $tf
strings /home/qinzhao/obj_dir/t.o | grep prof_dir
[qinzhao@localhost small]$ sh t
/home/qinzhao/Install/latest/bin/gcc -O3 -fprofile-generate
-fprofile-dir=/home/qinzhao/prof_dir -c -o /home/qinzhao/obj_dir/t.o t.c
/home/qinzhao/prof_dir//home/qinzhao/obj_dir/t.gcda
[qinzhao@localhost small]$ 


From the above, we can see:

when specifying the profiling directory with -fprofile-dir as
“/home/qinzhao/prof_dir”,  the user expects that the profiling data will 
be stored in this specific directory.  However, GCC concatenates  the profiling
directory “/home/qinzhao/prof_dir” with the path for the 
object file “/home/qinzhao/obj_dir” together. As a result, the profiling data
will be stored to:

/home/qinzhao/prof_dir/home/qinzhao/obj_dir/

instead of 

/home/qinzhao/prof_dir

This looks like a bug to me.

[Bug target/91970] New: arm: 64bit int to double conversion does not respect rounding mode

[nsz at gcc dot gnu.org]

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

Bug ID: 91970
   Summary: arm: 64bit int to double conversion does not respect
rounding mode
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on arm-* with

#include 
#include 
int main()
{
long long x = (1LL << 60) - 1;
double y;
fesetround(FE_DOWNWARD);
__asm__ __volatile__ ("" : "+m" (x));
y = x;
__asm__ __volatile__ ("" : "+m" (y));
fesetround(FE_TONEAREST);
printf("%a\n", y);
}

i get

0x1p60

instead of

0x1.fp+59

i assume this is because the conversion is handled by __aeabi_l2d
(also known as __floatdidf in libgcc) which is not rounding mode
aware.

this affects hardfloat targets which otherwise support directed
rounding modes.

[Bug gcov-profile/91969] New: Compiling testsuite/g++.dg/ipa/pr85421.C with -fdump-ipa-inline ICEs

[jamborm at gcc dot gnu.org]

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

Bug ID: 91969
   Summary: Compiling testsuite/g++.dg/ipa/pr85421.C with
-fdump-ipa-inline ICEs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

If you compile testsuite/g++.dg/ipa/pr85421.C with -fdump-ipa-inline, the
compiler hits an assert gcc_checking_assert(initialized_p()) in
profile_count::to_gcov_type():

$ /home/mjambor/gcc/icln/obj/gcc/testsuite/g++/../../xg++
-B/home/mjambor/gcc/icln/obj/gcc/testsuite/g++/../../
/home/mjambor/gcc/icln/src/gcc/testsuite/g++.dg/ipa/pr85421.C -nostdinc++
-I/home/mjambor/gcc/icln/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/mjambor/gcc/icln/obj/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/mjambor/gcc/icln/src/libstdc++-v3/libsupc++
-I/home/mjambor/gcc/icln/src/libstdc++-v3/include/backward
-I/home/mjambor/gcc/icln/src/libstdc++-v3/testsuite/util -fmessage-length=0  
-O3 -std=gnu++1y -w  -S -o pr85421.s  -fdump-ipa-inline   
during IPA pass: inline
/home/mjambor/gcc/icln/src/gcc/testsuite/g++.dg/ipa/pr85421.C:131:1: internal
compiler error: in to_gcov_type, at profile-count.h:757
  131 | } // namespace bk
  | ^
0xd64624 profile_count::to_gcov_type() const
/home/mjambor/gcc/icln/src/gcc/profile-count.h:757
0x21d73f1 recursive_inlining
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:1554
0x21d8b50 inline_small_functions
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2039
0x21da828 ipa_inline
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2550
0x21db6cc execute
/home/mjambor/gcc/icln/src/gcc/ipa-inline.c:2958
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This happens when GCC attempts to dump stuff in recursive_inlining when it
attempts to dump count of cgraph_edge:

 *.LTHUNK0/8>

[Bug libstdc++/91653] ostream::operator<<(streambuf*) should fail the ostream when write output stream error but not

[lh_mouse at 126 dot com]

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

Liu Hao  changed:

   What|Removed |Added

 CC||lh_mouse at 126 dot com

--- Comment #5 from Liu Hao  ---
This may be inconsistency (if not necessarily a defect) in the C++ standard,
since both `basic_ostream::{put,write}`, as UnformattedOutputFunctions, set
`badbit` in case of output failure, but `operator<<(basic_streambuf*)` doesn't.
Nevertheless GCC is doing the right thing and conform to all standards.

It should also be noted that if `operator<<(basic_streambuf*)` could not
extract any character, `failbit` is set on the output stream. Thus correct use
of this function requires a loop, as follows:

```
bool copy_stream(std::ostream& os, std::istream& is)
  {
while(os && (is.rdbuf()->sgetc()
 != std::istream::traits_type::eof()))
  os << is.rdbuf();
return !!os;
  }
```

Anyway, it is not a bug in libstdc++.

[Bug debug/91968] New: DW_AT_low_pc missing for DW_TAG_label with LTO

[keiths at redhat dot com]

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

Bug ID: 91968
   Summary: DW_AT_low_pc missing for DW_TAG_label with LTO
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keiths at redhat dot com
  Target Milestone: ---

Compilers tested: gcc version 10.0.0 20190930, several Fedora system compilers,
e.g., Fedora 29 (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1).

Consider the simple program (from GDB's test suite,
gdb/testsuite/gdb.base/label.c):

#include 

int
main (int argc, char **argv)
{
  int i = 0;
  goto there;

here:
  printf("not here\n");
  i = 1;

there:
  printf("but here\n");
  if (i == 0)
goto here;

done:
  return 0;
}

If this is compiled with LTO (gcc -g -flto label.c)[1], GDB is unable to set a
breakpoint at any of the labels. This is because GDB is looking for
DW_AT_low_pc, but this attribute is missing from the DIEs for the labels:

 <2>: Abbrev Number: 8 (DW_TAG_label)
   DW_AT_name: (indirect string, offset: 0xfe): there
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 13
   DW_AT_decl_column : 1
 <2>: Abbrev Number: 8 (DW_TAG_label)
<100>   DW_AT_name: (indirect string, offset: 0xff): here
<104>   DW_AT_decl_file   : 1
<105>   DW_AT_decl_line   : 9
<106>   DW_AT_decl_column : 1
 <2><107>: Abbrev Number: 8 (DW_TAG_label)
<108>   DW_AT_name: (indirect string, offset: 0xc6): done
<10c>   DW_AT_decl_file   : 1
<10d>   DW_AT_decl_line   : 18
<10e>   DW_AT_decl_column : 1

Is GDB supposed to deal with this in some other way?

[1] Alternatively, if you have a GDB build lying around:
$ make check RUNTESTFLAGS="--target_board unix/-flto" \
   TESTS=gdb.base/label.exp
That test will show several internal errors (assertion failures) as a result of
this.

[Bug rtl-optimization/87047] [7/8/9 Regression] performance regression because of if-conversion

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

Summary|[7/8/9/10 Regression]   |[7/8/9 Regression]
   |performance regression  |performance regression
   |because of if-conversion|because of if-conversion

--- Comment #15 from Alexander Monakov  ---
Fixed on the trunk, I'll ask about backporting to gcc-9 branch after a month or
so.

[Bug fortran/65438] Unnecessary ptr check

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|cesar at gcc dot gnu.org   |burnus at gcc dot 
gnu.org

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #17 from Stas Sergeev  ---
Created attachment 46991
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991=edit
the fix

Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build process passes (previous patches were only
tested for the part of the build process that
was failing).

This patch allows --with-build-time-tools=
to override the in-tree compiler, which I
think this option is for.
Please let me know if it is good or bad.

[Bug rtl-optimization/87047] [7/8/9/10 Regression] performance regression because of if-conversion

[amonakov at gcc dot gnu.org]

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

--- Comment #14 from Alexander Monakov  ---
Author: amonakov
Date: Wed Oct  2 15:37:12 2019
New Revision: 276466

URL: https://gcc.gnu.org/viewcvs?rev=276466=gcc=rev
Log:
ifcvt: improve cost estimation (PR 87047)

PR rtl-optimization/87047
* ifcvt.c (average_cost): New static function.  Use it...
(noce_process_if_block): ... here.

testsuite/
* gcc.dg/pr87047.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr87047.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ifcvt.c
trunk/gcc/ifcvt.h
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/91842] new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Martin Jambor  ---
Fixed by skipping the test on power.

[Bug testsuite/91842] new test case gcc.dg/ipa/ipa-sra-19.c in r275982 has compilation error

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Wed Oct  2 15:09:37 2019
New Revision: 276465

URL: https://gcc.gnu.org/viewcvs?rev=276465=gcc=rev
Log:
[PR testsuite/91842] Skip gcc.dg/ipa/ipa-sra-19.c on power

2019-10-02  Martin Jambor  

PR testsuite/91842
* gcc.dg/ipa/ipa-sra-19.c: Skip on powerpc.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c

[Bug c++/91967] gtest from google generates incorrect assembly code on x86 solaris

[bobw at cristie dot com]

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

--- Comment #1 from bob wilkinson  ---
Created attachment 46990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46990=edit
output of g++ with save-temps

[Bug c++/91967] New: gtest from google generates incorrect assembly code on x86 solaris

[bobw at cristie dot com]

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

Bug ID: 91967
   Summary: gtest from google generates incorrect assembly code on
x86 solaris
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bobw at cristie dot com
  Target Milestone: ---

I compile the latest version of gtest (from google) under cmake on Solaris 11.3
(x86), I see ...

cd
/export/home/jenkins/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest
&& /usr/local/bin/c++  -DBOOST_ALL_DYN_LINK -DBOOST_ASIO_DYN_LINK
-DBOOST_AUTO_LINK_NOMANGLE -DBOOST_NETWORK_ENABLE_HTTPS
-DBOOST_NO_VARIADIC_TEMPLATES -D_GLIBCXX_HAS_GTHREADS -D_GLIBCXX__PTHREADS
-D_XPG6 -D__EXTENSIONS__ -Dsunos
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../common/include
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../common/basic
-I/export/home/jenkins/work/3rdparty/trunk/cmake/../unix/common/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/../include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/build/openssl_1_1_1c/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/sqlite_3_28_0
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest/include
-I/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest
-isystem
/export/home/jenkins/work/3rdparty/trunk/cmake/../3rdparty/boost_1_70_0 -DCMAKE
-fPIC -Wall -Wextra -Dunix -pthread -std=c++11 -Wno-unused-parameter
-Wno-unknown-pragmas -O2 -DNDEBUG   -Wall -Wshadow -Werror
-Wno-error=dangling-else -DGTEST_HAS_PTHREAD=1 -fexceptions -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -std=c++11 -o
CMakeFiles/gtest.dir/src/gtest-all.cc.o -c
/export/home/jenkins/work/3rdparty/trunk/3rdparty/gtest_1_9_0/googletest/src/gtest-all.cc
Assembler: gtest-all.cc
"/var/tmp//ccc2a4pF.s", line 84753 : Illegal mnemonic
Near line: "int3"
"/var/tmp//ccc2a4pF.s", line 84753 : Syntax error
Near line: "int3"

jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
g++ --version
g++ (GCC) 9.2.0
Copyright (C) 2019 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.

jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
uname -a
SunOS solaris 5.11 11.3 i86pc i386 i86pc
jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$
grep TOPLEVEL_CONFIGURE_ARGUMENTS ~/src/gcc/gcc-9.2.0/config.log
TOPLEVEL_CONFIGURE_ARGUMENTS='./configure'
jenkins@solaris:~/work/3rdparty/trunk/3rdparty/build/gtest_1_9_0/googletest$

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

  Attachment #46987|0   |1
is obsolete||

--- Comment #12 from Oleg Endo  ---
Created attachment 46989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46989=edit
Proposed patch

(In reply to Zavadovsky Yan from comment #11)
> 
> Yes.
> Any variant - I can add more compiler options to "makefiles" or rebuild
> whole toolchain.

Great!  That makes things simpler.

The attached patch implements the ST40 special case for fabs and fneg
instructions.  You have to specify -m4-300 or -m4-300-single.  It will also
enable the fpchg instruction which is supported by ST40.

Please try it out.  Let me know what you find.  I'll briefly test it and commit
it to GCC 10, GCC 9, GCC 8, GCC 7 if there are no problems.  Although this
issue has been introduced in the SH FPU code refactoring in GCC 5...

[Bug c++/91966] New: pack expansion for Cartesian product breaks if certain indirections are involved

[ecrypa at posteo dot de]

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

Bug ID: 91966
   Summary: pack expansion for Cartesian product  breaks if
certain indirections are involved
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ecrypa at posteo dot de
  Target Milestone: ---

The following metaprogramming produces an unexpected output: see the types
`computed` and `expected` at the end.

https://godbolt.org/z/pX7WxD

BEGIN_CODE

// Reduced to this include-free example. Further reduction is hard: Either
// the bug(?) disappears, or the program becomes meaningless.

template
struct list {};

struct nil;



template
struct number {
  constexpr /*implicit*/ operator int() const { return n; }
  using type = number;
};

using false_ = number<0>;
using true_ = number<1>;

static_assert(!false_{}, "");
static_assert(true_{}, "");

template using numbers = list...>;



template
struct less_impl;

template
struct less_impl, number>
  : number<(lhs < rhs)> {};

template using less = typename less_impl::type;



template
struct sum_impl {
  static_assert(sizeof...(vs) == 0, "see specialization");
  using type = v0;
};

template
struct sum_impl, number, vs...>
  : sum_impl, vs...> {};

template using sum = typename sum_impl::type;



template
struct conditional_impl {
  static_assert(num{}, "see specialization");

  template
  using type = T;
};

template<>
struct conditional_impl {
  template
  using type = F;
};

template
using conditional = typename conditional_impl::template type;



template
struct min_filter_impl;

template
struct min_filter_impl> {
  template
  using count_better_mins = sum...>;

  using type = list, nil, nums>...>;

  using debug = list, nil, void>...>;

// error: expansion pattern 'conditional...>::type, nil, void>' contains no parameter packs

};

template using min_filter = typename min_filter_impl::type;



void test_min_filter() {
  using computed = min_filter>;
  using expected = list, nil, number<2>>;
  (void)(computed{} = expected{});// compiles for identical types

// error: no match for 'operator=' (operand types are 'computed' {aka
'list, number<7>, number<2> >'} and 'expected' {aka 'list,
nil, number<2> >'})

}

int main() {}

END_CODE

[Bug fortran/91963] Logical function does not simplify

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Wed, Oct 02, 2019 at 02:03:21PM +, kargl at gcc dot gnu.org wrote:
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > But is it valid fortran?
> 
> Yes.  It's valid.  gfortran has poor handling of implied-do loops
> in initialization expression.
> 

Actually, the testcase submitted here in BZ is the
one of three posted in c.l.f that is invalid.  C_BOOL
is the only interoperable type for ISO BIND C, so the
use of C_SIZEOF is invalid.

[Bug fortran/91963] Logical function does not simplify

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> But is it valid fortran?

Yes.  It's valid.  gfortran has poor handling of implied-do loops
in initialization expression.

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[m.cencora at gmail dot com]

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

--- Comment #13 from m.cencora at gmail dot com ---
You can remove my_array from the test case. I put there only to show that using
it instead of std::array allows to workaround the bug.

[Bug fortran/91716] [9 Regression] ICE in output_constant, at varasm.c:5026

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

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

--- Comment #9 from Bernd Edlinger  ---
now also for fixed in gcc-9 branch

[Bug fortran/91716] [9 Regression] ICE in output_constant, at varasm.c:5026

[edlinger at gcc dot gnu.org]

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

--- Comment #8 from Bernd Edlinger  ---
Author: edlinger
Date: Wed Oct  2 13:22:37 2019
New Revision: 276458

URL: https://gcc.gnu.org/viewcvs?rev=276458=gcc=rev
Log:
2019-10-02  Bernd Edlinger  

Backport from mainline

2019-09-13  Bernd Edlinger  

PR fortran/91716
* trans-array.c (gfc_conv_array_initializer): Always assign the
array type of the field to the string constant.

PR fortran/91716
* gfortran.dg/pr91716.f90: New test.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-array.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets

[gr.audio at gmail dot com]

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

--- Comment #5 from Guillaume  ---
I think I found a work-around for the time being.

If you define your packed structs with the 'volatile' qualifier, the bug
doesn't seem to show up. May not be completely ideal, but it appears to work,
and the reason why makes sense.

Like so: typedef volatile struct __attribute__((__packed__)) { ... }

Of course, would still be nice to fix the misalignment check...

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

--- Comment #7 from Jörg Richter  ---
Yes, I changed our code already to 
if( C != Enum() )

But I still think that an explicit cast should always silence this warning.

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
(In reply to Jörg Richter from comment #5)
> There needs to be at least a way to suppress the warning with a cast 
> or some other construct (not pragma).

That is simple: if ( C != A ) ...

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at ucw dot cz]

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

--- Comment #28 from Jan Hubicka  ---
> Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
> -flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.
Thanks! My testing concluded independently so I went ahead and comitted
the patch.  Funilly enough I have problem to get some reduced testcase,
perhaps Martin will chime in.

The main confusion here was the fact that I did not assume anonymous
namespace type to be ever matched agains non-C++ type, but in the
testcase it happens which triggered two not so well tought out code
paths.

Honza

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[hubicka at gcc dot gnu.org]

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

--- Comment #27 from Jan Hubicka  ---
Author: hubicka
Date: Wed Oct  2 12:41:36 2019
New Revision: 276454

URL: https://gcc.gnu.org/viewcvs?rev=276454=gcc=rev
Log:
PR c++/91222
* ipa-devirt.c (warn_types_mismatch): Fix conditional on anonymous
namespace types.

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

[Bug tree-optimization/91965] New: missing simplification for (C - a) << N

[amonakov at gcc dot gnu.org]

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

Bug ID: 91965
   Summary: missing simplification for (C - a) << N
   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: amonakov at gcc dot gnu.org
  Target Milestone: ---

Noticed this issue when preparing a testcase for PR 87047.  We do not simplify
(1048575ull - x) << 44 on GIMPLE:

unsigned long long foo(unsigned long long a)
{
return (1048575 - a) << 44;
}
void bar(unsigned long long *a)
{
for (int i = 0; i < 1024; i++)
a[i] = foo(a[i]);
}

we use (~a)<<44 for 'foo', but that is thanks to combine, in 'bar' combine
doesn't make the same transform (the 1048575 constant is moved into a pseudo in
another BB, and combine doesn't know that's the only use):

foo:
movq%rdi, %rax
notq%rax
salq$44, %rax
ret
bar:
leaq8192(%rdi), %rcx
movl$1048575, %edx
.L4:
movq%rdx, %rax
subq(%rdi), %rax
addq$8, %rdi
salq$44, %rax
movq%rax, -8(%rdi)
cmpq%rcx, %rdi
jne .L4
ret

Do we want to handle this early on via match.pd? Perhaps also applies to
simplifying (a +- C) << N.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Huh, I thought I'd already fixed this a while ago.

I was thinking of Bug 85632 which is different.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Fregl from comment #3)
> It seems this is firm limitation.

It's a bug, you just have to wait for it to be fixed.

[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support

[fregloin at gmail dot com]

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

--- Comment #3 from Fregl  ---
In out product we use 32 bit toolchain, but work with large files.
So there is only solution to use direct stat call insted fs::file_size?
It seems this is firm limitation.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[ktkachov at gcc dot gnu.org]

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #25)
> > --- Comment #24 from ktkachov at gcc dot gnu.org ---
> > Thanks. Unfortunately I still see the ICE building 507.cactuBSSN_r on 
> > aarch64
> > with -flto in the same place:
> >  995   gcc_assert (TYPE_NAME (t1)
> >  996   && TREE_CODE (TYPE_NAME (t1)) == TYPE_DECL);
> Sorry to hear that seems cactusBSSN triggers a lot of interesting
> behaviour here.  This conditional should fix it.
> 
> Index: ipa-devirt.c
> ===
> --- ipa-devirt.c  (revision 276420)
> +++ ipa-devirt.c  (working copy)
> @@ -986,8 +986,8 @@ warn_types_mismatch (tree t1, tree t2, l
>|| (type_with_linkage_p (TYPE_MAIN_VARIANT (t2))
> && type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t2
>  {
> -  if (type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
> -   && !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
> +  if (!type_with_linkage_p (TYPE_MAIN_VARIANT (t1))
> +   || !type_in_anonymous_namespace_p (TYPE_MAIN_VARIANT (t1)))
>   {
> std::swap (t1, t2);
> std::swap (loc_t1, loc_t2);

Thanks! That fixes the benchmark build (and the rest of SPEC builds fine with
-flto). It also bootstraps and tests on aarch64-none-linux-gnu fine.

[Bug target/88630] Incorrect float negating together with convertion to int on ST-40

[zavadovsky.yan at gmail dot com]

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

--- Comment #11 from Zavadovsky Yan  ---
>We can set it as a default behavior for all FPU-capable SH4 variants, 
>but that will pessimize it for everything.

>The other option is to enable this only for your specific CPU (ST-40), 
>which would require you to use the -m4-300 option, not the -m4 option

If behavior of hardware is variative for this fpscr register switching it by
some option sounds as good idea.


>Would that be feasible for you?

Yes.
Any variant - I can add more compiler options to "makefiles" or rebuild whole
toolchain.

[Bug c++/91964] Wrong -Wint-in-bool-context warning for enum constant

[joerg.rich...@pdv-fs.de]

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

--- Comment #5 from Jörg Richter  ---
There needs to be at least a way to suppress the warning with a cast 
or some other construct (not pragma).

[Bug libstdc++/81091] libstdc++ not built with large file support

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Richard Biener from comment #0)
> > libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> > fopen/open
> > in fstream and friends that can fail not only because of large files but
> > files with large inode numbers depending on the underlying filesystem.
> 
> Richi, are you sure about that?

I think I looked at all unresolved symbols of libstdc++.so and there were
some not using the LFS interfaces.  I didn't actually see you are "manually"
selecting the API.

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/81091] libstdc++ not built with large file support

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #0)
> libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> fopen/open
> in fstream and friends that can fail not only because of large files but
> files with large inode numbers depending on the underlying filesystem.

Richi, are you sure about that?

config/io/basic_file_stdio.cc does:

#ifdef _GLIBCXX_USE_LFS
if ((_M_cfile = fopen64(__name, __c_mode)))
#else
if ((_M_cfile = fopen(__name, __c_mode)))
#endif

And that macro should be set during configure, via:

dnl
dnl Check whether LFS support is available.
dnl
AC_DEFUN([GLIBCXX_CHECK_LFS], [
  AC_LANG_SAVE
  AC_LANG_CPLUSPLUS
  ac_save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$CXXFLAGS -fno-exceptions"
  AC_MSG_CHECKING([for LFS support])
  AC_CACHE_VAL(glibcxx_cv_LFS, [
GCC_TRY_COMPILE_OR_LINK(
  [#include 
   #include 
   #include 
  ],
  [FILE* fp;
   fopen64("t", "w");
   fseeko64(fp, 0, SEEK_CUR);
   ftello64(fp);
   lseek64(1, 0, SEEK_CUR);
   struct stat64 buf;
   fstat64(1, );],
  [glibcxx_cv_LFS=yes],
  [glibcxx_cv_LFS=no])
  ])
  if test $glibcxx_cv_LFS = yes; then
AC_DEFINE(_GLIBCXX_USE_LFS, 1, [Define if LFS support is available.])
  fi
  AC_MSG_RESULT($glibcxx_cv_LFS)
  CXXFLAGS="$ac_save_CXXFLAGS"
  AC_LANG_RESTORE
])

So I think fstream is OK.

However, there are some bugs elsewhere due to not checking _GLIBCXX_USE_LFS and
so not using the largefile APIs:

src/c++11/random.cc:_M_fd = ::open(fname, O_RDONLY);
src/c++11/random.cc:_M_file = static_cast(std::fopen(fname, "rb"));

This should be OK in practice, because fname is guaranteed to be either
"/dev/random" or "/dev/urandom" (it seems unlikely that those devices will have
inode numbers that don't fit in 32 bits).

Nothing in src/filesystem and std/c++17/fs_* checks _GLIBCXX_USE_LFS or uses
the LARGEFILE64 APIs. I think those files should be built with
_FILE_OFFSET_BITS=64 so that stat, lstat, open, truncate etc. handle large
files automatically, without having to remember to use the LARGEFILE64 versions
explicitly.

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 regression]   |[9 regression] Optimization
   |Optimization leads to   |leads to invalid code
   |invalid code|
  Known to fail||9.2.0

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

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Wed Oct  2 10:54:10 2019
New Revision: 276448

URL: https://gcc.gnu.org/viewcvs?rev=276448=gcc=rev
Log:
2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr91606.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug other/91879] --with-build-time-tools doesn't work as expected

[stsp at users dot sourceforge.net]

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

Stas Sergeev  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---
Summary|--with-build-sysroot|--with-build-time-tools
   |doesn't work as expected|doesn't work as expected

[Bug other/91879] --with-build-sysroot doesn't work as expected

[stsp at users dot sourceforge.net]

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

--- Comment #16 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #15)
> For the record, this has moved to
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html

Thanks, I also would like to apologize to Joseph for
not following his suggestion and instead keeping to
fight with the gcc build system. I can't help feeling
there is a bug here, and I think I am quite close to
getting it solved, so I'd be upset having to change the
approach after so many investigations, at least for now.

I've found this patch of Paolo Bonzini:
https://gcc.gnu.org/ml/gcc-patches/2006-01/msg00823.html
---
(GCC_TARGET_TOOL): Do not use a host tool if we found a target tool
with a complete path in either $with_build_time_tools or $exec_prefix.
---

That made me think that --with-build-time-tools=
should override the in-tree tools, but it is
not what actually happens. More details here:
https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
Basically, the idea was to build one djgpp on host,
and then use that one for building the target libs
in another build tree. But it doesn't pick up the
host-installed tools.
After looking at the Paolo's patch, I tried the following
change:

--- config/acx.m4.old  2019-10-02 02:39:31.976773572 +0300
+++ config/acx.m4  2019-10-02 02:08:57.223563920 +0300
@@ -522,7 +522,7 @@
   fi
 else
   ifelse([$4],,,
-  [ok=yes
+  [ok=no
   case " ${configdirs} " in
 *" patsubst([$4], [/.*], []) "*) ;;
 *) ok=no ;;


And indeed got the build done, as --with-build-time-tools=
now found all the host tools in preference of the in-tree tools.
So currently I suspect Paolo's patch is at fault.