[Bug c/98311] New: libcody configure checking problem

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98311
   Summary: libcody configure checking problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Yesterday's build was fine, today's not.

I get

configure:2624: result: ok
configure:2653: checking bugurl
configure:2670: result: github.com/urnathan/libcody
configure:2690: error: unknown check "df,extra,fold,rtl,yes"

Down in libcody/configure is

case $enable_checking in #(
  yes|all|yes,*) :
nms_checking=yes ;; #(
  no|none|release) :
nms_checking= ;; #(
  *) :
as_fn_error $? "unknown check \"$enable_checking\"" "$LINENO" 5 ;;
esac

Git blame says:

362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2715) case
$enable_checking in #(
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2716)   yes|all|yes,*) :
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2717)
nms_checking=yes ;; #(
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2718)   no|none|release)
:
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2719) nms_checking=
;; #(
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2720)   *) :
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2721) as_fn_error $?
"unknown check \"$enable_checking\"" "$LINENO" 5 ;;
362303298ac4 (Nathan Sidwell 2020-12-14 08:10:27 -0800 2722) esac

[Bug ada/98312] New: [11 Regression] Broken Ada bootstrap

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98312
   Summary: [11 Regression] Broken Ada bootstrap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: obry at gnat dot com
  Target Milestone: ---

Likely since r11-6071-g0feb237657c7c1f057754a8d8132a83adc63250e I see for PGO
bootstrap-lto-lean.mk:

[ 4194s] checking linux/reboot.h presence... yes
[ 4194s] checking for linux/reboot.h... yes
[ 4194s] g-sercom.adb:307:53: "ICANON" is undefined
[ 4194s] make[7]: *** [../gcc-interface/Makefile:299: g-sercom.o] Error 1
[ 4194s] make[7]: *** Waiting for unfinished jobs

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Priority|P3  |P1
  Known to fail||11.0
   Last reconfirmed||2020-12-16
 Status|UNCONFIRMED |NEW
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to work||10.2.0

[Bug analyzer/98293] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Just for the record, it started with r11-3840-gaf66094d03779377.

[Bug c/98294] [9/10/11 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1296 since r6-6901-g876217ae71cf0b34

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-16
 Ever confirmed|0   |1
Summary|[9/10/11 Regression] ICE in |[9/10/11 Regression] ICE in
   |calculate_line_spans, at|calculate_line_spans, at
   |diagnostic-show-locus.c:129 |diagnostic-show-locus.c:129
   |6   |6 since
   ||r6-6901-g876217ae71cf0b34
 CC||dmalcolm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r6-6901-g876217ae71cf0b34.

[Bug c++/98297] [8/9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Likely started with r8-2567-g776ff3efa9de7fce.

[Bug c/98311] libcody configure checking problem

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
I am also seeing some evidence that top of trunk won't build,
due to problems with the new modules source code.

Is is worth documenting here or should I raise a new bug report ?

[Bug tree-optimization/98308] ]ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3764 with -O3 -march=skylake-avx512 since r11-615-gdc0c0196340f7ac5

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-16
Summary|ICe in in   |]ICE in
   |vect_slp_analyze_node_opera |vect_slp_analyze_node_opera
   |tions, at   |tions, at
   |tree-vect-slp.c:3764 with   |tree-vect-slp.c:3764 with
   |-O3 -march=skylake-avx512   |-O3 -march=skylake-avx512
   ||since
   ||r11-615-gdc0c0196340f7ac5

--- Comment #1 from Martin Liška  ---
Confirmed, started with r11-615-gdc0c0196340f7ac5.

[Bug tree-optimization/98308] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3764 with -O3 -march=skylake-avx512 since r11-615-gdc0c0196340f7ac5

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|]ICE in |[11 Regression] ICE in
   |vect_slp_analyze_node_opera |vect_slp_analyze_node_opera
   |tions, at   |tions, at
   |tree-vect-slp.c:3764 with   |tree-vect-slp.c:3764 with
   |-O3 -march=skylake-avx512   |-O3 -march=skylake-avx512
   |since   |since
   |r11-615-gdc0c0196340f7ac5   |r11-615-gdc0c0196340f7ac5
   Target Milestone|--- |11.0
  Known to fail||11.0
  Known to work||10.2.0
 CC||rguenth at gcc dot gnu.org

[Bug c++/52830] ICE: "canonical types differ for identical types ..." when attempting SFINAE with member type

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Alex Coplan  ---
Thanks. The testcase no longer ICEs on trunk.

[Bug tree-optimization/98272] [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop by r11-5836

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:61e3c180ad6913fa5af39059de5ba7b3bde50cda

commit r11-6110-g61e3c180ad6913fa5af39059de5ba7b3bde50cda
Author: Eric Botcazou 
Date:   Wed Dec 16 09:39:07 2020 +0100

Fix PR tree-optimization/98272

This fixes the precision mismatch introduced by the previous change.

gcc/ChangeLog:
PR tree-optimization/98272
* tree-switch-conversion.c (bit_test_cluster::emit): When finding
out whether the entry test can be merged in the bit test, do the
computation using the type of the index expression.

gcc/testsuite/ChangeLog:
* gcc.dg/pr98272.c: New test.

[Bug tree-optimization/98272] [11 Regression] ICE: during GIMPLE pass: switchlower: in decompose, at wide-int.h:984 with -O -fno-tree-forwprop by r11-5836

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Botcazou  ---
.

[Bug tree-optimization/97750] ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #3 from Sergei Trofimovich  ---
In https://bugs.gentoo.org/760117 we got a similar report. I reproduced it
locally and minimized to the following:

// cat bug.c
char CopyPlane_src;
long CopyPlane_copy_pitch;
char *CopyFromUswc_src;
int CopyFromUswc_height;
void CopyPlane(char *dst) {
  __builtin_memcpy(dst, &CopyPlane_src, CopyPlane_copy_pitch);
}
void CopyFromUswc(long src_pitch) {
  char *dst;
  for (; CopyFromUswc_height;) {
unsigned unaligned = (long)CopyFromUswc_src;
if (unaligned)
  CopyPlane(&dst[unaligned]);
CopyFromUswc_src += src_pitch;
  }
}


Crashes as:

$ LANG=C gcc-11.0.0 -O2 -c bug.c -Wall -Wextra

during GIMPLE pass: wrestrict
bug.c: In function 'CopyFromUswc':
bug.c:8:6: internal compiler error: Segmentation fault
8 | void CopyFromUswc(long src_pitch) {
  |  ^~~~
0xb6956a crash_signal
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/toplev.c:327
0x7fe03834db5f ???
   
/usr/src/debug/sys-libs/glibc-2.32-r5/glibc-2.32/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x156ef41 operator_cast::op1_range(irange&, tree_node*, irange const&, irange
const&) const
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/range-op.cc:1881
0x1485a12 gori_compute::compute_name_range_op(irange&, gimple*, irange const&,
tree_node*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/gimple-range-gori.cc:490
0x1488b33 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
   
/usr/src/debug/sys-devel/gcc-11.0.0_pre/gcc-11.0.0_pre/gcc/gimple-range-gori.cc:1281
...

[Bug tree-optimization/97750] ICE in during GIMPLE pass: wrestrict on commit e0af865ab9d9d5b6b3ac7fdde26cf9bbf635b6b4

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Sergei Trofimovich  ---
Created attachment 49774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49774&action=edit
bug.c.orig

Attaching bug.c.orig. Unreduced preprocessed file. 'gcc-11.0.0 -O2 -x c -c
bug.c.orig' is enough to crash gcc.

[Bug tree-optimization/97750] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||11.0
 Status|WAITING |NEW
   Priority|P3  |P1
   Target Milestone|--- |11.0
 CC||amacleod at redhat dot com
  Known to work||10.2.0
Summary|ICE in during GIMPLE pass:  |[11 Regression] ICE in
   |wrestrict on commit |during GIMPLE pass:
   |e0af865ab9d9d5b6b3ac7fdde26 |wrestrict since
   |cf9bbf635b6b4   |r11-4135-ge864d395b4e862ce

--- Comment #5 from Martin Liška  ---
Confirmed, thank you for the test-case.

[Bug tree-optimization/98282] [8/9/10/11 Regression] Segmentation fault when compiling with optimization >= 2

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Will have a look after vacation.

[Bug target/98310] drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn

[rong.a.chen at intel dot com via Gcc-bugs]

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

--- Comment #1 from Rong Chen  ---
There is a report sent to lkml:
https://lore.kernel.org/lkml/202012152318.bhtyzswj-...@intel.com/, and the
config file can be found in the link.

[Bug tree-optimization/98282] [8/9/10/11 Regression] Segmentation fault when compiling with optimization >= 2

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 49775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49775&action=edit
gcc11-pr98282.patch

This version passed bootstrap/regtest and I'll use it in our tree temporarily
until you get back from vacation.

[Bug tree-optimization/88767] 'unroll and jam' not optimizing some loops

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
dup / fixed then.

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

[Bug tree-optimization/98137] Could use SLP to vectorize if split_constant_offset were smarter

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||helijia at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
*** Bug 88767 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/97750] [11 Regression] ICE in during GIMPLE pass: wrestrict since r11-4135-ge864d395b4e862ce

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Sergei Trofimovich  ---
Peeking at the gdb backtrace:

#0  operator_cast::op1_range (this=0x2e23ac0 , r=...,
type=0x77676c78, lhs=..., op2=...) at ../../gcc/gcc/range-op.cc:1881
#1  0x01f7195e in gimple_range_calc_op1 (r=..., stmt=0x777c55a0,
lhs_range=..., op2_range=...) at ../../gcc/gcc/gimple-range.cc:337
#2  0x01f817e2 in gori_compute::compute_name_range_op
(this=0x7fffd010, r=..., stmt=0x777c55a0, lhs=..., name=0x777b37e0)
at ../../gcc/gcc/gimple-range-gori.cc:507
#3  0x01f81c10 in gori_compute::compute_operand_range
(this=0x7fffd010, r=..., stmt=0x777c55a0, lhs=..., name=0x777b37e0)
at ../../gcc/gcc/gimple-range-gori.cc:607

  range_op_handler (PLUS_EXPR, type)->fold_range (lhs_neg,
  type,
  converted_lhs,
  lim_range);

(gdb) list range_op_handler
3420
3421// The tables are hidden and accessed via a simple extern function.
3422
3423range_operator *
3424range_op_handler (enum tree_code code, tree type)
3425{
3426  // First check if there is a pointer specialization.
3427  if (POINTER_TYPE_P (type))
3428return pointer_tree_table[code];
3429  if (INTEGRAL_TYPE_P (type))
3430return integral_tree_table[code];
3431  return NULL;
3432}

(gdb) call range_op_handler (PLUS_EXPR, type)
$2 = (range_operator *) 0x0

(gdb) call debug_generic_expr(type)
char *

(gdb) call POINTER_TYPE_P(type)
$7 = true

[Bug c/98313] New: Allow __attribute__((cleanup)) in types

[david at westcontrol dot com via Gcc-bugs]

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

Bug ID: 98313
   Summary: Allow __attribute__((cleanup)) in types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

The gcc __attribute__((cleanup)) feature can be useful for making the
equivalent of a C++ destructor in C code, as a way of ensuring resources are
freed even if you exit a function early with return.  Typical use-cases are
malloc'ed memory and locks.

In many situations, attaching the cleanup attribute to a type would give neater
code with fewer chances of error.  For example:

void indirect_free(void ** p)  {
free(*p);
*p = 0;
}

extern void do_something(int * p);

void foo(void) {
void * p = malloc(16);
do_something(p);
free(p);
}

void foo2(void) {
__attribute__((cleanup(indirect_free)))
void * p = malloc(16);
do_something(p);
}

Here, the cleanup attribute in "foo2" means you don't have to remember to free
p after calling do_something() - and if the function has multiple allocations,
this results in neater code with lower risk of bugs than a "traditional"
goto-based error handling.  But you still have to remember to put the cleanup
attribute on each relevant pointer.

If instead you had:

typedef __attribute__((cleanup(indirect_free))) void* auto_voidp;

auto_voidp auto_malloc(size_t size) {
return malloc(size);
}


then your code could be:

void foo3(void) {
void * p = auto_malloc(16);
do_something(p);
}


It would not remove all possibilities of error - copying an auto_voidp here
could easily lead to double-free errors.  (But this is C, not C++ - we need to
leave /some/ fun for the people debugging the code...)


Basically, all I'd like here is that if you attach a cleanup attribute to a
type (struct, typedef, etc.), then the attribute is automatically applied to
any definitions of variables of that type.

[Bug rtl-optimization/98271] ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d

commit r11-6111-g5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d
Author: Martin Liska 
Date:   Tue Dec 15 09:57:19 2020 +0100

options: fix integer overflow

gcc/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* opts-common.c (set_option): Do not allow overflow for integer
arguments.

gcc/testsuite/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* gcc.dg/pr98271.c: New test.

[Bug tree-optimization/98279] ICE in apply_scale with --param=hot-bb-frequency-fraction >= 2^31

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d

commit r11-6111-g5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d
Author: Martin Liska 
Date:   Tue Dec 15 09:57:19 2020 +0100

options: fix integer overflow

gcc/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* opts-common.c (set_option): Do not allow overflow for integer
arguments.

gcc/testsuite/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* gcc.dg/pr98271.c: New test.

[Bug rtl-optimization/98276] ICE in want_to_gcse_p, at gcse.c:808 with --param=gcse-cost-distance-ratio > 2^31

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d

commit r11-6111-g5c5eb7e4872025e8d5e8ae2f0e568403f7c8803d
Author: Martin Liska 
Date:   Tue Dec 15 09:57:19 2020 +0100

options: fix integer overflow

gcc/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* opts-common.c (set_option): Do not allow overflow for integer
arguments.

gcc/testsuite/ChangeLog:

PR rtl-optimization/98271
PR rtl-optimization/98276
PR tree-optimization/98279
* gcc.dg/pr98271.c: New test.

[Bug rtl-optimization/98271] ICE in apply_scale, at profile-count.h:1082 with large --param=align-loop-iterations

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/98276] ICE in want_to_gcse_p, at gcse.c:808 with --param=gcse-cost-distance-ratio > 2^31

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/98279] ICE in apply_scale with --param=hot-bb-frequency-fraction >= 2^31

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c/98311] libcody configure checking problem

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think it would be desirable to follow what libcpp does with enable_checking:

# Enable expensive internal checks
is_release=
if test -f $srcdir/../gcc/DEV-PHASE \
   && test x"`cat $srcdir/../gcc/DEV-PHASE`" != xexperimental; then
  is_release=yes
fi

AC_ARG_ENABLE(checking,
[AS_HELP_STRING([[--enable-checking[=LIST]]],
[enable expensive run-time checks.  With LIST,
 enable only specific categories of checks.
 Categories are: yes,no,all,none,release.
 Flags are: misc,valgrind or other strings])],
[ac_checking_flags="${enableval}"],[
# Determine the default checks.
if test x$is_release = x ; then
  ac_checking_flags=yes
else
  ac_checking_flags=release
fi])
IFS="${IFS= }"; ac_save_IFS="$IFS"; IFS="$IFS,"
for check in release $ac_checking_flags
do
case $check in
# these set all the flags to specific states
yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking=
;;
no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
# these enable particular checks
assert) ac_assert_checking=1 ;;
misc) ac_checking=1 ;;
valgrind) ac_valgrind_checking=1 ;;
# accept
*) ;;
esac
done
IFS="$ac_save_IFS"

The NMS_CHECKING seems to mostly looking like either the ac_checking or
ac_assert_checking, pick the one that suits better.  But it is desirable to go
through the list one by one and enable/disable it as it goes, and to have the
default based on DEV-PHASE.

[Bug sanitizer/97868] warn about using fences with TSAN

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:8833eab4461b4b7050f06a231c3311cc1fa87523

commit r11-6112-g8833eab4461b4b7050f06a231c3311cc1fa87523
Author: Martin Liska 
Date:   Mon Dec 7 15:55:59 2020 +0100

Add -Wtsan.

gcc/ChangeLog:

PR sanitizer/97868
* common.opt: Add new warning -Wtsan.
* doc/invoke.texi: Likewise.
* tsan.c (instrument_builtin_call): Warn users about unsupported
std::atomic_thread_fence.

gcc/testsuite/ChangeLog:

PR sanitizer/97868
* gcc.dg/tsan/atomic-fence.c: New test.

[Bug sanitizer/97868] warn about using fences with TSAN

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Implemented.

[Bug bootstrap/98314] New: [11 Regression] Install fails with "install -C"

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98314
   Summary: [11 Regression] Install fails with "install -C"
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

It can be convenient to do:

  make install INSTALL="/path/to/install -C"

to avoid touching files that haven't in fact changed (and so
avoid rebuilds of makefile rules that depend on the timestamps
of the installed tools).  That no longer works with c++tools:

/usr/bin/install -C -p g++-mapper-server
…/libexec/gcc/aarch64-none-linux-gnu/11.0.0
/usr/bin/install: options --compare (-C) and --preserve-timestamps are mutually
exclusive
Try '/usr/bin/install --help' for more information.
Makefile:92: recipe for target 'install' failed

I guess the simplest fix is to drop the -p, but maybe that's
bad for other reasons.

[Bug c++/98315] New: [11 regression] libcody breaks Solaris bootstrap

[ro at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98315
   Summary: [11 regression] libcody breaks Solaris bootstrap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

Since the introduction of libcody, Solaris 11 bootstrap is broken:

* On Solaris 11.4:

In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.cc:26:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^

  where  has

/*
 * Clear the hints portion of an xuio_t, leaving the initial uio_t and the
 * xu_ext union untouched.
 *
 * Note that this does not touch xu_type.  Since zero copy is recognized as
 * UIO_XUIO with xu_type of UIOTYPE_ZEROCOPY, if extending a uio_t not setup
 * for zero copy into a full xuio_t then chances are that xu_type should be
 * initialized too as if the xuio_t had been bzero'd - ie to UIOTYPE_ASYNCIO.
 */
#define XUIO_BZERO_HINTS(xuiop) do { \
bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
_NOTE(CONSTCOND) } while (0)

  This macros isn't used anywhere, so I wonder why #pragma poison would be
  offended.

* On Solaris 11.3:

In file included from /usr/include/sys/stream.h:16,
 from /usr/include/netinet/in.h:66,
 from /usr/include/sys/socket.h:32,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.cc:26:
/usr/include/sys/strmdep.h:25:26: error: attempt to use poisoned "bcopy"
 #define strbcpy(s, d, c) bcopy(s, d, c)
  ^

  with the following in :

/*
 * Copy data from one data buffer to another.
 * The addresses must be word aligned - if not, use bcopy!
 */
#define strbcpy(s, d, c)bcopy(s, d, c)

I've hacked around both for no by removing bcopy and bzero from #pragma GCC
poison
in gcc/system.h.

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/98316] New: [11 regression] cc1plus doesn't link on Solaris 11.3

[ro at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98316
   Summary: [11 regression] cc1plus doesn't link on Solaris 11.3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

Even with PR c++/98315 hacked around, Solaris 11.3 (only) bootstrap is still
broken:

Undefined   first referenced
 symbol in file
__xnet_connect  ../libcody/libcody.a(netclient.o)
__xnet_socket   ../libcody/libcody.a(netclient.o)
__xnet_getaddrinfo  ../libcody/libcody.a(netclient.o)
freeaddrinfo../libcody/libcody.a(netclient.o)
gai_strerror../libcody/libcody.a(netclient.o)
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
make[3]: *** [/vol/gcc/src/hg/master/local/gcc/cp/Make-lang.in:136: cc1plus]
Error 1

Before Solaris 11.4 folded libsocket and libnsl into libc, one needed to link
with both for the socket functions.  The same issue exists with the other use
of $(LIBCODY) in c++tools/Makefile.in.

We already have 4 instances of the libsocket/libnsl check in the tree:

  gotools/configure.ac
  libcc1/configure.ac
  libgo/configure.ac
  libphobos/m4/druntime/libraries.m4

Instead of adding yet two others, we could make use of the autoconf-archive's
m4/ax_lib_socket_nsl.m4 (AX_LIB_SOCKET_NSL).

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Besides, currently libcody.a (and, once this PR is fixed, libsocket and
libnsl) are linked into every backend instead of just into cc1plus.  I
believe this should change, just like f951 is the only user of $(ZLIB)
(and $(ZLIBINC)).

[Bug c++/98317] New: Vector Extensions aligned(1) not generating unaligned loads/stores

[danielhanchen at gmail dot com via Gcc-bugs]

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

Bug ID: 98317
   Summary: Vector Extensions aligned(1) not generating unaligned
loads/stores
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danielhanchen at gmail dot com
  Target Milestone: ---

The ordering of aligned(1) causes GCC to generate movaps / movups.

typedef float   float128_tv1__attribute__ ((aligned(1), vector_size(16)));
typedef float   float128_tv2__attribute__ ((vector_size(16), aligned(1)));

float128_tv1 provides MOVAPS
float128_tv2 provides MOVUPS

It seems like the ordering of the arguments changes the assembly.

https://gcc.godbolt.org/z/5qs7e7

It seems like GCC 10.2 and 9.2 all have this issue.
Unless if this was already documentated, this issue can cause massive issues if
memory is unaligned and an aligned load/store is used instead.

[Bug c++/98317] Vector Extensions aligned(1) not generating unaligned loads/stores

[danielhanchen at gmail dot com via Gcc-bugs]

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

Daniel Han-Chen  changed:

   What|Removed |Added

 CC||danielhanchen at gmail dot com

--- Comment #1 from Daniel Han-Chen  ---
https://gcc.godbolt.org/z/sGWevT

I also tried separating the __attribute__s


typedef float   float128_tv1__attribute__ ((aligned(1), vector_size(16)));
typedef float   float128_tv2__attribute__ ((vector_size(16), aligned(1)));
typedef float   float128_tv3__attribute__((aligned(1))) __attribute__
((vector_size(16)));
typedef float   float128_tv4__attribute__ ((vector_size(16)))
__attribute__((aligned(1)));


aligned as the first argument still fails.

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-16
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |11.0
   Assignee|bkoz at gcc dot gnu.org|redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
with GCC 8 and 9 the results are very consistent on x86_64: atomic_flag and
atomic_uchar and atomic_int all have identical performance, but clearing is ~4
times slower than setting. The spin_mutex test is very slightly slower than the
sum of atomic_flag::test_and_set() and atomic_flag::clear() (which makes sense,
since that's what it does).

With GCC 10 and trunk, clear is now as fast as set.

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Jonathan Wakely  ---
With trunk on powerpc64le the results are consistent for the different types,
but the clear operations are faster:

atomic_flag.cc  atomic_flag::test_and_set()  358r
atomic_flag.cc  atomic_flag::clear() 159r
atomic_flag.cc  atomic_uchar::operator|=(1)  357r
atomic_flag.cc  atomic_flag::operator=(0)159r
atomic_flag.cc  atomic_int::operator|=(1)357r
atomic_flag.cc  atomic_int::operator=(0) 158r

[Bug target/98302] [11 Regression] Wrong code on aarch64

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #3 from Alex Coplan  ---
Hi Martin, can you post the yarpgen seed (or the original cpp files) and I will
have a go at reproducing/reducing?

[Bug target/98302] [11 Regression] Wrong code on aarch64

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Martin Liška  ---
(In reply to Alex Coplan from comment #3)
> Hi Martin, can you post the yarpgen seed (or the original cpp files) and I
> will have a go at reproducing/reducing?

Sure, it's 202213617.
Thank you for help.

[Bug bootstrap/98318] New: libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Bug ID: 98318
   Summary: libcody breaks DragonFly bootstrap
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rimvydas.jas at gmail dot com
  Target Milestone: ---

Created attachment 49776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49776&action=edit
possible fix

Since the introduction of libcody, gcc bootstrap is broken on DragonFly BSD:

gmake[3]: Leaving directory '/build/trunk/libcpp'
Configuring stage 1 in ./libcody
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-dragonfly5.9
checking host system type... x86_64-unknown-dragonfly5.9
checking number of CPUs... unknown
checking maintainer-mode...
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -std=c++11 accepts -g... yes
checking whether g++ -std=c++11 is for C++11... yes
checking adding -Wl,--no-undefined to linker... ok
/data/gg/libcody/configure: CONFIG_FILES+= ./Makesub: not found
/data/gg/libcody/configure: CONFIG_FILES+= ./tests/Makesub: not found
checking bugurl... github.com/urnathan/libcody
checking checking... yes
checking exceptions... no
...
ar rc libcommon.a diagnostic.o diagnostic-color.o diagnostic-show-locus.o
diagnostic-format-json.o json.o edit-context.o pretty-print.o intl.o sbitmap.o
vec.o input.o version.o hash-table.o ggc-none.o memory-block.o selftest.o
selftest-diagnostic.o sort.o
ranlib  libcommon.a
gmake[3]: *** No rule to make target '../libcody/libcody.a', needed by
'cc1-checksum.c'.  Stop.
gmake[3]: Leaving directory '/build/trunk/gcc'
gmake[2]: *** [Makefile:4781: all-stage1-gcc] Error 2
gmake[2]: Leaving directory '/build/trunk'
gmake[1]: *** [Makefile:27488: stage1-bubble] Error 2
gmake[1]: Leaving directory '/build/trunk'
gmake: *** [Makefile:1004: all] Error 2

The /bin/sh is almquist shell and do not take VAR+= style appends.

Another issue missing  for sockaddr_in6 in netclient.cc and
netserver.cc.

Attached diff allows to bootstrap gcc11 once again.

[Bug tree-optimization/96239] Failure to recognize __builtin_bswap16 pattern

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:cd676dfa57e643a4f7d8445e6ebad0f21cf3fd84

commit r11-6115-gcd676dfa57e643a4f7d8445e6ebad0f21cf3fd84
Author: Jakub Jelinek 
Date:   Wed Dec 16 13:08:07 2020 +0100

bswap: Handle vector CONSTRUCTORs [PR96239]

The following patch teaches the bswap pass to handle for small (2/4/8 byte
long) vectors a CONSTRUCTOR by determining if the bytes of the constructor
come from non-vector sources and are either nop or bswap and changing the
CONSTRUCTOR in that case to VIEW_CONVERT_EXPR from scalar integer to
the vector type.

Unfortunately, as I found after the patch was written, due to pass ordering
this doesn't really fix the original testcase, just the one I wrote,
because both loop and slp vectorization is done only after the bswap pass.
A possible way out of that would be to perform just this particular bswap
optimization (i.e. for CONSTRUCTOR assignments with integral vector types
call find_bswap_or_nop and bswap_replace if successful) also during the
store merging pass, it isn't really a store, but the store merging pass
already performs bswapping when handling store, so it wouldn't be that big
hack.  What do you think?

2020-12-16  Jakub Jelinek  

PR tree-optimization/96239
* gimple-ssa-store-merging.c (find_bswap_or_nop): Handle a vector
CONSTRUCTOR.
(bswap_replace): Likewise.

* gcc.dg/pr96239.c: New test.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Rimvydas (RJ)  ---
Could there be added configure option to disable use of libcody functionality
globally like "./configure --disable-cody" or --disable-libstdcxx-modules?

[Bug target/98302] [11 Regression] Wrong code on aarch64

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Alex Coplan  ---
Can't repro with that seed (at least on aarch64-elf-gcc). I expect we're seeing
different source files.

I see:
$ md5sum src/*
72fdf911a2c5f9cc21df5af3ffb4726e  src/driver.cpp
b8fdebf50f579fa5d7c93de5d42ae217  src/func.cpp
ce2afb8e50893400329f5fd1d3015caf  src/init.h

$ yarpgen --version
yarpgen version 2.0 (build 9cb35d3 on 2020:10:30)

I guess we need (at least) matching (yarpgen commit, seed) to end up with the
same source files? Might be easiest to just post the cpp files if possible.

[Bug target/98302] [11 Regression] Wrong code on aarch64

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Liška  ---
Created attachment 49777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49777&action=edit
Packed yarpgen test-case

[Bug c++/98317] Vector Extensions aligned(1) not generating unaligned loads/stores

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm not convinced it is a bug.  Because vector_size by definition increases the
alignment, say if you have vector_size on int, the vector type doesn't have
alignof(int) alignment, but alignment of the vector type.
Similarly, if one uses
typedef int T __attribute__((aligned (1)));
typedef T V __attribute__((vector_size (16)));
I'd argue that V should have still 16-byte alignment.
Having the attributes on the same typedef or on the same type is a grey area,
but what we do currently matches what is done with the separate typedefs.
I'd strongly suggest to use separate typedefs, i.e. one that makes a vector
type
typedef float V __attribute__((vector_size (16)));
and then another one that makes it unaligned:
typedef V U __attribute__((aligned (1)));

[Bug target/98302] [11 Regression] Wrong code on aarch64

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Alex Coplan  ---
Thanks, I can reproduce it now.

[Bug libstdc++/98319] New: LFTS headers give errors if included as C++11 or C++98

[redi at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98319
   Summary: LFTS headers give errors if included as C++11 or C++98
   Product: gcc
   Version: 10.2.1
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: ---

For example:

/home/jwakely/gcc/11/include/c++/11.0.0/experimental/source_location: In static
member function ‘static constexpr
std::experimental::fundamentals_v2::source_location
std::experimental::fundamentals_v2::source_location::current(const char*, const
char*, int, int)’:
/home/jwakely/gcc/11/include/c++/11.0.0/experimental/source_location:63:5:
error: body of ‘constexpr’ function ‘static constexpr
std::experimental::fundamentals_v2::source_location
std::experimental::fundamentals_v2::source_location::current(const char*, const
char*, int, int)’ not a return-statement

It should be possible to include them and then test the feature test macro to
see if they are usable.

[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/98317] Vector Extensions aligned(1) not generating unaligned loads/stores

[danielhanchen at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Daniel Han-Chen  ---
Oh ok then.

It's cause I was trying to do unaligned loads by following:
https://stackoverflow.com/questions/9318115/loading-data-for-gccs-vector-extensions

In it, it mentioned using typedef char __attribute__ ((vector_size (16),aligned
(1))) unaligned_byte16, which works, though the other way does not.

But I like your solution by declaring the type as aligned(1) separately.

[Bug c/98311] libcody configure checking problem

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
   Last reconfirmed||2020-12-16
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c++/98297] [8/9/10/11 Regression] ICE in cp_parser_elaborated_type_specifier, at cp/parser.c:19653

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug target/98302] [11 Regression] Wrong code on aarch64

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-16
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #8 from Martin Liška  ---
(In reply to Alex Coplan from comment #7)
> Thanks, I can reproduce it now.

Great. I tried to reduce that with:
gcc10: -Werror -fsanitize=address,undefined -fno-sanitize-recover=all - OK
gcc11: -O2 - OK
gcc11: -O3 - Assert happens

[Bug bootstrap/98314] [11 Regression] Install fails with "install -C"

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-16
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug target/98302] [11 Regression] Wrong code on aarch64

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Liška  ---
Btw. how powerful machine do you use for reduction?
What's a wall time of an interestingness test you're going to use?

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-12-16
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-16
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Jonathan Wakely  ---
Be patient, people have to sleep sometimes.

And please stop CCing me on everything, this is nothing to do with me and I
can't do anything about it.

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[ro at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Rainer Orth  ---
Created attachment 49778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49778&action=edit
Initial patch

The attach has only been lightly tested so far: it allowed cc1plus to link on
Solaris 11.3, bootstrap still running.

[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:a2c2eec183acf25c9b214fa0827718e4d2fdfc93

commit r11-6137-ga2c2eec183acf25c9b214fa0827718e4d2fdfc93
Author: Jonathan Wakely 
Date:   Tue Dec 15 20:28:11 2020 +

libstdc++: Test errno macros directly, not via autoconf [PR 93151]

This fixes a bug caused by a mismatch between the macros defined by
 when GCC is built and the macros defined by  when
users include . If the user code is compiled with
_XOPEN_SOURCE defined to 500 or 600, Darwin suppresses the
ENOTRECOVERABLE and EOWNERDEAD macros, which are not defined by SUSv3
(aka POSIX.1-2001).

Since POSIX requires the errno macros to be macros (and not variables or
enumerators) we can just test for them directly using the preprocessor.
That means that  will match what is actuallydefined when
it's included, not what was defined when GCC was built. With that change
there is no need for the GLIBCXX_CHECK_SYSTEM_ERROR configure checks and
they can be removed.

libstdc++-v3/ChangeLog:

PR libstdc++/93151
* acinclude.m4 (GLIBCXX_CHECK_SYSTEM_ERROR): Remove.
* configure.ac: Regenerate.
* config/os/generic/error_constants.h: Test POSIX errno macros
directly, instead of corresponding _GLIBCXX_HAVE_EXXX macros.
* testsuite/19_diagnostics/headers/system_error/errc_std_c++0x.cc:
Likewise.
* testsuite/19_diagnostics/headers/system_error/93151.cc: New
test.

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-6138-g3cee0c6562e5d8df69a9d6ad613a6f3edcfcc797
Author: Jonathan Wakely 
Date:   Wed Dec 16 11:51:42 2020 +

libstdc++: Add performance test for atomic_flag [PR 46447]

This adds a test to compare the performance of std::atomic_flag with
similar operations on std::atomic_uchar and std::atomic_int.

libstdc++-v3/ChangeLog:

PR libstdc++/46447
* testsuite/performance/29_atomics/atomic_flag.cc: New test.

[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:ab9bd93271061f436c10e35e261ecb73e2108ccc

commit r11-6139-gab9bd93271061f436c10e35e261ecb73e2108ccc
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:37:17 2020 +

libstdc++: Fix errors from Library Fundamentals TS headers in C++11 [PR
98319]

Currently the ,  and
 headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.

libstdc++-v3/ChangeLog:

PR libstdc++/98319
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

[tnfchris at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Tamar Christina  ---
Unfortunately I can still reproduce this with 483.xalancbmk on spec2006.

It seems to indeed happen only with -flto so I have no idea how to reduce it..

As of g:8833eab4461b4b7050f06a231c3311cc1fa87523 I still get

during RTL pass: expand
BinFileInputStream.cpp: In member function 'makeStream':
BinFileInputStream.cpp:145:1: internal compiler error: Segmentation fault
  145 | }
  | ^
0xbf7a33 crash_signal
../../gcc-fsf/gcc/toplev.c:327
0x6e34f4 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-fsf/gcc/tree.h:3337
0x6e34f4 warn_dealloc_offset
../../gcc-fsf/gcc/builtins.c:13413
0x701927 maybe_emit_free_warning(tree_node*)
../../gcc-fsf/gcc/builtins.c:13586
0x71264b initialize_argument_information
../../gcc-fsf/gcc/calls.c:2629
0x71264b expand_call(tree_node*, rtx_def*, int)
../../gcc-fsf/gcc/calls.c:4009
0x852887 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-fsf/gcc/expr.c:11276
0x72881b expand_expr
../../gcc-fsf/gcc/expr.h:282
0x72881b expand_call_stmt
../../gcc-fsf/gcc/cfgexpand.c:2831
0x72881b expand_gimple_stmt_1
../../gcc-fsf/gcc/cfgexpand.c:3835
0x72881b expand_gimple_stmt
../../gcc-fsf/gcc/cfgexpand.c:3999
0x72ddd3 expand_gimple_basic_block
../../gcc-fsf/gcc/cfgexpand.c:6036
0x73019f execute
../../gcc-fsf/gcc/cfgexpand.c:6720

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:6175383249143309fdc780a02bea484f4450def7

commit r11-6140-g6175383249143309fdc780a02bea484f4450def7
Author: H.J. Lu 
Date:   Thu Dec 3 11:01:06 2020 -0800

Switch to a new section if the SECTION_RETAIN bit doesn't match

When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.

gcc/

PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
nullptr.
* varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
return and switch to a new section later.
(assemble_start_function): Pass decl to switch_to_section.
(assemble_variable): Likewise.
(switch_to_section): If the SECTION_RETAIN bit doesn't match,
switch to a new section.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: New test.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.
* c-c++-common/attr-used-9.c: Likewise.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:2a976020603589e897fcfa3276590ef50b489d34

commit r11-6141-g2a976020603589e897fcfa3276590ef50b489d34
Author: H.J. Lu 
Date:   Thu Dec 3 15:39:59 2020 -0800

Warn used and not used symbols in section with the same name

When SECTION_RETAIN is used, issue a warning when a symbol without used
attribute and a symbol with used attribute are placed in the section with
the same name, like

int __attribute__((used,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;

since assembler will put them in different sections with the same section
name.

gcc/

PR target/98146
* varasm.c (switch_to_section): Warn when a symbol without used
attribute and a symbol with used attribute are placed in the
section with the same name.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: Updated.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:151d1347c99acfcf0f5bcd8caac36dcc7353816d

commit r11-6142-g151d1347c99acfcf0f5bcd8caac36dcc7353816d
Author: H.J. Lu 
Date:   Mon Dec 14 20:10:13 2020 -0800

Require .init_array/.fini_array support for SHF_GNU_RETAIN

Since SHF_GNU_RETAIN support doesn't work for crtstuff.c which switches
the output section directly with asm statement:

---
static void __attribute__((used))
__do_global_dtors_aux (void)
{
  static _Bool completed;

  if (__builtin_expect (completed, 0))
return;
  completed = 1;
}

static void __attribute__((__used__))
call___do_global_dtors_aux (void)
{
  asm ("\t.section\t.fini");
  __do_global_dtors_aux ();
  asm ("\t.section\t.text");
}
---

use SHF_GNU_RETAIN only if .init_array/.fini_array section is supported.

gcc/

PR target/98146
* defaults.h (SUPPORTS_SHF_GNU_RETAIN): New.
* varasm.c (get_section): Replace HAVE_GAS_SHF_GNU_RETAIN with
SUPPORTS_SHF_GNU_RETAIN.
(resolve_unique_section): Likewise.
(get_variable_section): Likewise.
(switch_to_section): Likewise.

gcc/testsuite/

PR target/98146
* lib/target-supports.exp
(check_effective_target_R_flag_in_section): Also check
HAVE_INITFINI_ARRAY_SUPPORT != 0.

[Bug target/98146] [11 Regression] section type conflict when "used" attribute is applied to decl with specific section

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug libstdc++/93151] system_error header fails to compile with -D_XOPEN_SOURCE=600

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/46447] std::atomic_flag slower than std::atomic_uchar

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Benjamin Kosnik from comment #3)
> I'd like to generalize this test case for the performance testsuite.

Done.

[Bug libstdc++/98319] LFTS headers give errors if included as C++11 or C++98

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug c/98320] New: Parameter is malformed in the called function

[ypn00vb at gmail dot com via Gcc-bugs]

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

Bug ID: 98320
   Summary: Parameter is malformed in the called function
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ypn00vb at gmail dot com
  Target Milestone: ---

Created attachment 49779
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49779&action=edit
main function

When compiling with the -m64 option, one of the parameters passed to the
function is damaged. When compiling with the -m32 option, there is no damage,
everything works.
PS. In the assembler listing, you can see that there is no instruction to move
the stack pointer with the -m64 option. Therefore, the assembler insertion of a
flag register push instruction overwrites the parameter in memory.

[Bug target/97141] [10/11 Regression] aarch64, SVE: ICE in decompose, at rtl.h (during expand) since r10-4676-g9c437a108a

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Alex Coplan  ---
Adding -fno-tree-forwprop gives us an ICE in LRA instead:

$ aarch64-elf-gcc -c pr97141.c -O3 -march=armv8.2-a+sve -fno-tree-forwprop

during RTL pass: reload
pr97141.c: In function 'g':
pr97141.c:8:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
8 | }
  | ^
0xc08d23 lra_constraints(bool)
/home/alecop01/toolchain/src/gcc/gcc/lra-constraints.c:5061
0xbeff49 lra(_IO_FILE*)
/home/alecop01/toolchain/src/gcc/gcc/lra.c:2329
0xba2af8 do_reload
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5802
0xba2af8 execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5988
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Originally noticed this LRA ICE with the related testcase:

int a;
void b() {
  a = 0;
  for (; a != -24; a = (short)a - 3) {
short *c;
*c |= 0 < b;
  }
}

[Bug bootstrap/98314] [11 Regression] Install fails with "install -C"

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Thanks, fixed by r11-6136.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-cvs/2020-December/33
   ||9290.html
 Status|NEW |RESOLVED

--- Comment #1 from Eric Botcazou  ---
.

[Bug c/98311] libcody configure checking problem

[nathan at gcc dot gnu.org via Gcc-bugs]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed 4be6c4e2a4d

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[nathan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Nathan Sidwell  ---
Looks good, and separating out cc1plus' libraries from other executables is
goodness.

do you want to take this bug?

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[nathan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Nathan Sidwell  ---
I think this is fixed by 
6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage

please let me know

[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3

[ro at gcc dot gnu.org via Gcc-bugs]

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

Rainer Orth  changed:

   What|Removed |Added

   Assignee|nathan at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
That's easiest, I guess.  With one minor addition (gcc/objcp/Make-lang.in needs
the same treatment), the Solaris 11.3 build completed successfully; make check
still running.

I'll try the patch on Solaris 11.4 and Linux/x86_64 tonight, then post it.

[Bug libstdc++/96083] Clang can't compile : error: use of undeclared identifier '__builtin_sprintf'

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:96d9670e88333d8896a5d2f2bb0403c1e2ad19ab

commit r11-6146-g96d9670e88333d8896a5d2f2bb0403c1e2ad19ab
Author: Jonathan Wakely 
Date:   Wed Dec 16 13:50:34 2020 +

libstdc++: Only use __builtin_sprintf if supported [PR 96083]

Clang doesn't support __builtin_sprintf, so use std::sprintf instead.

libstdc++-v3/ChangeLog:

PR libstdc++/96083
* include/ext/throw_allocator.h: Use __has_builtin to check for
__builtin_sprintf support, and use std::sprtinf if necessary.

[Bug target/98321] New: [nvptx] 'atom.add.f32' for atomic add of 32-bit 'float'

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98321
   Summary: [nvptx] 'atom.add.f32' for atomic add of 32-bit
'float'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---
Target: nvptx

Consider:

TYPE f(TYPE a, TYPE b)
{
  #pragma acc atomic update
  a += b;

  return a;
}

Compiling always with '-fopenacc', for '-DTYPE=int'/'-DTYPE=long' I do see the
expected 'atom.add.u32'/'atom.add.u64', but for '-DTYPE=float' I do not see the
expected 'atom.add.f32' but instead an 'atom.cas.b32' loop.  (I understand that
'-DTYPE=double': 'atom.add.f64' depends on PTX 5.0, SM 6.0 support.)

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
I can confirm that and I'm going to reduce that.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug 98160 Summary: [11 Regression] ICE in default_tree_printer at 
gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160

   What|Removed |Added

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

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Martin Liška  ---
New reduced test-case:

$ cat 1.ii
namespace xercesc_2_5 {
class MemoryManager;
class XMemory {
  void *operator new(unsigned long, MemoryManager *);
};
class MemoryManager {
public:
  virtual void *allocate();
};
void *XMemory::operator new(unsigned long, MemoryManager *manager) {
  long headerSize(sizeof(MemoryManager));
  void *block = manager->allocate();
  return block + headerSize;
}
} // namespace xercesc_2_5

$ cat 2.ii
namespace xercesc_2_5 {
class MemoryManager;
class XMemory {
public:
  void *operator new(unsigned long, MemoryManager *);
  void operator delete(void *, MemoryManager *);
};
class XMLPlatformUtils {
public:
  static MemoryManager *fgMemoryManager;
};
class ValueStackOf : public XMemory {
public:
  ValueStackOf(int, bool);
};
class XPathMatcherStack {
  XPathMatcherStack();
  ValueStackOf *fContextStack;
};
XPathMatcherStack::XPathMatcherStack()
: fContextStack(new (XMLPlatformUtils::fgMemoryManager)
ValueStackOf(8, XMLPlatformUtils::fgMemoryManager)) {}
} // namespace xercesc_2_5

$ g++ 1.ii 2.ii -O2 -flto=16 -shared
1.ii: In static member function 'static void* xercesc_2_5::XMemory::operator
new(long unsigned int, xercesc_2_5::MemoryManager*)':
1.ii:13:16: warning: pointer of type 'void *' used in arithmetic
[-Wpointer-arith]
   13 |   return block + headerSize;
  |  ~~^~~~
during RTL pass: expand
2.ii: In member function '__ct_base ':
2.ii:22:74: internal compiler error: Segmentation fault
   22 | ValueStackOf(8,
XMLPlatformUtils::fgMemoryManager)) {}
  |
 ^
0xcce44f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x81da08 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3337
0x81da08 warn_dealloc_offset
/home/marxin/Programming/gcc/gcc/builtins.c:13413
0x836127 maybe_emit_free_warning(tree_node*)
/home/marxin/Programming/gcc/gcc/builtins.c:13586
0x84545e initialize_argument_information
/home/marxin/Programming/gcc/gcc/calls.c:2629
0x84545e expand_call(tree_node*, rtx_def*, int)
/home/marxin/Programming/gcc/gcc/calls.c:4009
0x978104 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:11276
0x8590cd expand_expr
/home/marxin/Programming/gcc/gcc/expr.h:282
0x8590cd expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2831
0x8590cd expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3835
0x8590cd expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3999
0x85e5fa expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6036
0x8600b6 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6720
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/cc3Mo9q4.mk:2: /tmp/ccFzg763.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Martin Liška  ---
(In reply to Martin Sebor from comment #4)
> Fixed in r11-6028.

Even the original test-case still ICEs after this revision. I'm testing
r11-6147 right now.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

[pmderodat at gcc dot gnu.org via Gcc-bugs]

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

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from pmderodat at gcc dot gnu.org ---
Hello Martin,

Thank you for reporting this and sorry for the inconvenience! As discussed on
gcc-patches@, I suspect that my testing hasn’t detected this because of some
inconsistency with my incremental builds.

This should be fixed now that
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbe22e189a355f19eb1344fcaf91bc2bb0b95f36
is pushed.

[Bug libstdc++/98108] Broken Schwarz counter for iostreams initialization

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #7 from Jonathan Wakely  ---
I've reverted the change because it breaks the build for some targes.

So you'll just have to fix your code. The simplest way is to ensure you include
 before defining a global that wants to use std::cout.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Liška  ---
Thank you for the fix, it works for me.

[Bug target/98320] Parameter is malformed in the called function

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
You are clobbering the red zone.

[Bug ada/98312] [11 Regression] Broken Ada bootstrap

[pmderodat at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from pmderodat at gcc dot gnu.org ---
That’s a relief, thank you for the confirmation :)

[Bug fortran/98284] ICE in get_array_index

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:5098d35fb1997aa6fd6d7e37d0fd4501a5fe2f9d

commit r11-6149-g5098d35fb1997aa6fd6d7e37d0fd4501a5fe2f9d
Author: Harald Anlauf 
Date:   Wed Dec 16 17:25:06 2020 +0100

PR fortran/98284 - ICE in get_array_index

Reject DATA elements with the ALLOCATABLE attribute also when they are
components of a derived type.

gcc/fortran/ChangeLog:

PR fortran/98284
* resolve.c (check_data_variable): Reject DATA elements with the
ALLOCATABLE attribute.

gcc/testsuite/ChangeLog:

PR fortran/98284
* gfortran.dg/pr98284.f90: New test.

[Bug fortran/98284] ICE in get_array_index

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #5 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11.

Thanks for the reduced testcase and for draft patch!

[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu

[mhillen at linux dot ibm.com via Gcc-bugs]

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

Marius Hillenbrand  changed:

   What|Removed |Added

 CC||mhillen at linux dot ibm.com

--- Comment #6 from Marius Hillenbrand  ---
I reproduced and bisected with the config shared by Matthias. The issue begins
with the introduction of ipa-modref. There is an inbetween range of commits
that fail with a different symptom, yet this commit is the first I found that
exactly fails as initially reported here:

commit d119f34c952f8718fdbabc63e2f369a16e92fa07
Author: Jan Hubicka 
Date:   Sun Sep 20 07:25:16 2020 +0200

New modref/ipa_modref optimization passes

2020-09-19  David Cepelik  
Jan Hubicka  

* Makefile.in: Add ipa-modref.c and ipa-modref-tree.c.
* alias.c: (reference_alias_ptr_type_1): Export.
* alias.h (reference_alias_ptr_type_1): Declare.
* common.opt (fipa-modref): New.
* gengtype.c (open_base_files): Add ipa-modref-tree.h and
ipa-modref.h
* ipa-modref-tree.c: New file.
* ipa-modref-tree.h: New file.
* ipa-modref.c: New file.
* ipa-modref.h: New file.
* lto-section-in.c (lto_section_name): Add ipa_modref.
* lto-streamer.h (enum lto_section_type): Add
LTO_section_ipa_modref.
* opts.c (default_options_table): Enable ipa-modref at -O1+.
* params.opt (-param=modref-max-bases, -param=modref-max-refs,
-param=modref-max-tests): New params.
* passes.def: Schedule pass_modref and pass_ipa_modref.
* timevar.def (TV_IPA_MODREF): New timevar.
(TV_TREE_MODREF): New timevar.
* tree-pass.h (make_pass_modref): Declare.
(make_pass_ipa_modref): Declare.
* tree-ssa-alias.c (dump_alias_stats): Include ipa-modref-tree.h
and ipa-modref.h
(alias_stats): Add modref_use_may_alias, modref_use_no_alias,
modref_clobber_may_alias, modref_clobber_no_alias, modref_tests.
(dump_alias_stats): Dump new stats.
(nonoverlapping_array_refs_p): Fix formating.
(modref_may_conflict): New function.
(ref_maybe_used_by_call_p_1): Use it.
(call_may_clobber_ref_p_1): Use it.
(call_may_clobber_ref_p): Update.
(stmt_may_clobber_ref_p_1): Update.
* tree-ssa-alias.h (call_may_clobber_ref_p_1): Update.

[Bug target/98302] [11 Regression] Wrong code on aarch64

[acoplan at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from Alex Coplan  ---
Reduced to:

int c = 1705;
char a;
long f = 50887638;
unsigned long long *h(unsigned long long *k, unsigned long long *l) {
  return *k ? k : l;
}
void aa() {}
int main() {
  long d = f;
  for (char g = 0; g < (char)c - 10; g += 2) {
unsigned long long i = d, j = 4;
a = *h(&i, &j) << ((d ? 169392992 : 0) - 169392955LL);
  }
  if (a)
__builtin_abort();
}

which is miscompiled at -O2 -ftree-vectorize or -O3.

[Bug c++/98322] New: optimizes to false instead true

[sucicf1 at outlook dot com via Gcc-bugs]

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

Bug ID: 98322
   Summary: optimizes to false instead true
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sucicf1 at outlook dot com
  Target Milestone: ---

bool always_true (bool a, bool b)
{
return (a == b) == (~a ^ b);
} 

is optimized to 

xorl%eax, %eax
ret

instead return 1.

[Bug c++/98322] optimizes to false instead true

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I don't think that's true.
Note, that with -Wall you get the warning:
true.c: In function 'always_true':
true.c:3:29: warning: '~' on a boolean expression [-Wbool-operation]
3 | return (a == b) == (~a ^ b);
  | ^
true.c:3:29: note: did you mean to use logical not?
3 | return (a == b) == (~a ^ b);
  | ^
  |

[Bug c++/98315] [11 regression] libcody breaks Solaris bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Nathan Sidwell  ---
> I think this is fixed by 
> 6ff747f023c 2020-12-16 | c++: Fix (some) solaris breakage
>
> please let me know

Unfortunately not: there are still two instances of the problem:

In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from
/vol/gcc/src/hg/master/local/gcc/cp/../../c++tools/resolver.h:25,
 from
/vol/gcc/src/hg/master/local/gcc/cp/../../c++tools/resolver.cc:23,
 from
/vol/gcc/src/hg/master/local/gcc/cp/mapper-resolver.cc:27:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^
In file included from /usr/include/sys/socket.h:25,
 from /vol/gcc/src/hg/master/local/gcc/../libcody/cody.hh:29,
 from /vol/gcc/src/hg/master/local/gcc/cp/mapper-client.h:26,
 from /vol/gcc/src/hg/master/local/gcc/cp/module.cc:232:
/usr/include/sys/uio.h:192:3: error: attempt to use poisoned "bzero"
   bzero(&(xuiop)->xu_hint, sizeof ((xuiop)->xu_hint)); \
   ^

[Bug bootstrap/98323] New: current trunk won't build with clang

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98323
   Summary: current trunk won't build with clang
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Current trunk has hash 5098d35fb1997aa6.

I tried building it with clang version 11.0.0
and got this:

../../trunk.git/gcc/cp/module.cc:4156:43: error: expected ')'
  size_t alloc = (offsetof (impl, impl::stack)
  ^
../../trunk.git/gcc/cp/module.cc:4156:23: note: to match this '('
  size_t alloc = (offsetof (impl, impl::stack)
  ^
/usr/lib64/clang/11.0.0/include/stddef.h:104:42: note: expanded from macro
'offsetof'
#define offsetof(t, d) __builtin_offsetof(t, d)
 ^

For the record, it builds happily with recent gcc.