[Bug tree-optimization/95638] [10 Regression] Legit-looking code doesn't work with -O2

[amker at gcc dot gnu.org]

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

--- Comment #14 from bin cheng  ---
(In reply to Richard Biener from comment #13)
> GCC 10.2 is released, adjusting target milestone.

Hmm, this should be fixed on GCC10/GCC9.  I backported PR95638/PR95804
separately using cherry-pick, so the backport information for latter PR is not
reflected here.

[Bug target/96260] [10/11 Regression] RISC-V: -fsanitize=kernel-address is not available after gcc10

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Kito Cheng :

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

commit r11-2283-g2ca1b6d009b194286c3ec91f9c51cc6b0a475458
Author: Kito Cheng 
Date:   Wed Jul 22 14:50:40 2020 +0800

PR target/96260 - KASAN should work even back-end not porting anything.

 - Most KASAN function don't need any porting anything in back-end
   except asan stack protection.

 - However kernel will given shadow offset when enable asan stack
   protection, so eveything in KASAN can work if shadow offset is given.

 - Verified with x86 and risc-v.

 - Verified with RISC-V linux kernel.

gcc/ChangeLog:

PR target/96260
* asan.c (asan_shadow_offset_set_p): New.
* asan.h (asan_shadow_offset_set_p): Ditto.
* toplev.c (process_options): Allow -fsanitize=kernel-address
even TARGET_ASAN_SHADOW_OFFSET not implemented, only check when
asan stack protection is enabled.

gcc/testsuite/ChangeLog:

PR target/96260
* gcc.target/riscv/pr91441.c: Update warning message.
* gcc.target/riscv/pr96260.c: New.

[Bug fortran/95718] [8/9/10/11 Regression] Wrong pointer associated status without initialization

[peng.w...@compiler-dev.com]

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

--- Comment #4 from PengWang  ---
(In reply to kargl from comment #3)
>16.5.2.2 Pointer association status
> 
>A pointer may have a pointer association status of associated,
>disassociated, or undefined.  Its association status may change
>during execution of a program.  Unless a pointer is initialized
>(explicitly or by default), it has an initial association status
>of undefined.  A pointer may be initialized to have an association
>status of disassociated or associated.
> 
>13.7.16 ASSOCIATED (POINTER [, TARGET])
> 
>POINTER shall be a pointer.  It may be of any type or may be a
>   procedure pointer.  Its pointer association status shall not
>   be undefined.
> 
> Your program is invalid.

thank you very much! The status of undefined has confused me for a long time,
now I understand it finally, thank you~

[Bug fortran/96294] New: Compile error for pointer function

[peng.w...@compiler-dev.com]

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

Bug ID: 96294
   Summary: Compile error for pointer function
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peng.w...@compiler-dev.com
  Target Milestone: ---

I got a testcase like this:


program a
IMPLICIT NONE
myfunc() = 311
print*,myfunc()

contains
FUNCTION myfunc() RESULT (result_ptr)
IMPLICIT NONE
INTEGER, POINTER :: result_ptr
INTEGER, SAVE, TARGET:: targ

result_ptr => targ
END FUNCTION myfunc
end program a


But I got a compile error for the testcase above:

func-04.f90:7:4:

7 | FUNCTION myfunc() RESULT (result_ptr)
  |1
Error: INTERNAL-PROC procedure at (1) is already declared as STATEMENT-PROC
procedure.
F2008: A pointer function assignment is ambiguous if it is the first executable
statement after the specification block. Please add any other kind of
executable statement before it. FIXME
func-04.f90:7:4:

7 | FUNCTION myfunc() RESULT (result_ptr)
  |1
Error: Statement function ‘myfunc’ at (1) may not have pointer or allocatable
attribute
func-04.f90:3:19:

3 | myfunc() = 311
  |   1
Error: Pointer assignment target cannot be a constant at (1)


I wonder if this pointer function feature is not support by gfortran ,or if it
is a bug above?

this is the options given when GCC was configured:
# gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc -enable-checking=release
-enable-languages=c,fortran -disable-bootstrap -disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)

[Bug target/96260] [10/11 Regression] RISC-V: -fsanitize=kernel-address is not available after gcc10

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:83f1fbb9e7afaa77d52b200c7937788faa5f24d7

commit r10-8516-g83f1fbb9e7afaa77d52b200c7937788faa5f24d7
Author: Kito Cheng 
Date:   Wed Jul 22 14:50:40 2020 +0800

PR target/96260 - KASAN should work even back-end not porting anything.

 - Most KASAN function don't need any porting anything in back-end
   except asan stack protection.

 - However kernel will given shadow offset when enable asan stack
   protection, so eveything in KASAN can work if shadow offset is given.

 - Verified with x86 and risc-v.

 - Verified with RISC-V linux kernel.

gcc/ChangeLog:

PR target/96260
* asan.c (asan_shadow_offset_set_p): New.
* asan.h (asan_shadow_offset_set_p): Ditto.
* toplev.c (process_options): Allow -fsanitize=kernel-address
even TARGET_ASAN_SHADOW_OFFSET not implemented, only check when
asan stack protection is enabled.

gcc/testsuite/ChangeLog:

PR target/96260
* gcc.target/riscv/pr91441.c: Update warning message.
* gcc.target/riscv/pr96260.c: New.

(cherry picked from commit 2ca1b6d009b194286c3ec91f9c51cc6b0a475458)

[Bug target/96260] [10/11 Regression] RISC-V: -fsanitize=kernel-address is not available after gcc10

[kito at gcc dot gnu.org]

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #6 from Kito Cheng  ---
Fixed on GCC 10 branch and trunk.

[Bug tree-optimization/96295] New: Wmaybe-uninitialized warning for range operator with empty range struct

[vries at gcc dot gnu.org]

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

Bug ID: 96295
   Summary: Wmaybe-uninitialized warning for range operator with
empty range struct
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider test-case tui-winsource.c (minimized from gdb sources, filed as gdb PR
https://sourceware.org/bugzilla/show_bug.cgi?id=26282):
...
struct tui_source_window_iterator
{
public:
  typedef tui_source_window_iterator self_type;
  typedef void *value_type;

  explicit tui_source_window_iterator (void *it, void *end) {}

  explicit tui_source_window_iterator (void *it) {}

  bool operator!= (const self_type &other) const { return false; }

  value_type operator* () const { return (value_type)0; }

  self_type &operator++ () { return *this; }
};

struct tui_source_windows
{
  tui_source_window_iterator begin () const
  {
return tui_source_window_iterator ((void *)0, (void *)0);
  }

  tui_source_window_iterator end () const
  {
return tui_source_window_iterator ((void*)0);
  }
};

void
foo (void)
{
  for (void *win : tui_source_windows ())
{
  (void)win;
}
}
...

With gcc-10, we have:
...
$ g++-10 -x c++  -Wall -O0 -g -c tui-winsource.c
...

And with gcc-11 (g++-11 (SUSE Linux) 11.0.0 20200720 (experimental) [revision
8764e9a3fc43f1117db77d1f056b6c3f15a29db3]):
...
$ g++-11 -x c++  -Wall -O0 -g -c tui-winsource.c
tui-winsource.c: In function ‘void foo()’:
tui-winsource.c:34:40: warning: ‘’ may be used uninitialized
[-Wmaybe-uninitialized]
   34 |   for (void *win : tui_source_windows ())
  |^
tui-winsource.c:20:30: note: by argument 1 of type ‘const tui_source_windows*’
to ‘tui_source_window_iterator tui_source_windows::begin() const’ declared here
   20 |   tui_source_window_iterator begin () const
  |  ^
tui-winsource.c:34:40: note: ‘’ declared here
   34 |   for (void *win : tui_source_windows ())
  |^
...

At gimple, we have:
...
struct tui_source_windows & __for_range;
struct tui_source_windows D.2465;

try
  {
__for_range = &D.2465;
tui_source_windows::begin (__for_range);
tui_source_windows::end (__for_range);
...

So, strictly speaking the warning is correct, because &D.2465 is not
initialized, and consequently __for_range is not initialized when it is passed
as argument to tui_source_windows::begin.

But it shouldn't matter, because struct tui_source_windows is an empty struct.

Workaround is to add:
...

 struct tui_source_windows
 {
+  tui_source_windows () {}

   tui_source_window_iterator begin () const
...
which gives us:
...
struct tui_source_windows & __for_range;
struct tui_source_windows D.2469;

try
  {
tui_source_windows::tui_source_windows (&D.2469);
__for_range = &D.2469;
tui_source_windows::begin (__for_range);
tui_source_windows::end (__for_range);
...

[Bug other/96296] New: libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]

[vries at gcc dot gnu.org]

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

Bug ID: 96296
   Summary: libiberty/dyn-string.c:280:3: warning: ‘strncpy’
output truncated before terminating nul copying as
many bytes from a string as its length
[-Wstringop-truncation]
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Reported and discussed earlier here:
https://gcc.gnu.org/legacy-ml/gcc/2019-03/msg00184.html ]

I ran into this warning in dyn-string.c:
...
$ gcc-11 src/libiberty/dyn-string.c -I src/include/ -c -DHAVE_STRING_H
-DHAVE_STDLIB_H  -Wall -O2
src/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
src/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated before
terminating nul copying as many bytes from a string as its length
[-Wstringop-truncation]
  280 |   strncpy (dest->s + pos, src, length);
  |   ^~~~
src/libiberty/dyn-string.c:272:16: note: length computed here
  272 |   int length = strlen (src);
  |^~~~
...

As mentioned here ( https://gcc.gnu.org/legacy-ml/gcc/2019-03/msg00199.html ):
"Using memcpy instead of strncpy would avoid the warning".

Tentative untested patch fixes the warning:
...
diff --git a/libiberty/dyn-string.c b/libiberty/dyn-string.c
index e10f691181a..bf155effb5f 100644
--- a/libiberty/dyn-string.c
+++ b/libiberty/dyn-string.c
@@ -277,7 +277,7 @@ dyn_string_insert_cstr (dyn_string_t dest, int pos, const
char *sr
c)
   for (i = dest->length; i >= pos; --i)
 dest->s[i + length] = dest->s[i];
   /* Splice in the new stuff.  */
-  strncpy (dest->s + pos, src, length);
+  memcpy (dest->s + pos, src, length);
   /* Compute the new length.  */
   dest->length += length;
   return 1;
...

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[bardeau at iram dot fr]

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

Sebastien Bardeau  changed:

   What|Removed |Added

 CC||bardeau at iram dot fr

--- Comment #7 from Sebastien Bardeau  ---
Created attachment 48919
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48919&action=edit
ICE in gfc_conv_scalarized_array_ref

Example code producing an ICE in gfc_conv_scalarized_array_ref

[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring

[bardeau at iram dot fr]

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

--- Comment #8 from Sebastien Bardeau  ---
I am experiencing an ICE looking pretty much the same as this one.

gfortran version and messages:

bardeau ~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/bardeau/Softs/gcc-10.1.0/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../srcdir/configure --with-gmp=/home/bardeau/Softs/gcc-deps
--prefix=/home/bardeau/Softs/gcc-10.1.0 --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 

bardeau ~> gfortran -c ice.f90 
ice.f90:21:0:

   21 | t = a(1)%c(1:l).eq.b%d(1:l)
  | 
internal compiler error: Segmentation fault
0xbaf7ff crash_signal
../../srcdir/gcc/toplev.c:328
0x6f8c06 gfc_conv_scalarized_array_ref
../../srcdir/gcc/fortran/trans-array.c:3490
0x6fb19c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../srcdir/gcc/fortran/trans-array.c:3641
0x7265ae gfc_conv_variable
../../srcdir/gcc/fortran/trans-expr.c:2827
0x7229ee gfc_conv_expr_op
../../srcdir/gcc/fortran/trans-expr.c:3620
0x7229ee gfc_conv_expr(gfc_se*, gfc_expr*)
../../srcdir/gcc/fortran/trans-expr.c:8672
0x72aebb gfc_trans_assignment_1
../../srcdir/gcc/fortran/trans-expr.c:10878
0x6f2933 trans_code
../../srcdir/gcc/fortran/trans.c:1864
0x71bb74 gfc_generate_function_code(gfc_namespace*)
../../srcdir/gcc/fortran/trans-decl.c:6835
0x6f63a1 gfc_generate_module_code(gfc_namespace*)
../../srcdir/gcc/fortran/trans.c:2264
0x6987b5 translate_all_program_units
../../srcdir/gcc/fortran/parse.c:6293
0x6987b5 gfc_parse_file()
../../srcdir/gcc/fortran/parse.c:6545
0x6efa7f gfc_be_parse_file
../../srcdir/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23
 Status|UNCONFIRMED |ASSIGNED

--- Comment #3 from Martin Liška  ---
Confirmed, working on that. Unfortunately it started with
r10-3542-g0b92cf305dcf3438.

[Bug target/96297] New: Redundant zero extension after inlining the function

[bina2374 at gmail dot com]

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

Bug ID: 96297
   Summary: Redundant zero extension after inlining the function
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bina2374 at gmail dot com
CC: kito at gcc dot gnu.org, wilson at gcc dot gnu.org
  Target Milestone: ---
Target: riscv32-unknown-elf

Command line: bin/riscv64-unknown-elf-gcc -march=rv32imafc -mabi=ilp32f -O3
call_is_digit.c -S

==
 C Source
==
unsigned char is_digit(unsigned char c) {
  return ((c >= '0') & (c <= '9')) ? 1 : 0;
}

int call_is_digit(unsigned char c) {
  if (is_digit(c))
return 0xa;
  else
return 0;
}

=
 GCC asm
=
is_digit:
addia0,a0,-48
sltiu   a0,a0,10
ret

call_is_digit:
addia0,a0,-48
andia0,a0,0xff  # redundant zero extension
li  a5,9
bleua0,a5,.L5
li  a0,0
ret
.L5:
li  a0,10
ret

The zero extension instruction in the function is_digit is eliminated in
combine pass, but it in the function call_is_digit can not be eliminated.

[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed. With checking enabled WPA is stuck staging from:

  r8-1894-g29f1e2b173f1701b(07 Jul 2017 13:28)(hubi...@ucw.cz): [took: 1.445s]
result: FAILED (124)
ipa-comdats.c: Remove optimize check from gate.


* ipa-comdats.c: Remove optimize check from gate.
* ipa-fnsummary.c (ipa_fn_summary_generate): do not generate summary
for functions not optimized.
(ipa_fn_summary_read): Skip optimize check.
(ipa_fn_summary_write): Likewise.
* ipa-inline-analysis.c (do_estimate_growth_1): Check that caller
is optimized.
* ipa-inline.c (can_inline_edge_p): Not optimized functions are
uninlinable.
(can_inline_edge_p): Check flag_pcc_struct_return for match.
(check_callers): Give up on caller which is not optimized.
(inline_small_functions): Likewise.
(ipa_inline): Do not give up when not optimizing.
* ipa-visbility.c (function_and_variable_visibility): Do not optimize
away unoptimizes cdtors.
(whole_program_function_and_variable_visibility): Do
ipa_discover_readonly_nonaddressable_vars in LTO mode.
* ipa.c (process_references): Do not check optimize.
(symbol_table::remove_unreachable_nodes): Update optimize check.
(set_writeonly_bit): Update optimize check.
(pass_ipa_cdtor_merge::gate): Do not check optimize.
(pass_ipa_single_use::gate): Remove.

[Bug tree-optimization/96245] Failure to optimize arithmetic pattern in switch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/96267] gcov-tool merge more coverage data error.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

[Bug ipa/96291] [10/11 Regression] -flto fails as "internal compiler error: Segmentation fault" during IPA pass: cp incall_for_symbol_thunks_and_aliases()

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Jambor  ---
I guess I should take a look

[Bug tree-optimization/96298] New: [11 Regression] wrong code with -O -fno-tree-forwprop

[zsojka at seznam dot cz]

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

Bug ID: 96298
   Summary: [11 Regression] wrong code with -O -fno-tree-forwprop
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: powerpc64-unknown-linux-gnu

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

Multiple targets are failing this testcase; x86_64-pc-linux-gnu doesn't fail.

$ powerpc64-unknown-linux-gnu-gcc -O -fno-tree-forwprop testcase.c -static
$ ./a.out 
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

$ powerpc64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64/bin/powerpc64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-2284-20200723104325-g02cada26e47-checking-yes-rtl-df-extra-powerpc64/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64-unknown-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
--with-sysroot=/usr/powerpc64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=powerpc64-unknown-linux-gnu
--with-ld=/usr/bin/powerpc64-unknown-linux-gnu-ld
--with-as=/usr/bin/powerpc64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-2284-20200723104325-g02cada26e47-checking-yes-rtl-df-extra-powerpc64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20200723 (experimental) (GCC)

[Bug gcov-profile/96035] directories created when writing gcov data have limited rights compared to umask

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:24c35a5ef3f88cf3c25c8bf17f9ff706e4286f53

commit r11-2285-g24c35a5ef3f88cf3c25c8bf17f9ff706e4286f53
Author: Martin Liska 
Date:   Fri Jul 10 10:56:34 2020 +0200

gcov: create folders with 0777.

libgcc/ChangeLog:

PR gcov-profile/96035
* libgcov-driver-system.c: Create gcov folders with 0777
so that it respects a system umask.

[Bug gcov-profile/96035] directories created when writing gcov data have limited rights compared to umask

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed, thank you Michael for the patch.

[Bug target/96263] [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1 since r10-4373-gc265dfbf748e

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|[10/11 Regression] ICE: in  |[10/11 Regression] ICE: in
   |lra_assign, at  |lra_assign, at
   |lra-assigns.c:1648 with -O  |lra-assigns.c:1648 with -O
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fnon-call-exceptions   |-fnon-call-exceptions
   |-msse4  |-msse4
   |--param=max-sched-ready-ins |--param=max-sched-ready-ins
   |ns=1|ns=1 since
   ||r10-4373-gc265dfbf748e9fc3

--- Comment #2 from Martin Liška  ---
Started with r10-4373-gc265dfbf748e9fc3.

[Bug target/96262] [11 Regression] ICE: in decompose, at rtl.h:2280 with -O -mavx512bw since r11-1411-gc7199fb6e694d1a0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
Summary|[11 Regression] ICE: in |[11 Regression] ICE: in
   |decompose, at rtl.h:2280|decompose, at rtl.h:2280
   |with -O -mavx512bw  |with -O -mavx512bw since
   ||r11-1411-gc7199fb6e694d1a0
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |crazylht at gmail dot 
com
 Ever confirmed|0   |1

[Bug debug/96261] -fcompare-debug failure (length) with -Os -fno-gcse-lm -fnon-call-exceptions

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(with -std=c++14).

[Bug debug/96261] -fcompare-debug failure (length) with -Os -fno-gcse-lm -fnon-call-exceptions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r5-5019-g27d93d2c8a36cea4.

[Bug fortran/96294] Compile error for pointer function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
read

F2008: A pointer function assignment is ambiguous if it is the first executable
statement after the specification block. Please add any other kind of
executable statement before it. FIXME

program a
IMPLICIT NONE
print *, "begin"
myfunc() = 311
print*,myfunc()

contains
FUNCTION myfunc() RESULT (result_ptr)
IMPLICIT NONE
INTEGER, POINTER :: result_ptr
INTEGER, SAVE, TARGET:: targ

result_ptr => targ
END FUNCTION myfunc
end program a

gives

 begin
 311

[Bug target/96206] internal compiler error: in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
I can't reproduce that with the current GCC 8 branch.
Can you please check 8.4.0 release?

[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Confirmed on ppc64le machine.

[Bug libstdc++/92285] Layout of istreambuf_iterator subobject depends on -std mode

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.3|10.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jonathan Wakely  ---
This was already fixed for 10.1, I just need to do some docs.

[Bug target/96263] [10/11 Regression] ICE: in lra_assign, at lra-assigns.c:1648 with -O -flive-range-shrinkage -fnon-call-exceptions -msse4 --param=max-sched-ready-insns=1 since r10-4373-gc265dfbf748e

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Biener  ---
veclower, esp. VEC_COND_EXPR lowering certainly makes a mess out of the
testcase
(doing component-wise rather than smaller-vector size operations).  Also
somehow doing odd things like

  _5 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e
.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_
6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4
_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6,
 e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
   f.68_7 = f;
-  r_74 = _5 & f.68_7;
+  _35 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4
_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6,
 e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.
4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6
, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
+  _38 = BIT_FIELD_REF <_35, 128, 0>;
+  _40 = BIT_FIELD_REF ;
+  _43 = _38 & _40;
+  _45 = {e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, 
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6,
e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6, e.4_6};
+  _85 = BIT_FIELD_REF <_45, 128, 128>;
+  _56 = BIT_FIELD_REF ;
+  _61 = _56 & _85;
...

that _35 is v64qi.  Eventually the removed folding made a smaller CTOR from it,
but re-emitting the CTOR makes no sense at all.  Luckily we clean that up
(I have no hopes for -O0 though).  We should make veclower behave more
sanely.

But the change probably just exposed a latent bug.

[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.3|---

--- Comment #17 from Jonathan Wakely  ---
Unsetting the milestone, any further changes will be on trunk only.

[Bug other/84889] Ideas on revamping how we format diagnostics

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
Dave, should we unset the milestone? Any further changes will only happen on
trunk not the gcc-10 branch, right?

[Bug other/89635] More ANSI SGR codes in diagnostics?

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|10.3|---

--- Comment #5 from Jonathan Wakely  ---
Unsetting the milestone.

[Bug fortran/96294] Compile error for pointer function

[peng.w...@compiler-dev.com]

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

--- Comment #2 from PengWang  ---
(In reply to Dominique d'Humieres from comment #1)
> read
> 
> F2008: A pointer function assignment is ambiguous if it is the first
> executable statement after the specification block. Please add any other
> kind of executable statement before it. FIXME
> 
> program a
> IMPLICIT NONE
> print *, "begin"
> myfunc() = 311
> print*,myfunc()
> 
> contains
> FUNCTION myfunc() RESULT (result_ptr)
> IMPLICIT NONE
> INTEGER, POINTER :: result_ptr
> INTEGER, SAVE, TARGET:: targ
> 
> result_ptr => targ
> END FUNCTION myfunc
> end program a
> 
> gives
> 
>  begin
>  311

Where is this explanation to be found, I have not seen it yet, maybe the
standard documents that I have are imcomplete, Can I have the download link of
your standard document? thank you very much!!!

[Bug tree-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|powerpc64-unknown-linux-gnu |powerpc64-unknown-linux-gnu
   ||, x86_64-*-*
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0

--- Comment #1 from Richard Biener  ---
On ppc64le I for example see

   [local count: 119292720]:
  a.0_1 = a;
  _13 = VIEW_CONVERT_EXPR(a.0_1);
  _6 = ~_13;
  _10 = _13 & 9187201950435737471;
  _12 = _6 & 9259542123273814144;
  _21 = _10 + 9187201950435737471;
  _22 = _21 ^ _12;
  _23 = VIEW_CONVERT_EXPR(_22);
  _28 = 9259542123273814144 - _10;
  _29 = _12 ^ _28;
  _30 = VIEW_CONVERT_EXPR(_29);
  _31 = VIEW_CONVERT_EXPR(_30);
  _32 = VIEW_CONVERT_EXPR(_23);
  _33 = _32 ^ _31;
  _34 = VIEW_CONVERT_EXPR(_33);
  x = _34;

likewise on x86_64 with -mno-sse where it fails as well.

[Bug tree-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
-fdisable-rtl-combine fixes it.  In the end it elides an xor, but it prints
many matches so not sure what goes on.  Likely an issue in some
simplify-rtx thing.

@@ -175,15 +1453,7 @@
 (expr_list:REG_EQUAL (plus:DI (reg:DI 85 [ _10 ])
 (const_int 9187201950435737471 [0x7f7f7f7f7f7f7f7f]))
 (nil)
-(insn 14 13 17 2 (parallel [
-(set (reg:DI 108)
-(xor:DI (reg:DI 106)
-(reg:DI 86 [ _12 ])))
-(clobber (reg:CC 17 flags))
-]) "t.c":8:18 521 {*xordi_1}
- (expr_list:REG_DEAD (reg:DI 106)
-(expr_list:REG_UNUSED (reg:CC 17 flags)
-(nil
+(note 14 13 17 2 NOTE_INSN_DELETED)
 (insn 17 14 18 2 (parallel [
 (set (reg:DI 110)
 (minus:DI (reg:DI 105)
@@ -199,22 +1469,22 @@
 (insn 18 17 20 2 (parallel [
 (set (reg:DI 112)
 (xor:DI (reg:DI 110)
-(reg:DI 86 [ _12 ])))
+(reg:DI 106)))
 (clobber (reg:CC 17 flags))
 ]) "t.c":8:25 521 {*xordi_1}
- (expr_list:REG_DEAD (reg:DI 110)
-(expr_list:REG_DEAD (reg:DI 86 [ _12 ])
-(expr_list:REG_UNUSED (reg:CC 17 flags)
+ (expr_list:REG_UNUSED (reg:CC 17 flags)
+(expr_list:REG_DEAD (reg:DI 106)
+(expr_list:REG_DEAD (reg:DI 110)
 (nil)
 (insn 20 18 21 2 (parallel [
 (set (reg:DI 114)
-(xor:DI (reg:DI 108)
-(reg:DI 112)))
+(xor:DI (reg:DI 112)
+(reg:DI 86 [ _12 ])))
 (clobber (reg:CC 17 flags))
 ]) "t.c":8:23 521 {*xordi_1}
- (expr_list:REG_DEAD (reg:DI 112)
-(expr_list:REG_DEAD (reg:DI 108)
-(expr_list:REG_UNUSED (reg:CC 17 flags)
+ (expr_list:REG_DEAD (reg:DI 86 [ _12 ])
+(expr_list:REG_UNUSED (reg:CC 17 flags)
+(expr_list:REG_DEAD (reg:DI 112)
 (nil)

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
It doesn't fail with 9.3 .

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
I'm gonna bisect that.

[Bug fortran/96294] Compile error for pointer function

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
See https://gcc.gnu.org/wiki/GFortranStandards.

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|10.3|---
 Status|WAITING |NEW

--- Comment #24 from David Malcolm  ---
Clearing the milestone field.  I think the only remaining things are (still):

> (In reply to David Malcolm from comment #0)
> [...]
> > * the diagnostic and the followup notes are grouped, so it's easier to pick
> > out what messages relate to what
> [...]
> > IIRC, clang does something where the left-hand column is only non-empty for
> > the start of a diagnostic; followup lines (e.g. due to line wrapping) are
> > indented by 1 char, so that the "wall of text" is broken up somewhat
> [...]

[Bug fortran/96294] Compile error for pointer function

[peng.w...@compiler-dev.com]

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

--- Comment #4 from PengWang  ---
(In reply to Dominique d'Humieres from comment #3)
> See https://gcc.gnu.org/wiki/GFortranStandards.

thanks a lot!!! ^_^

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Trying 17, 14 -> 18:
   17: r147:DI=r145:DI^r121:DI
  REG_DEAD r145:DI
  REG_DEAD r121:DI
   14: r144:DI=r142:DI^r121:DI
  REG_DEAD r142:DI
   18: r148:DI=r144:DI^r147:DI
  REG_DEAD r147:DI
  REG_DEAD r144:DI

(no other insn here not mentioned uses r144 or r147)

This could simplify to just r142^r145.  But we go completely wrong here,
instead:

Failed to match this instruction:
(set (reg:DI 148)
(xor:DI (xor:DI (reg:DI 145)
(reg:DI 142))
(reg:DI 121 [ _12 ])))
Successfully matched this instruction:
(set (reg:DI 147)
(xor:DI (reg:DI 145)
(reg:DI 142)))
Successfully matched this instruction:
(set (reg:DI 148)
(xor:DI (reg:DI 147)
(reg:DI 121 [ _12 ])))
allowing combination of insns 14, 17 and 18
original costs 4 + 4 + 4 = 12
replacement costs 4 + 4 = 8
deferring deletion of insn with uid = 14.
modifying insn i217: r147:DI=r145:DI^r142:DI
  REG_DEAD r142:DI
  REG_DEAD r145:DI
deferring rescan insn with uid = 17.
modifying insn i318: r148:DI=r147:DI^r121:DI
  REG_DEAD r121:DI
  REG_DEAD r147:DI
deferring rescan insn with uid = 18.


That sounds like simplify-rtx yes.

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

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Hey Göran.

I like both your suggestions for the documentation update. Can you please send
a patch to the gcc-patches mailing list?

[Bug gcov-profile/96267] gcov-tool merge more coverage data error.

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-2291-gde8bfcc8e45d9c77c48c9f071836698aa6db5ff3
Author: Dong JianQiang 
Date:   Wed Jul 22 01:24:52 2020 +0800

gcov-tool: Fix merging of different endian coverage data [PR96267]

2020-07-21  Dong JianQiang  

gcc/ChangeLog:

PR gcov-profile/96267
* gcov-io.c (gcov_open): enable if IN_GCOV_TOOL.

[Bug gcov-profile/96267] gcov-tool merge more coverage data error.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Thank you for the suggested patch, I've just installed it.

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Last reconfirmed|2020-06-03 00:00:00 |2020-07-23
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug target/96262] [11 Regression] ICE: in decompose, at rtl.h:2280 with -O -mavx512bw since r11-1411-gc7199fb6e694d1a0

[crazylht at gmail dot com]

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

--- Comment #3 from Hongtao.liu  ---
a patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550427.html

[Bug tree-optimization/96058] [10/11 Regression] ICE in c_getstr at gcc/fold-const.c:15475

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
@Martin: Can you please take a look?

[Bug target/96265] building nvptx-none on platforms other than x86_64-linux-gnu, e.g. aarch64-linux-gnu and powerpc64le-linux-gnu

[doko at debian dot org]

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

--- Comment #1 from Matthias Klose  ---
patch for the target hook posted at
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550534.html

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Started with r11-1715-g346bce6fe0cf1ed5f6a7ad732d2361d77b203c87.

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 CC||jamborm at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
It seems to me something related to IPA SRA.
@Martin: Can you please take a look?

[Bug c++/96299] New: Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

[gcc-bugzilla at mysko dot org]

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

Bug ID: 96299
   Summary: Defaulted operator <=> implicitly deleted when a
member has operator < and operator == and return type
is specified
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at mysko dot org
  Target Milestone: ---

The following sample fails to compile with GCC 10.1 and with trunk as of
2020-07-22.

===
#include 

struct Legacy
{
  bool operator==(Legacy const&) const;
  bool operator<(Legacy const&) const;
};

struct A
{
  std::strong_ordering operator <=> (A const& other) const = default;
  Legacy l;
};

int main()
{
  A a, b;

  return a < b;
}
===

With the following error:
: In function 'int main()':

:19:14: error: use of deleted function 'constexpr std::strong_ordering
A::operator<=>(const A&) const'

   19 |   return a < b;

  |  ^

:11:24: note: 'constexpr std::strong_ordering A::operator<=>(const A&)
const' is implicitly deleted because the default definition would be
ill-formed:

   11 |   std::strong_ordering operator <=> (A const& other) const = default;

  |^~~~

:11:24: error: no match for 'operator<=>' (operand types are 'Legacy'
and 'Legacy')


>From my understanding of p1186r3
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1186r3.html) the code
should be accepted. The GCC standards support table lists p1186r3 as
implemented in GCC 10. According to p1186r3, the defaulted operator <=> should
use the member's < and == operators if the return type is specified
(strong/weak/partial), and should not require a <=> operator for the member.

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Summary for node e/3:
  Returns value
  Descriptor for parameter 0:
(locally) unused
param_size_limit: 16, size_reached: 8, by_ref
* Access to unit offset: 0, unit size: 8, type: long int, alias_ptr_type:
long int *, certain

== IPA-SRA decisions ==

Evaluating analysis results for e/3
  Will remove return value.
  Will remove parameter 0

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[jamborm at gcc dot gnu.org]

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

--- Comment #6 from Martin Jambor  ---
(In reply to Martin Liška from comment #4)
> It seems to me something related to IPA SRA.
> @Martin: Can you please take a look?

I will but -fno-dce -fno-tree-dce strongly suggest this is a duplicate of PR
93385.

[Bug ipa/96235] Segmentation fault with "-Og -fno-dce -fno-tree-dce -finline-small-functions -fipa-sra"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93385

--- Comment #7 from Martin Liška  ---
(In reply to Martin Jambor from comment #6)
> (In reply to Martin Liška from comment #4)
> > It seems to me something related to IPA SRA.
> > @Martin: Can you please take a look?
> 
> I will but -fno-dce -fno-tree-dce strongly suggest this is a duplicate of PR
> 93385.

Thank you.

[Bug fortran/96224] -fdump-tree-original could use more sophisticated or mangled procedure names

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23

--- Comment #1 from Dominique d'Humieres  ---
Could you be more explicit about what you would like?

[Bug c++/52094] ICE on definition of nested class in wrong namespace scope with wrong nested-name-qualifier

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #8 from Marek Polacek  ---
Comment 2 testcase fixed with r11-175.

[Bug target/94065] AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

   Target Milestone|10.3|10.0
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Edelsohn  ---
Fixed in 10.1

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

[lavr at ncbi dot nlm.nih.gov]

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

--- Comment #2 from lavr at ncbi dot nlm.nih.gov ---
I don't want my structure to be aligned at the int boundary.  I want my
structure to reflect the actual data layout "byte","byte","short","int" as they
are laid out without any gaps, and "packed" guarantees such a disposition.  I
also don't want GCC issue warnings "just in case" where there's nothing
happening: like I said the "short int" field is located at the native "short
int" offset (multiple of 20, so there's no need for the warning; and so on with
the int field.  GCC should worry only if, for example, an int is placed at an
odd offset, or, for 4 byte ints, at an offset not multiple of 4.

[Bug c/96293] Extraneously noisy "taking address of packed member may result in an unaligned pointer value"

[lavr at ncbi dot nlm.nih.gov]

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

lavr at ncbi dot nlm.nih.gov changed:

   What|Removed |Added

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

--- Comment #3 from lavr at ncbi dot nlm.nih.gov ---
I don't want my structure to be aligned at the int boundary.  I want my
structure to reflect the actual data layout "byte","byte","short","int" as they
are laid out without any gaps, and "packed" guarantees such a disposition.  I
also don't want GCC issue warnings "just in case" where there's nothing
happening: like I said the "short int" field is located at the native "short
int" offset (multiple of 20, so there's no need for the warning; and so on with
the int field.  GCC should worry only if, for example, an int is placed at an
odd offset, or, for 4 byte ints, at an offset not multiple of 4.

[Bug tree-optimization/96295] [11 Regression] -Wmaybe-uninitialized warning for range operator with reference to an empty struct

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
Summary|Wmaybe-uninitialized|[11 Regression]
   |warning for range operator  |-Wmaybe-uninitialized
   |with empty range struct |warning for range operator
   ||with reference to an empty
   ||struct
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Last reconfirmed||2020-07-23
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning detects and avoids triggering for objects of empty
types but in the test case __for_range is a reference to such an object and the
logic doesn't consider those.  The tweak below makes the warning go away.  Let
me handle this.

diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 2f0ff724cde..fa88cad841c 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -401,6 +401,8 @@ maybe_warn_operand (ao_ref &ref, gimple *stmt, tree lhs,
tree rhs,
  The first_field() test is important for C++ where the predicate
  alone isn't always sufficient.  */
   tree rhstype = TREE_TYPE (rhs);
+  if (POINTER_TYPE_P (rhstype))
+rhstype = TREE_TYPE (rhstype);
   if (TYPE_EMPTY_P (rhstype)
   || (RECORD_OR_UNION_TYPE_P (rhstype)
  && (!first_field (rhstype)

[Bug c++/96278] three-way comparison operator comparison to 0: spurious nullptr warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
  Known to fail||10.2.0, 11.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23

--- Comment #3 from Martin Sebor  ---
Confirmed with today's top of trunk and GCC 10.2.

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

[vvinayag at arm dot com]

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

--- Comment #19 from vvinayag at arm dot com ---
Created attachment 48921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48921&action=edit
Add -std=c++11 to the aarch64 native build fix

This patch adds CXX="$CXX -std=c++11" to the patch provided for the aarch64
native build fix.

[Bug c++/95700] read-md.c: "missing sentinel in function call" when building gcc with musl

[vvinayag at arm dot com]

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

--- Comment #20 from vvinayag at arm dot com ---
(In reply to vvinayag from comment #18)
> (In reply to Ilya Leoshkevich from comment #17)
> > Created attachment 48917 [details]
> > aarch64 native build fix
> > 
> > Could you please try the attached patch? It fixed the issue for me, and
> > survived bootstrap/regtest on x86_64.
> 
> Hi Ilya,
> 
> I am testing this patch now. Will update when done.
> 
> Also, I was a bit incorrect when I mentioned that this is for building the
> compiler on an aarch64-none-linux-gnu machine. The build machine is actually
> x86_64.
> BUILD: x86_64/linux
> HOST: aarch64-none-linux-gnu
> TARGET: aarch64-none-linux-gnu
> Sorry for the confusion.

The patch did not fix the issue for me, unfortunately, because CXX_FOR_BUILD is
still set to 'g++'.
But to make it work, I added the line: CXX="$CXX -std=c++11", as shown in the
file I have attached.
With this additional line in both configure and configure.ac, CXX_FOR_BUILD is
set to 'g++ -std=c++11', and the build succeeded for me. However, I do not know
whether that is the right solution.

[Bug middle-end/96300] New: missing -Wuninitialized reading a struct member by a conditionally assigned pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 96300
   Summary: missing -Wuninitialized reading a struct member by a
conditionally assigned pointer
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Of the two functions below with uninitialized reads only the first bug is
detected.  The second one is not.  Both instances should trigger
-Wuninitialized.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-uninit=/dev/stdout z.c
int f (int i)
{
  int x, y, *p = i ? &x : &y;

  return *p;   // -Wuninitialized
}

struct S { int i; };

int g (int i)
{
  struct S x, y, *p = i ? &x : &y;

  return p->i;   // missing -Wuninitialized
}

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

z.c: In function ‘f’:
z.c:5:10: warning: ‘x’ is used uninitialized [-Wuninitialized]
5 |   return *p;   // -Wuninitialized
  |  ^~
f (int i)
{
  int y;
  int x;

   [local count: 1073741824]:
  return x_9(D);

}



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

g (int i)
{
  struct S y;
  struct S x;
  struct S * iftmp.1_1;
  int _4;

   [local count: 1073741824]:
  if (i_2(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  goto ; [100.00%]

   [local count: 536870912]:

   [local count: 1073741824]:
  # iftmp.1_1 = PHI <&x(3), &y(5)>
  _4 = iftmp.1_1->i;
  x ={v} {CLOBBER};
  y ={v} {CLOBBER};
  return _4;

}

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:3373a73172d0e39fe054ab2d4bbff746b36c0fe8

commit r10-8520-g3373a73172d0e39fe054ab2d4bbff746b36c0fe8
Author: Thomas Koenig 
Date:   Thu Jul 23 17:56:09 2020 +0200

Fix handling of implicit_pure by checking if non-pure procedures are
called.

Procedures are marked as implicit_pure if they fulfill the criteria of
pure procedures.  In this case, a procedure was not marked as not being
implicit_pure which called another procedure, which had not yet been
marked as not being implicit_impure.

Fixed by iterating over all procedures, setting callers of procedures
which are non-pure and non-implicit_pure as non-implicit_pure and
doing this until no more procedure has been changed.

Backport from trunk r11-2215-g3055d879edb1bc2a3923f92a5e681c8f6774fbc3 .

gcc/fortran/ChangeLog:

2020-07-10  Thomas Koenig  

PR fortran/96018
* frontend-passes.c (gfc_check_externals): Adjust formatting.
(implicit_pure_call): New function.
(implicit_pure_expr): New function.
(gfc_fix_implicit_pure): New function.
* gfortran.h (gfc_fix_implicit_pure): New prototype.
* parse.c (translate_all_program_units): Call
gfc_fix_implicit_pure.

[Bug middle-end/96300] missing -Wuninitialized reading a struct member by a conditionally assigned pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||24639

--- Comment #1 from Martin Sebor  ---
GCC returns zero from f() and expands the conditional and the uninitialized
load in g().  Clang optimizes both functions into just a return instruction
(leaving the result unspecified) without issuing a warning.  Its static
analyzer detects both bugs:

z.c:5:3: warning: Undefined or garbage value returned to caller
[core.uninitialized.UndefReturn]

  return *p;   // -Wuninitialized

  ^

z.c:14:3: warning: Undefined or garbage value returned to caller
[core.uninitialized.UndefReturn]

  return p->i;   // missing -Wuninitialized

  ^~~

2 warnings generated.

Compiler returned: 0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4

--- Comment #1 from Dominique d'Humieres  ---
> Select rank mishandles allocatable and pointer arguments when using bind(c) 
> with:

AFACT only when the arrays are not allocated.

[Bug fortran/96220] -fc-prototypes forgets types for doubles

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Thomas Kथà¤nig
:

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

commit r10-8521-g5b9f6489081520b7cb10d3ddfae6f010e0986314
Author: Thomas Koenig 
Date:   Sun Jul 19 17:27:45 2020 +0200

Always use name from c_interop_kinds_table for -fc-prototypes.

When a user specified a KIND that was a parameter taking the value
of an iso_c_binding KIND, the code used the name of that parameter
to look up the type name.  Corrected by always looking it up in
the table of C interop kinds (which was previously done for
non-C-interop types, anyway).

gcc/fortran/ChangeLog:

PR fortran/96220
* dump-parse-tree.c (get_c_type_name): Always use the entries from
c_interop_kinds_table to find the correct C type.

(cherry picked from commit 2e1b25350aa96b3f5678a056d0b55bb323c452d9)

[Bug fortran/94738] C descriptor passed to Fortran from C apepars to have wrong type information.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Dominique d'Humieres  ---
This seems fixed on trunk (GCC11) and

gcc version 10.1.1 20200717 [revision r10-8504-g8e6c87b2baee] (GCC).

[Bug fortran/94536] result keyword not working within module function interface in combination with a module procedure body

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-07-23
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Dominique d'Humieres  ---
This seems to be fixed since

gcc version 9.3.1 20200723  [revision r9-8756-g0a5be099c6f3p2] (GCC).

[Bug fortran/94048] ICE and other problems using rank intrinsic to set array size

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed since at least GCC7. My instrumented compiler gives

../../work/gcc/fortran/expr.c:3278:37: runtime error: index 15 out of bounds
for type 'gfc_expr *[15]'
../../work/gcc/fortran/expr.c:3280:35: runtime error: index 15 out of bounds
for type 'gfc_expr *[15]'
../../work/gcc/fortran/expr.c:3282:38: runtime error: index 15 out of bounds
for type 'gfc_expr *[15]'
=
==16543==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61704260 at pc 0x000100140461 bp 0x7ffeefbfe570 sp 0x7ffeefbfe568
READ of size 8 at 0x61704260 thread T0
#0 0x100140460 in check_references(gfc_ref*, bool (*)(gfc_expr*))
expr.c:3282
#1 0x100160c06 in check_restricted(gfc_expr*) expr.c:3394
#2 0x10016fc77 in restricted_args(gfc_actual_arglist*) expr.c:3157
#3 0x10016fd1c in restricted_intrinsic(gfc_expr*) expr.c:3245
#4 0x100160923 in check_restricted(gfc_expr*) expr.c:3356
#5 0x100160067 in gfc_specification_expr(gfc_expr*) expr.c:3497
#6 0x100017254 in resolve_array_bound(gfc_expr*, int) array.c:379
#7 0x10001e426 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:422
#8 0x10040013c in resolve_symbol(gfc_symbol*) resolve.c:15922
#9 0x1003f8ccd in resolve_symbol(gfc_symbol*) resolve.c:15334
#10 0x1004f2aa6 in do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) symbol.c:4170
#11 0x100511004 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4195
#12 0x100454636 in resolve_types(gfc_namespace*) resolve.c:17211
#13 0x1003f3e32 in gfc_resolve(gfc_namespace*) resolve.c:17326
#14 0x100375344 in gfc_parse_file() parse.c:6448
#15 0x10055baf3 in gfc_be_parse_file() f95-lang.c:212
#16 0x106bdcb9c in compile_file() toplev.c:458
#17 0x106bebc34 in do_compile() toplev.c:2307
#18 0x10a663058 in toplev::main(int, char**) toplev.c:2446
#19 0x10ac0eea4 in main main.c:39
#20 0x7fff6e3decc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)

0x61704260 is located 0 bytes to the right of 736-byte region
[0x61703f80,0x61704260)
allocated by thread T0 here:
#0 0x15bc6200f in wrap_calloc sanitizer_flags.h:38
#1 0x1098e04ca in xcalloc xmalloc.c:162
#2 0x100436be1 in resolve_actual_arglist(gfc_actual_arglist*,
procedure_type, bool) resolve.c:2069
#3 0x100413232 in resolve_function(gfc_expr*) resolve.c:3208
#4 0x100416423 in gfc_resolve_expr(gfc_expr*) resolve.c:7056
#5 0x100017234 in resolve_array_bound(gfc_expr*, int) array.c:378
#6 0x10001e426 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:422
#7 0x10040013c in resolve_symbol(gfc_symbol*) resolve.c:15922
#8 0x1003f8ccd in resolve_symbol(gfc_symbol*) resolve.c:15334
#9 0x1004f2aa6 in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4170
#10 0x100511004 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4195
#11 0x100454636 in resolve_types(gfc_namespace*) resolve.c:17211
#12 0x1003f3e32 in gfc_resolve(gfc_namespace*) resolve.c:17326
#13 0x100375344 in gfc_parse_file() parse.c:6448
#14 0x10055baf3 in gfc_be_parse_file() f95-lang.c:212
#15 0x106bdcb9c in compile_file() toplev.c:458
#16 0x106bebc34 in do_compile() toplev.c:2307
#17 0x10a663058 in toplev::main(int, char**) toplev.c:2446
#18 0x10ac0eea4 in main main.c:39
#19 0x7fff6e3decc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)

SUMMARY: AddressSanitizer: heap-buffer-overflow expr.c:3282 in
check_references(gfc_ref*, bool (*)(gfc_expr*))
Shadow bytes around the buggy address:
  0x1c2e07f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2e0800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2e0810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2e0820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c2e0830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1c2e0840: 00 00 00 00 00 00 00 00 00 00 00 00[fa]fa fa fa
  0x1c2e0850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2e0860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2e0870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2e0880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c2e0890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap regio

[Bug d/96301] New: d: internal compiler error: Segmentation fault during RTL pass: expand on armhf/armel/s390x

[ibuclaw at gdcproject dot org]

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

Bug ID: 96301
   Summary: d: internal compiler error: Segmentation fault during
RTL pass: expand on armhf/armel/s390x
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Seen here https://buildd.debian.org/status/package.php?p=gtk-d&suite=sid

Reduced test, accommodating for struct and static array returns as well.

Compile with '-frelease -fPIC -O2' or '-O2 -fno-assert' to trigger
---
version (Struct)
{
struct Type
{
size_t length;
int* ptr;
}
}
else version (Array)
{
alias Type = int[100];
]
else
{
alias Type = int[];
}

class Container
{
Type children;

void remove(void* data)
{
Type remove(Type range)
{
auto result = range;
if (result.front)
return result;
assert(0);
}
if (data)
remove(children);
}
}

int front(Type a)
{
return a.ptr[0];
}

[Bug d/96301] d: internal compiler error: Segmentation fault during RTL pass: expand on armhf/armel/s390x

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw  ---
The static array path has a different ICE, but the underlying cause is the
same.

test.d:20:18: internal compiler error: in convert_memory_address_addr_space_1,
at explow.c:302
   20 | auto result = range;
  |  ^
0x5f8abc convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.c:302
0x5f8b2f convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.c:405
0x5f8b2f convert_memory_address_addr_space(scalar_int_mode, rtx_def*, unsigned
char)
../../gcc/explow.c:404
0x5f8b2f memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
../../gcc/explow.c:418
0x8f8171 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10462
0x902578 expand_expr
../../gcc/expr.h:282
0x902578 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5158
0x902578 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5056
0x7ff7a0 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3749
0x7ff7a0 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0x804aff expand_gimple_basic_block
../../gcc/cfgexpand.c:5888
0x806f16 execute
../../gcc/cfgexpand.c:6543

[Bug fortran/93690] Type Bound Generic Assignment Bug Using Intrinsic Assignments

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-07-23
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
It works if assignMe is ELEMENTAL IMPURE.

[Bug c++/68828] [concepts] ICE in fold with requires and function call around parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-23
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Compiles fine since r278449 which came without a test, so let's add this one.

[Bug c++/68828] [concepts] ICE in fold with requires and function call around parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
*** Bug 68827 has been marked as a duplicate of this bug. ***

[Bug c++/68827] [concepts] ICE in fold where requires parameter shadows function argument

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Also compiles fine since r278449.

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

[Bug c++/67491] [meta-bug] concepts issues

[mpolacek at gcc dot gnu.org]

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

Bug 68827 Summary: [concepts] ICE in fold where requires parameter shadows 
function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68827

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug target/94065] AIX rs6000 NO_SUM_IN_TOC and NO_FP_IN_TOC disable logic reversed in aix config files

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8759-geb0a835d643394d89b13d4f0ac12f2af3e78228d
Author: David Edelsohn 
Date:   Thu Mar 5 20:41:08 2020 -0500

rs6000: Correct logic to disable NO_SUM_IN_TOC and NO_FP_IN_TOC [PR94065]

aix61.h, aix71.h and aix72.h intends to prevent SUM_IN_TOC and FP_IN_TOC
when cmodel=large.  This patch defines the variables associated with the
target options to 1 to _enable_ NO_SUM_IN_TOC and enable NO_FP_IN_TOC.

Bootstrapped on powerpc-ibm-aix7.2.0.0

2020-03-06  David Edelsohn  
PR target/94065
* config/rs6000/aix61.h (TARGET_NO_SUM_IN_TOC): Set to 1 for
cmodel=large.
(TARGET_NO_FP_IN_TOC): Same.
* config/rs6000/aix71.h: Same.
* config/rs6000/aix72.h: Same.

(cherry picked from commit 3dcf51ad7b0a9cacba1a056755c16cc1cf7984ee)

[Bug c++/68826] [concepts] ICE in fold expression with requires

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Also compiles fine since r278449.

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

[Bug c++/68828] [concepts] ICE in fold with requires and function call around parameters

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
*** Bug 68826 has been marked as a duplicate of this bug. ***

[Bug c++/67491] [meta-bug] concepts issues

[mpolacek at gcc dot gnu.org]

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

Bug 68826 Summary: [concepts] ICE in fold expression with requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68826

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|segher at gcc dot gnu.org  |sayle at gcc dot gnu.org

--- Comment #7 from Segher Boessenkool  ---
Roger has a fix, reassigning.

[Bug target/96236] __builtin_mma_disassemble_acc() doesn't store elements correctly in LE mode

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:5497677b497b95a261089d19f5295cc80f99a2b6

commit r10-8522-g5497677b497b95a261089d19f5295cc80f99a2b6
Author: Peter Bergner 
Date:   Wed Jul 22 11:44:35 2020 -0500

rs6000: __builtin_mma_disassemble_acc() doesn't store elements correctly in
LE mode

PR96236 shows a problem where we don't correctly store our 512-bit
accumulators
correctly in little-endian mode.  The patch below detects when we're doing
a
little-endian memory access and stores to the correct memory locations.

2020-07-22  Peter Bergner  

gcc/
PR target/96236
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin):
Handle
little-endian memory ordering.

gcc/testsuite/
PR target/96236
* gcc.target/powerpc/mma-double-test.c: Update storing results for
correct little-endian ordering.
* gcc.target/powerpc/mma-single-test.c: Likewise.

(cherry picked from commit ae575662833d70cb7d74b9538096c7becc79af14)

[Bug c++/35098] ICE with attribute unused in template

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
This got fixed by r10-7998.

[Bug target/95750] [x86] Use dummy atomic insn instead of mfence in __atomic_thread_fence(seq_cst)

[josephcsible at gmail dot com]

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

Joseph C. Sible  changed:

   What|Removed |Added

 CC||josephcsible at gmail dot com

--- Comment #14 from Joseph C. Sible  ---
I notice this change affects -Os too, even though "lock orq $0,(%rsp)" is 6
bytes and "mfence" is only 3 bytes.

[Bug c++/56673] multi-versioning not GC safe

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
Got fixed by r204039.  Probably not worth adding the test.

[Bug fortran/96220] -fc-prototypes forgets types for doubles

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:159c7ca3c3ce34e401b9e57734ecca8b37d8a0ec

commit r9-8760-g159c7ca3c3ce34e401b9e57734ecca8b37d8a0ec
Author: Thomas Koenig 
Date:   Sun Jul 19 17:27:45 2020 +0200

Always use name from c_interop_kinds_table for -fc-prototypes.

When a user specified a KIND that was a parameter taking the value
of an iso_c_binding KIND, the code used the name of that parameter
to look up the type name.  Corrected by always looking it up in
the table of C interop kinds (which was previously done for
non-C-interop types, anyway).

gcc/fortran/ChangeLog:

PR fortran/96220
* dump-parse-tree.c (get_c_type_name): Always use the entries from
c_interop_kinds_table to find the correct C type.

(cherry picked from commit 2e1b25350aa96b3f5678a056d0b55bb323c452d9)

[Bug c++/79367] ICE with decltype of VLA in lambda

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-checking,   |rejects-valid
   |ice-on-valid-code   |
 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Since r10-6389 we no longer crash but issue an error:

79367.C: In lambda function:
79367.C:6:22: error: ‘c’ declared as reference but not initialized
6 |   [&] { decltype (b) c; } ();
  |  ^

[Bug rtl-optimization/96298] [11 Regression] wrong code with -O -fno-tree-forwprop

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

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

commit r11-2296-gd4b3ea941b1a15cadb79e7ff8a36891131f8804b
Author: Roger Sayle 
Date:   Thu Jul 23 18:48:54 2020 +0100

Resolve regression rtl-optimization/96298.  Sorry for the breakage.

2020-07-23  Roger Sayle  

gcc/ChangeLog
PR rtl-optimization/96298
* simplify-rtx.c (simplify_binary_operation_1) [XOR]: Xor doesn't
distribute over xor, so (a^b)^(c^b) is not the same as (a^c)^b.

[Bug ada/96302] New: Linux build of gnat/ada fails for lack of gnatdll

[andy.riebs at hpe dot com]

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

Bug ID: 96302
   Summary: Linux build of gnat/ada fails for lack of gnatdll
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andy.riebs at hpe dot com
  Target Milestone: ---

In a build with gnat on a Linux system (CentOS 7.x on amd64/x86_64, in my
case), the attempt to install gnatdll results in an error.

For non-Windows users, my work-around for this is

--- gcc/ada/gcc-interface/Make-lang.in.orig 2020-07-22 15:52:11.939013857
-0400
+++ gcc/ada/gcc-interface/Make-lang.in  2020-07-22 15:53:12.665368912 -0400
@@ -838,8 +838,8 @@
  $(INSTALL_PROGRAM) $$tool$(exeext)
$(DESTDIR)$(bindir)/$$install_name; \
fi ; \
  done; \
- $(RM) $(DESTDIR)$(bindir)/gnatdll$(exeext); \
- $(INSTALL_PROGRAM) gnatdll$(exeext)
$(DESTDIR)$(bindir)/gnatdll$(exeext); \
+#$(RM) $(DESTDIR)$(bindir)/gnatdll$(exeext); \
+#$(INSTALL_PROGRAM) gnatdll$(exeext)
$(DESTDIR)$(bindir)/gnatdll$(exeext); \
fi

[Bug c++/87765] Internal compiler error: coerce_template_parms (8.2) or cxx_eval_constant_expression (trunk)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #5 from Marek Polacek  ---
Since r10-6416 the test in Comment 4 no longer ICEs:

87765.C: In function ‘constexpr void t(X)’:
87765.C:3:51: error: call to non-‘constexpr’ function ‘int X::s()’
3 | template static constexpr void t(X x) { Y v;}
  |~~~^~
87765.C:3:51: note: in template argument for type ‘int’

The original test, however, still ICEs.

[Bug fortran/96220] -fc-prototypes forgets types for doubles

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
A backport to gcc 8 would require hand intervention, which I do not
think is worth it.

Hence, closing.

[Bug c++/87032] incorrect nested structure with union initialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-07-23
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Fixed by r269371.

[Bug c++/90301] RangeV3 usage, ICE internal compiler error: canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
No preprocessed source provided, assuming fixed then.

[Bug c++/89871] Wall + designated initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Test added.

[Bug c++/90623] compilation error with fold expression and parameter pack

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
This compiles fine since r273944.

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Thomas Kथà¤nig
:

https://gcc.gnu.org/g:7be5add5534f4310b294f1b7ad8855a424edb8c1

commit r9-8761-g7be5add5534f4310b294f1b7ad8855a424edb8c1
Author: Thomas Koenig 
Date:   Thu Jul 23 20:26:10 2020 +0200

Fix handling of implicit_pure by checking if non-pure procedures are
called.

Procedures are marked as implicit_pure if they fulfill the criteria of
pure procedures.  In this case, a procedure was not marked as not being
implicit_pure which called another procedure, which had not yet been
marked as not being implicit_impure.

Fixed by iterating over all procedures, setting callers of procedures
which are non-pure and non-implicit_pure as non-implicit_pure and
doing this until no more procedure has been changed.

Backport from trunk r11-2215-g3055d879edb1bc2a3923f92a5e681c8f6774fbc3 .

gcc/fortran/ChangeLog:

2020-07-10  Thomas Koenig  

PR fortran/96018
* frontend-passes.c (gfc_check_externals): Adjust formatting.
(implicit_pure_call): New function.
(implicit_pure_expr): New function.
(gfc_fix_implicit_pure): New function.
* gfortran.h (gfc_fix_implicit_pure): New prototype.
* parse.c (translate_all_program_units): Call
gfc_fix_implicit_pure.

[Bug fortran/96018] [9/10/11 Regression] Optimization issue with external HDF5 library

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #19 from Thomas Koenig  ---
Fixed on all affected branches, closing.

Thanks a lot for the bug report!

[Bug fortran/96224] -fdump-tree-original could use more sophisticated or mangled procedure names

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Could you be more explicit about what you would like?

How about:

mod::init ()

or

mod.init ()

to indicate the relevant namespace.