[Bug tree-optimization/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #1 from Martin Liška  ---
*** Bug 95628 has been marked as a duplicate of this bug. ***

[Bug bootstrap/95628] [11 regression] ICE in gcc build after r11-1181

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/95633] New: [11 regression] ICEs since r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0

[clyon at gcc dot gnu.org]

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

Bug ID: 95633
   Summary: [11 regression] ICEs since
r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

I've noticed regressions since
r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0:

on aarch64:
FAIL: gcc.target/aarch64/sve/clastb_5.c -march=armv8.2-a+sve (internal compiler
error)
FAIL: gcc.target/aarch64/sve/clastb_5.c -march=armv8.2-a+sve (test for excess
errors)
Excess errors:
during GIMPLE pass: vect
dump file: clastb_5.c.163t.vect
/gcc/testsuite/gcc.target/aarch64/sve/clastb_2.c:15:1: internal compiler error:
in operator[], at vec.h:867
0x649e5a vec::operator[](unsigned int)
/gcc/vec.h:867
0x649e5a vec::operator[](unsigned int)
/gcc/vec.h:1433
0x104773d vec::operator[](unsigned int)
/gcc/vec.h:998
0x104773d vectorizable_condition
/gcc/tree-vect-stmts.c:9986
0x105df8e vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/gcc/tree-vect-stmts.c:10735
0x1060fa7 vect_transform_loop_stmt
/gcc/tree-vect-loop.c:8310
0x1078f61 vect_transform_loop(_loop_vec_info*, gimple*)
/gcc/tree-vect-loop.c:8711
0x109eccc try_vectorize_loop_1
/gcc/tree-vectorizer.c:991
0x109f7a9 vectorize_loops()
/gcc/tree-vectorizer.c:1128




on arm-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp1:
FAIL: gcc.dg/pr86179.c (internal compiler error)
FAIL: gcc.dg/pr86179.c (test for excess errors)
Excess errors:
during GIMPLE pass: vect
/gcc/testsuite/gcc.dg/pr86179.c:7:6: internal compiler error: in operator[], at
vec.h:867
0xfba61e vec::operator[](unsigned int)
/gcc/vec.h:867
0xfba61e vec::operator[](unsigned int)
/gcc/vec.h:1433
0xfba61e vect_create_vectorized_promotion_stmts
/gcc/tree-vect-stmts.c:4466
0xfba61e vectorizable_conversion
/gcc/tree-vect-stmts.c:4934
0xfd9906 vect_transform_stmt(vec_info*, _stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
/gcc/tree-vect-stmts.c:10680
0x100912d vect_schedule_slp_instance
/gcc/tree-vect-slp.c:4052
0x100900f vect_schedule_slp_instance
/gcc/tree-vect-slp.c:3953
0x100900f vect_schedule_slp_instance
/gcc/tree-vect-slp.c:3953
0x100900f vect_schedule_slp_instance
/gcc/tree-vect-slp.c:3953
0x100900f vect_schedule_slp_instance
/gcc/tree-vect-slp.c:3953
0x100900f vect_schedule_slp_instance
/gcc/tree-vect-slp.c:3953
0x1010774 vect_schedule_slp(vec_info*)
/gcc/tree-vect-slp.c:4167
0xff34d2 vect_transform_loop(_loop_vec_info*, gimple*)
/gcc/tree-vect-loop.c:8623
0x10188aa try_vectorize_loop_1
/gcc/tree-vectorizer.c:991
0x1019349 vectorize_loops()
/gcc/tree-vectorizer.c:1128

[Bug sanitizer/95634] New: [11 Regression] ICE in output_operand: invalid address mode

[marxin at gcc dot gnu.org]

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

Bug ID: 95634
   Summary: [11 Regression] ICE in output_operand: invalid address
mode
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

The following fails:

$ /xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/pr38048-1.c
-mabi=ilp32 -fsanitize=address -c -S -fdump-rtl-all
during RTL pass: final
dump file: pr38048-1.c.320r.final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/pr38048-1.c:
In function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/pr38048-1.c:14:1:
internal compiler error: output_operand: invalid address mode
   14 | }
  | ^
0xc65336 output_operand_lossage(char const*, ...)
/home/marxin/Programming/gcc/gcc/final.c:3609
0x15a4dfd aarch64_print_address_internal
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:10464
0x15a5546 aarch64_print_operand_address
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:10568
0xc65553 output_address(machine_mode, rtx_def*)
/home/marxin/Programming/gcc/gcc/final.c:4067
0x15a4601 aarch64_print_operand
/home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:10250
0xc654b1 output_operand(rtx_def*, int)
/home/marxin/Programming/gcc/gcc/final.c:4051
0xc65efc output_asm_insn(char const*, rtx_def**)
/home/marxin/Programming/gcc/gcc/final.c:3963
0xc69dc3 output_asm_insn(char const*, rtx_def**)
/home/marxin/Programming/gcc/gcc/final.c:3840
0xc69dc3 final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.c:3106
0xc6a0bb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.c:3152
0xc6a1c6 final_1
/home/marxin/Programming/gcc/gcc/final.c:2020
0xc6adb4 rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.c:4658
0xc6adb4 execute
/home/marxin/Programming/gcc/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/95634] [11 Regression] ICE in output_operand: invalid address mode

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Started with my g:8b6731e674c76cb48a417f2eef74ced92a17f469.

[Bug sanitizer/95634] [11 Regression] ICE in output_operand: invalid address mode

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Most likely a ptr_mode vs Pmode issue.

[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas

[bruck.michael at gmail dot com]

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

Michael Bruck  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Michael Bruck  ---
Yes. Also std::is_lambda_closure<> or an equivalent facility seems to be
missing from the std.

[Bug tree-optimization/95633] [11 regression] ICEs since r11-1143-gb05d5563f4be13b4a0d0951375a82adf483973c0

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug sanitizer/95634] [11 Regression] ICE in output_operand: invalid address mode

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Andrew Pinski from comment #2)
> Most likely a ptr_mode vs Pmode issue.

Yep, I've got a working patch for it..

[Bug ipa/93429] Missed IPA-CP on by-ref argument directly passed through from caller

[fxue at gcc dot gnu.org]

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

fxue at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from fxue at gcc dot gnu.org ---
Fixed.

[Bug c/95635] New: -Warray-bounds falsely claims out-of-bounds access

[gccbugs at dima dot secretsauce.net]

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

Bug ID: 95635
   Summary: -Warray-bounds falsely claims out-of-bounds access
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugs at dima dot secretsauce.net
  Target Milestone: ---

Created attachment 48716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48716&action=edit
Bug demo

Hi. I'm running gcc-10 from Debian:

  dima@shorty:~$ gcc-10 --version
  gcc-10 (Debian 10.1.0-3) 10.1.0

I'm building the attached source like this:

  gcc-10 -Warray-bounds -O2 -c -o /dev/null tst.c

And I get this:

tst.c: In function 'a':
tst.c:12:27: warning: array subscript  is outside array bounds of
'int[0]' [-Warray-bounds]
   12 | if(L[i] > 0 && arr[L[i]] )
  |~~~^~
tst.c:8:9: note: while referencing 'arr'
8 | int arr[0];
  | ^~~
tst.c:12:27: warning: array subscript  is outside array bounds of
'int[0]' [-Warray-bounds]
   12 | if(L[i] > 0 && arr[L[i]] )
  |~~~^~
tst.c:8:9: note: while referencing 'arr'
8 | int arr[0];


The array arr[] has 0 elements, and gcc is telling me I'm accessing outside of
those bounds. But L[i]>0 is always false, so we'll never actually look at
arr[anything]. gcc knows this most of the time. If I remove the -O2 or the b()
call or lots of little unrelated-looking things, the issue goes away. Thanks.

[Bug target/95488] Suboptimal multiplication codegen for v16qi

[crazylht at gmail dot com]

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

--- Comment #5 from Hongtao.liu  ---
Microbenchmark

cat test.c

#include 
#include 
#include 

typedef char  v16qi  __attribute__ ((vector_size (16)));
extern v16qi interleave_mul (v16qi, v16qi);
extern v16qi extend_mul (v16qi, v16qi);

#define LOOP 3000


int
main ()
{
  int i;
  unsigned long long start, end;
  unsigned long long diff;
  unsigned int aux;
  v16qi *p0;
  v16qi *p1;
  v16qi x, y;

  p0 = (v16qi *) malloc (LOOP *  sizeof (*p0));
  p1 = (v16qi *) malloc (LOOP *  sizeof (*p1));
  for (i = 0; i < LOOP; i++)
for (int j = 0; j != 16; j++)
{
  p0[i][j] = 1 + i + j;
  p1[i][j] = 1 + i * i + j * j;
}

#if 1
  start = __rdtscp (&aux);
  for (i = 0; i < LOOP; i+=16)
y = interleave_mul (p0[i], p1[i]);
  end = __rdtscp (&aux);
  diff = end - start;

  printf ("interleave_mul : %lld\n", diff);

#endif

#if 1
  start = __rdtscp (&aux);
  for (i = 0; i < LOOP; i+=16)
x = extend_mul (p0[i], p1[i]);
  end = __rdtscp (&aux);
  diff = end - start;

  printf ("extend_mul :%lld\n", diff);
#endif

  free (p0);
  free (p1);

  return 0;
}
---
show a little bit improvement:

interleave_mul : 10418
extend_mul :103922083

[Bug target/95524] Subtimal codegen for shift by constant for v16qi/v32qi under -march=skylake

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
Microbenchmark show

interleave_ashiftrt : 69023847
magic_ashiftrt :  62488066

Seems 10% improvement.

[Bug c/95635] -Warray-bounds falsely claims out-of-bounds access

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Known to work||9.3.0
   Last reconfirmed||2020-06-11
 Ever confirmed|0   |1
  Known to fail||10.1.0, 11.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-4390-g8299dfae93644680.

[Bug target/95636] New: ICE in sched2: internal compiler error: in create_block_for_bookkeeping, at sel-sched.c:4549

[qianchao9 at huawei dot com]

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

Bug ID: 95636
   Summary: ICE in sched2: internal compiler error: in
create_block_for_bookkeeping, at sel-sched.c:4549
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qianchao9 at huawei dot com
  Target Milestone: ---

There exists a ICE on AArch64 when using GCC11.

Compiling this with -fsel-sched-pipelining -fselective-scheduling2
-fvar-tracking-assignments -Os:

typedef long unsigned int size_t;
extern volatile int  chk_calls;
volatile char *s2 = "defg";
volatile size_t l1 = 1;
long buf1[64];
char *buf2 = (char *) (buf1 + 32);

void
__attribute__((noinline))
test3 (void)
{
  struct A { char buf1[10]; char buf2[10]; } a;
  char *r; 
  char buf3[20];
  int i;
  r = buf3;
  for (i = 0; i < 2; ++i)
{
  if (i == l1 + 1)
 r = &a.buf1[1];
  else if (i == l1)
 r = &a.buf2[7];
  else if (i == l1 + 1)
 r = &buf3[5];
  else if (i == l1 + 2)
 r = &a.buf1[9];
}
  __builtin___memcpy_chk (r, s2, l1, __builtin_object_size (r, 0));
  if (chk_calls != 5){
abort ();
  }
}

gives:

during RTL pass: sched2
testcase.c:32:1: internal compiler error: in create_block_for_bookkeeping, at
sel-sched.c:4549
   32 | }
  | ^
0xd4e55b create_block_for_bookkeeping
../../gcc/sel-sched.c:4549
0xd4e55b find_place_for_bookkeeping
../../gcc/sel-sched.c:4686
0xd4e55b generate_bookkeeping_insn
../../gcc/sel-sched.c:4786
0xd4e55b move_op_at_first_insn
../../gcc/sel-sched.c:6063
0xd4eca7 code_motion_path_driver
../../gcc/sel-sched.c:6657
0xd4f123 code_motion_process_successors
../../gcc/sel-sched.c:6342
0xd4f123 code_motion_path_driver
../../gcc/sel-sched.c:6608
0xd4f123 code_motion_process_successors
../../gcc/sel-sched.c:6342
0xd4f123 code_motion_path_driver
../../gcc/sel-sched.c:6608
0xd4f123 code_motion_process_successors
../../gcc/sel-sched.c:6342
0xd4f123 code_motion_path_driver
../../gcc/sel-sched.c:6608
0xd4fd4b move_op
../../gcc/sel-sched.c:6702
0xd4fd4b move_exprs_to_boundary
../../gcc/sel-sched.c:5223
0xd4fd4b schedule_expr_on_boundary
../../gcc/sel-sched.c:5436
0xd53af7 fill_insns
../../gcc/sel-sched.c:5578
0xd55713 schedule_on_fences
../../gcc/sel-sched.c:7353
0xd55713 sel_sched_region_2
../../gcc/sel-sched.c:7491
0xd56743 sel_sched_region_1
../../gcc/sel-sched.c:7533
0xd57bf7 sel_sched_region(int)
../../gcc/sel-sched.c:7634
0xd5855f run_selective_scheduling()
../../gcc/sel-sched.c:7720


during sched2 pass, we get bb:

(code_label 181 191 180 15 11 (nil) [2 uses])
(note 180 181 194 15 [bb 15] NOTE_INSN_BASIC_BLOCK)
(debug_insn 194 180 193 15 (var_location:SI i (plus:SI (reg:SI 1 x1 [orig:103
ivtmp.11 ] [103])
(const_int 1 [0x1]))) -1
 (nil))

gcc/cfgrtl.c (rtl_split_block) tries to splits that bb to 

(code_label 181 191 180 15 11 (nil) [2 uses])
(note 180 181 205 15 [bb 15] NOTE_INSN_BASIC_BLOCK)

and new_bb:

(note 205 180 194 20 [bb 20] NOTE_INSN_BASIC_BLOCK)
(debug_insn 194 205 204 20 (var_location:SI i (plus:SI (reg:SI 1 x1 [orig:103
ivtmp.11 ] [103])
(const_int 1 [0x1]))) -1
 (nil))
(note 204 194 193 20 NOTE_INSN_DELETED)

Although new_bb contained only debug insns, we will swap the block numbers of
new_bb and single_succ(new_bb). So NOTE_INSN_DELETED note emited by
gcc/cfgrtl.c (rtl_split_block) is unnecessary here.

the following fixes the latent bug - we delete new_bb's NOTE_INSN_DELETED note

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 80687fb5359..6dece11bf0c 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -9158,7 +9158,12 @@ sched_split_block_1 (basic_block first_bb, rtx after)
   /* sched_split_block emits note if *check == BB_END.  Probably it
  is better to rip that note off.  */

-  return e->dest;
+  basic_block new_bb = e->dest;
+  rtx_insn *last_insn = BB_END (e->dest);
+  if (NOTE_P (last_insn) && NOTE_KIND (last_insn) == NOTE_INSN_DELETED)
+delete_insn (last_insn);
+
+  return new_bb;
 }


Bootstrap and tested on aarch64 platform. No new regression witnessed. 

Any suggestions?

[Bug sanitizer/95634] [11 Regression] ICE in output_operand: invalid address mode

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug sanitizer/95634] [11 Regression] ICE in output_operand: invalid address mode

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1197-g8cff672cb9a132d3d3158c2edfc9a64b55292b80
Author: Martin Liska 
Date:   Thu Jun 11 09:34:41 2020 +0200

asan: fix RTX emission for ilp32

gcc/ChangeLog:

PR sanitizer/95634
* asan.c (asan_emit_stack_protection): Fix emission for ilp32
by using Pmode instead of ptr_mode.

Co-Authored-By: Jakub Jelinek 

[Bug c++/95626] [concepts] incorrect ambiguous overload with constraints "A && !B" vs "!B"

[godeffroy.valet at m4x dot org]

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

--- Comment #2 from Godeffroy Valet  ---
Oh, ok, thank you for the information. Strange rule...

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #33 from Martin Liška  ---
> 
> The profile directory generated by the new executable compiled with this
> patch was 112G  in size, a lot smaller than previous 1TB. 

That's quite a promising reduction.

> Though still bigger than what ICC generated.

Yep, but we should be only 2x bigger right now?

Can you please test the parallel merging script? I can merge 10GB gcov files
(5000 runs with 264 files each) in about 50s.

[Bug tree-optimization/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On June 10, 2020 9:54:39 PM GMT+02:00, "marxin at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95627
>
>Bug ID: 95627
>   Summary: [11 Regression] ICE in rs6000_density_test at
>rs6000.c:4992 since
>r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1
>   Product: gcc
>   Version: 11.0
>Status: UNCONFIRMED
>  Keywords: ice-on-valid-code
>  Severity: normal
>  Priority: P3
> Component: tree-optimization
>  Assignee: unassigned at gcc dot gnu.org
>  Reporter: marxin at gcc dot gnu.org
>CC: rguenth at gcc dot gnu.org
>  Target Milestone: ---
>  Host: x86_64-linux-gnu
>Target: ppc64le-linux-gnu
>
>Since the revision I see:
>
>$ ./xgcc -B.
>/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c
>-fvar-tracking-assignments-toggle -ftree-loop-vectorize -O2
>during GIMPLE pass: vect
>/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c:
>In function ‘ff_pred8x8_plane_c’:
>/home/mliska/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20070520-1.c:4:6:
>internal compiler error: Segmentation fault
>4 | void ff_pred8x8_plane_c(uint8_t *src, int stride){
>  |  ^~
>0xe7e38f crash_signal
>../../gcc/toplev.c:328
>0x1259ce4 rs6000_density_test
>../../gcc/config/rs6000/rs6000.c:4992
>0x125a00c rs6000_finish_cost
>../../gcc/config/rs6000/rs6000.c:5102
>0x1150170 finish_cost
>../../gcc/tree-vectorizer.h:1400
>0x1153821 vect_compute_single_scalar_iteration_cost
>../../gcc/tree-vect-loop.c:1134
>0x11568fb vect_analyze_loop_2
>../../gcc/tree-vect-loop.c:2041
>0x11586ef vect_analyze_loop(loop*, vec_info_shared*)
>../../gcc/tree-vect-loop.c:2583
>0x119131c try_vectorize_loop_1
>../../gcc/tree-vectorizer.c:894
>0x1191d69 vectorize_loops()
>../../gcc/tree-vectorizer.c:1128
>Please submit a full bug report,
>with preprocessed source if appropriate.
>Please include the complete backtrace with any bug report.
>See  for instructions.

Just skip debug stmts in the IL walk in the backend or deal with NULL stmt info
result for lookup of those. I have public holidays today.

[Bug tree-optimization/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Let me fix that.

[Bug tree-optimization/95199] Remove extra variable created for memory reference in loop vectorization.

[zhoukaipeng3 at huawei dot com]

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

--- Comment #9 from Kaipeng Zhou  ---
Created attachment 48717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48717&action=edit
Remove extra variable created for memory reference in loop vectorization.

Looks like no one is preparing this patch.  I tried to make it.

Bootstrap and deja tested on x86 and aarch64.  No new problem.

Is that ok?

[Bug tree-optimization/92860] [8/9/10/11 regression] Global flags affected by -O settings are clobbered by optimize attribute

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #24 from David Binderman  ---
Is this error message related ?

/home/dcb/gcc/results.20200611/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/xsaveoptintrin.h:55:9:
internal compiler error: Error: global_options are modified in local context

   55 | #pragma GCC pop_options
  | ^~~
0xe6fefe cl_optimization_compare(gcc_options*, gcc_options*)
/home/dcb/gcc/working/gcc/options-save.c:0
0x97c7b9 handle_pragma_pop_options(cpp_reader*)
../../trunk.git/gcc/c-family/c-pragma.c:1090
0x7a0565 cp_parser_pragma(cp_parser*, pragma_context, bool*)
../../trunk.git/gcc/cp/parser.c:43983
0x79d432 cp_parser_toplevel_declaration(cp_parser*)
../../trunk.git/gcc/cp/parser.c:13502

It seems to be a preprocessor crash, so I don't know how to reduce
the test case.

[Bug fortran/37974] gfortran runtime segmentation fault

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE
 CC||ma...@linux-mips.org

--- Comment #4 from Maciej W. Rozycki  ---


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

[Bug fortran/17887] g77 generates code that results in segmentation fault

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||deji_aking at yahoo dot ca

--- Comment #4 from Maciej W. Rozycki  ---
*** Bug 37974 has been marked as a duplicate of this bug. ***

[Bug target/95637] New: Read-only data assigned to `.sdata' rather than `.rodata'

[ma...@linux-mips.org]

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

Bug ID: 95637
   Summary: Read-only data assigned to `.sdata' rather than
`.rodata'
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
  Target Milestone: ---
Target: riscv*-*-linux-gnu

As observed in PR fortran/95631 read-only data gets assigned to `.sdata'
rather than `.rodata', which in turn causes invalid attempts to modify it
not to be trapped at run time.

A test case from the PR referred is:

C
C CHANGE THE VALUE OF 4
C

  CALL INC(4)
  WRITE (*, 30) 4
30FORMAT ('2+2=',I4)
  END

  SUBROUTINE INC(I)
  I = I + 1
  END

which is supposed to trap on the modification of literal 4 in INC.
Instead the program runs to completion and prints:

2+2=   5

I have no C language test case at hand, but I guess it does not matter,
this one is sweet and simple.

[Bug fortran/17887] g77 generates code that results in segmentation fault

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 CC||ma...@linux-mips.org

--- Comment #5 from Maciej W. Rozycki  ---
*** Bug 95631 has been marked as a duplicate of this bug. ***

[Bug fortran/95631] Unable to redefine a literal with `-std=legacy'

[ma...@linux-mips.org]

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

Maciej W. Rozycki  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #5 from Maciej W. Rozycki  ---
Thanks for the clarification, and quoting the relevant pieces of the
respective standards in particular.

I have marked the relevant duplicates, and hopefully the somewhat more
meaningful bug summary will serve in the future.  It may be worth adding
this test case to the test suite, though for that I gather we'd have to
trap that SIGSEGV and convert it to a successful return, whereas running
through would have to exit unsuccessfully.  Regrettably my Fortran fu is
too weak to come up with a signal handler quickly.

NB numerous computer systems do not support memory protection and have
no way to mark a segment read-only, and may otherwise either not support
instrumentation at all or it can be disabled for performance reasons, so
the phenomenon observed/reported may indeed have been just a peculiarity
of the implementation.

I have filed PR target/95637 for the `.sdata' assignment of read-only
data with `riscv*-*-linux-gnu' targets.

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

[Bug fortran/94022] Array slices of assumed-size arrays

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:6a07010b774cb5a0b1790b857e69d3d8534eebd2

commit r11-1228-g6a07010b774cb5a0b1790b857e69d3d8534eebd2
Author: José Rui Faustino de Sousa 
Date:   Thu Jun 11 13:24:55 2020 +0200

Patch to Bug 94022 - Array slices of assumed-size arrays.

Make sure that when passing array sections of assumed-size arrays to
procedures expecting an assumed-rank array the upper bound of the
last dimension of the array section does not get improperly reset
to -1 to mark it has an assumed size array.

gcc/fortran/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/94022
* trans-expr.c (gfc_conv_procedure_call): In the case of
assumed-size arrays ensure that the reference is to a full array.

gcc/testsuite/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/94022
* gfortran.dg/PR94022.f90: New test.

[Bug c++/95638] New: Legit-looking code doesn't work with -O2

[officesamurai at gmail dot com]

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

Bug ID: 95638
   Summary: Legit-looking code doesn't work with -O2
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: officesamurai at gmail dot com
  Target Milestone: ---

Created attachment 48718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48718&action=edit
The failing code

The attached code produces wrong result when build with -O2 and without
-fno-strict-aliasing, but I don't believe it does anything illegal. The only
fishy thing it does is creating a pointer to T before an object of that type is
constructed at that location (in Storage::Storage and Storage::push_back), but
the pointer is just passed to the placement new, which should be fine according
to [basic.life] (because "...using the pointer as if the pointer were of type
void*, is well-defined").


$ g++-10.1.0 -v
Using built-in specs.
COLLECT_GCC=g++-10.1.0
COLLECT_LTO_WRAPPER=/home/brd/soft/gcc-10.1.0/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=/home/brd/soft/gcc-10.1.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 

$ g++-10.1.0 -O2 gcc10_aliasing_issue.cpp -o test -std=c++14 && ./test
Null!!!

$ g++-10.1.0 -O2 -fno-strict-aliasing gcc10_aliasing_issue.cpp -o test
-std=c++14 && ./test
OK


P.S. The same code works fine with GCC 9 and earlier versions.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

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

commit r10-8271-g3e9261f0e013108135bf09f0f91b279b9c5cbd9e
Author: Patrick Palka 
Date:   Wed Jun 10 17:37:53 2020 -0400

libstdc++: Fix some ranges algos optimizations [PR95578]

ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator.  But in the checks that guard these optimizations we
currently only test that the iterator of the iterator/sentinel pair has
the appropriate type before proceeding with the corresponding
optimization, and do not also test the sentinel type.

This breaks the testcase in this PR because this testcase constructs via
range adaptors a range whose begin() is a __normal_iterator and whose
end() is a custom sentinel type, and then performs ranges::copy on it.
From there we bogusly perform the __normal_iterator unwrapping
optimization on this iterator/sentinel pair, which immediately leads to
a constraint failure since the custom sentinel type does not model
sentinel_for.

This patch fixes this issue by refining each of the problematic checks
to also test that the iterator and sentinel types are the same before
applying the corresponding unwrapping optimization.  Along the way, some
code simplifications are made.

libstdc++-v3/ChangeLog:

PR libstdc++/95578
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Also check that the iterator and sentinel have the same type before
applying the unwrapping optimization for __normal_iterator.
Split the check into two, one for the first iterator/sentinel
pair and another for second iterator/sentinel pair.  Remove uses
of __niter_base, and remove uses of std::move on a
__normal_iterator.
* include/bits/ranges_algobase.h (__equal_fn): Likewise.
(__copy_or_move): Likewise.  Perform similar adjustments for
the reverse_iterator and move_iterator optimizations.  Inline
the checks into the if-constexprs, and use using-declarations to
make them less visually noisy.  Remove uses of __niter_wrap.
(__copy_or_move_backward): Likewise.
* testsuite/25_algorithms/copy/95578.cc: New test.
* testsuite/25_algorithms/copy_backward/95578.cc: New test.
* testsuite/25_algorithms/equal/95578.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/95578.cc: New
test.
* testsuite/25_algorithms/move/95578.cc: New test.
* testsuite/25_algorithms/move_backward/95578.cc: New test.

(cherry picked from commit a73051a0ea9ce8281e748a74dd924a6eb8fb3723)

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 10.2+, thanks for the bug report.

[Bug c++/95638] Legit-looking code doesn't work with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
All I can say is that bisection shows (at least when preprocessed with g++
8.3.1 first) that this changed behavior in
r10-7184-ge4e9a59105a81cdd6c1328b0a5ed9fe4cc82840e
No time to analyze if it is a bug in the code or on the GCC side.
CCing patch author.

[Bug c++/95609] span could have better layout

[s_gccbugzilla at nedprod dot com]

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

--- Comment #2 from Niall Douglas  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Niall Douglas from comment #0)
> > I would assume that the ABI ship has sailed, as usual
> 
> Nope.

Ok, so if you did want to reuse span as any future
std::file_handle::buffer_type, the following program would compile:

```
#include 
#include 
#include 

using buffer_type = std::span;

static_assert(sizeof(buffer_type) == sizeof(struct iovec));
static_assert(std::is_trivially_copyable_v);
static_assert(std::is_standard_layout_v);
static_assert(std::is_layout_compatible_v);
```

[Bug c++/95638] Legit-looking code doesn't work with -O2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
The code works with -flifetime-dse=1, so I bet there's some object that goes
out of life:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1230-g2ff0f48819c8a7ed5d7c03e2bfc02e5907e2ff1a
Author: José Rui Faustino de Sousa 
Date:   Thu Jun 11 14:14:30 2020 +0200

Wrong array section bounds when passing to an intent-in pointer dummy.

Add code to allow for the creation a new descriptor for array
sections with the correct one based indexing.

Rework the generated descriptors indexing (hopefully) fixing the
wrong offsets generated.

gcc/fortran/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/52351
PR fortran/85868
* trans-array.c (gfc_conv_expr_descriptor): Enable the
creation of a new descriptor with the correct one based
indexing for array sections.  Rework array descriptor
indexing offset calculation.

gcc/testsuite/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/52351
PR fortran/85868
* gfortran.dg/coarray_lib_comm_1.f90: Adjust match test for
the newly generated descriptor.
* gfortran.dg/PR85868A.f90: New test.
* gfortran.dg/PR85868B.f90: New test.

[Bug fortran/52351] Wrong bounds when passing an array section to an intent-in pointer dummy

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

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

commit r11-1230-g2ff0f48819c8a7ed5d7c03e2bfc02e5907e2ff1a
Author: José Rui Faustino de Sousa 
Date:   Thu Jun 11 14:14:30 2020 +0200

Wrong array section bounds when passing to an intent-in pointer dummy.

Add code to allow for the creation a new descriptor for array
sections with the correct one based indexing.

Rework the generated descriptors indexing (hopefully) fixing the
wrong offsets generated.

gcc/fortran/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/52351
PR fortran/85868
* trans-array.c (gfc_conv_expr_descriptor): Enable the
creation of a new descriptor with the correct one based
indexing for array sections.  Rework array descriptor
indexing offset calculation.

gcc/testsuite/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/52351
PR fortran/85868
* gfortran.dg/coarray_lib_comm_1.f90: Adjust match test for
the newly generated descriptor.
* gfortran.dg/PR85868A.f90: New test.
* gfortran.dg/PR85868B.f90: New test.

[Bug c++/95638] Legit-looking code doesn't work with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #2)
> The code works with -flifetime-dse=1, so I bet there's some object that goes
> out of life:
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
> https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

The difference between -flifetime-dse=1 and the default is not in uses after
end of scope, but in relying on content being defined across start of the
constructor.

Snake Trap

[EPS Environmental via Gcc-bugs]

Snake Trap

catches all snakes, rodents and crowling insects (including poisonous snakes)
20,000 LBP per unit (up to 5 traps with installation) - suitable for Homes
16,000 LBP per unit (up to 20 traps with installation and weekly visit) - 
suitable for Bakeries, Pastries, Retaurants or Hotels


Gabriel Mitri
Managing Director 
EPS ENVIRONMEMTAL Ets.
Green motion  "We Convert Waste Into Money"
Mobile     : +961 76 911 483
Skype ID   : Gabriel Mitri LB 
E-mail     : eps.gm.mi...@gmail.com

[Ads961.com] Professional Advertisement in Lebanon(email) 

b...@adsleb.com (Tel) 

+961 1 411 410 (whatsapp) 

+961 71 072 786If you no longer wish to receive mail from us, you can   
 

unsubscribe

Ads961, Badaro, Beirut, LB, 50-110, Lebanon

[Bug target/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug target/95627] [11 Regression] ICE in rs6000_density_test at rs6000.c:4992 since r11-1181-g371cc683371bedb0e53ebcee0c0e89604a1e74b1

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:444035eafa2fbabbb1261f258bfd41e8051aab34

commit r11-1231-g444035eafa2fbabbb1261f258bfd41e8051aab34
Author: Martin Liska 
Date:   Thu Jun 11 11:24:20 2020 +0200

rs6000: skip debug info statements

gcc/ChangeLog:

PR target/95627
* config/rs6000/rs6000.c (rs6000_density_test): Skip debug
statements.

[Bug c++/95639] New: wrong error location

[f.heckenb...@fh-soft.de]

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

Bug ID: 95639
   Summary: wrong error location
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

This may be similar to #93979, but I'm not sure.

% cat test.cpp
#define S(A) sizeof (A)

int main ()
{
  int a[10];
  return (int) S (a);
}
% g++ -Wold-style-cast test.cpp
t.cpp: In function 'int main()':
t.cpp:1:23: warning: use of old-style cast to 'int' [-Wold-style-cast]
1 | #define S(A) sizeof (A)
  |   ^
t.cpp:6:16: note: in expansion of macro 'S'
6 |   return (int) S (a);
  |^

The warning itself is correct, but the location and the note point at the
macro, while the offending cast is in main.

[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1235-g2ee70f5d161edd99a7af97d166b251bcf83cd91b
Author: José Rui Faustino de Sousa 
Date:   Thu Jun 11 15:15:25 2020 +0200

PR95331 - Unlimited polymorphic arrays have wrong bounds.

When iterating over a class array use the bounds provided by the
transformed descriptor (in sym->backend_decl) instead of the original
bounds of the array (in the descriptor passed in the class _data)
which are passed in se->expr.

The patch partially depends on the patch for PR52351 and PR85868, but
does not seems to break anything by itself.

gcc/fortran/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/95331
* trans-array.c (gfc_conv_array_ref): For class array dummy
arguments use the transformed descriptor in sym->backend_decl
instead of the original descriptor.

gcc/testsuite/ChangeLog:

2020-06-11  José Rui Faustino de Sousa  

PR fortran/95331
* gfortran.dg/PR95331.f90: New test.

[Bug fortran/95640] New: gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

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

Bug ID: 95640
   Summary: gfortran ieee_selected_real_kind returns 10
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test.f90

program test
  use,intrinsic :: ieee_arithmetic

  print *, " selected_real_kind(16) = ", selected_real_kind(16)
  print *, "ieee_selected_real_kind(16) = ", ieee_selected_real_kind(16)
end program test

Cray: 

> ftn test.f90
> ./a.out
 selected_real_kind(16) = 16
ieee_selected_real_kind(16) = 16

Intel:

> module swap PrgEnv-cray PrgEnv-intel
> ifort test.f90
> ./a.out
 selected_real_kind(16) = 16
ieee_selected_real_kind(16) = 16

Gfortran: 

> module swap PrgEnv-intel PrgEnv-gnu
> gfortran test.f90
> ./a.out
 selected_real_kind(16) = 10
ieee_selected_real_kind(16) = 10



The output from gfortran is problematic because ieee_selected_real_kind should
not return 10.   If the users want KIND=10 (i.e. the Intel-proprietary 80-bit
x87 floats), then they need to use selected_real_kind and not the IEEE version.

[Bug c++/95639] wrong error location

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-06-11

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

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

--- Comment #1 from Bill Long  ---
The main problem here is that selected_real_kind and ieee_selected_real_kind
have different specifications. The ieee_selected_real_kind requires a KIND
value corresponding to an IEEE floating format, whereas selected_real_kind is
only limited to formats supported by the processor, including non-ieee formats,
like the x87 80-bit format.  (Which, apparently, even the Intel compiler no
longer supports.) 

The expected output from gfortran would be

> gfortran test.f90
> ./a.out
 selected_real_kind(16) = 10
ieee_selected_real_kind(16) = 16

[Bug c++/95609] span could have better layout

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-11

--- Comment #3 from Jonathan Wakely  ---
As discussed on the reflector, that's only going to work on some targets.

Libstdc++ doesn't dictate the layout of struct iovec, and POSIX only
guarantees:

  The  header shall define the iovec structure, which shall
  include at least the following members:

  void   *iov_base  Base address of a memory region for input or output. 
  size_t  iov_len   The size of the memory pointed to by iov_base. 

POSIX doesn't say what order the members are in, and allows additional members.

So while there is some value making span layout-compatible with linux's
iovec, there's no guarantee it will be usable on other POSIX systems, nor
Windows. So a custom buffer type will probably need to be defined eventually
anyway.

Linux's layout is the obvious one though, and is also used by AIX 7.2, Solaris
11, FreeBSD 12 and OpenBSD 6.6, which means we can assume it's true for most of
the widely-used unix-like systems.

[Bug c++/95639] wrong error location

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
With a trivial patch we generate:

95639.C: In function ‘int main()’:
95639.C:6:14: warning: use of old-style cast to ‘int’ [-Wold-style-cast]
6 |   return (int) S (a);
  |  ^
  |  -
  |  static_cast ()


I suspect that's much better.

[Bug fortran/95503] [9/10/11 Regression] ICE in gfc_is_simply_contiguous, at fortran/expr.c:5844

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:87af4f40453a9c84363bde5d9a58466de7fbee2e

commit r11-1236-g87af4f40453a9c84363bde5d9a58466de7fbee2e
Author: Harald Anlauf 
Date:   Thu Jun 11 15:48:56 2020 +0200

PR fortran/95503 - Fix ICE in gfc_is_simply_contiguous, at
fortran/expr.c:5844

The check for assigning a pointer that cannot be determined to be simply
contiguous at compile time to a contiguous pointer does not need to be
invoked if the lhs of the assignment is known to have conflicting
attributes.

2020-06-11  Harald Anlauf  

gcc/fortran/
PR fortran/95503
* expr.c (gfc_check_pointer_assign): Skip contiguity check of rhs
of pointer assignment if lhs cannot be simply contiguous.

gcc/testsuite/
PR fortran/95503
* gfortran.dg/pr95503.f90: New test.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-11
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code

--- Comment #2 from Dominique d'Humieres  ---
Confirmed since at least GCC5, note the later returns

  selected_real_kind(16) =   10
 ieee_selected_real_kind(16) =   -1

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:605e9b1a9b3250537a7269eba7e9c316b0f00d29

commit r10-8273-g605e9b1a9b3250537a7269eba7e9c316b0f00d29
Author: Harald Anlauf 
Date:   Sun Jun 7 16:43:12 2020 +0200

PR fortran/95091 - Buffer overflows with submodules and long symbols

Add cast to fix bootstrap error with -Werror=sign-compare.

gcc/fortran/
PR fortran/95091
* class.c (gfc_hash_value): Add cast.

(cherry picked from commit 5aaccde3db39fac7e7f6677ceccc1eadd9c6a424)

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-8272-gbf6199ecc9c2dc9f6b5eca3d18ff48b374a8feb9
Author: Harald Anlauf 
Date:   Sun Jun 7 14:47:24 2020 +0200

PR fortran/95091 - Buffer overflows with submodules and long symbols

With submodules, name mangling results in long internal symbols.  This
requires adjustment of the sizes of temporaries to avoid buffer overflows.

2020-06-07  Harald Anlauf  

gcc/fortran/
PR fortran/95091
* class.c (get_unique_type_string, gfc_hash_value): Enlarge
buffers, and check whether the strings returned by
get_unique_type_string() fit.

(cherry picked from commit b342cfd648e6658363c7c8fef83af8f59dba1795)

[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed on master.

[Bug fortran/52351] Wrong bounds when passing an array section to an intent-in pointer dummy

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on master.

[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds

[tkoenig at gcc dot gnu.org]

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

Bug 52351 Summary: Wrong bounds when passing an array section to an intent-in 
pointer dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52351

   What|Removed |Added

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

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[qing.zhao at oracle dot com]

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

--- Comment #34 from Qing Zhao  ---
> 
>> Though still bigger than what ICC generated.
> 
> Yep, but we should be only 2x bigger right now?
Yes, around 2-3 times bigger, much better now.
> 
> Can you please test the parallel merging script? I can merge 10GB gcov files
> (5000 runs with 264 files each) in about 50s.

I will make the request soon (I don’t have the permission to do this). Might
might take some time for others to do this.

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Koenig  ---
Fixed on master, closing.

[Bug fortran/95331] Unlimited polymorphic arrays have wrong bounds

[tkoenig at gcc dot gnu.org]

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

Bug 85868 Summary: Subarray of a pointer array associated with a pointer dummy 
argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868

   What|Removed |Added

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

[Bug fortran/94022] Array slices of assumed-size arrays

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #5 from Thomas Koenig  ---
Fixed on master, closing.

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:77137fbd464b20e2422c887d1e46fa5f1c38dc9e

commit r9-8666-g77137fbd464b20e2422c887d1e46fa5f1c38dc9e
Author: Harald Anlauf 
Date:   Sun Jun 7 16:43:12 2020 +0200

PR fortran/95091 - Buffer overflows with submodules and long symbols

Add cast to fix bootstrap error with -Werror=sign-compare.

gcc/fortran/
PR fortran/95091
* class.c (gfc_hash_value): Add cast.

(cherry picked from commit 5aaccde3db39fac7e7f6677ceccc1eadd9c6a424)

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-8665-gabfe42c1fb66a534290bd0a808c2d90842ee848b
Author: Harald Anlauf 
Date:   Sun Jun 7 14:47:24 2020 +0200

PR fortran/95091 - Buffer overflows with submodules and long symbols

With submodules, name mangling results in long internal symbols.  This
requires adjustment of the sizes of temporaries to avoid buffer overflows.

2020-06-07  Harald Anlauf  

gcc/fortran/
PR fortran/95091
* class.c (get_unique_type_string, gfc_hash_value): Enlarge
buffers, and check whether the strings returned by
get_unique_type_string() fit.

(cherry picked from commit b342cfd648e6658363c7c8fef83af8f59dba1795)

[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, and backported to 10-branch and 9-branch.

Thanks for the report!

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the quick response and quick fix :)

[Bug tree-optimization/95635] -Warray-bounds while iterating over an escaped constant local array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||86318
  Component|c   |tree-optimization
Summary|-Warray-bounds falsely  |-Warray-bounds while
   |claims out-of-bounds access |iterating over an escaped
   ||constant local array
   Keywords||diagnostic,
   ||missed-optimization
 Blocks||56456

--- Comment #2 from Martin Sebor  ---
-Warray-bounds relies on the optimizer to eliminate dead code.  In the test
case, GCC (unnecessarily) assumes that the escaped array may be modified by the
call to c().  This missing optimization (tracked in pr86318) keeps the second
test from being eliminated (see also the test case below).  I note that Clang
optimizes the function to a no-op as expected.

That aside, arrays with zero elements are meant to be used as trailing members
of structures.  Using them anywhere else is a bug waiting to happen.  I would
recommend against using them in any other contexts as they may start getting
diagnosed even more aggressively (e.g., even declaring one that's not last in a
struct might trigger a warning in the future).  I'll keep this open since a
similar warning can be triggered with a non-empty array due to the same
limitation.

A test case for the missing optimization:

$ cat pr95635.c && gcc -O3 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
pr95635.c
void f (const int*);

void g (void)
{
  const int i = -1;
  f (&i);
  if (i != -1)// folded to false
__builtin_abort ();   // eliminated
}

void h (void)
{
  const int a[] = { -1 };
  f (a);
  if (*a != -1)   // not folded
__builtin_abort ();
}

;; Function g (g, funcdef_no=0, decl_uid=1933, cgraph_uid=1, symbol_order=0)

g ()
{
  const int i;

   [local count: 1073741824]:
  i = -1;
  f (&i);
  i ={v} {CLOBBER};
  return;

}



;; Function h (h, funcdef_no=1, decl_uid=1937, cgraph_uid=2, symbol_order=1)

h ()
{
  const int a[1];
  int _1;

   [local count: 1073741824]:
  a[0] = -1;
  f (&a);
  _1 = a[0];
  if (_1 != -1)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86318
[Bug 86318] const local aggregates can be assumed not to be modified even when
escaped

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Depends on||69101

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Bill Long from comment #0)
> > cat test.f90

> Gfortran: 
> 
> > module swap PrgEnv-intel PrgEnv-gnu
> > gfortran test.f90
> > ./a.out
>  selected_real_kind(16) = 10
> ieee_selected_real_kind(16) = 10
> 
> The output from gfortran is problematic because ieee_selected_real_kind
> should not return 10.   If the users want KIND=10 (i.e. the
> Intel-proprietary 80-bit x87 floats), then they need to use
> selected_real_kind and not the IEEE version.

IEEE-754 permits the extended double type (See 3.7 Extended and
extendable precisions).  I do not see in the Fortran standard that
the output from ieee_seleted_real_kind must select binary32,
binary64, or binary128.

That said, ieee_selected_real_kind is completely broken.
See PR69101.  I used to have patch that fixed this PR,
but never got around to committing it.  The patch attached
in 69101 is not correct.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69101
[Bug 69101] [F03] IEEE_SELECTED_REAL_KIND is not generic

[Bug c++/95641] New: Bogus error message in the class base specifier

[haoxintu at gmail dot com]

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

Bug ID: 95641
   Summary: Bogus error message in the class base specifier
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

This code bug.cc

class A {};
class B : virtual class A{};

In gcc-trunk

$g++ -c bug.cc
bug.cc:2:19: error: expected class-name before ‘class’
2 | class B : virtual class A{};
  |   ^
bug.cc:2:19: error: expected ‘{’ before ‘class’
bug.cc:2:25: error: redefinition of ‘class A’
2 | class B : virtual class A{};
  | ^
bug.cc:1:7: note: previous definition of ‘class A’
1 | class A {};
  |   ^
bug.cc:2:1: error: multiple types in one declaration
2 | class B : virtual class A{};
  | ^

There are four error messages, I guess some of them are bogus.

I tested bug.cc in other compilers, and they only give one message.

In clang : "error: expected class name",
In icc : "error: expected an identifier",
In msvc : " error C2518: keyword 'class' is invalid in a base class list;
expected a class name".

Reproduced in Godbolt : https://godbolt.org/z/KuEPNF

[Bug tree-optimization/94335] [10/11 Regression] False positive -Wstringop-overflow warning with -O2

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
(In reply to kal.conley from comment #6)

For reference, this was also submitted as pr95353 and is now fixed on trunk
(GCC 11).

The test case in comment #0 still triggers a warning.

[Bug c++/95641] Bogus error message in the class base specifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2020-06-11
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Haoxin Tu from comment #0)
> There are four error messages, I guess some of them are bogus.

The parser gets confused after the first one.

[Bug c++/95638] Legit-looking code doesn't work with -O2

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I don't see anything obviously wrong with the code. Nothing seems to write to
the storage before the constructor, let alone rely on those writes being
preserved.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Thu, Jun 11, 2020 at 02:56:58PM +, kargl at gcc dot gnu.org wrote:
> 
> IEEE-754 permits the extended double type (See 3.7 Extended and
> extendable precisions).  I do not see in the Fortran standard that
> the output from ieee_seleted_real_kind must select binary32,
> binary64, or binary128.

Addendum 1, in case anyone cares.  Neither IEEE decimal64 nor
decimal128 can be returned as gfortran currently does not
support RADIX=10.

> That said, ieee_selected_real_kind is completely broken.
> See PR69101.  I used to have patch that fixed this PR,
> but never got around to committing it.  The patch attached
> in 69101 is not correct.

Addendum 2, I may have found my last working patch.  If I get
around to it, I might post it in the PR.

Addendum 3, F2018 has added at least ieee_fma.  gfortran does 
not support it.

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

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

--- Comment #5 from Bill Long  ---
The same user also submitted a bug about IEEE_FMA not being supported.  Is
there already a bug/rfe for that in the gcc bugzilla?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[longb at cray dot com]

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

--- Comment #6 from Bill Long  ---
(In reply to kargl from comment #3)
> (In reply to Bill Long from comment #0)
> > > cat test.f90
>  
> > Gfortran: 
> > 
> > > module swap PrgEnv-intel PrgEnv-gnu
> > > gfortran test.f90
> > > ./a.out
> >  selected_real_kind(16) = 10
> > ieee_selected_real_kind(16) = 10
> > 
> > The output from gfortran is problematic because ieee_selected_real_kind
> > should not return 10.   If the users want KIND=10 (i.e. the
> > Intel-proprietary 80-bit x87 floats), then they need to use
> > selected_real_kind and not the IEEE version.
> 
> IEEE-754 permits the extended double type (See 3.7 Extended and
> extendable precisions).  I do not see in the Fortran standard that
> the output from ieee_seleted_real_kind must select binary32,
> binary64, or binary128.
> 
> That said, ieee_selected_real_kind is completely broken.
> See PR69101.  I used to have patch that fixed this PR,
> but never got around to committing it.  The patch attached
> in 69101 is not correct.


The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes
"The result has a value equal to a value of the kind type parameter of an
ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts to
binary32, 64, 128 for RADIX=2 (the default).  The 80-bit x87 format is not part
of the quoted IEEE standard.

[Bug libstdc++/95642] New: std::fstream ctr and open member functions fail to compile with argument of custom type convertible to std::filesystem::path

[manx-bugzilla at problemloesungsmaschine dot de]

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

Bug ID: 95642
   Summary: std::fstream ctr and open member functions fail to
compile with argument of custom type convertible to
std::filesystem::path
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manx-bugzilla at problemloesungsmaschine dot de
  Target Milestone: ---

Created attachment 48719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48719&action=edit
test case

std::fstream (and related classes) ctr and open member functions fail to
compile with an argument of a custom type implicitly convertible to
std::filesystem::path.

When compiling the attached test.cpp (via 'g++ -std=c++17 -Wall -Wextra -O3 -c
test.cpp'), gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0 fails with the error message
[1].

This does also happen with GCC 8 and 10, as well as trunk (as of today on
godbolt.org).

C++17 [fstream] does not list any SFINAE in the std::filesystem::path overload
that I am trying to call here, thus I think this is a GCC/libstdc++ bug.

Note that Clang/LLVM (with libc++) as well as MSVC correctly compile the
provided test case. See https://godbolt.org/z/K6v3Cb .

[1]:
test.cpp: In function ‘void foo(mypath)’:
test.cpp:7:41: error: no matching function for call to
‘std::basic_fstream::basic_fstream(mypath&, const openmode&)’
7 | std::fstream bar(p, std::ios::binary);
  | ^
In file included from test.cpp:2:
/usr/include/c++/9/fstream:1106:7: note: candidate: ‘std::basic_fstream<_CharT,
_Traits>::basic_fstream(std::basic_fstream<_CharT, _Traits>&&) [with _CharT =
char; _Traits = std::char_traits]’
 1106 |   basic_fstream(basic_fstream&& __rhs)
  |   ^
/usr/include/c++/9/fstream:1106:7: note:   candidate expects 1 argument, 2
provided
/usr/include/c++/9/fstream:1098:2: note: candidate: ‘template std::basic_fstream<_CharT, _Traits>::basic_fstream(const
_Path&, std::ios_base::openmode)’
 1098 |  basic_fstream(const _Path& __s,
  |  ^
/usr/include/c++/9/fstream:1098:2: note:   template argument
deduction/substitution failed:
/usr/include/c++/9/fstream:1097:32: error: ‘struct mypath’ has no member named
‘make_preferred’
 1097 |   template>
  |^~~~
/usr/include/c++/9/fstream:1083:7: note: candidate: ‘std::basic_fstream<_CharT,
_Traits>::basic_fstream(const string&, std::ios_base::openmode) [with _CharT =
char; _Traits = std::char_traits; std::string =
std::__cxx11::basic_string; std::ios_base::openmode =
std::_Ios_Openmode]’
 1083 |   basic_fstream(const std::string& __s,
  |   ^
/usr/include/c++/9/fstream:1083:40: note:   no known conversion for argument 1
from ‘mypath’ to ‘const string&’ {aka ‘const
std::__cxx11::basic_string&’}
 1083 |   basic_fstream(const std::string& __s,
  | ~~~^~~
/usr/include/c++/9/fstream:1053:7: note: candidate: ‘std::basic_fstream<_CharT,
_Traits>::basic_fstream(const char*, std::ios_base::openmode) [with _CharT =
char; _Traits = std::char_traits; std::ios_base::openmode =
std::_Ios_Openmode]’
 1053 |   basic_fstream(const char* __s,
  |   ^
/usr/include/c++/9/fstream:1053:33: note:   no known conversion for argument 1
from ‘mypath’ to ‘const char*’
 1053 |   basic_fstream(const char* __s,
  | ^~~
/usr/include/c++/9/fstream:1043:7: note: candidate: ‘std::basic_fstream<_CharT,
_Traits>::basic_fstream() [with _CharT = char; _Traits =
std::char_traits]’
 1043 |   basic_fstream()
  |   ^
/usr/include/c++/9/fstream:1043:7: note:   candidate expects 0 arguments, 2
provided
test.cpp:8:33: error: no matching function for call to
‘std::basic_fstream::open(mypath&, const openmode&)’
8 | bar.open(p, std::ios::binary);
  | ^
In file included from test.cpp:2:
/usr/include/c++/9/fstream:1177:7: note: candidate: ‘void
std::basic_fstream<_CharT, _Traits>::open(const char*, std::ios_base::openmode)
[with _CharT = char; _Traits = std::char_traits; std::ios_base::openmode
= std::_Ios_Openmode]’
 1177 |   open(const char* __s,
  |   ^~~~
/usr/include/c++/9/fstream:1177:24: note:   no known conversion for argument 1
from ‘mypath’ to ‘const char*’
 1177 |   open(const char* __s,
  |^~~
/usr/include/c++/9/fstream:1218:7: note: candidate: ‘void
std::basic_fstream<_CharT, _Traits>::open(const string&,
std::ios_base::openmode) [with _CharT = char; _Traits = std::char_traits;
std::string = std::__cxx11::basic_string; std::ios_base::openmode =
std::_Ios_Openmode]’
 1218 |   open(const std::string& __s,
  |   ^~~~
/usr/include/c++/9/fstream:12

[Bug tree-optimization/95643] New: Optimizer fails to realize that a variable tested twice in a row is the same both times

[josephcsible at gmail dot com]

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

Bug ID: 95643
   Summary: Optimizer fails to realize that a variable tested
twice in a row is the same both times
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---

Consider this code, compiled at -O3:

extern int e;
void f(int x, int y) {
if(y) {
if(y && !x) __builtin_unreachable();
if(x) ++e;
}
}

GCC 10.1 on AMD64 produces the following assembly:

f:
testl   %edi, %edi
je  .L1
testl   %esi, %esi
jne .L10
.L1:
ret
.L10:
addl$1, e(%rip)
ret

Godbolt link: https://godbolt.org/z/Z75QTM
The "y" in "if(y && !x)" is necessarily true, but GCC doesn't realize this,
since changing "if(y && !x)" to the equivalent "if(!x)" results in much better
assembly:

f:
testl   %esi, %esi
je  .L1
addl$1, e(%rip)
.L1:
ret

We should be able to generate this assembly even with the redundant check of
"y".

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  ---
So, if we're not backporting any further, we might as well mark it
as fixed.

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Thu, Jun 11, 2020 at 04:12:57PM +, longb at cray dot com wrote:
> 
> --- Comment #5 from Bill Long  ---
> The same user also submitted a bug about IEEE_FMA not being supported.  Is
> there already a bug/rfe for that in the gcc bugzilla?
> 

Not that I am aware of.

I had planned on looking at ieee support after 10.1 was released,
because it is a longer term effort.  The switch to git has caused
me to abandon that effort.

[Bug fortran/95644] New: IEEE_FMA is missing from the IEEE_ARITHMETIC module

[longb at cray dot com]

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

Bug ID: 95644
   Summary: IEEE_FMA is missing from the IEEE_ARITHMETIC module
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat test2.f90

program test

  use, intrinsic :: ieee_arithmetic, only : ieee_fma

  implicit none

end program test


Intel:

> ifort test2.f90

Cray:

> module swap PrgEnv-intel PrgEnv-cray
> ftn test2.f90
> ./a.out

gfortran:

> module swap PrgEnv-cray PrgEnv-gnu
> gfortran test2.f90
test2.f90:2:43:

2 | use, intrinsic :: ieee_arithmetic, only : ieee_fma
1
Error: Symbol 'ieee_fma' referenced at (1) not found in module
'ieee_arithmetic'
>

[Bug c/95645] New: Linux kernel regression "during GIMPLE pass: adjust_alignment"

[elver at google dot com]

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

Bug ID: 95645
   Summary: Linux kernel regression "during GIMPLE pass:
adjust_alignment"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elver at google dot com
  Target Milestone: ---

Created attachment 48720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48720&action=edit
Preprocessed source

With GCC at trunk (87af4f40453a9c84363bde5d9a58466de7fbee2e), compiling the
Linux kernel (v5.7, x86-64) fails for the following source file:

gcc -Wp,-MD,arch/x86/boot/.string.o.d  -nostdinc -isystem
/usr/local/google/home/elver/third_party/gcc/local/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
-I./arch/x86/include -I./arch/x86/include/generated  -I./include
-I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h -include
./include/linux/compiler_types.h -D__KERNEL__ -m16 -g -Os
-DDISABLE_BRANCH_PROFILING -Wall -Wstrict-prototypes -march=i386 -mregparm=3
-fno-strict-aliasing -fomit-frame-pointer -fno-pic -mno-mmx -mno-sse
-ffreestanding -fno-stack-protector -Wno-address-of-packed-member
-mpreferred-stack-boundary=2 -D_SETUP -fmacro-prefix-map=./=
-fno-asynchronous-unwind-tables  -DKBUILD_MODFILE='"arch/x86/boot/string"'
-DKBUILD_BASENAME='"string"' -DKBUILD_MODNAME='"string"' -c -o
arch/x86/boot/string.o arch/x86/boot/string.c   
during GIMPLE pass: adjust_alignment
arch/x86/boot/string.c: In function ‘simple_strtoull’:  
arch/x86/boot/string.c:121:20: internal compiler error: in execute, at
adjust-alignment.c:74   
  121 | unsigned long long simple_strtoull(const char *cp, char **endp,
unsigned int base)  
  |^~~  
0x7964a5 execute
../.././gcc/adjust-alignment.c:74 


This can be reproduced with the following command line and the attached
preprocessed source:

/usr/local/google/home/elver/third_party/gcc/local/bin/gcc  -nostdinc -m16 -g
-Os -Wall -Wstrict-prototypes -march=i386 -mregparm=3 -fno-strict-aliasing
-fomit-frame-pointer -fno-pic -mno-mmx -mno-sse -ffreestanding
-fno-stack-protector -Wno-address-of-packed-member
-mpreferred-stack-boundary=2 -fmacro-prefix-map=./=
-fno-asynchronous-unwind-tables -c -o /dev/null string-preprocessed.c

[Bug target/95237] LOCAL_DECL_ALIGNMENT shrinks alignment, FAIL gcc.target/i386/pr69454-2.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||elver at google dot com

--- Comment #16 from Jakub Jelinek  ---
*** Bug 95645 has been marked as a duplicate of this bug. ***

[Bug c/95645] Linux kernel regression "during GIMPLE pass: adjust_alignment"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Dup.

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

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Thu, Jun 11, 2020 at 04:21:25PM +, longb at cray dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
> 
> --- Comment #6 from Bill Long  ---
> (In reply to kargl from comment #3)
> > (In reply to Bill Long from comment #0)
> > > > cat test.f90
> >  
> > > Gfortran: 
> > > 
> > > > module swap PrgEnv-intel PrgEnv-gnu
> > > > gfortran test.f90
> > > > ./a.out
> > >  selected_real_kind(16) = 10
> > > ieee_selected_real_kind(16) = 10
> > > 
> > > The output from gfortran is problematic because ieee_selected_real_kind
> > > should not return 10.   If the users want KIND=10 (i.e. the
> > > Intel-proprietary 80-bit x87 floats), then they need to use
> > > selected_real_kind and not the IEEE version.
> > 
> > IEEE-754 permits the extended double type (See 3.7 Extended and
> > extendable precisions).  I do not see in the Fortran standard that
> > the output from ieee_seleted_real_kind must select binary32,
> > binary64, or binary128.
> > 
> > That said, ieee_selected_real_kind is completely broken.
> > See PR69101.  I used to have patch that fixed this PR,
> > but never got around to committing it.  The patch attached
> > in 69101 is not correct.
> 
> 
> The description in the Fortran standard for IEEE_SELECTED_REAL_KIND includes
> "The result has a value equal to a value of the kind type parameter of an
> ISO/IEC/IEEE 60559:2011 floating-point format..." This, in practice, amounts 
> to
> binary32, 64, 128 for RADIX=2 (the default).  The 80-bit x87 format is not 
> part
> of the quoted IEEE standard.
> 

IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):

  Five basic formats are defined in this clause:
Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
Two decimal formats, with encodings in lengths of 64 and 128 bits.

  Additional arithmetic formats are recommended for extending these basic
  formats (see 3.7).

If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of
IEEE-754 basic formats, then it ought to say that.   Looks like a defect
in the Fortran standard.

If one looks into 3.7 (p. 14), it further recommends

  Language standards should define mechanisms supporting extendable
  precision for each supported radix.

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1238-gb32eea9c0c25a03e77170675abc4e4bcab6d2b3b
Author: Jonathan Wakely 
Date:   Thu Jun 11 18:41:37 2020 +0100

libstdc++: Fix istream::ignore discarding too many chars (PR 94749)

The current code assumes that if the next character in the stream is
equal to the delimiter then we stopped because we saw that delimiter,
and so discards it.  But in the testcase for the PR we stop because we
reached the maximum number of characters, and it's coincidence that the
next character equals the delimiter. We should not discard the next
character in that case.

The fix is to check that we haven't discarded __n characters already,
instead of checking whether the next character equals __delim. Because
we've already checked for EOF, if we haven't discarded __n yet then we
know we stopped because we saw the delimiter. On the other hand, if the
next character is the delimiter we don't know if that's why we stopped.

PR libstdc++/94749
* include/bits/istream.tcc (basic_istream::ignore(streamsize,
CharT)):
Only discard an extra character if we didn't already reach the
maximum number.
* src/c++98/istream.cc (istream::ignore(streamsiz, char))
(wistream::ignore(streamsize, wchar_t)): Likewise.
* testsuite/27_io/basic_istream/ignore/char/94749.cc: New test.
* testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc: New test.

[Bug target/95646] New: arm-none-eabi function attribute 'cmse_nonsecure_entry' wipes register values with -Os

[c.woodward at cascoda dot com]

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

Bug ID: 95646
   Summary: arm-none-eabi function attribute
'cmse_nonsecure_entry' wipes register values with -Os
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c.woodward at cascoda dot com
  Target Milestone: ---

Created attachment 48721
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48721&action=edit
test file exhibiting the issue with cmse_nonsecure_entry and Os

This issue is specific to arm-none-eabi target, when building with arm CMSE and
-Os. The issue is that the calling convention is violated in functions marked
with __attribute__((cmse_nonsecure_entry)), and registers are wiped when they
should be preserved.

The issue only occurs when using -Os on the command line. O1, O2, O3 do not
produce the issue. Using function attributes to affect the optimisation level
does not seem to either cause nor prevent the error - only command line option.

The issue is that upon returning from the entry function, r8, r9, r10, r11 and
r12 are wiped without being restored. As per the 'Procedure Call Standard for
ARM Architecture' document, these should be preserved by the subroutine.

The 'ARM v8-M Security Extensions: Requirements on development tools' (section
5.4) specification specifies that all registers must be cleared before
returning from a secure entry function, which I imagine is where this issue
originates. However it also states that the registers should be restored, which
can be observed in O0. In O1, O2, O3, these are optimised out, which is fine.
However, in Os, the registers are cleared, but never restored, which causes
issues that are quite difficult to debug.

I have attached a simple (single function, no includes) c file that can be used
to recreate the issue.

I also have a runtime test that can demonstrate the broken behaviour if that
would be useful?

For anyone finding this bug and looking for a temporary workaround, do not use
'-Os' when compiling secure code for trustzone.

gcc args to recreate issue: -mcmse -mcpu=cortex-m23 -Os -c test.c

gcc version: 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain
9-2020-q2-update)
Target: arm-none-eabi
Configured with:
/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/src/gcc/configure
--target=arm-none-eabi
--prefix=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native
--libexecdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/lib
--infodir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib
--with-headers=yes --with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/arm-none-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr
--with-mpfr=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr
--with-mpc=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr
--with-isl=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr
--with-libelf=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Arm Embedded Toolchain 9-2020-q2-update'
--with-multilib-list=rmprofile,aprofile

(also tested and issue still exists with gcc version 7.3.1, 7.2.1, 8.3.1,
9.2.1)

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Fixed in master. I'll keep the bug open as I will probably backport the fix.

[Bug fortran/95644] IEEE_FMA is missing from the IEEE_ARITHMETIC module

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-11
 Status|UNCONFIRMED |NEW

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

[marxin at gcc dot gnu.org]

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

--- Comment #35 from Martin Liška  ---
(In reply to Qing Zhao from comment #34)
> > 
> >> Though still bigger than what ICC generated.
> > 
> > Yep, but we should be only 2x bigger right now?
> Yes, around 2-3 times bigger, much better now.

Fine. I'm going to finalize the patch and send to it GCC mailing list.

> > 
> > Can you please test the parallel merging script? I can merge 10GB gcov files
> > (5000 runs with 264 files each) in about 50s.
> 
> I will make the request soon (I don’t have the permission to do this). Might
> might take some time for others to do this.

Thanks.

[Bug tree-optimization/95643] Optimizer fails to realize that a variable tested twice in a row is the same both times

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
After FRE1 we have

  _2 = x_9(D) == 0;
  if (_2 != 0)

so we assert things for _2 and not x_9, and we lose the __builtin_unreachable
information in CCP2.

[Bug fortran/95544] ICE in gfc_can_put_var_on_stack, at fortran/trans-decl.c:494

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-1240-g7fd614ee818983274eb5e47cbb8ec68b20994963
Author: Harald Anlauf 
Date:   Thu Jun 11 20:29:45 2020 +0200

PR fortran/95544 - Fix ICE in NULL() argument to intrinsics

Fortran 2018: An argument to an intrinsic procedure other than ASSOCIATED,
NULL, or PRESENT shall be a data object.  An EXPR_NULL is not a data
object.  Add checks for intrinsics.

2020-06-11  Steven G. Kargl  
Harald Anlauf  

gcc/fortran/
PR fortran/95544
* check.c (invalid_null_arg): Rename to gfc_invalid_null_arg.
(gfc_check_associated, gfc_check_kind, gfc_check_merge)
(gfc_check_shape, gfc_check_size, gfc_check_spread)
(gfc_check_transfer): Adjust.
(gfc_check_len_lentrim, gfc_check_trim): Check for NULL() argument.
* gfortran.h: Declare gfc_invalid_null_arg ().
* intrinsic.c (check_arglist): Check for NULL() argument.

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
I'll commit that as obvious.

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:

https://gcc.gnu.org/g:800dac8fca3cf75512913e380df339fa2253ba76

commit r10-8274-g800dac8fca3cf75512913e380df339fa2253ba76
Author: Iain Sandoe 
Date:   Thu Jun 11 14:11:14 2020 +0100

coroutines: Ensure distinct DTOR trees [PR95137].

Part of the PR notes that there are UBSAN fails for the coroutines
test suite.  These are primarily related to the use of the same DTOR
tree in the two edges from the await block.  Fixed by building a new
tree for each.

gcc/cp/ChangeLog:

PR c++/95137
* coroutines.cc (expand_one_await_expression): Build separate
DTOR trees for the awaitable object on the destroy and resume
paths.

(cherry picked from commit 006f28aefeb3be575239beddc7febe56dff463a2)

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:393ccb72566dc004b9ab5c3b8fb6fdca6c095812

commit r11-1241-g393ccb72566dc004b9ab5c3b8fb6fdca6c095812
Author: Harald Anlauf 
Date:   Thu Jun 11 21:03:48 2020 +0200

PR fortran/95611 - ICE in access_attr_decl, at fortran/decl.c:9075

When reporting a duplicate access specification of an operator, refer to
the proper symbol.

2020-06-11  Harald Anlauf 

gcc/fortran/
PR fortran/95611
* decl.c (access_attr_decl): Use correct symbol in error message.

Co-Authored-By: Steven G. Kargl  

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-8275-g3b9a3b484f7c89bc5064bf32ecfa2b4aee218d5f
Author: Harald Anlauf 
Date:   Thu Jun 11 21:03:48 2020 +0200

PR fortran/95611 - ICE in access_attr_decl, at fortran/decl.c:9075

When reporting a duplicate access specification of an operator, refer to
the proper symbol.

2020-06-11  Harald Anlauf 

gcc/fortran/
PR fortran/95611
* decl.c (access_attr_decl): Use correct symbol in error message.

Co-Authored-By: Steven G. Kargl  
(cherry picked from commit 393ccb72566dc004b9ab5c3b8fb6fdca6c095812)

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-8667-gf2db0516e1ad6e1c08ed36b14920422f7699c153
Author: Harald Anlauf 
Date:   Thu Jun 11 21:03:48 2020 +0200

PR fortran/95611 - ICE in access_attr_decl, at fortran/decl.c:9075

When reporting a duplicate access specification of an operator, refer to
the proper symbol.

2020-06-11  Harald Anlauf 

gcc/fortran/
PR fortran/95611
* decl.c (access_attr_decl): Use correct symbol in error message.

Co-Authored-By: Steven G. Kargl  
(cherry picked from commit 393ccb72566dc004b9ab5c3b8fb6fdca6c095812)

[Bug fortran/95611] ICE in access_attr_decl, at fortran/decl.c:9075

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC-11, 10-branch and 9-branch.

Thanks for the report!

[Bug fortran/91640] [9 Regression] ICE: gimplification failed (contiguous expr)

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Tobias,

are you still planning a backport to 9-branch?

[Bug libstdc++/94749] std::istream::ignore discards too many characters

[serpent7776 at gmail dot com]

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

--- Comment #6 from serpent7776 at gmail dot com ---
thanks

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Thu, Jun 11, 2020 at 10:14:21AM -0700, Steve Kargl wrote:
> 
> IEEE-754 calls binary32, 64, 128 the basic formats (Sec. 3, p. 6):
> 
>   Five basic formats are defined in this clause:
> Three binary formats, with encodings in lengths of 32, 64, and 128 bits.
> Two decimal formats, with encodings in lengths of 64 and 128 bits.
> 
>   Additional arithmetic formats are recommended for extending these basic
>   formats (see 3.7).
> 
> If J3 really intended that IEEE_SELECTED_REAL_KIND return a kind for one of
> IEEE-754 basic formats, then it ought to say that.   Looks like a defect
> in the Fortran standard.
> 
> If one looks into 3.7 (p. 14), it further recommends
> 
>   Language standards should define mechanisms supporting extendable
>   precision for each supported radix.
> 

I have asked on the J3 mailing list if Section 17 should
be restricted to the basic formats.

[Bug libstdc++/95642] std::fstream ctr and open member functions fail to compile with argument of custom type convertible to std::filesystem::path

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is a known issue.

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

[Bug libstdc++/90704] filesystem::path overloads for file streams are not conforming

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||manx-bugzilla@problemloesun
   ||gsmaschine.de

--- Comment #2 from Jonathan Wakely  ---
*** Bug 95642 has been marked as a duplicate of this bug. ***