[Bug target/96789] x264: sub4x4_dct() improves when vectorization is disabled

[linkw at gcc dot gnu.org]

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

--- Comment #3 from Kewen Lin  ---
Bisection shows it started to fail from r11-205.

[Bug libstdc++/95322] std::list | take | transform, expression does not work cbegin() == end()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:3ae0cd94abc15e33dc06ca7a5f76f14b1d74129f

commit r11-2898-g3ae0cd94abc15e33dc06ca7a5f76f14b1d74129f
Author: Patrick Palka 
Date:   Wed Aug 26 21:51:48 2020 -0400

libstdc++: Implement remaining piece of LWG 3448

Almost all of the proposed resolution for LWG 3448 is already
implemented; the only part left is to adjust the return type of
transform_view::sentinel::operator-.

libstdc++-v3/ChangeLog:

PR libstdc++/95322
* include/std/ranges (transform_view::sentinel::__distance_from):
Give this a deduced return type.
(transform_view::sentinel::operator-): Adjust the return type so
that it's based on the constness of the iterator rather than
that of the sentinel.
* testsuite/std/ranges/adaptors/95322.cc: Refer to LWG 3488.

[Bug fortran/96809] New: Duplicated module name in Fortran test cases

[joey.ye.cc at gmail dot com]

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

Bug ID: 96809
   Summary: Duplicated module name in Fortran test cases
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joey.ye.cc at gmail dot com
  Target Milestone: ---

$ pwd
gcc/testsuite/gfortran.fortran-torture/execute
$ grep -i "module test$" *
pr32140.f90:MODULE TEST
pr32604.f90:MODULE TEST

When tested with "make check -j16", these two case may run in parallel and
create test.mod at the same time. It leads to conflict and random test failure.

Suggested solution: use module naming convention like test_pr32140 to avoid
possible conflict.

[Bug gcov-profile/96285] The documentation of -fprofile-exclude-files is unclear

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:8ca43e4ea58ae436af4b5818916abc15b2fd8f49

commit r11-2891-g8ca43e4ea58ae436af4b5818916abc15b2fd8f49
Author: Göran Uddeborg 
Date:   Wed Aug 26 17:06:28 2020 -0600

Fix documentation of -fprofile-exclude-files

The wording of the description of -fprofile-exclude-files is easy to
misunderstand.  One can be led to believe a file is excluded only if
it matches all of the patterns, not just one.  This patch tries to
clarify the function.  It also adjusts the wording of
-fprofile-filter-files accordingly.

gcc/

PR gcov-profile/96285
* common.opt, doc/invoke.texi: Clarify wording of
-fprofile-exclude-files and adjust -fprofile-filter-files to
match.

[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The way GCC actually behaves is that this constant is unsigned in the 
preprocessor but signed outside the preprocessor.  I'm not sure that's 
exactly intent (though the preprocessor having only a single signed and 
unsigned type, with this constant not fitting in the signed type, means it 
couldn't be interpreted as signed in the preprocessor if allowed in #if 
expressions at all).  The warnings are attempting to cover both the C90 
case where a decimal constant too large for signed long can be unsigned 
long, and the case of a constant too large for intmax_t.

[Bug target/96804] Arguments are swapped in floating-point addition

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
IEEE 754 does not specify the choice of output NaN.  None of the C 
bindings to IEEE 754 specify the choice of output NaN.  There are various 
architecture differences in choice of output NaN (for example, RISC-V 
always uses a canonical quiet NaN, x87 chooses based on comparing the 
payloads, SSE chooses based on the operand order to the instruction).  
Since none of the C bindings specify anything about the choice of output 
NaN, there is no expectation that particular C syntax constructs map to 
any particular rules for choice of NaN.  And even once you have a choice 
of NaN from an arithmetic operation, the C bindings leave it 
implementation-defined whether assignment, function return and other 
conversions as if by assignment are a convertFormat or copy operation (and 
convertFormat from a type to itself might change a NaN payload).

[Bug target/96808] MMA built-in dies with incorrect sharing of tree nodes error

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Target||powerpc*-*-*
   Target Milestone|--- |11.0
 CC||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-08-26

[Bug target/96808] New: MMA built-in dies with incorrect sharing of tree nodes error

[bergner at gcc dot gnu.org]

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

Bug ID: 96808
   Summary: MMA built-in dies with incorrect sharing of tree nodes
error
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

bergner@pike:~/$ cat bug.c 
void
test (__vector_quad *dst, vector unsigned char vc)
{
  __vector_quad vq[2];
  __builtin_mma_xxsetaccz([1]);
  __builtin_mma_xvf32gerpp([1], vc, vc);
  *dst = vq[1];
}

bergner@pike:~/$ gcc -S -O2 -mcpu=power10 bug.c 
bug.c: In function ‘test’:
bug.c:2:1: error: incorrect sharing of tree nodes
2 | test (__vector_quad *dst, vector unsigned char vc)
  | ^~~~
MEM[(__vector_quad *) + 64B]
MEM[(__vector_quad *) + 64B] = _4;
during GIMPLE pass: cfg
bug.c:2:1: internal compiler error: verify_gimple failed
0x11337297 verify_gimple_in_cfg(function*, bool)
/home/bergner/gcc/gcc-fsf-mainline-bug/gcc/tree-cfg.c:5491
0x10ffb54f execute_function_todo
/home/bergner/gcc/gcc-fsf-mainline-bug/gcc/passes.c:1992
0x10ff9da3 do_per_function
/home/bergner/gcc/gcc-fsf-mainline-bug/gcc/passes.c:1640
0x10ffb867 execute_todo
/home/bergner/gcc/gcc-fsf-mainline-bug/gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This is a bug in rs6000_gimple_fold_mma_builtin not expecting to handle an
array of accumulators.  Mine.  This dies on trunk and GCC 10.

[Bug tree-optimization/96807] New: Division by zero produces zero with gcc -O2

[fazedo at gmail dot com]

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

Bug ID: 96807
   Summary: Division by zero produces zero with gcc -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fazedo at gmail dot com
  Target Milestone: ---

Hello,

The following code produces 1/0 = 0 with gcc -O2: 



#include 
#include 

int main(int argn, char** argc){
  unsigned base = argn>1 ? atoi(argc[1]) : 0;
  if (base!=1) printf("%d\n", 1/base); // produces 0 for base=0 with -O2
  return 0; 
}


The same behavior occurs with clang but not with icc.  If 1/base is not guarded
by if or if base is a signed integer, it produces a floating point exception
even with -O2. 

As a result, Fortran's intrinsic power operator (**) applied to integers is
producing wrong results when the base is zero and the exponent is negative.
Instead of giving division by zero or infinity, it gives zero.

The code given below shows that base**(-1) yields 0 when base=0. 

It is my understanding that gfortran calls functions pow_iX_iY from
libgfortran/generated. These functions are correctly coded but they produce
0**n=0 for n<0 due to optimizations when libgfortran is compiled. 


program power
  implicit none
  integer (kind = 4) :: base = 0

  print *, base**(-1)   ! produces 0
  print *, real(base, 4)**(-1)  ! produces infinity
end program



By the way, is there any advantage to using the pow_XX_YY.c functions on
libgfortran/generated instead of __powiXX2 (and its integer version) defined
for __builtin_powi on libgcc2.c?

It seems to me that libgcc2's version reads much better and should be a little
faster because it saves the first multiplication (by pow=1).

The only difference in behaviour I see is that when the exponent is negative
and the base if a floating point type, libgcc2 calculates 1/(x**(-n)) while
libgfortran calculates (1/x)**(-n). The first version being more accurate.

I am using gcc 9.3.0 on x86-64.

Best regards,
Fabio Azevedo

[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
I'm working on a patch.

[Bug rtl-optimization/96796] [9/10/11 Regression] aarch64: ICE during RTL pass: reload

[acoplan at gcc dot gnu.org]

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

--- Comment #5 from Alex Coplan  ---
Started with this change:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8eaff6ef97836100801f7b40dc03f77fbebe03ac

[Bug ipa/96806] ICE: in good_cloning_opportunity_p, at ipa-cp.c:3235 with -O -fipa-cp -fipa-cp-clone --param=ipa-cp-max-recursive-depth=94 --param=logical-op-non-short-circuit=0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||fxue at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
   Last reconfirmed||2020-08-26

--- Comment #1 from Martin Liška  ---
Likely started when the params were added?
r10-5098-g9b14fc3326e08797

[Bug target/96802] [11 Regression] ICE in ix86_handle_option, at common/config/i386/i386-common.c:338

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 11.

[Bug target/96802] [11 Regression] ICE in ix86_handle_option, at common/config/i386/i386-common.c:338

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:8f1ea8ddccc34c28f72910d9f61bacd35cc73270

commit r11-2890-g8f1ea8ddccc34c28f72910d9f61bacd35cc73270
Author: H.J. Lu 
Date:   Wed Aug 26 12:37:05 2020 -0700

x86: Reject target("no-general-regs-only")

Reject target("no-general-regs-only") pragma and attribute.

gcc/

PR target/96802
* config/i386/i386-options.c (ix86_valid_target_attribute_inner_p):
Reject target("no-general-regs-only").

gcc/testsuite/

PR target/96802
* gcc.target/i386/pr96802-1.c: New test.
* gcc.target/i386/pr96802-2.c: Likewise.

[Bug ipa/96806] New: ICE: in good_cloning_opportunity_p, at ipa-cp.c:3235 with -O -fipa-cp -fipa-cp-clone --param=ipa-cp-max-recursive-depth=94 --param=logical-op-non-short-circuit=0

[zsojka at seznam dot cz]

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

Bug ID: 96806
   Summary: ICE: in good_cloning_opportunity_p, at ipa-cp.c:3235
with -O -fipa-cp -fipa-cp-clone
--param=ipa-cp-max-recursive-depth=94
--param=logical-op-non-short-circuit=0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -fipa-cp -fipa-cp-clone
--param=ipa-cp-max-recursive-depth=94 --param=logical-op-non-short-circuit=0
testcase.C 
testcase.C: In function 'int w(const p*, const p*, const m*, int)':
testcase.C:45:1: warning: control reaches end of non-void function
[-Wreturn-type]
   45 | }
  | ^
during IPA pass: cp
testcase.C: At global scope:
testcase.C:49:1: internal compiler error: in good_cloning_opportunity_p, at
ipa-cp.c:3235
   49 | }
  | ^
0xa68e97 good_cloning_opportunity_p
/repo/gcc-trunk/gcc/ipa-cp.c:3235
0x1ce1a8c decide_about_value
/repo/gcc-trunk/gcc/ipa-cp.c:5482
0x1ce3024 decide_whether_version_node
/repo/gcc-trunk/gcc/ipa-cp.c:5549
0x1ce3024 ipcp_decision_stage
/repo/gcc-trunk/gcc/ipa-cp.c:5731
0x1ce3024 ipcp_driver
/repo/gcc-trunk/gcc/ipa-cp.c:5918
0x1ce3024 execute
/repo/gcc-trunk/gcc/ipa-cp.c:6009
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2874-20200826111256-ge3684bcbf88-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2874-20200826111256-ge3684bcbf88-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200826 (experimental) (GCC)

[Bug target/96802] [11 Regression] ICE in ix86_handle_option, at common/config/i386/i386-common.c:338

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |hjl.tools at gmail dot 
com
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-August/
   ||552720.html
   Keywords||patch

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552720.html

[Bug c++/96805] [10/11 Regression] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Last reconfirmed||2020-08-26
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.3
 Ever confirmed|0   |1
Summary|ICE: Segmentation fault in  |[10/11 Regression] ICE:
   |instantiate_template /  |Segmentation fault in
   |pop_nested_class()  |instantiate_template /
   ||pop_nested_class()

--- Comment #3 from Marek Polacek  ---
Confirmed.  Seems like this one started with r11-2747 instead.

[Bug c++/96805] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

--- Comment #2 from Marc Mutz  ---
also in gcc version 10.2.1 20200826 (GCC)

[Bug libstdc++/96731] uniform_int_distribution requirement that its type is_integral is too strict

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Created attachment 49135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49135=edit
Patch to relax std::uniform_int_distribution requirements

This patch allows a custom integer-like type to be used with
std::uniform_int_distribution, but it's harder than it seems.

We need to use std::make_unsigned, which is undefined for non-integral types.
The patch will use _IntType is numeric_limits<_IntType>::is_signed is false,
otherwise it will use make_unsigned_t<_IntType> if possible, and unsigned long
long otherwise.

But the example still fails, because std::sample also requires an integral
type, and also wants to use make_unsigned. And the standard is clear that it's
not just undefined, but ill-formed and requires a diagnostic:

> Mandates: For the overload in namespace std, Distance is an integer type

I don't plan to work on this any further for now.

[Bug c++/96805] ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

--- Comment #1 from Marc Mutz  ---
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/d/gcc/10/libexec/gcc/x86_64-pc-linux-gnu/10.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/d/gcc/10
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion :
(reconfigured) ../gcc/configure --prefix=/d/gcc/10
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200824 (GCC)

[Bug c++/96805] New: ICE: Segmentation fault in instantiate_template / pop_nested_class()

[marc.mutz at kdab dot com]

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

Bug ID: 96805
   Summary: ICE: Segmentation fault in instantiate_template /
pop_nested_class()
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marc.mutz at kdab dot com
  Target Milestone: ---

Created attachment 49134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49134=edit
BZ2-compressed preprocessed source

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96732 looks similar, but this is
on 10.2, not 11...

$ g++ -E -pipe -O2 -fPIC -std=c++2a -fvisibility=hidden
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections -fno-exceptions
-Wall -Wextra -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond
-Wno-stringop-overflow -Wno-format-overflow -Wsuggest-override -D_REENTRANT
-DQT_NO_JAVA_STYLE_ITERATORS -DPCRE2_DISABLE_JIT -DHAVE_CONFIG_H
-DQT_VERSION_STR='"6.0.0"' -DQT_VERSION_MAJOR=6 -DQT_VERSION_MINOR=0
-DQT_VERSION_PATCH=0 -DQT_BOOTSTRAPPED -DQT_NO_CAST_TO_ASCII
-DPCRE2_CODE_UNIT_WIDTH=16 -DQT_NO_FOREACH -DQT_NO_CAST_FROM_ASCII
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_BOOTSTRAP_LIB
-DQT_BUILDING_QT -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_DEPRECATED_WARNINGS_SINCE=0x06
-DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/marc/Qt/qtbase/src/tools/bootstrap -I. -I/home/marc/Qt/qtbase/src/tools
-I/home/marc/Qt/qtbase/src/3rdparty/tinycbor/src
-I/home/marc/Qt/qtbase/src/3rdparty/pcre2/src -I../../../include
-I../../../include/QtCore -I../../../include/QtCore/6.0.0
-I../../../include/QtCore/6.0.0/QtCore -I../../../include/QtXml
-I../../../include/QtXml/6.0.0 -I../../../include/QtXml/6.0.0/QtXml
-I/home/marc/Qt/qtbase/mkspecs/linux-g++ -o qendian.ii
/home/marc/Qt/qtbase/src/corelib/global/qendian.cpp
../../../include/QtCore/../../../qtbase/src/corelib/tools/qarraydataops.h:102:77:
internal compiler error: Segmentation fault
  102 | noexcept(std::is_nothrow_constructible_v>)
  |
^
0xc2ee1f crash_signal
../../gcc/gcc/toplev.c:328
0x6280c5 pop_nested_class()
../../gcc/gcc/cp/class.c:8184
0x738747 instantiate_template_1
../../gcc/gcc/cp/pt.c:20853
0x733694 instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:20908
0x733694 instantiate_alias_template
../../gcc/gcc/cp/pt.c:20946
0x733694 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:15147
0x739b0f lookup_template_class_1
../../gcc/gcc/cp/pt.c:9853
0x73a1ec lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:10119
0x756b3d finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:3408
0x6fe15d cp_parser_template_id
../../gcc/gcc/cp/parser.c:16739
0x6fe3cc cp_parser_class_name
../../gcc/gcc/cp/parser.c:23713
0x6fb101 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:6776
0x6fb101 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6458
0x702706 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:18134
0x6e93ed cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17792
0x6fc9a9 cp_parser_type_specifier_seq
../../gcc/gcc/cp/parser.c:22402
0x6f6f34 cp_parser_type_id_1
../../gcc/gcc/cp/parser.c:22219
0x6f9473 cp_parser_template_type_arg
../../gcc/gcc/cp/parser.c:22310
0x6fcb2f cp_parser_template_argument
../../gcc/gcc/cp/parser.c:17189
0x6fcb2f cp_parser_template_argument_list
../../gcc/gcc/cp/parser.c:17100
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/96802] [11 Regression] ICE in ix86_handle_option, at common/config/i386/i386-common.c:338

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
   Target Milestone|--- |11.0
   Last reconfirmed||2020-08-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Uroš Bizjak  ---
Looks like fallout from recent general-regs-only function attribute addition.

CC author.

[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #4 from Richard Smith  ---
(In reply to Richard Smith from comment #3)
> such a literal "has no type" in C, which presumably results in undefined
> behavior

Ah, no, C11 6.4.4/2 makes this a constraint violation. But either way I think
there's room for a vendor extension here.

[Bug c/96788] "integer constant is so large that it is unsigned" warning is incorrect

[richard-gccbugzilla at metafoo dot co.uk]

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

--- Comment #3 from Richard Smith  ---
In the mean time, what is GCC's intent here? Clang is following the behavior
described by GCC's diagnostic text, treating decimal integer literals that
don't fit in 'long long' but do fit in 'unsigned long long' as the latter type
(I've not checked back far enough to tell if this is what GCC ever actually
did, or if we got this by looking at the diagnostics and didn't check the
behavior). If that's not what GCC intends to do any more, that'd be useful for
us to know, and we can switch to following GCC's actual behavior. (It'd also
make sense to update the diagnostic text in that case!)

It looks like both the Clang behavior (treat the literal as 'unsigned long
long') and the GCC behavior (treat the literal as '__int128' where available
and 'long long' otherwise) are conforming extensions in both C and C++, even
though __int128 isn't (yet) an extended integer type: such a literal "has no
type" in C, which presumably results in undefined behavior, and makes the
program ill-formed in C++, so it seems there is room for a vendor extension in
both languages.

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:5494edae83ad33c769bd1ebc98f0c492453a6417

commit r11-2887-g5494edae83ad33c769bd1ebc98f0c492453a6417
Author: Jonathan Wakely 
Date:   Wed Aug 26 19:32:30 2020 +0100

libstdc++: Use correct argument type for __use_alloc [PR 96803]

The _Tuple_impl constructor for allocator-extended construction from a
different tuple type uses the _Tuple_impl's own _Head type in the
__use_alloc test. That is incorrect, because the argument tuple could
have a different type. Using the wrong type might select the
leading-allocator convention when it should use the trailing-allocator
convention, or vice versa.

libstdc++-v3/ChangeLog:

PR libstdc++/96803
* include/std/tuple
(_Tuple_impl(allocator_arg_t, Alloc, const _Tuple_impl&)):
Replace parameter pack with a type parameter and a pack and pass
the first type to __use_alloc.
* testsuite/20_util/tuple/cons/96803.cc: New test.

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is not a regression, it's been wrong since I added uses-allocator
construction in r174443.

[Bug c/96804] Arguments are swapped in floating-point addition

[chfast at gmail dot com]

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

--- Comment #3 from Paweł Bylica  ---
Yes, you are right, that is not violation of IEEE 754 (I assumed wrongly
previously, sorry).

However, it still maybe undesired to get different binary results depending on
optimization enabled/disabled.

[Bug target/65146] alignment of _Atomic structure member is not correct

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

URL||https://gitlab.com/x86-psAB
   ||Is/i386-ABI/-/issues/1

--- Comment #23 from H.J. Lu  ---
I created:

https://gitlab.com/x86-psABIs/i386-ABI/-/issues/1

[Bug c/96804] Arguments are swapped in floating-point addition

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Paweł Bylica from comment #0)
> This is a problem because when both arguments are NaNs, the result may be
> different than the one predicted by IEEE 754.

Could you quote the sentence in IEEE 754 that you believe is violated? As far
as I can tell, the order doesn't matter:

"For an operation with quiet NaN inputs, other than maximum and minimum
operations, if a floating-point result is to be delivered the result shall be a
quiet NaN which should be one of the input NaNs."

[Bug c/96804] Arguments are swapped in floating-point addition

[chfast at gmail dot com]

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

--- Comment #1 from Paweł Bylica  ---
Created attachment 49133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49133=edit
Assembly output

[Bug c/96804] New: Arguments are swapped in floating-point addition

[chfast at gmail dot com]

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

Bug ID: 96804
   Summary: Arguments are swapped in floating-point addition
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

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

In the following function, when compiling without optimizations -O0 with GCC
10.2.0 (x86_64-linux-gnu) the arguments to the add instructions are swapped.

float fadd(const float* a, const float* b)
{
return *a + *b;
}

Assembly snippet:

movq%rdi, -8(%rbp)   # a
movq%rsi, -16(%rbp)  # b
movq-8(%rbp), %rax   # a
movss   (%rax), %xmm1# *a
movq-16(%rbp), %rax  # b
movss   (%rax), %xmm0# *b
addss   %xmm1, %xmm0 # = *b + *a

This is a problem because when both arguments are NaNs, the result may be
different than the one predicted by IEEE 754.

[Bug target/65146] alignment of _Atomic structure member is not correct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #22 from Jakub Jelinek  ---
Created attachment 49131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49131=edit
gcc11-pr65146.patch

More complete patch.

[Bug libstdc++/96803] std::tuple chooses wrong constructor for uses-allocator construction

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-26
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug libstdc++/96803] New: std::tuple chooses wrong constructor for uses-allocator construction

[redi at gcc dot gnu.org]

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

Bug ID: 96803
   Summary: std::tuple chooses wrong constructor for
uses-allocator construction
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 

struct X
{
  using allocator_type = std::allocator;

  X(X&&) { }
  X(std::allocator_arg_t, const allocator_type&, X&&) { }

  explicit X(int) { }
  explicit X(int, allocator_type) { }
};

int main()
{
  std::tuple o(0);
  std::tuple ok(o);
  std::tuple nok(std::allocator_arg, std::allocator(), o);
}

The last line of main fails:

In file included from tup.C:1:
/home/jwakely/gcc/10/include/c++/10.2.1/tuple: In instantiation of
'std::_Head_base<_Idx, _Head, true>::_Head_base(std::__uses_alloc1<_Alloc>,
_UHead&&) [with _Alloc = std::allocator; _UHead = const int&; long
unsigned int _Idx = 0; _Head = X]':
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:421:43:   required from
'std::_Tuple_impl<_Idx, _Head>::_Tuple_impl(std::allocator_arg_t, const
_Alloc&, const std::_Tuple_impl<_Idx, _UHead>&) [with _Alloc =
std::allocator; _UHead = int; long unsigned int _Idx = 0; _Head = X]'
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:775:70:   required from
'std::tuple<_Elements>::tuple(std::allocator_arg_t, const _Alloc&, const
std::tuple<_Args2 ...>&) [with _Alloc = std::allocator; _UElements =
{int}; bool _Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_explicitly_constructible(), bool>::type  = false; _Elements = {X}]'
tup.C:19:65:   required from here
/home/jwakely/gcc/10/include/c++/10.2.1/tuple:110:65: error: no matching
function for call to 'X::X(const std::allocator_arg_t&, const
std::allocator&, const int&)'
  110 |  : _Head(allocator_arg, *__a._M_a, std::forward<_UHead>(__uhead)) { }
  | ^
tup.C:12:12: note: candidate: 'X::X(int, X::allocator_type)'
   12 |   explicit X(int, allocator_type) { }
  |^
tup.C:12:12: note:   candidate expects 2 arguments, 3 provided
tup.C:11:12: note: candidate: 'X::X(int)'
   11 |   explicit X(int) { }
  |^
tup.C:11:12: note:   candidate expects 1 argument, 3 provided
tup.C:9:3: note: candidate: 'X::X(std::allocator_arg_t, const allocator_type&,
X&&)'
9 |   X(std::allocator_arg_t, const allocator_type&, X&&) { }
  |   ^
tup.C:9:50: note:   no known conversion for argument 3 from 'const int' to
'X&&'
9 |   X(std::allocator_arg_t, const allocator_type&, X&&) { }
  |  ^~~
tup.C:8:3: note: candidate: 'X::X(X&&)'
8 |   X(X&&) { }
  |   ^
tup.C:8:3: note:   candidate expects 1 argument, 3 provided


The problem is that the __use_alloc call in _Tuple_impl uses the wrong type.

[Bug target/96802] New: [11 Regression] ICE in ix86_handle_option, at common/config/i386/i386-common.c:338

[asolokha at gmx dot com]

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

Bug ID: 96802
   Summary: [11 Regression] ICE in ix86_handle_option, at
common/config/i386/i386-common.c:338
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-11.0.0-alpha20200823 snapshot (g:87c753ac241f25d222d46ba1ac66ceba89d6a200)
ICEs when compiling gcc/testsuite/gcc.target/aarch64/target_attr_11.c:

% x86_64-unknown-linux-gnu-gcc-11.0.0 -c
gcc/testsuite/gcc.target/aarch64/target_attr_11.c
gcc/testsuite/gcc.target/aarch64/target_attr_11.c:8:1: internal compiler error:
in ix86_handle_option, at common/config/i386/i386-common.c:338
8 | {
  | ^
0x7a563c ix86_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/common/config/i386/i386-common.c:338
0x1152123 ix86_valid_target_attribute_inner_p
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/config/i386/i386-options.c:1200
0x1151fcf ix86_valid_target_attribute_inner_p
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/config/i386/i386-options.c:1088
0x1156d7d ix86_valid_target_attribute_tree(tree_node*, tree_node*,
gcc_options*, gcc_options*, bool)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/config/i386/i386-options.c:1302
0x1157064 ix86_valid_target_attribute_p(tree_node*, tree_node*, tree_node*,
int)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/config/i386/i386-options.c:1408
0x8a9382 handle_target_attribute
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c-family/c-attribs.c:4379
0x7b2947 decl_attributes(tree_node**, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/attribs.c:714
0x7cf96d start_function(c_declspecs*, c_declarator*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c/c-decl.c:9184
0x82c920 c_parser_declaration_or_fndef
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c/c-parser.c:2434
0x8364a3 c_parser_external_declaration
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c/c-parser.c:1773
0x836fb9 c_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c/c-parser.c:1646
0x836fb9 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c/c-parser.c:21819
0x890efd c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200823/work/gcc-11-20200823/gcc/c-family/c-opts.c:1188

[Bug tree-optimization/96801] New: Refactoring of LIM introduced possible bug

[stefansf at linux dot ibm.com]

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

Bug ID: 96801
   Summary: Refactoring of LIM introduced possible bug
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefansf at linux dot ibm.com
  Target Milestone: ---

Consider the following example:

int a = 0, f = 0, g = 0, h = 0, i = 0;  
int b = 0;  
static int c[1][1]; 
static int *const d = [0][0]; 
int *e = 0; 
int main() {
  for (; i < 1; i++) { // LOOP-A
for (; b != 0; b++) // LOOP-B   
  if (f != 0) { 
*e = (*d)--;
break;  
  } 
  } 
  for (g = 0; g < 1; g++) { // LOOP-C   
for (h = 0; h < 1; h++) // LOOP-D   
  a = a ^ c[g][h];  
  } 
  printf("checksum = %X\n", a); 
  return a; 
}

Basically LOOP-A does nothing since the condition of inner LOOP-B never
evaluates to true. Thus we are left with LOOP-C which runs exactly one time as
does LOOP-D. Expression a ^ c[g][h] should evaluate to 0 since a as well as
c[0][0] are 0. In total we would expect to see "checksum = 0" being printed.
This is the case for me prior commit 6aec53ee4f7. With this commit "random"
numbers are printed.

Can someone confirm this?

[Bug rtl-optimization/96796] [9/10/11 Regression] aarch64: ICE during RTL pass: reload

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||10.1.1, 11.0
Summary|[9 Regression] aarch64: ICE |[9/10/11 Regression]
   |during RTL pass: reload |aarch64: ICE during RTL
   ||pass: reload
  Known to work|10.1.1, 11.0|

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Updating regression markers then

[Bug target/65146] alignment of _Atomic structure member is not correct

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #21 from Jakub Jelinek  ---
So, are we talking about something like (no -Wpsabi here)
--- gcc/config/i386/i386.c.jj   2020-08-24 10:00:01.321258451 +0200
+++ gcc/config/i386/i386.c  2020-08-26 17:54:39.089468108 +0200
@@ -16487,7 +16487,11 @@ iamcu_alignment (tree type, int align)

   /* Intel MCU psABI specifies scalar types > 4 bytes aligned to 4
  bytes.  */
-  mode = TYPE_MODE (strip_array_types (type));
+  type = strip_array_types (type);
+  if (TYPE_ATOMIC (type))
+return align;
+
+  mode = TYPE_MODE (type);
   switch (GET_MODE_CLASS (mode))
 {
 case MODE_INT:
@@ -16757,7 +16761,7 @@ ix86_minimum_alignment (tree exp, machin
   /* Don't do dynamic stack realignment for long long objects with
  -mpreferred-stack-boundary=2.  */
   if ((mode == DImode || (type && TYPE_MODE (type) == DImode))
-  && (!type || !TYPE_USER_ALIGN (type))
+  && (!type || (!TYPE_USER_ALIGN (type) && !TYPE_ATOMIC (type)))
   && (!decl || !DECL_USER_ALIGN (decl)))
 {
   gcc_checking_assert (!TARGET_STV);
@@ -20293,7 +20297,10 @@ x86_field_alignment (tree type, int comp
 return computed;
   if (TARGET_IAMCU)
 return iamcu_alignment (type, computed);
-  mode = TYPE_MODE (strip_array_types (type));
+  type = strip_array_types (type);
+  if (TYPE_ATOMIC (type))
+return computed;
+  mode = TYPE_MODE (type);
   if (mode == DFmode || mode == DCmode
   || GET_MODE_CLASS (mode) == MODE_INT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
No idea whether we need the ix86_minimum_alignment change and about IAMCU I'll
defer to H.J., but the last hunk fixes something like #c1 or
struct A { char a; _Atomic long long b; };
struct B { char a; _Atomic double b; };
int a = __builtin_offsetof (struct A, b);
int b = __builtin_offsetof (struct B, b);
with -m32 for me.

[Bug rtl-optimization/96796] [9 Regression] aarch64: ICE during RTL pass: reload

[acoplan at gcc dot gnu.org]

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

--- Comment #3 from Alex Coplan  ---
Adding -fcommon, I can reproduce this ICE on trunk. The default changed in GCC
10 (as of 6271dd984d7f920d4fb17ad37af6a1f8e6b796dc).

[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage

[ma.noack.pr at gmail dot com]

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

Matthias Noack  changed:

   What|Removed |Added

 CC||ma.noack.pr at gmail dot com

--- Comment #8 from Matthias Noack  ---
Still failing in 10.2 (original reproducer).

[Bug other/96800] [11 regression] compilation error for 20_util/function_objects/searchers.cc after r11-2857

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64*-linux-gnu
   Host||powerpc64*-linux-gnu
 CC||fdumont at gcc dot gnu.org
  Build||powerpc64*-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
Also experimental/functional/searchers.cc

FAIL: experimental/functional/searchers.cc (test for excess errors)
UNRESOLVED: experimental/functional/searchers.cc compilation failed to produce
executable

[Bug other/96800] New: [11 regression] compilation error for 20_util/function_objects/searchers.cc after r11-2857

[seurer at gcc dot gnu.org]

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

Bug ID: 96800
   Summary: [11 regression] compilation error for
20_util/function_objects/searchers.cc after r11-2857
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:4797a61cc5024fc9adf5918e9bb2b78988f9e4d4, r11-2857 

spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xg++
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/function_objects/searchers.cc
-std=gnu++17 -fdiagnostics-plain-output ./libtestc++.a -Wl,--gc-sections
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./searchers.exe
In file included from
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/hashtable.h:35,
 from
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/unordered_map:46,
 from
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/functional:61,
 from
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/function_objects/searchers.cc:21:
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/hashtable_policy.h:
In instantiation of 'const _Equal& std::__detail::_Hashtable_base<_Key, _Value,
_ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _Traits>::_M_eq() const [with
_Key = char; _Value = std::pair; _ExtractKey =
std::__detail::_Select1st; _Equal = test03()::; _Hash =
test03()::; _RangeHash = std::__detail::_Mod_range_hashing;
_Unused = std::__detail::_Default_ranged_hash; _Traits =
std::__detail::_Hashtable_traits]':
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/hashtable.h:621:
  required from 'std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal,
_Hash, _RangeHash, _Unused, _RehashPolicy, _Traits>::key_equal
std::_Hashtable<_Key, _Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash,
_Unused, _RehashPolicy, _Traits>::key_eq() const [with _Key = char; _Value =
std::pair; _Alloc = std::allocator >; _ExtractKey = std::__detail::_Select1st; _Equal =
test03()::; _Hash = test03()::; _RangeHash =
std::__detail::_Mod_range_hashing; _Unused =
std::__detail::_Default_ranged_hash; _RehashPolicy =
std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits; std::_Hashtable<_Key,
_Value, _Alloc, _ExtractKey, _Equal, _Hash, _RangeHash, _Unused, _RehashPolicy,
_Traits>::key_equal = test03()::]'
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/bits/unordered_map.h:851:
  required from 'std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::key_equal
std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::key_eq() const [with _Key
= char; _Tp = long int; _Hash = test03()::; _Pred =
test03()::; _Alloc = std::allocator >; std::unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::key_equal =
test03()::]'
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/functional:1054:
  required from '_Pred std::__boyer_moore_map_base<_Key, _Tp, _Hash,
_Pred>::_M_pred() const [with _Key = char; _Tp = long int; _Hash =
test03()::; _Pred = test03()::]'
/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/functional:1250:
  required from 'std::pair<_ForwardIterator2, _ForwardIterator2>
std::boyer_moore_searcher<_RAIter, _Hash,
_BinaryPredicate>::operator()(_RandomAccessIterator2, 

[Bug target/65146] alignment of _Atomic structure member is not correct

[jason at gcc dot gnu.org]

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

--- Comment #20 from Jason Merrill  ---
This issue came up in the GCC/LLVM compatibility discussion today.

[Bug tree-optimization/96466] [11 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:122 with -Og -finline-functions-called-once -fno-tree-ccp

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Martin Liška from comment #3)
> It's the same store as PR96453: copyprop can eliminate that to:
> 
> Folding statement: _3 = { 5 };
> Queued stmt for removal.  Folds to: { 5 }
> Folding statement: _4 = VEC_COND_EXPR <_3 > { 4441221374 }, { -1 }, { 0 }>;
> gimple_simplified to _4 = { 0 };
> Folded into: _4 = { 0 };
> 
> @Richi: Can we teach copyprop to fold constant expressions for
> VEC_COND_EXPRs that have first argument equal to a constant?

Not sure what you are asking for - copyprop already does constant folding.
Also wouldn't -fno-tree-copy-prop then re-introduce the issue?  Doesn't
the issue exist with -O0 when always_inline is used?  Hmm, no, then I see

   :
  x_3 = 5;
  v_4 = { 4441221375 };
  x.0_5 = x_3;
  _6 = {x.0_5};
  _7 = v_4 <= _6;
  _8 = VEC_COND_EXPR <_7, { -1 }, { 0 }>;
  _9 = VIEW_CONVERT_EXPR(_8);
  _13 = VIEW_CONVERT_EXPR(_9);
  _14 = _13 & 4441221375;
  v_10 = {_14};
  _11 = v_10;

fed into ISEL which makes it happy.

OK, so ISEL does not like

  _4 = { 0 };
  _5 = VEC_COND_EXPR <_4, { -1 }, { 0 }>;

but I think it has to cope with this situation.  I can imagine even
sth like

 _4 = { 0 };
 _5 = _4;
 _6 = VEC_COND_EXPR <_5, { -1 }, { 0 }>;

thus a stray copy.  Or a more complex boolean vector like { 0, -1, 0, -1 }
or so.  For a constant it should be possible to fake a compare generating
it, say, for

(vector(2) ) { 0, -1 }

use (signed:64){ 0, -1 } != (signed:64){ 0, 0 }

of course for a general SSA boolean vector there's no way to build it up
if the target cannot code-generate it by itself.

Note that if you'd have

 _4 = { 0, -1 };
 _5 = VEC_COND_EXPR <_4, a_7, b_8>;

then while you can constant-fold away the condition you will end up
with a VEC_PERM which might not be supported either.  So faking a
compare is IMHO better here.

[Bug tree-optimization/96698] [10/11 Regression] ICE during GIMPLE pass:vect

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:2130efe6ac7beba72d289e3dd145daa10aeaed54

commit r11-2882-g2130efe6ac7beba72d289e3dd145daa10aeaed54
Author: Richard Biener 
Date:   Wed Aug 26 15:12:17 2020 +0200

tree-optimization/96698 - fix ICE when vectorizing nested cycles

This fixes vectorized PHI latch edge updating and delay it until
all of the loop is code generated to deal with the case that the
latch def is a PHI in the same block.

2020-08-26  Richard Biener  

PR tree-optimization/96698
* tree-vectorizer.h (loop_vec_info::reduc_latch_defs): New.
(loop_vec_info::reduc_latch_slp_defs): Likewise.
* tree-vect-stmts.c (vect_transform_stmt): Only record
stmts to update PHI latches from, perform the update ...
* tree-vect-loop.c (vect_transform_loop): ... here after
vectorizing those PHIs.
(info_for_reduction): Properly handle non-reduction PHIs.

* gcc.dg/vect/pr96698.c: New testcase.

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:42fb390082b59c0b5af6a9f1e5a2e608ccb8e193

commit r9-8833-g42fb390082b59c0b5af6a9f1e5a2e608ccb8e193
Author: Jonathan Wakely 
Date:   Wed Aug 26 14:47:51 2020 +0100

libstdc++: Enable assertions in constexpr string_view members [PR 71960]

Since GCC 6.1 there is no reason we can't just use __glibcxx_assert in
constexpr functions in string_view. As long as the condition is true,
there will be no call to std::__replacement_assert that would make the
function ineligible for constant evaluation.

PR libstdc++/71960
* include/experimental/string_view (basic_string_view):
Enable debug assertions.
* include/std/string_view (basic_string_view):
Likewise.

(cherry picked from commit 3eefb302d2bd8502cb3d8fe44e672b11092ccaf6)

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:85847fd421d7760f45f0e69c7ae3607f2f898bb8

commit r10-8676-g85847fd421d7760f45f0e69c7ae3607f2f898bb8
Author: Jonathan Wakely 
Date:   Wed Aug 26 14:47:51 2020 +0100

libstdc++: Enable assertions in constexpr string_view members [PR 71960]

Since GCC 6.1 there is no reason we can't just use __glibcxx_assert in
constexpr functions in string_view. As long as the condition is true,
there will be no call to std::__replacement_assert that would make the
function ineligible for constant evaluation.

PR libstdc++/71960
* include/experimental/string_view (basic_string_view):
Enable debug assertions.
* include/std/string_view (basic_string_view):
Likewise.

(cherry picked from commit 3eefb302d2bd8502cb3d8fe44e672b11092ccaf6)

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:3eefb302d2bd8502cb3d8fe44e672b11092ccaf6

commit r11-2881-g3eefb302d2bd8502cb3d8fe44e672b11092ccaf6
Author: Jonathan Wakely 
Date:   Wed Aug 26 14:47:51 2020 +0100

libstdc++: Enable assertions in constexpr string_view members [PR 71960]

Since GCC 6.1 there is no reason we can't just use __glibcxx_assert in
constexpr functions in string_view. As long as the condition is true,
there will be no call to std::__replacement_assert that would make the
function ineligible for constant evaluation.

PR libstdc++/71960
* include/experimental/string_view (basic_string_view):
Enable debug assertions.
* include/std/string_view (basic_string_view):
Likewise.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 26 Aug 2020, matz at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #11 from Michael Matz  ---
> (In reply to Jan Hubicka from comment #10)
> > > We could also punt: when enable-link-mutex we could artificially up the 
> > > job
> > > number for make to account for the waiting link steps.  I.e. when 
> > > normally -jN
> > > was given, the link step could be done under -j(N + nr-language - 1).  
> > > That
> > > would lead to the
> > > nr-of-languages-1 job server tokens taken up by the sleeping link steps 
> > > to be
> > > accounted for, and hence the (single running) link step still be able to 
> > > use N
> > > threads/processes in parallel.
> > 
> > I do not think it is easy to do with current make jobserver.  The
> > toplevel jobserver opens the pipi with -jN many tokens and all other
> > makes connect to it.  It does not provide interface to return a token
> > and re-take it unless we implement it of course.
> 
> Sure, but that's not the only way the above punting could be done.  The
> parallel
> phase that currently communicates with the jobserver essentially tries to get 
> N
> tokens.  It could be changed to assume that there are implicitely
> nr-of-languages-1 more tokens available.  I.e. the number of threads/processes
> would always be enlarged by nr-of-languages-1, even without any tokens from 
> the
> jobserver.

I wonder whether the link-mutex is better be implemented with
a set of artificial dependences.  If we want to serialize
building cc1, cc1plus, etc. then just have

cc1: cc1plus
cc1plus: ...
...

and only conditionally enable those somehow.  But IIRC nowadays
that "waiting" also prints those progress markers ...

[Bug tree-optimization/96783] [11 Regression] std::rotate miscompiled

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:71b6257e3a90995e1c1d3d2716a0eec5eef243db

commit r11-2877-g71b6257e3a90995e1c1d3d2716a0eec5eef243db
Author: Richard Biener 
Date:   Wed Aug 26 14:24:01 2020 +0200

tree-optimization/96783 - fix vectorization of negative step SLP

This appropriately uses VMAT_ELEMENTWISE when the vectors cannot be
filled from a single SLP group until we get more explicit support
for negative stride SLP.

2020-08-26  Richard Biener  

PR tree-optimization/96783
* tree-vect-stmts.c (get_group_load_store_type): Use
VMAT_ELEMENTWISE for negative strides when we cannot
use VMAT_STRIDED_SLP.

* gcc.dg/vect/pr96783-1.c: New testcase.
* gcc.dg/vect/pr96783-2.c: Likewise.

[Bug tree-optimization/96783] [11 Regression] std::rotate miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[matz at gcc dot gnu.org]

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

--- Comment #11 from Michael Matz  ---
(In reply to Jan Hubicka from comment #10)
> > We could also punt: when enable-link-mutex we could artificially up the job
> > number for make to account for the waiting link steps.  I.e. when normally 
> > -jN
> > was given, the link step could be done under -j(N + nr-language - 1).  That
> > would lead to the
> > nr-of-languages-1 job server tokens taken up by the sleeping link steps to 
> > be
> > accounted for, and hence the (single running) link step still be able to 
> > use N
> > threads/processes in parallel.
> 
> I do not think it is easy to do with current make jobserver.  The
> toplevel jobserver opens the pipi with -jN many tokens and all other
> makes connect to it.  It does not provide interface to return a token
> and re-take it unless we implement it of course.

Sure, but that's not the only way the above punting could be done.  The
parallel
phase that currently communicates with the jobserver essentially tries to get N
tokens.  It could be changed to assume that there are implicitely
nr-of-languages-1 more tokens available.  I.e. the number of threads/processes
would always be enlarged by nr-of-languages-1, even without any tokens from the
jobserver.

[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 9.4 and 10.3, but I'm not going to bother changing it on the gcc-8
branch.

[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:9def04578cca8a0850e835eb095d9ff60097f691

commit r9-8832-g9def04578cca8a0850e835eb095d9ff60097f691
Author: Jonathan Wakely 
Date:   Mon Aug 24 16:10:07 2020 +0100

libstdc++: Make variant_npos conversions explicit [PR 96766]

libstdc++-v3/ChangeLog:

PR libstdc++/96766
* include/std/variant (_Variant_storage): Replace implicit
conversions from size_t to __index_type with explicit casts.

(cherry picked from commit 074436cf8cdd2a9ce75cadd36deb8301f00e55b9)

[Bug ada/96799] New: C and Ada frontends have a different interpretation of double constants

[demoonlit at panathenaia dot halfmoon.jp]

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

Bug ID: 96799
   Summary: C and Ada frontends have a different interpretation of
double constants
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: demoonlit at panathenaia dot halfmoon.jp
  Target Milestone: ---

Hello.
Each of the C and Ada frontends has a different interpretation of the some kind
of double constants.

Reproducing:
Write the same small double constants for each language.

double1.c

const double d_min = 0x0.3eP-1072;


double2.ads

package double2 is
   d_min : constant Long_Float := 16#0.3e#e-268;
end double2;


(Note: These constants are the hexadecimal of __DBL_DENORM_MIN__ and wanted to
be rounded to the minimal value of double. The precise value is 0x0.4P-1072,
but __DBL_DENORM_MIN__ is a written as decimal, so these constants are got from
it by the conversion. This value is unimportant because perhaps this bug can be
reproduced with other values.)

Compile them.

$ gcc -W -Wall -S double1.c
$ gcc -W -Wall -S double2.ads
double2.ads:2:35: warning: floating-point value underflows to 0.0

Ada frontend reports the underflow. C frontend does not.
And compare double1.s and double2.s.

double1.s

.text
.globl _d_min
.const
.align 3
_d_min:
.long   1   # <- It has been rounded.
.long   0
.ident  "GCC: (GNU) 10.1.0"
.subsections_via_symbols


double2.s

.text
.globl _double2_E
.data
.align 1
_double2_E:
.space 2
.globl _double2__d_min
.const
.align 3
_double2__d_min:
.space 8# <- It has been truncated.
.ident  "GCC: (GNU) 10.1.0"
.subsections_via_symbols


I first noticed it in the FreeBSD 32bit. FreeBSD 32bit has the lesser precision
of long double than other environments. However, then I tried it in FreeBSD
64bit, Linux, and MacOSX and it is reproducible too.

[Bug libstdc++/96766] std::swap(std::variant, std::variant) triggers undefined behavior sanitizer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4b6366f24890e25a07f9a045d15633c5b1fb80cb

commit r10-8675-g4b6366f24890e25a07f9a045d15633c5b1fb80cb
Author: Jonathan Wakely 
Date:   Mon Aug 24 16:10:07 2020 +0100

libstdc++: Make variant_npos conversions explicit [PR 96766]

libstdc++-v3/ChangeLog:

PR libstdc++/96766
* include/std/variant (_Variant_storage): Replace implicit
conversions from size_t to __index_type with explicit casts.

(cherry picked from commit 074436cf8cdd2a9ce75cadd36deb8301f00e55b9)

[Bug analyzer/96798] New: Analyzer failures on Darwin

[dominiq at lps dot ens.fr]

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

Bug ID: 96798
   Summary: Analyzer failures on Darwin
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: iains at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin19.6
Target: x86_64-apple-darwin19.6
 Build: x86_64-apple-darwin19.6

On Darwin I get the following failures

FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 519)
FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 520)
FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)
FAIL: gcc.dg/analyzer/memset-1.c  (test for warnings, line 67)
FAIL: gcc.dg/analyzer/memset-1.c  (test for warnings, line 68)
FAIL: gcc.dg/analyzer/memset-1.c (test for excess errors)

due to

/opt/gcc/work/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function
'test_27':
/opt/gcc/work/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:519:3: warning:
UNKNOWN
  519 |   __analyzer_eval (p->x == 0); /* { dg-warning "TRUE" } */
  |   ^~~
/opt/gcc/work/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:520:3: warning:
UNKNOWN
  520 |   __analyzer_eval (p->y == 0); /* { dg-warning "TRUE" } */
  |   ^~~

and

/opt/gcc/work/gcc/testsuite/gcc.dg/analyzer/memset-1.c:67:3: warning: TRUE
   67 |   __analyzer_eval (buf[42] == 'A'); /* { dg-warning "UNKNOWN" } */
  |   ^~~~
/opt/gcc/work/gcc/testsuite/gcc.dg/analyzer/memset-1.c:68:3: warning: FALSE
   68 |   __analyzer_eval (buf[42] == '\0'); /* { dg-warning "UNKNOWN" } */
  |   ^

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka  ---
> We could also punt: when enable-link-mutex we could artificially up the job
> number for make to account for the waiting link steps.  I.e. when normally -jN
> was given, the link step could be done under -j(N + nr-language - 1).  That
> would lead to the
> nr-of-languages-1 job server tokens taken up by the sleeping link steps to be
> accounted for, and hence the (single running) link step still be able to use N
> threads/processes in parallel.

I do not think it is easy to do with current make jobserver.  The
toplevel jobserver opens the pipi with -jN many tokens and all other
makes connect to it.  It does not provide interface to return a token
and re-take it unless we implement it of course.

Honza
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[matz at gcc dot gnu.org]

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

--- Comment #9 from Michael Matz  ---
We could also punt: when enable-link-mutex we could artificially up the job
number for make to account for the waiting link steps.  I.e. when normally -jN
was given, the link step could be done under -j(N + nr-language - 1).  That
would lead to the
nr-of-languages-1 job server tokens taken up by the sleeping link steps to be
accounted for, and hence the (single running) link step still be able to use N
threads/processes in parallel.

[Bug c++/25814] Request for warning for parser ambiguity of function declarations and variable declarations with initializations

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #15 from Marek Polacek  ---
David, presumably you're not working on this at the moment?

[Bug tree-optimization/96565] Failure to optimize out VLA even though it is left unused

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Ah, no - error in my patch.

[Bug rtl-optimization/96796] [9 Regression] aarch64: ICE during RTL pass: reload

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
There's a reduced test-case:

cat pr96796.c
struct S0 {
  signed f0 : 8;
  unsigned f1;
  unsigned f4;
};
struct S1 {
  long f3;
  char f4;
} g_3_4;

int g_5, func_1_l_32, func_50___trans_tmp_31;
static struct S0 g_144, g_834, g_1255, g_1261;

int g_273[120] = {};
int *g_555;
char **g_979;
static int g_1092_0;
static int g_1193;
int safe_mul_func_int16_t_s_s(int si1, int si2) { return si1 * si2; }
static struct S0 *func_50();
int func_1() { func_50(g_3_4, g_5, func_1_l_32, 8, 3); }
void safe_div_func_int64_t_s_s(int *);
void safe_mod_func_uint32_t_u_u(struct S0);
struct S0 *func_50(int p_51, struct S0 p_52, struct S1 p_53, int p_54,
   int p_55) {
  int __trans_tmp_30;
  char __trans_tmp_22;
  short __trans_tmp_19;
  long l_985_1;
  long l_1191[8];
  safe_div_func_int64_t_s_s(g_273);
  __builtin_printf((char*)g_1261.f4);
  safe_mod_func_uint32_t_u_u(g_834);
  g_144.f0 += 1;
  for (;;) {
struct S1 l_1350 = {_1350};
for (; p_53.f3; p_53.f3 -= 1)
  for (; g_1193 <= 2; g_1193 += 1) {
__trans_tmp_19 = safe_mul_func_int16_t_s_s(l_1191[l_985_1 + p_53.f3],
   p_55 % (**g_979 = 10));
__trans_tmp_22 = g_1255.f1 * p_53.f4;
__trans_tmp_30 = __trans_tmp_19 + __trans_tmp_22;
if (__trans_tmp_30)
  g_1261.f0 = p_51;
else {
  g_1255.f0 = p_53.f3;
  int *l_1422 = g_834.f0 = g_144.f4 != (*l_1422)++ > 0 < 0 ^ 51;
  g_555 = ~0;
  g_1092_0 |= func_50___trans_tmp_31;
}
  }
  }
}

[Bug tree-optimization/96565] Failure to optimize out VLA even though it is left unused

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
OK, well - but the fix exposes (IIRC I ran into this at some time in the past
already) that GIMPLE_RESX does not have virtual operands but it needs to
represent a use of global memory at least in the case it exits the current
function.  So with the fix which is simply

diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
index cc93f559286..6b2f64c0250 100644
--- a/gcc/tree-ssa-dse.c
+++ b/gcc/tree-ssa-dse.c
@@ -888,11 +888,16 @@ dse_classify_store (ao_ref *ref, gimple *stmt,
  gimple *def = defs[i];
  gimple *use_stmt;
  use_operand_p use_p;
+ /* If the path ends here we do not need to process it further.
+This for example happens with calls to noreturn functions.  */
+ if (gimple_code (def) != GIMPLE_PHI
+ && has_zero_uses (gimple_vdef (def)))
+   defs.unordered_remove (i);
  /* If the path to check starts with a kill we do not need to
 process it further.
 ???  With byte tracking we need only kill the bytes currently
 live.  */
- if (stmt_kills_ref_p (def, ref))
+ else if (stmt_kills_ref_p (def, ref))
{
  if (by_clobber_p && !gimple_clobber_p (def))
*by_clobber_p = false;

I see

FAIL: g++.dg/eh/spec7.C  -std=gnu++98 execution test
FAIL: g++.dg/eh/spec7.C  -std=gnu++14 execution test
FAIL: g++.dg/eh/spec7.C  -std=gnu++17 execution test
FAIL: g++.dg/eh/spec7.C  -std=gnu++2a execution test
FAIL: gcc.target/i386/cleanup-1.c execution test
FAIL: gcc.target/i386/cleanup-2.c execution test

also (a testsuite issue)

FAIL: gcc.dg/builtin-object-size-4.c execution test

the RESX issue is possibly latent even without the above patch.

[Bug fortran/96797] New: OpenACC fortran acc_get_cuda_stream

[samunaga at amd dot com]

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

Bug ID: 96797
   Summary: OpenACC fortran acc_get_cuda_stream
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: samunaga at amd dot com
  Target Milestone: ---

Created attachment 49130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49130=edit
source_code.txt contains source code for all the 3 files

When compiling OpenACC fortran code fft.f90 which calls a function defined in
cufft.cu file, we are getting the below error

Error:
Function 'acc_get_cuda_stream' at (1) has no IMPLICIT type

Steps to reproduce the error:

nvcc -c --compiler-bindir /usr/bin/ cufft.cu (using GCC7.5.0 for NVCC)
gfortran -fopenacc -o fftf fft.f90 cufft.o -lm -lcufft
-L/usr/local/cuda-10.2/targets/x86_64-linux/lib/ -lcudart

CUDA version: 10.2
GCC version: 10.1

When compiling the equivalent C code(fftc.c), the executable got build without
any errors.

Steps for compilation:
nvcc -c --compiler-bindir /usr/bin/ cufft.cu (using GCC7.5.0 for NVCC)
gcc -fopenacc -o fftc fftc.c cufft.o -lcufft -lcudart
-L/usr/local/cuda-10.2/targets/x86_64-linux/lib

Please find attached source code for cufft.cu,fft.f90,fftc.c

We observed that, acc_get_cuda_stream is declared in openacc.h file(C
implementaion uses this)
But acc_get_cuda_stream is not declared in openacc.f90 file(fortran
implementation uses openacc.mod)

[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
Ehm...

2006-10-29  Richard Guenther  

* config/i386/i386-protos.h (ix86_expand_floorceil): Declare.
(ix86_expand_floorceildf_32): Likewise.
* config/i386/i386.c (ix86_expand_sse_compare_mask): New
static helper function.
(ix86_expand_floorceil): Expander for floor and ceil to SSE
math.
(ix86_expand_floorceildf_32): Same for DFmode on 32bit archs.
* config/i386/i386.md (floordf2): Adjust to enable floor
expansion via ix86_expand_floorceil if TARGET_SSE_MATH and
-fno-trapping-math is enabled and if not optimizing for size.
(floorsf2, ceildf2, ceilsf2): Likewise.
* config/i386/sse.md (sse_maskcmpsf3): New insn.
(sse2_maskcmpdf3): Likewise.

[Bug c++/21146] unable to resolve visible symbol

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=13590
   Last reconfirmed|2009-02-07 20:18:28 |2020-8-26
 Blocks|65608   |94404

--- Comment #7 from Jonathan Wakely  ---
(In reply to Manuel López-Ibáñez from comment #4)
> Do we know how icc resolves the ambiguity?

I assume it checks that the two lookup results for "S" actually name the same
type, and so decides there's no ambiguity.

I think that is correct according to [class.member.lookup]. The declaration
sets for lookup of S in ::C and in ::B and in :S and in ::A<::S> all find the
same type, ::S. So there is no ambiguity.

This was ambiguous in C++03 but that was changed by CWG 39
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#39

So GCC is wrong.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
[Bug 65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
There's graph when omitting link mutex:
https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/24409fcf099230dbc19ef50e193655c578d6d527/gcc-10-without-mutex-lock.svg

As seen, memory peak is slightly more than 12GB.

[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[trnka at scm dot com]

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

Tomáš Trnka  changed:

   What|Removed |Added

 CC||trnka at scm dot com

--- Comment #12 from Tomáš Trnka  ---
The fix for this broke assumed length optional character arguments. I have
noticed this on 10.2.1 20200723, which is currently used by Fedora 32.

Bisected using the following testcase:

subroutine foo (n, lVal, sVal)
   integer,   intent(in)  :: n
   logical, optional, intent(out) :: lVal(n)
   character(*),optional, intent(out) :: sVal(n)

   integer :: nFound

   nFound = 0

   if (present(lVal)) then
  nFound = nFound + 1
   end if

   if (present(sVal)) then
  nFound = nFound + 1
   end if

   write(*,*) nFound

end subroutine

Affected versions compile this to the following:

  character(kind=1)[0:D.3919][1:_sval] * restrict sval.0;
…
  if (sval.0 != 0B)
{
  ubound.2 = (integer(kind=8)) *n;
  size.3 = NON_LVALUE_EXPR ;
  size.3 = MAX_EXPR ;
  D.3917 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <_sval> * 8;
  D.3918 = (sizetype) NON_LVALUE_EXPR <_sval>;
  D.3919 = size.3 + -1;
  D.3920 = ((bitsizetype) (sizetype) NON_LVALUE_EXPR <_sval> *
(bitsizetype) (sizetype) NON_LVALUE_EXPR ) * 8;
  D.3921 = (sizetype) NON_LVALUE_EXPR <_sval> * (sizetype) NON_LVALUE_EXPR
;
  sval.0 = (character(kind=1)[0:D.3919][1:_sval] * restrict) sval;
}
…
  if (sval.0 != 0B)
{
  nfound = nfound + 1;
}


The first test thus relies on an unitialized value of sval.0. If that value
happens to be zero, the actual "sval" argument will be ignored even if it is
present.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Wed, 26 Aug 2020, hubicka at ucw dot cz wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #3 from Jan Hubicka  ---
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> > 
> > --- Comment #2 from Martin Liška  ---
> > (In reply to Jan Hubicka from comment #1)
> > > > As seen
> > > > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> > > > 
> > > > each blocking linking of a GCC front-end leads to a wasted jobserver 
> > > > worker.
> > > Hmm, I am not sure how to interpret the graph. I can see that there is a
> > > funny staircase of ltranses but how that relates to jobserver workers?
> > 
> > Yes, I mean the staircase of LTRANS because at the beginning N-1 links are
> > waiting for lock:
> > 
> > [  299s] lock-and-run.sh: (PID 7351) waiting 0 sec to acquire linkfe.lck 
> > from
> > PID 7347
> > ...
> > 
> > For jobserver they are still running even though they sleep.
> Aha, so it is extra locking mechanizm we add without jobserver
> knowledge.
> > 
> > 
> > > We limit makefile to link a binary at a time to avoid Richi's box getting
> > > out of memory, right?
> > 
> > No. It's because we want to have a reasonable contrains which is right now 
> > 8GB.
> > Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA 
> > parallel
> > streaming peak), which is probably not desired.
> 
> 10x1.3GB will get consumed only if the building machine has 10 threads.
> I wonder if the jobserver WPA streaming integration will happen this
> year, with that snd some patches to WPA memory use we could fit in 8GB
> unless very large parallelism is configured.

Note even without LTO the link step will consume about 1GB for each FE,
this is enough to make my box with 6GB ram swap and die miserably
when bootstrapping with all languages enabled.  Yes, without LTO
bootstrap - ld.bfd (also gold) really are that memory hungry.

> I suppose only really effective solution would to teach the jobserver
> that some jobs are "big" and consume multiple tokens, that is WPA, while
> other jobs like ltranses and streaming are small.

The only effective solution would be to make the glue with the waiting
mechanism pass on its token?  Hmm, I guess since lto-wrapper invokes
make again and also waits lto-wrapper itself still sits on the original
token from the parent jobserver and thus this isn't really dependent on
the waiting mechanism but an inherent "bug" in the way we execute
the LTRANS compiles in jobserver mode?

[Bug rtl-optimization/96796] [9 Regression] aarch64: ICE during RTL pass: reload

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64
   Target Milestone|--- |9.4

[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-08-26
 CC||uros at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|c   |target
 Target||x86_64-*-* i?86-*-*

--- Comment #5 from Richard Biener  ---
Confirmed.  Looks like the inline-expanded sequence is off with -frounding-math
(we also inline expand at -O0 but not -Os which is somewhat surprising).

[Bug c++/86564] Declaration containing qualified-id interpreted as function-style cast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The tentative parse when trying to parse it as a function declaration is
aborted with the cp_parser_error below in cp_parser_direct_declarator:
else if (unqualified_name
 && (qualifying_scope
 || (!identifier_p (unqualified_name
  {
cp_parser_error (parser, "expected unqualified-id");
unqualified_name = error_mark_node;
  }
So, shall that be replaced with an unconditional error, so that it doesn't
abort the tentative parsing, or shall it remember this case some way and let
only the semantic analysis in decl.c error on it later?

Another testcase (accepts-invalid):
namespace a {
  enum c { d };
  struct e {
e(c);
  };
}; // namespace a
a::e f(a::e(a::d));

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Jan Hubicka from comment #1)
> > As seen
> > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> > 
> > each blocking linking of a GCC front-end leads to a wasted jobserver worker.
> Hmm, I am not sure how to interpret the graph. I can see that there is a
> funny staircase of ltranses but how that relates to jobserver workers?
> We limit makefile to link a binary at a time to avoid Richi's box getting
> out of memory, right?

Yes.  With LTO there's also the parallel stream-out which hard-locks the box
since it is/was not integrated with jobserver.

> NUmber of partitions is currently 128 what is 100% of CPU usage for you?
> 
> Honza

[Bug rtl-optimization/96796] [9 Regression] aarch64: ICE during RTL pass: reload

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||10.1.1, 11.0, 8.4.1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2020-08-26
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||9.3.1
Summary|aarch64: ICE during RTL |[9 Regression] aarch64: ICE
   |pass: reload|during RTL pass: reload

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on GCC 9 branches. Other branches don't ICE for me

[Bug rtl-optimization/96796] New: aarch64: ICE during RTL pass: reload

[yangyang305 at huawei dot com]

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

Bug ID: 96796
   Summary: aarch64: ICE during RTL pass: reload
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyang305 at huawei dot com
  Target Milestone: ---

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

Hi, gcc-9.3.0 ICEs when compiling the attached testcase with -Os on aarch64.

gcc -Os test.i

during RTL pass: reload
test.c: In function ‘func_50.isra.0.constprop’:
test.c:1852:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)

0x936ddf lra_constraints(bool)
../../gcc-9.3.0/gcc/lra-constraints.c:4901
0x92144f lra(_IO_FILE*)
../../gcc-9.3.0/gcc/lra.c:2472
0x8e083f do_reload
../../gcc-9.3.0/gcc/ira.c:5523
0x8e083f execute
../../gcc-9.3.0/gcc/ira.c:5707
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #4 from Martin Liška  ---
> > > For jobserver they are still running even though they sleep.
> > Aha, so it is extra locking mechanizm we add without jobserver
> > knowledge.
> 
> It's unrelated to jobserver, one can enable it with configure option mentioned
> in the title.

Yep, but that is where I see the problem - if we simply wait for lock
and jobserver does not know that, he counts it as a job..
> > This is of course still not very pretty, but it is impossible to tell in
> > advance what job is big and what job is small.
> 
> Sure, it's all quite compilicated. One needs to negotiate with jobserver :)

Yep...
Honza
> 
> I'm going to collect graph w/o --enable-link-mutex on my machine.
> 
> > 
> > Honza

Re: [Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[Jan Hubicka]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #4 from Martin Liška  ---
> > > For jobserver they are still running even though they sleep.
> > Aha, so it is extra locking mechanizm we add without jobserver
> > knowledge.
> 
> It's unrelated to jobserver, one can enable it with configure option mentioned
> in the title.

Yep, but that is where I see the problem - if we simply wait for lock
and jobserver does not know that, he counts it as a job..
> > This is of course still not very pretty, but it is impossible to tell in
> > advance what job is big and what job is small.
> 
> Sure, it's all quite compilicated. One needs to negotiate with jobserver :)

Yep...
Honza
> 
> I'm going to collect graph w/o --enable-link-mutex on my machine.
> 
> > 
> > Honza

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
> > For jobserver they are still running even though they sleep.
> Aha, so it is extra locking mechanizm we add without jobserver
> knowledge.

It's unrelated to jobserver, one can enable it with configure option mentioned
in the title.

> > 
> > 
> > > We limit makefile to link a binary at a time to avoid Richi's box getting
> > > out of memory, right?
> > 
> > No. It's because we want to have a reasonable contrains which is right now 
> > 8GB.
> > Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA 
> > parallel
> > streaming peak), which is probably not desired.
> 
> 10x1.3GB will get consumed only if the building machine has 10 threads.

Typical OBS machine used for package build is either 8 (required minimum) or
16. 

> I wonder if the jobserver WPA streaming integration will happen this
> year, with that snd some patches to WPA memory use we could fit in 8GB
> unless very large parallelism is configured.
> 
> I suppose only really effective solution would to teach the jobserver
> that some jobs are "big" and consume multiple tokens, that is WPA, while
> other jobs like ltranses and streaming are small.
> 
> This is of course still not very pretty, but it is impossible to tell in
> advance what job is big and what job is small.

Sure, it's all quite compilicated. One needs to negotiate with jobserver :)

I'm going to collect graph w/o --enable-link-mutex on my machine.

> 
> Honza

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[hubicka at ucw dot cz]

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

--- Comment #3 from Jan Hubicka  ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #2 from Martin Liška  ---
> (In reply to Jan Hubicka from comment #1)
> > > As seen
> > > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> > > 
> > > each blocking linking of a GCC front-end leads to a wasted jobserver 
> > > worker.
> > Hmm, I am not sure how to interpret the graph. I can see that there is a
> > funny staircase of ltranses but how that relates to jobserver workers?
> 
> Yes, I mean the staircase of LTRANS because at the beginning N-1 links are
> waiting for lock:
> 
> [  299s] lock-and-run.sh: (PID 7351) waiting 0 sec to acquire linkfe.lck from
> PID 7347
> ...
> 
> For jobserver they are still running even though they sleep.
Aha, so it is extra locking mechanizm we add without jobserver
knowledge.
> 
> 
> > We limit makefile to link a binary at a time to avoid Richi's box getting
> > out of memory, right?
> 
> No. It's because we want to have a reasonable contrains which is right now 
> 8GB.
> Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA parallel
> streaming peak), which is probably not desired.

10x1.3GB will get consumed only if the building machine has 10 threads.
I wonder if the jobserver WPA streaming integration will happen this
year, with that snd some patches to WPA memory use we could fit in 8GB
unless very large parallelism is configured.

I suppose only really effective solution would to teach the jobserver
that some jobs are "big" and consume multiple tokens, that is WPA, while
other jobs like ltranses and streaming are small.

This is of course still not very pretty, but it is impossible to tell in
advance what job is big and what job is small.

Honza

Re: [Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[Jan Hubicka]

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
> 
> --- Comment #2 from Martin Liška  ---
> (In reply to Jan Hubicka from comment #1)
> > > As seen
> > > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> > > 
> > > each blocking linking of a GCC front-end leads to a wasted jobserver 
> > > worker.
> > Hmm, I am not sure how to interpret the graph. I can see that there is a
> > funny staircase of ltranses but how that relates to jobserver workers?
> 
> Yes, I mean the staircase of LTRANS because at the beginning N-1 links are
> waiting for lock:
> 
> [  299s] lock-and-run.sh: (PID 7351) waiting 0 sec to acquire linkfe.lck from
> PID 7347
> ...
> 
> For jobserver they are still running even though they sleep.
Aha, so it is extra locking mechanizm we add without jobserver
knowledge.
> 
> 
> > We limit makefile to link a binary at a time to avoid Richi's box getting
> > out of memory, right?
> 
> No. It's because we want to have a reasonable contrains which is right now 
> 8GB.
> Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA parallel
> streaming peak), which is probably not desired.

10x1.3GB will get consumed only if the building machine has 10 threads.
I wonder if the jobserver WPA streaming integration will happen this
year, with that snd some patches to WPA memory use we could fit in 8GB
unless very large parallelism is configured.

I suppose only really effective solution would to teach the jobserver
that some jobs are "big" and consume multiple tokens, that is WPA, while
other jobs like ltranses and streaming are small.

This is of course still not very pretty, but it is impossible to tell in
advance what job is big and what job is small.

Honza

[Bug c++/84026] invalid 'unnamed scoped enum is not allowed' when scoped enum has a full qualified-id

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed testcase (so it doesn't define S1::E1 twice):

struct S1 {
  enum class E1;
};
enum class S1::E1 {}; // OK

struct S2 {
  enum class E2;
};
enum class ::S2::E2 {}; // Not OK

[Bug c++/84026] invalid 'unnamed scoped enum is not allowed' when scoped enum has a full qualified-id

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83132
   Last reconfirmed|2018-01-25 00:00:00 |2020-8-26

--- Comment #3 from Jonathan Wakely  ---
PR 83132 is related.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Jan Hubicka from comment #1)
> > As seen
> > here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> > 
> > each blocking linking of a GCC front-end leads to a wasted jobserver worker.
> Hmm, I am not sure how to interpret the graph. I can see that there is a
> funny staircase of ltranses but how that relates to jobserver workers?

Yes, I mean the staircase of LTRANS because at the beginning N-1 links are
waiting for lock:

[  299s] lock-and-run.sh: (PID 7351) waiting 0 sec to acquire linkfe.lck from
PID 7347
...

For jobserver they are still running even though they sleep.


> We limit makefile to link a binary at a time to avoid Richi's box getting
> out of memory, right?

No. It's because we want to have a reasonable contrains which is right now 8GB.
Without --enable-link-mutex, we would consume ~ 10 x 1.3 GB (plus WPA parallel
streaming peak), which is probably not desired.

> 
> NUmber of partitions is currently 128 what is 100% of CPU usage for you?

It's written in the graph footnote "CPU count: 16".

[Bug tree-optimization/96615] Failure to optimize out loop that eventually ends but has no side effects involving decrease of loop counter using an unsigned operation and the loop being done through r

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> Even not with -ffinite-loops.  The reason is that finiteness of loops is
> determined by frontends now and recorded in loop->finite_p but the loop
> only appears after tail-recursion optimization.  I guess tailr could
> unconditionally set loop->finite_p since the stack is bounded
> but it relies on loop discovery and thus there's no easy way to do this
> (not sure if the loop is always natural).

We used to have discussions about this.  We also consider function
possibily infinite if it is self recrusive even though it self-recurses
finitely many times.  I think relying on finiteness of stack is safe
assumption and in both cases we should mark loops as finite, but there
was some concerns from the C++ developers (Mark Mitchell
https://gcc.gnu.org/legacy-ml/gcc/1999-08/msg00700.html)
I think we could indeed in both cases (pure-const and tail recursion)
assume finiteness based on finiteness of the stack.

Honza
> 
> Of course niter analysis might do a better job on this kind of loop
> to prove finiteness ...
> 
> One reason for the failure is of course that we compute
> 
> Analyzing # of iterations of loop 1
>   exit condition 0 < [(int) ((unsigned int) bytes_7(D) + 4294967232), + , -64]
>   bounds on difference of bases: -2147483648 ... 2147483647
>   result:
> under assumptions (int) ((unsigned int) bytes_7(D) + 4294967232) <=
> 2147483584
> zero if (int) ((unsigned int) bytes_7(D) + 4294967295) < 0
> # of iterations ((unsigned int) bytes_7(D) + 4294967295) / 64, bounded by
> 33554432
>   (set_nb_iterations_in_loop = scev_not_known))
> 
> which we throw away, not using it for loop estimates / max number of 
> iterations
> computation.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  ---
> As seen
> here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> 
> each blocking linking of a GCC front-end leads to a wasted jobserver worker.
Hmm, I am not sure how to interpret the graph. I can see that there is a
funny staircase of ltranses but how that relates to jobserver workers?
We limit makefile to link a binary at a time to avoid Richi's box getting
out of memory, right?

NUmber of partitions is currently 128 what is 100% of CPU usage for you?

Honza

Re: [Bug bootstrap/96794] New: --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[Jan Hubicka]

> As seen
> here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg
> 
> each blocking linking of a GCC front-end leads to a wasted jobserver worker.
Hmm, I am not sure how to interpret the graph. I can see that there is a
funny staircase of ltranses but how that relates to jobserver workers?
We limit makefile to link a binary at a time to avoid Richi's box getting
out of memory, right?

NUmber of partitions is currently 128 what is 100% of CPU usage for you?

Honza

[Bug target/96795] New: MVE: issue with polymorphism and integer promotion

[avieira at gcc dot gnu.org]

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

Bug ID: 96795
   Summary: MVE: issue with polymorphism and integer promotion
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avieira at gcc dot gnu.org
  Target Milestone: ---

An example of this issue can be observed when trying to compile:

#include 
uint16x8_t foo (uint16x8_t a, int16_t b)
{
  return vaddq (a, (b<<3));
}

This will lead to an __ARM_undef being selected.

I believe this is because __ARM_mve_coerce only accepts one type for scalar
parameters and should have accepted the same range of types for scalar as is
done in __ARM_mve_typeid.

A workaround for this is to cast (b<<3) to uint16_t.

[Bug c++/12228] [DR 244/399] syntax error calling a qualified template dtor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-01-11 00:00:00 |2020-8-26
  Known to fail||11.0

--- Comment #5 from Jonathan Wakely  ---
Still rejected by current trunk, and https://wg21.link/cwg399 is still open.

[Bug c/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[chfast at gmail dot com]

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

--- Comment #4 from Paweł Bylica  ---
I missed some information:

This affects both double and float variants: __builtin_floor() and
__builtin_floorf().

This affects also usage of floor() C standard library function as the function
call usually replaced with __builtin_floor() in optimized builds.

This affects also libstdc++ where std::floor() is implemented with
__builtin_floor().

[Bug c++/71975] In c++11/14 mode enumname::name is assumed name to be part of the enumname

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
I think GCC is correct to reject this, name lookup fails for enu::wow so the
friend declaration is invalid.

[Bug bootstrap/96794] New: --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[marxin at gcc dot gnu.org]

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

Bug ID: 96794
   Summary: --with-build-config=bootstrap-lto-lean with
--enable-link-mutex leads to poor LTRANS utilization
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

As seen
here:https://gist.githubusercontent.com/marxin/223890df4d8d8e490b6b2918b77dacad/raw/7e0363da60dcddbfde4ab68fa3be755515166297/gcc-10-with-zstd.svg

each blocking linking of a GCC front-end leads to a wasted jobserver worker.

[Bug c++/66900] No error message for ill-formed program with qualified name lookup

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=26950
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-26
   Keywords||accepts-invalid

--- Comment #1 from Jonathan Wakely  ---
>From the attachment:

namespace N {
int j = 1;
}

namespace M {
typedef int N;
void f() {
N::j = 2;
}
}

int main() { M::f(); }

[Bug bootstrap/96794] --with-build-config=bootstrap-lto-lean with --enable-link-mutex leads to poor LTRANS utilization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||hubicka at gcc dot gnu.org,
   ||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-08-26

[Bug c/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[chfast at gmail dot com]

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

--- Comment #3 from Paweł Bylica  ---
Created attachment 49128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49128=edit
Compiler invocation log

[Bug c/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[chfast at gmail dot com]

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

--- Comment #1 from Paweł Bylica  ---
Created attachment 49126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49126=edit
Test source code

[Bug c/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[chfast at gmail dot com]

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

--- Comment #2 from Paweł Bylica  ---
Created attachment 49127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49127=edit
Assembly output

[Bug c/96793] New: __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[chfast at gmail dot com]

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

Bug ID: 96793
   Summary: __builtin_floor produces wrong result when rounding
direction is FE_DOWNWARD
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

Created attachment 49125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49125=edit
Preprocessed test code

If the rounding direction is set to FE_DOWNWARD by fesetround(),
the __builtin_floor() result is -0 where it should be +0. Eg.
__builtin_floor(0.25) == -0.

The outputs are done with GCC 10.2.0 (x86_64-linux-gnu) with -O2
-frounding-math -lm. Full gcc -v output in cli.log file. This is also
reproducible in GCC 9 and trunk.


The test code to reproduce the bug checks if the result's sign is 0 as expected
(attached as builtin_floor_test.c):

enum { FE_DOWNWARD = 0x400 };

extern int fesetround(int rounding_direction);

__attribute__((noinline))
float builtin_floorf(float value)
{
return __builtin_floorf(value);
}

int main()
{
fesetround(FE_DOWNWARD);
float result = builtin_floorf(0.25f);
return __builtin_signbitf(result) != 0;
}


The __builtin_floor() generates the following assembly (part of
builtin_floor_test.s):

movss   .LC1(%rip), %xmm2
movss   .LC0(%rip), %xmm4
movaps  %xmm0, %xmm3
movaps  %xmm0, %xmm1
andps   %xmm2, %xmm3
ucomiss %xmm3, %xmm4
jbe .L2
cvttss2sil  %xmm0, %eax
pxor%xmm3, %xmm3
andnps  %xmm1, %xmm2
cvtsi2ssl   %eax, %xmm3
movaps  %xmm3, %xmm4
cmpnless%xmm0, %xmm4
movss   .LC2(%rip), %xmm0
andps   %xmm0, %xmm4
subss   %xmm4, %xmm3
movaps  %xmm3, %xmm0
orps%xmm2, %xmm0
.L2:
ret

[Bug c++/52771] name found in contexts not referring to the same entity should not compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/52771] name found in contexts not referring to the same entity should not compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|accepts-invalid |

--- Comment #2 from Jonathan Wakely  ---
clang accepts this without a murmur. EDG warns about the ambiguous lookup
result:

"52771.C", line 13: warning: ambiguous class member reference -- type
  "foo::foo" (declared at line 1) used in preference to class "foo"
  (declared at line 9)
return px->foo::A();  
   ^

I think this is actually undefined, because the meaning of foo changes and that
violates [basic.scope.class] p2: "A name N used in a class S shall refer to the
same declaration in its context and when re-evaluated in the completed scope of
S. No diagnostic is required for a violation of this rule."

Compilers are not required to diagnose violations of this rule, it's just
undefined (but see https://wg21.link/p1697r0 for a proposal to require a
diagnostic).

[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
It's "fixed" for C++11 because N::a is meaningful for scoped enums, and fails
to find it. But the code is invalid even in C++03.

Clang and EDG both reject this even in C++03 mode. We might want to do the
same.

EDG with --c++03 says:

"e.C", line 3: error: name followed by "::" must be a class or namespace name
  enum N { e0 = N::a };
^

"e.C", line 2: warning: variable "N::a" was declared but never referenced
  const int a = 42;
^

1 error detected in the compilation of "e.C".


Clang says:

e.C:3:19: warning: use of enumeration in a nested name specifier is a C++11
extension [-Wc++11-extensions]
enum N { e0 = N::a };
  ^
e.C:3:19: error: no member named 'a' in 'N::N'; did you mean simply 'a'?
enum N { e0 = N::a };
  ^~~~
  a
e.C:2:15: note: 'a' declared here
const int a = 42;
  ^
1 warning and 1 error generated.