[Bug tree-optimization/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  ---
Author: pinskia
Date: Fri Dec 13 08:31:42 2019
New Revision: 279338

URL: https://gcc.gnu.org/viewcvs?rev=279338=gcc=rev
Log:
Add C testcases for PR 86659


testsuite/ChangeLog:
2019-12-13  Andrew Pinski  

   * gcc.c-torture/execute/pr86659-1.c: New test.
   * gcc.c-torture/execute/pr86659-2.c: New test.



Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr86659-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr86659-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/86659] [9 regression] gnat.dg/sso/q[23].adb FAIL

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> I have a C testcase which I will be adding by the end of the week.

Done:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00924.html
https://gcc.gnu.org/ml/gcc-cvs/2019-12/msg00460.html

[Bug sanitizer/92928] New: When address and UB sanitizer are combined, sanitizing boost serialization code crashes

[m4rk0p0p at gmail dot com]

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

Bug ID: 92928
   Summary: When address and UB sanitizer are combined, sanitizing
boost serialization code crashes
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m4rk0p0p at gmail dot com
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: ---

I've tried to use boost serialization to serialize a class which contains a
std::vector>> as a member (where Base is my abstract base
class). According to the boost documentation
(https://www.boost.org/doc/libs/1_71_0/libs/serialization/doc/serialization.html#derivedpointers),
we must register the derived classes using method register_type of the archive
for the serialization to work properly. However, calling this method results in
abnormal program termination if it is compiled with options -fsanitize=address
-fsanitize=undefined.

The whole example with serialization is too complicated to show here, but I've
analyzed the issue and identified the offending code on lines 188-190 in boost
void_cast
(https://github.com/boostorg/serialization/blob/develop/include/boost/serialization/void_cast.hpp).
In fact, the following program provides a minimal example that reproduces the
issue:

#include 

class Base
{
public:
virtual ~Base() = default;
virtual bool foo() noexcept = 0;
};

class Derived : public Base
{
public:
Derived() noexcept {};
bool foo() noexcept override { return true; };
};

int main()
{
auto diff = reinterpret_cast(
static_cast(reinterpret_cast(1 << 20))) - (1 << 20);

std::cout << diff << "\n";
}

Compiling this code with gcc 9.2 (using -fsanitize=address
-fsanitize=undefined) and running it results in the following output:

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 255
==3==ERROR: AddressSanitizer failed to allocate 0xdfff0001000 (15392894357504)
bytes at address 2008fff7000 (errno: 12)
==3==ReserveShadowMemoryRange failed while trying to map 0xdfff0001000 bytes.
Perhaps you're using ulimit -v

[Bug c++/92919] invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan)

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
valgrind reports this too:
==31127== Invalid read of size 1
==31127==at 0x2594AFA: wide_str_to_charconst (charset.c:1980)
==31127==by 0x2594AFA: cpp_interpret_charconst(cpp_reader*, cpp_token
const*, unsigned int*, int*) (charset.c:2045)
==31127==by 0xCE5C02: lex_charconst(cpp_token const*) (c-lex.c:1373)
==31127==by 0xCE3990: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:617)
==31127==by 0xAC982C: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:807)
==31127==by 0xAC94B5: cp_lexer_new_main() (parser.c:654)
==31127==by 0xACD972: cp_parser_new() (parser.c:3969)
==31127==by 0xB2E00F: c_parse_file() (parser.c:43064)
==31127==by 0xCF6495: c_common_parse_file() (c-opts.c:1186)
==31127==by 0x15141F6: compile_file() (toplev.c:458)
==31127==by 0x1517382: do_compile() (toplev.c:2267)
==31127==by 0x151767A: toplev::main(int, char**) (toplev.c:2406)
==31127==by 0x251E0F9: main (main.c:39)
==31127==  Address 0x51084af is 1 bytes before a block of size 2 alloc'd
==31127==at 0x483AD19: realloc (vg_replace_malloc.c:836)
==31127==by 0x25E0E6C: xrealloc (xmalloc.c:179)
==31127==by 0x2593C4C: cpp_interpret_string_1(cpp_reader*, cpp_string
const*, unsigned long, cpp_string*, cpp_ttype, cpp_string_location_reader*,
cpp_substring_ranges*) (charset.c:1753)
==31127==by 0x2594A30: cpp_interpret_string (charset.c:1784)
==31127==by 0x2594A30: cpp_interpret_charconst(cpp_reader*, cpp_token
const*, unsigned int*, int*) (charset.c:2036)
==31127==by 0xCE5C02: lex_charconst(cpp_token const*) (c-lex.c:1373)
==31127==by 0xCE3990: c_lex_with_flags(tree_node**, unsigned int*, unsigned
char*, int) (c-lex.c:617)
==31127==by 0xAC982C: cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*)
(parser.c:807)
==31127==by 0xAC94B5: cp_lexer_new_main() (parser.c:654)
==31127==by 0xACD972: cp_parser_new() (parser.c:3969)
==31127==by 0xB2E00F: c_parse_file() (parser.c:43064)
==31127==by 0xCF6495: c_common_parse_file() (c-opts.c:1186)
==31127==by 0x15141F6: compile_file() (toplev.c:458)

[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-13
  Component|target  |other
Summary|[avr] invalid merge of  |[8/9/10 Regression][avr]
   |symbols in progmem and data |invalid merge of symbols in
   |sections|progmem and data sections
 Ever confirmed|0   |1

--- Comment #2 from Georg-Johann Lay  ---
Confirmed with v8, v9 and v10.

Set component to "other" for now, dunno if it's a missing target hook or a tree
flaw.

[Bug preprocessor/92919] invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-13
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47486=edit
gcc10-pr92919.patch

Untested fix.

[Bug fortran/86416] [OMPVV SOLLVE] Defaultmap issues on OpenMP 4.5

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #4)
> > 2. CHARACTER default mapping not correct according to the specs.
> See PR 92920.

Missed a fineprint: OpenMP 4.5 + 5.0: "1.2.6 Data Terminology" has
"scalar variable
  For C/C++: A scalar variable, as defined by the base language.
  For Fortran: A scalar variable with intrinsic type, as defined by the
   base language, excluding character type."

[Bug fortran/92931] New: gfortran compiler errors

[zmth at yahoo dot com]

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

Bug ID: 92931
   Summary: gfortran compiler errors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmth at yahoo dot com
  Target Milestone: ---

Created attachment 47488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47488=edit
.o file

integer8 lisf(17),i8
nn=3
lisf=[1,1,2,(0,i=4,4*nn+5)] 
print,lisf
end

Then run the .exe file gives no reported error but it has the wrong, non 0,
values in the 5th thru 17th entries in array lisf. If change the 4*nn+5 to the
equal 17 then all is well.
Also the following does give the bogus ...array constructor... error message
when it should NOT.

integer8 lisf(17),i8
nn=3
i8=0
lisf=[1,1,2,(i8,i=4,4*nn+5)]
print,lisf
end

Windows 7 64bit , compile line :gfortran -save-temps gccerr.f03

[Bug fortran/92931] gfortran compiler errors

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-13
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
With the minimum fixes needed to make this Fortran.

implicit none
integer(8) lisf(17)
nn=3
lisf=[1,1,2,(0,i=4,4*nn+5)] 
print '(20(I0,1X))', lisf
end

% gfcx -o z -Wall a.f90
% ./z
1 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Looks like pilot error.

[Bug c++/91165] [10 Regression] error: location references block not in block tree

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #6)
> Slightly further reduced #c3:
> template  constexpr T bar (T c) { return c; }
> template  struct S {
>   T f;
>   U g;
>   constexpr S (T c, U h) : f(c), g(h) {}
> };
> template 
> constexpr S foo (T &, U h) { return S (c, bar (h)); }
> struct C { void baz (int); void qux (); };
> void C::baz (int a) { foo (a, ""); }
> void C::qux () { foo (0, ""); }
> 
> Seems some TARGET_EXPR is not unshared during the constexpr evaluation.

The expression that isn't being unshared here is &"", which is built in baz,
cached as the result of bar(&""), and reused when we again see bar(&"") while
evaluating the call to foo in qux.  This seems like reasonable sharing to me,
but perhaps we should strip locations from cached results.

[Bug target/92934] mips jump to invalid address

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The gcc patch that is attached has incorrect definition for allegrex_madd and
allegrex_msub.  It uses match_dup when it should really be using match_operand
and the constraint of "0".

[Bug c++/92933] [coroutines] compiler ICE compiling coroutine with try/catch

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe  ---
thanks,
oddly there's a test case in the test-suite that does something similar, I
shall have to investigate what's different in the codegen.

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
As for the other ICE, I'm still lost, I don't see similar bug to the above in
other functions that write summaries.
In output_symtab I see that all cgraph_nodes are streamed out, just those that
fail lto_symtab_encoder_in_partition_p (i.e. the non-offloaded ones) will not
have the callees and summaries and various other stuff streamed.
lto_output_node sets boundary_p for the other partition nodes, and that
sometimes leads to in_other_partition being set.  Now that certainly isn't set
when such nodes are streamed in again and e.g. FOR_EACH_DEFINED_FUNCTION then
happily iterates over those in the offloading lto1.  Note, modifying some flags
on nodes during the offloading LTO streaming is dangerous, as if we also stream
normal LTO, where e.g. in_other_partition shouldn't be set when for offloading
LTO it should be, we could be in trouble.

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

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

--- Comment #8 from Roman Zhuykov  ---
Fixed.

Yes, I'm closing the PR, I suppose this should not be backported.  It's a pity
we don't have an ability to create regression test for such situation.

[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Is this still an issue with current trunk?
Can you please check?

[Bug other/91189] 20% binary size regression in avr-gcc 9.1.0 from 8.3.0

[witold.a.markowski at gmail dot com]

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

Witold Markowski  changed:

   What|Removed |Added

 CC||witold.a.markowski at gmail 
dot co
   ||m

--- Comment #5 from Witold Markowski  ---
I did a small research in this topic and now I know that avr-gcc-9.1.0 compiler
generates some additional, overhead operations, like:


 932:   6e 87   std Y+14, r22   ; 0x0e
 934:   7f 87   std Y+15, r23   ; 0x0f
 936:   88 8b   std Y+16, r24   ; 0x10
 938:   99 8b   std Y+17, r25   ; 0x11
 93a:   6e 85   ldd r22, Y+14   ; 0x0e
 93c:   7f 85   ldd r23, Y+15   ; 0x0f
 93e:   88 89   ldd r24, Y+16   ; 0x10
 940:   99 89   ldd r25, Y+17   ; 0x11 

Storing and reading back the same registers.

I just found that exactly the same case is already reported with issue id
90706. Because of this I will not attach any examples here. In my opinion the
current issue depends on 90706 (please somebody update the 'Depends on' field
of the issue).
When 90706 is fixed then we should recheck this again and we will se how much
it improves the situation.

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
The ICE in determine_versionability is on:
3844if (node->has_gimple_body_p ()
3845&& opt_for_fn (node->decl, flag_ipa_cp)
3846&& opt_for_fn (node->decl, optimize))
3847  {
3848class ipa_node_params *info = IPA_NODE_REF (node);
3849determine_versionability (node, info);
651   info->versionable = (reason == NULL);
where info is NULL for a node that has been called from declare target to, but
is not itself marked declare target to.

[Bug c++/92933] New: [coroutines] compiler ICE compiling coroutine with try/catch

[lewissbaker.opensource at gmail dot com]

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

Bug ID: 92933
   Summary: [coroutines] compiler ICE compiling coroutine with
try/catch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lewissbaker.opensource at gmail dot com
  Target Milestone: ---

Created attachment 47490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47490=edit
Example program

Compiling the attached program crashes the compiler with a segmentation fault
when compiling with gcc coroutines branch.

See https://godbolt.org/z/kCNVfQ

This has a simple coroutine that looks like:

struct some_error {};

task foo() {
try {
co_return;
} catch (some_error) {
}
}

Compilation with '-std=c++2a' crashes with the following error:

: In function 'task foo()':
:64:1: internal compiler error: Segmentation fault
   64 | }
  | ^

Removing the try/catch compiles fine.
Replacing the catch(some_error) with catch(...) compiles fine.

[Bug c/92934] mips jump to invalid address

[pechenskih.stas at ya dot ru]

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

--- Comment #1 from darksectordds  ---
Created attachment 47492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47492=edit
example

Added example file

[Bug c/92934] New: mips jump to invalid address

[pechenskih.stas at ya dot ru]

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

Bug ID: 92934
   Summary: mips jump to invalid address
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pechenskih.stas at ya dot ru
  Target Milestone: ---

Created attachment 47491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47491=edit
dump-elf

Hello. 

I tried to add support for the Allegrex architecture (based on mips r4000).
After building the compiler, I started testing it and found that I can't access
a variable of type float. All times i got something like

23:57:284 user_mainE[JIT]: x86\compbranch.cpp:606 Jump to invalid address:
02428dd0 PC 0890a364 LR 0890a374
23:57:284 user_mainE[JIT]: x86\compbranch.cpp:606 Jump to invalid address:
02428dd0 PC 0890a36c LR 0890a374
23:57:284 user_mainE[JIT]: x86\compbranch.cpp:606 Jump to invalid address:
02428dd0 PC 0890a374 LR 0890a374
23:57:284 user_mainE[JIT]: x86\compbranch.cpp:597 Branch in Jump delay slot
at 0890a378 in block starting at 0890a364
23:57:284 user_mainE[JIT]: x86\compbranch.cpp:606 Jump to invalid address:
02428dd0 PC 0890a374 LR 0890a374
23:57:284 user_mainE[JIT]: x86\compbranch.cpp:597 Branch in Jump delay slot
at 0890a378 in block starting at 0890a374

I have only recently started to dive into such a low level of programming, so I
do not understand everything and what i do it's only for cognition as well.

I create a simple exaple with declare float type variable and print value.
I checked other types like this and all works fine except float type.
PS: all psp library got here https://github.com/pspdev/pspsdk

[Bug target/92934] mips jump to invalid address

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Andrew Pinski  ---
There are other issues with the patch than what I have gave.  Since you are
using a custom patch, you should report this issue to the patch author rather
than to us.  This is bugzilla is to report bugs against the fsf clean sources.

[Bug target/92934] mips jump to invalid address

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
.

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Instead of the #c6 patch, perhaps we want:
--- gcc/ipa-fnsummary.c.jj  2019-12-05 14:02:20.559570378 +0100
+++ gcc/ipa-fnsummary.c 2019-12-13 18:01:08.344828332 +0100
@@ -4364,24 +4364,24 @@ static void
 ipa_fn_summary_write (void)
 {
   struct output_block *ob = create_output_block (LTO_section_ipa_fn_summary);
+  lto_symtab_encoder_iterator lsei;
   lto_symtab_encoder_t encoder = ob->decl_state->symtab_node_encoder;
   unsigned int count = 0;
-  int i;

-  for (i = 0; i < lto_symtab_encoder_size (encoder); i++)
+  for (lsei = lsei_start_function_in_partition (encoder); !lsei_end_p (lsei);
+   lsei_next_function_in_partition ())
 {
-  symtab_node *snode = lto_symtab_encoder_deref (encoder, i);
-  cgraph_node *cnode = dyn_cast  (snode);
-  if (cnode && cnode->definition && !cnode->alias)
+  cgraph_node *cnode = lsei_cgraph_node (lsei);
+  if (cnode->definition && !cnode->alias)
count++;
 }
   streamer_write_uhwi (ob, count);

-  for (i = 0; i < lto_symtab_encoder_size (encoder); i++)
+  for (lsei = lsei_start_function_in_partition (encoder); !lsei_end_p (lsei);
+   lsei_next_function_in_partition ())
 {
-  symtab_node *snode = lto_symtab_encoder_deref (encoder, i);
-  cgraph_node *cnode = dyn_cast  (snode);
-  if (cnode && cnode->definition && !cnode->alias)
+  cgraph_node *cnode = lsei_cgraph_node (lsei);
+  if (cnode->definition && !cnode->alias)
{
  class ipa_fn_summary *info = ipa_fn_summaries->get (cnode);
  class ipa_size_summary *size_info = ipa_size_summaries->get (cnode);
which follows what the other IPA function summary writer functions do?
Of course, this doesn't do anything about determine_versionability ICE.

[Bug target/92934] mips jump to invalid address

[pechenskih.stas at ya dot ru]

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

--- Comment #6 from darksectordds  ---
That was my patch. I've only recently started to study it all.

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

--- Comment #7 from Roman Zhuykov  ---
Author: zhroma
Date: Fri Dec 13 17:33:38 2019
New Revision: 279377

URL: https://gcc.gnu.org/viewcvs?rev=279377=gcc=rev
Log:
modulo-sched: fix branch rescheduling issue (PR92591)

PR rtl-optimization/92591
* modulo-sched.c (ps_add_node_check_conflicts): Improve checking
for history > 0 case.

testsuite:

PR rtl-optimization/92591
* gcc.dg/pr92951-1.c: New test.
* gcc.dg/pr92951-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr92951-1.c
trunk/gcc/testsuite/gcc.dg/pr92951-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/modulo-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Looking into how getter variable is determined:

vp_35 is function parameter
_124 = MEM[(const struct Value *)vp_35(D)].asBits_;
_125 = _124 ^ 18446181123756130304;
_126 = (struct JSObject *) _125
...
_50 = MEM[(struct Function *)_126].jitinfo
...
getter_60 = _50->D.102800.getter;
ok_64 = getter_60 (cx_325(D), D.1007269, self_323, D.1007259)

Seems our jump functions would need a lot of work to handle this.

[Bug middle-end/86416] [OpenMP] Offloading - better lto1 error message if mode not supported on offloading target

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||lto
  Component|fortran |middle-end
Summary|[OMPVV SOLLVE] Defaultmap   |[OpenMP] Offloading -
   |issues on OpenMP 4.5|better lto1 error message
   ||if mode not supported on
   ||offloading target

--- Comment #7 from Tobias Burnus  ---
Let's change the PR's subject to something more explicit for the first issue.
(Especially as the second one is INVALID.)

I have also posted an initial patch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00970.html

[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
The problem is that there isn't even a target hook to disallow such
optimizations, files as as PR92932.

In a respective hook, at least the attributes and address spaces of either
object must be available.

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
I'll note that GCC doesn't yet implement the OpenMP 5.0 automatic declare
target for functions with definitions called from declare target functions or
target regions.  I've tried to do that this summer, but came up with too many
questions for which there are no answers yet, so it is e.g. unclear where the
compiler should do it, the implementation I had (will attach) was done quite
late, which means e.g. that if it should affect in the end whether some
variables will be declare target or not implicitly, it would be too late to
change depending on that the implicit mapping or privatization behavior on
target constructs, because by the time target is resolved declare variant on
some vars still wouldn't be done implicitly.
In the #c1 testcase, I see only two templates with their single or so method
each wrapped in declare target and nothing else, so I bet the testcase is
invalid (dunno if that is in the original RAJA).

Anyway, with Honza's help I came up with:
--- gcc/ipa-fnsummary.c 2019-12-03 21:45:21.538147319 +0100
+++ gcc/ipa-fnsummary.c 2019-12-13 16:24:14.007917974 +0100
@@ -4372,7 +4372,10 @@ ipa_fn_summary_write (void)
 {
   symtab_node *snode = lto_symtab_encoder_deref (encoder, i);
   cgraph_node *cnode = dyn_cast  (snode);
-  if (cnode && cnode->definition && !cnode->alias)
+  if (cnode
+ && cnode->definition
+ && !cnode->alias
+ && lto_symtab_encoder_in_partition_p (encoder, cnode))
count++;
 }
   streamer_write_uhwi (ob, count);
@@ -4381,7 +4384,10 @@ ipa_fn_summary_write (void)
 {
   symtab_node *snode = lto_symtab_encoder_deref (encoder, i);
   cgraph_node *cnode = dyn_cast  (snode);
-  if (cnode && cnode->definition && !cnode->alias)
+  if (cnode
+ && cnode->definition
+ && !cnode->alias
+ && lto_symtab_encoder_in_partition_p (encoder, cnode))
{
  class ipa_fn_summary *info = ipa_fn_summaries->get (cnode);
  class ipa_size_summary *size_info = ipa_size_summaries->get (cnode);
patch with which this ICE is gone but there is another later on, so more work
is needed.

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 47489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47489=edit
gcc10-implicit-declare-target-to.patch

For reference, here is the implicit declare target to discovery, but done late
rather than early.
And the unclear things include e.g. "Implicit declare target to discovery" mail
to omp-lang in August.

[Bug c/92934] mips jump to invalid address

[pechenskih.stas at ya dot ru]

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

--- Comment #2 from darksectordds  ---
Created attachment 47493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47493=edit
allegrex support

Added path for allegrex support.

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

[zhroma at gcc dot gnu.org]

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

--- Comment #6 from Roman Zhuykov  ---
Author: zhroma
Date: Fri Dec 13 17:02:53 2019
New Revision: 279375

URL: https://gcc.gnu.org/viewcvs?rev=279375=gcc=rev
Log:
modulo-sched: speed up DDG analysis (PR90001)

PR rtl-optimization/90001
* ddg.c (create_ddg): Init max_dist array for each node.
(free_ddg): Free max_dist array.
(create_ddg_edge): Use bool field instead of aux union.
(set_recurrence_length): Use prepared max_dist information instead
of calling longest_simple_path.
(create_scc): Remove graph argument, fill node's aux.count with
SCC id, and move set_recurrence_length call to...
(create_ddg_all_sccs): ...here, after filling all max_dist arrays
using Floyd–Warshall-like algorithm.
(update_dist_to_successors): Remove the whole function.
(longest_simple_path): Likewise.
* ddg.h (struct ddg_node): Add max_dist pointer.
(struct ddg_edge): Use bool field instead of unused aux union.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ddg.c
trunk/gcc/ddg.h

[Bug target/83464] [SH] ICE: in final_scan_insn, at final.c:3025 with -mlra

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #4 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #3)
> Is this still an issue with current trunk?
> Can you please check?

I have to try. I'll run a testbuild. Currently the package has the following
workaround for PR/81426:

# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
ifneq (,$(filter $(DEB_HOST_ARCH_CPU),sh3 sh4))
export DEB_CXXFLAGS_MAINT_STRIP += -O2
export DEB_CXXFLAGS_MAINT_APPEND += -O1
endif

See:
https://salsa.debian.org/qt-kde-team/qt/qt5webkit/blob/master/debian/rules#L20

Maybe LRA works these days.

[Bug fortran/92931] gfortran compiler errors

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to dan hayes from comment #0)
> Created attachment 47488 [details]
> .o file
> 
> integer8 lisf(17),i8
> nn=3
> lisf=[1,1,2,(0,i=4,4*nn+5)] 
> print,lisf
> end
> 

This is not the code you tested as it is not Fortran.

gfcx -o z a.f90
a.f90:1:8:

1 | integer8 lisf(17),i8
  |1
Error: Malformed type-spec at (1)
a.f90:3:0:

3 | lisf=[1,1,2,(0,i=4,4*nn+5)]
  | 
Error: Incompatible ranks 0 and 1 in assignment at (1)

[Bug tree-optimization/92932] New: Optimizers generate wrong code due to aggressive data optimization.

[gjl at gcc dot gnu.org]

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

Bug ID: 92932
   Summary: Optimizers generate wrong code due to aggressive data
optimization.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

GCC sometimes aliases symbols if they refer to identical data.  However, in
order for this to be legitimate optimization, it must be ensured that the code
will be accessed in the same way.

This is not always the case, an example where this generates wrong code is
PR92606.

Such a new hook needs at least the following information to disallow aliasing 
by means of .set or similar means:

* The attributes specified for either objects.

* The address spaces specified for either objects.

[Bug tree-optimization/92932] Optimizers generate wrong code due to aggressive data optimization.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Blocks||92606
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
[Bug 92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and
data sections

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Thomas Henlich from comment #13)
> Just a minor issue: I think that the sense of the message arguments in calls
> to gfc_notify_std() should be inverted - they should describe the feature as
> supported in the correct standard, and not as an error message.
> 
> For example:
> 
> gfc_notify_std (GFC_STD_F2018, "positive width required at %L",
> _locus)
> 
> should read
> gfc_notify_std (GFC_STD_F2018, "zero width at %L", _locus)
> 
> It just seems counter-intuitive to read a message like:
> gfortran -std=f2008 -o test-f2018.exe test-f2018.f90
> 
> 2 | write(*, "(e0.10e2)")  0.00314_4
>   |1
> Error: Fortran 2018: positive width required at (1)
> 
> because the user is trying to access a feature (zero width) of Fortran 2018,
> but that fails. The current message implies that "Fortran 2018 requires a
> positive width" which is exactly the opposite, this is confusing.

% cd gcc/fortran
% grep gfc_notify_std *c | wc -l
 280

Need to audit at least 280 uses of gfc_notify_std.


Looks like a good introductory task for a new gfortran contributor.

[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler

[asolokha at gmx dot com]

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

--- Comment #7 from Arseny Solokha  ---
There are no backporting pending, I believe? If so, should this PR be closed
now?

[Bug fortran/92920] [OpenMP] Implicit mapping of character scalars (nonalloc/nonptr) – shall be firstprivate not tofrom

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #3 from Tobias Burnus  ---
INVALID.

Missed a fineprint in the spec (OpenMP 4.5 + 5.0: "1.2.6 Data Terminology"):

"scalar variable
  For C/C++: A scalar variable, as defined by the base language.
  For Fortran: A scalar variable with intrinsic type, as defined by the
   base language, excluding character type."

Hence, the current version is fine.

[Bug sanitizer/92928] When address and UB sanitizer are combined, sanitizing boost serialization code crashes

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Even more reduced (without headers):
struct Base
{
  virtual ~Base() = default;
  virtual bool foo() noexcept = 0;
};

struct Derived : public Base
{
  Derived() noexcept {};
  bool foo() noexcept override { return true; };
};

int main()
{
  int diff = reinterpret_cast<__PTRDIFF_TYPE__>(static_cast(reinterpret_cast(1 << 20))) - (1 << 20);
  __builtin_printf ("%d\n", diff);
}

I'd say this is just invalid, there is no object of type Base or Derived at the
address 1 << 20 and -fsanitize=vptr attempts to verify that the object has the
right virtual table pointer, but as nothing is mapped at 1 << 20, that access
obviously fails.
You get exactly the same behavior with clang++ -fsanitize=address,undefined.
Both will work with -fsanitize=address,undefined -fno-sanitize=vptr.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #15)
> Would it work to include them at the end of BINFO_VIRTUALS but omit them 
> in build_vtbl_initializer?

With my very limited understanding, I thought that for the vtables it is
important that if a base defines some virtual method that for a derived type
which either doesn't override it or overrides it the same virtual method has
the same index.  Now, if the consteval virtuals are at the end of
BINFO_VIRTUALS but indexed from the start as others, if say base has 3 normal
and 2 consteval virtual methods, 0/1/2 indexes will be the normal and 3/4 will
be the consteval ones.  If I derive a class from this, don't override the first
normal virtual method, override the second one (dtor, two entries), don't
override the first consteval method, override the second one and add one new
normal and one new consteval methods, like:
struct base {
  virtual int foo ();
  virtual ~base ();
  virtual consteval int bar () { return 42; }
  virtual consteval int baz () { return 43; }
};
struct derived : public base {
  virtual ~derived ();
  virtual consteval int baz () { return 44; }
  virtual int qux ();
  virtual consteval int quux () { return 45; }
};
what would happen with indexes in derived BINFO_VIRTUALS?  If the non-consteval
ones need to go first as that is what we emit into vtables, then qux needs to
have index 3, but doesn't bar already have that?

The only thing that comes to my mind is to use  e.g. negative indexes for the
consteval methods and count in that case from the end, i.e. foo would get
DECL_VINDEX 0, dtors DECL_VINDEX 1/2, bar DECL_VINDEX -1, baz DECL_VINDEX -2,
qux DECL_VINDEX 3 and quux DECL_VINDEX -3 and when actually looking up the
entry in BINFO_VIRTUALS, transform negative indexes into chain_length
(BINFO_VIRTUALS) + DECL_VINDEX, i.e. bar would be the last in BINFO_VIRTUALS
chain of both base and derived, baz the penultimate and quux in derived the
antepenultimate.
Thoughts on that?

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #13 from Thomas Henlich  ---
Just a minor issue: I think that the sense of the message arguments in calls to
gfc_notify_std() should be inverted - they should describe the feature as
supported in the correct standard, and not as an error message.

For example:

gfc_notify_std (GFC_STD_F2018, "positive width required at %L", _locus)

should read
gfc_notify_std (GFC_STD_F2018, "zero width at %L", _locus)

It just seems counter-intuitive to read a message like:
gfortran -std=f2008 -o test-f2018.exe test-f2018.f90

2 | write(*, "(e0.10e2)")  0.00314_4
  |1
Error: Fortran 2018: positive width required at (1)

because the user is trying to access a feature (zero width) of Fortran 2018,
but that fails. The current message implies that "Fortran 2018 requires a
positive width" which is exactly the opposite, this is confusing.

[Bug target/92904] varargs for __int128 is placed at an unaligned location and uses movdqa for the load

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug fortran/92929] New: Fortran OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92929
   Summary: Fortran OpenACC/OpenMP 'target' 'exit data'/'update'
optimizations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
jules at gcc dot gnu.org
  Target Milestone: ---

As of Tobias' recent r277631 "Fortran/OpenMP] Don't create "alloc:" for 'target
exit data'",
,
this is done for Fortran OpenMP '!$omp target exit data'/'!$omp target update',
but not for OpenACC '!$acc exit data'/'!$acc update'; see
'gcc/gimplify.c:gimplify_scan_omp_clauses':

/* For Fortran, not only the pointer to the data is mapped but also
   the address of the pointer, the array descriptor etc.; for
   'exit data' - and in particular for 'delete:' - having an 'alloc:'
   does not make sense.  Likewise, for 'update' only transferring the
   data itself is needed as the rest has been handled in previous
   directives.  */
if ((code == OMP_TARGET_EXIT_DATA || code == OMP_TARGET_UPDATE)
&& (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_POINTER
|| OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_TO_PSET))
  remove = true;

Note that I'm not proposing to also do that for OpenACC at this point; I have
one doubt about that I need to look into first, but don't have time for right
now.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Increasing number of entries does not seem to help:
Indirect call counterall: 140960933, values: [429856732:-1], [484692916:1218],
[1203869319:12593], [245854587:8179], [1829590552:52], [401302964:7072],
[839575652:1422], [2041842690:854], [1646699888:428], [1259057892:1485],
[1777186207:1066], [901349086:1276], [2135000278:93], [1926702874:1281],
[2135000278:108], [717405103:513].

[Bug c++/92357] ICE in IPA pass fnsummary in openmp offload

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 47487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47487=edit
pr92357.C

Further reduced.

[Bug other/92606] [8/9/10 Regression][avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Created attachment 47485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47485=edit
123f.c: C test case with address space __flash.

...and the code is also wrong with address spaces like __flash (and the same
options like in comment #1):

$ avr-gcc -mmcu=atmega128 123f.c -flto -Os -save-temps -o 123f.elf

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

--- Comment #3 from Thomas Schwinge  ---
(In reply to myself from comment #1)
> /* For target {,enter ,exit }data only the array slice is
>mapped, but not the pointer to it.  */

Some handling for OpenACC 'data' got added in r236678 "use firstprivate
pointers for subarrays in c and c++",
, but is
somewhat spread out, and not easy to follow:

case OACC_DATA:
  if (TREE_CODE (TREE_TYPE (decl)) != ARRAY_TYPE)
break;
  /* FALLTHRU */
case OMP_TARGET_DATA:
case [...]:
  if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
  || (OMP_CLAUSE_MAP_KIND (c)
  == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
/* For target {,enter ,exit }data only the array slice is
   mapped, but not the pointer to it.  */
remove = true;
[...]
if (code == OACC_DATA
&& OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
&& (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
|| OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
  remove = true;
if (remove)
  *list_p = OMP_CLAUSE_CHAIN (c);

..., and not sure if this also relates to the following:

'omp_notice_variable':

if (octx->region_type == ORT_ACC_DATA
  && (n2->value & GOVD_MAP_0LEN_ARRAY))
nflags |= GOVD_MAP_0LEN_ARRAY;
goto found_outer;

'gimplify_scan_omp_clauses':

if (code == OACC_DATA
&& OMP_CLAUSE_CODE (c) == OMP_CLAUSE_MAP
&& OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER)
  flags |= GOVD_MAP_0LEN_ARRAY;

(Maybe the idea there is to preserve 'GOMP_MAP_FIRSTPRIVATE_POINTER',
'GOMP_MAP_FIRSTPRIVATE_REFERENCE' until some other processing
('GOVD_MAP_0LEN_ARRAY') has been done, and only then remove them, right at the
end.  But that wouldn't be quite obvious.)

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #14 from Thomas Henlich  ---
(In reply to Thomas Henlich from comment #13)

As reference, see this comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081#c0

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #15 from Thomas Henlich  ---
(In reply to Thomas Henlich from comment #13)

As reference, see this comment:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081#c0

[Bug target/92922] [10 regression] [ilp32] FAIL: gcc.target/aarch64/sve/acle/asm/ldnt1_u32.c -std=c90 -O1 -g -DTEST_FULL (internal compiler error)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|[10 regression] FAIL:   |[10 regression] [ilp32]
   |gcc.target/aarch64/sve/acle |FAIL:
   |/asm/ldnt1_u32.c  -std=c90  |gcc.target/aarch64/sve/acle
   |-O1 -g -DTEST_FULL  |/asm/ldnt1_u32.c  -std=c90
   |(internal compiler error)   |-O1 -g -DTEST_FULL
   ||(internal compiler error)

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[antoshkka at gmail dot com]

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

Antony Polukhin  changed:

   What|Removed |Added

 CC||antoshkka at gmail dot com

--- Comment #16 from Antony Polukhin  ---
Can we increase the priority of this issue to P1 or P2? It affects the very
basics of the C++.

BTW, I've minimized example. It aborts on every version of GCC with -std=c++11,
passes on Clang:


int constructed = 0;

class lock_guard_ext{
public:
lock_guard_ext() { ++constructed; }
~lock_guard_ext() { --constructed; }
};

struct Access {
lock_guard_ext lock;
int value;
};

int t() {
throw 0;
}

Access foo1() {
return { {}, t() };
}

int main () {
try {
foo1();
} catch (int) {}
if (constructed != 0)
__builtin_abort();
}

[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug target/92606] [avr] invalid merge of symbols in progmem and data sections

[gjl at gcc dot gnu.org]

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

--- Comment #1 from Georg-Johann Lay  ---
Created attachment 47484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47484=edit
123.c: C test case.

Confirmed with the attached test case compiler with

$ avr-gcc -mmcu=atmega128 123.c -flto -Os -save-temps -o 123.elf

Then 123.elf.ltrans0.s reads:

xyz_prog:
.byte   123
...
.setxyz,xyz_prog

Which is obviously wrong.  With -ffat-lto-objects (so that 123.s has asm code)
it is correct: xyz and xyz_prog are distinct objects, the first in .data and
the latter in .progmem.data.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #12 from Thomas Henlich  ---
The following:

program test
write(*, "(e0.10e2)")  0.00314_4
end

results in error:

At line 2 of file test-f2018.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Period required in format
(e0.10e2)
^

[Bug inline-asm/92921] Feature request: Automatic transliteration of AT inline asm into Intel syntax

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #1)
> The pattern in inline asm is intentionally a black box, it can contain
> anything and can be used for all kinds of purposes.  So, doing any kind of
> such transformations is a bad idea.

I agree.  LLVM tries to mimic GCC's inline-asm but falls over because it does
not treat it as a black box as GCC does.  This is why LLVM keeps on adding
these "features".  There are other "features" which LLVM adds to inline-asm to
try to get better inline-asm but it falls over when porting good inline-asm
from GCC to LLVM.

[Bug target/92908] [10 Regression] wrong code with -Og -fno-tree-fre -mavx512bw and vector compare

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Dec 13 10:12:55 2019
New Revision: 279369

URL: https://gcc.gnu.org/viewcvs?rev=279369=gcc=rev
Log:
PR target/92908
* simplify-rtx.c (simplify_relational_operation): Punt for vector
cmp_mode and scalar mode, if simplify_relational_operation returned
const_true_rtx.
(simplify_const_relational_operation): Change VOID_mode in function
comment to VOIDmode.

* gcc.target/i386/avx512bw-pr92908.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr92908.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

  Component|fortran |middle-end
Summary|Fortran OpenACC/OpenMP  |OpenACC/OpenMP 'target'
   |'target' 'exit  |'exit data'/'update'
   |data'/'update'  |optimizations
   |optimizations   |

--- Comment #1 from Thomas Schwinge  ---
Relatedly, since r228777 "Merge from gomp-4_1-branch to trunk" ("which brings
in most of the OpenMP 4.5 support for C and C++"), the following optimization
is done:

case OMP_TARGET_ENTER_DATA:
case OMP_TARGET_EXIT_DATA:
case OACC_ENTER_DATA:
case OACC_EXIT_DATA:
case OACC_HOST_DATA:
  if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
  || (OMP_CLAUSE_MAP_KIND (c)
  == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
/* For target {,enter ,exit }data only the array slice is
   mapped, but not the pointer to it.  */
remove = true;
  break;

Why is this not applicable for OpenACC '!$acc update'/OpenMP '!$omp target
update', too?  (This is now also relevant for C/C++.)

[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to myself from comment #1)
>   if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FIRSTPRIVATE_POINTER
>   || (OMP_CLAUSE_MAP_KIND (c)
>   == GOMP_MAP_FIRSTPRIVATE_REFERENCE))
> /* For target {,enter ,exit }data only the array slice is
>mapped, but not the pointer to it.  */
> remove = true;

> Why is this not applicable for OpenACC '!$acc update'/OpenMP '!$omp target
> update', too?  (This is now also relevant for C/C++.)

I see I asked the same question before, and in
 Cesar answered:
"I suppose they can be added here, but lower_omp_target already ignores
GOMP_MAP_FIRSTPRIVATE_POINTER for non-offloaded and data_region regions."

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-13
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
I hacked libgcov to make merging no longer reproducible
Index: libgcov-merge.c
===
--- libgcov-merge.c (revision 279167)
+++ libgcov-merge.c (working copy)
@@ -130,12 +130,27 @@ merge_topn_values_set (gcov_type *counte
}
}

+  if (j == GCOV_TOPN_VALUES)
+   {
+ int min = 0;
+ for (j = 1; j < GCOV_TOPN_VALUES; j++)
+   if (counters[2 * j + 1] < counters[2 * min + 1])
+ min = j;
+ if (counters[2 * min + 1] < read_counters[2 * i + 1])
+   {
+  counters[2 * min] = read_counters[2 * i];
+  counters[2 * min + 1] = read_counters[2 * i + 1];
+   }
+   }
+
+#if 0
   /* We haven't found a slot, bail out.  */
   if (j == GCOV_TOPN_VALUES)
{
  counters[1] = -1;
  return;
}
+#endif
 }
 }

with this I now get:
Trying transformations on stmt ok_20 = getter_18 (cx_131(D), D.1007269,
self_129, D.1007259);
Indirect call counterall: 140964179, values: [939751711:140005207],
[2105057161:149880], [708289787:11], [484692916:60283], [1777186207:5],
[245854587:38900], [1967741779:28458], [1785108787:23272], [429856732:17057],
[401533446:13488], [1203869319:10772], [183365365:9606], [401302964:7243],
[824316005:3379], [758688187:2121], [1528155396:1983].
/aux/hubicka/firefox-2019-2/dom/bindings/BindingUtils.cpp:3035:19: missed:
Indirect call -> direct call from other module getter_18=> 939751711 (will
resolve only with LTO)

So the histogram of destinations is indeed greatly dominated by one estination
but there are very many others (not all are listed since I started dropping
them).

One way to make reproducible merging better is to drop destinations with small
trip counts before merging, but I am not sure it would help everywhere.

[Bug middle-end/92930] New: GCC incorrectly optimizes away __builtin_apply() calls

[green at redhat dot com]

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

Bug ID: 92930
   Summary: GCC incorrectly optimizes away __builtin_apply() calls
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: green at redhat dot com
  Target Milestone: ---

Compile the following with -O2 and it optimizes away the call to bar()/foo(). 
This is incorrect, as foo() may have side-effects.


void foo(int a, int b, int c, int d, int e, int f, int g);

static void bar(int a, ...)
{
  __builtin_apply(foo, __builtin_apply_args(), 20);
}

int main(void)
{
  bar(1024, 1025, 1026, 1027, 1028, 1029, 1030);

  return 0;
}

[Bug tree-optimization/92932] Optimizers generate wrong code due to aggressive data optimization.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Dup of at least PR92294 and  PR54666; I thought there was a much older bug
dealing with the alias attribute but I can't seem to find it right now.

[Bug fortran/91726] [8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from anlauf at gcc dot gnu.org ---
This appears to be fixed on trunk.  Since this is marked as a regression,
shall it be backported?

[Bug rtl-optimization/90706] [9/10 Regression] Useless code generated for stack / register operations on AVR

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||larsch at belunktum dot dk

--- Comment #6 from Georg-Johann Lay  ---
*** Bug 91189 has been marked as a duplicate of this bug. ***

[Bug other/91189] 20% binary size regression in avr-gcc 9.1.0 from 8.3.0

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Georg-Johann Lay  ---


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

[Bug fortran/57129] [8/9/10 Regression] Improve error message for conflicts between PROCEDURE and DERIVED.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #18 from anlauf at gcc dot gnu.org ---
The error message emitted for the code in comment#0 is:

z0.f90:2:8:

2 |   type t
  |1
Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 't' at (1)
z0.f90:3:5:

3 |   end type t
  | 1
Error: Expecting END SUBROUTINE statement at (1)
z0.f90:4:19:

4 |   type, extends(t) :: t2
  |   1
Error: Symbol 't' at (1) has not been previously defined
z0.f90:5:5:

5 |   end type t2
  | 1
Error: Expecting END SUBROUTINE statement at (1)

Is there anything left to do?

[Bug c/92935] New: typeof() on an atomic type doesn't always return the corresponding unqualified type

[luc.vanoostenryck at gmail dot com]

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

Bug ID: 92935
   Summary: typeof() on an atomic type doesn't always return the
corresponding unqualified type
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luc.vanoostenryck at gmail dot com
  Target Milestone: ---

Created attachment 47495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47495=edit
testcases

typeof() on an atomic type is supposed to return the corresponding
unqualified type.

This is what's happening in cases like:
const _Atomic int tmp;
typeof(tmp) i;
or
typeof(({_Atomic typeof(const int) tmp; })) j;

But, surprisingly, it's not what's happening in a simpler case like:
typeof(_Atomic const int) k;
or
typeof(_Atomic typeof(const int)) l;

[Bug fortran/92114] equivalence in module causes ICE

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-13
  Known to work||10.0, 8.3.1, 9.2.1
 Ever confirmed|0   |1

--- Comment #4 from anlauf at gcc dot gnu.org ---
Since this works with 8.3.1 and higher, is it fixed, and can this PR be closed?

[Bug middle-end/92930] [8/9/10 Regression] GCC incorrectly optimizes away __builtin_apply() calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-13
 CC||jakub at gcc dot gnu.org
Version|unknown |10.0
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.4
Summary|GCC incorrectly optimizes   |[8/9/10 Regression] GCC
   |away __builtin_apply()  |incorrectly optimizes away
   |calls   |__builtin_apply() calls
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
I think this started with r160615.

[Bug tree-optimization/92930] [8/9/10 Regression] GCC incorrectly optimizes away __builtin_apply() calls

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47494=edit
gcc10-pr92930.patch

Untested fix.

[Bug fortran/92114] equivalence in module causes ICE

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Fri, Dec 13, 2019 at 09:20:24PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114
> 
> anlauf at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2019-12-13
>   Known to work||10.0, 8.3.1, 9.2.1
>  Ever confirmed|0   |1
> 
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> Since this works with 8.3.1 and higher, is it fixed, and can this PR be 
> closed?
> 

I think the answer is "yes".

The 7-branch is now closed, so what happens
on 7.x is no longer germaine.  This may also
be cygwin specific, and comment #3 appears 
to confirm that the code compiles with at
least 8.3.

[Bug c++/92933] [coroutines] compiler ICE compiling coroutine with try/catch

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
Author: iains
Date: Fri Dec 13 21:40:59 2019
New Revision: 279385

URL: https://gcc.gnu.org/viewcvs?rev=279385=gcc=rev
Log:
c++-coroutines - Fix PR 92933.

This fixes an omission in handling registration of local variables,
where compiler-generated ones have no name.

2019-12-13  Iain Sandoe  

gcc/cp/

PR c++/92933
* coroutines.cc (register_local_var_uses): Handle unnamed
compiler-generated local variables.


Added:
branches/c++-coroutines/gcc/testsuite/g++.dg/coroutines/torture/pr92933.C
Modified:
branches/c++-coroutines/ChangeLog.coroutines
branches/c++-coroutines/gcc/cp/coroutines.cc

[Bug c++/92933] [coroutines] compiler ICE compiling coroutine with try/catch

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Sandoe  ---
fixed on the branch, it should percolate through to compiler explorer in due
course.

[Bug libgomp/92881] [OpenACC] In async context, need to use 'gomp_remove_var_async' instead of 'gomp_remove_var'

[jules at gcc dot gnu.org]

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

--- Comment #1 from jules at gcc dot gnu.org ---
Author: jules
Date: Fri Dec 13 23:14:15 2019
New Revision: 279388

URL: https://gcc.gnu.org/viewcvs?rev=279388=gcc=rev
Log:
Fix potential race condition in OpenACC "exit data" operations

PR libgomp/92881

libgomp/
* libgomp.h (gomp_remove_var_async): Add prototype.
* oacc-mem.c (delete_copyout): Call gomp_remove_var_async instead of
gomp_remove_var.
* target.c (gomp_unref_tgt): Change return type to bool, indicating
whether target_mem_desc was unmapped.
(gomp_unref_tgt_void): New.
(gomp_remove_var): Reimplement in terms of...
(gomp_remove_var_internal): ...this new helper function.
(gomp_remove_var_async): New, implemented using above helper function.
(gomp_unmap_vars_internal): Use gomp_unref_tgt_void instead of
gomp_unref_tgt.

Reviewed-by: Thomas Schwinge 

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/libgomp.h
trunk/libgomp/oacc-mem.c
trunk/libgomp/target.c

[Bug tree-optimization/92938] constprop function is assigned to a different section than the original function

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
I don't think this is a GCC bug.
The reasoning is bitmap_replace is not marked as being in the section .init_*
at all.  GCC decides to clone it for constant-prop.  Really any function which
is marked as __gnu_inline__ should not be marked as static or should be marked
as always_inline instead.

[Bug tree-optimization/92938] constprop function is assigned to a different section than the original function

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> The reasoning is bitmap_replace is not marked as being in the section
> .init_* at all.

Yes, and thus it should not make direct references to data which is in .init*
sections.

> GCC decides to clone it for constant-prop.  Really any
> function which is marked as __gnu_inline__ should not be marked as static or
> should be marked as always_inline instead.

I've removed __gnu_inline__ attribute, so that function definition looks like
this:

static inline void bitmap_replace(unsigned long *dst,
  const unsigned long *old,
  const unsigned long *new,
  const unsigned long *mask,
  unsigned int nbits)
{
 if ((__builtin_constant_p(nbits) && (nbits) <= 32 && (nbits) > 0))
  *dst = (*old & ~(*mask)) | (*new & *mask);
 else
  __bitmap_replace(dst, old, new, mask, nbits);
}

This does not resolve the issue.

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Sat Dec 14 00:52:46 2019
New Revision: 279392

URL: https://gcc.gnu.org/viewcvs?rev=279392=gcc=rev
Log:
PR middle-end/91582 - missing heap overflow detection for strcpy
PR middle-end/92868 - ICE: tree check: expected integer_cst, have ssa_name

gcc/ChangeLog:

PR middle-end/91582
PR middle-end/92868
* builtins.c (addr_decl_size): New function.
(gimple_call_alloc_size): Add arguments.
(compute_objsize): Add an argument.  Set *PDECL even for allocated
objects.
Correct checking for negative wide_int.
Correct handling of negative outer offsets into unknown regions
or with unknown inner offsets.
Extend offsets to at most sizetype precision.
Only handle constant subobject sizes.
* builtins.h (gimple_call_alloc_size): Add arguments.
* tree.c (component_ref_size): Always return sizetype.
* tree-ssa-strlen.c (strinfo::alloc): New member.
(get_addr_stridx): Add argument.
(get_stridx): Use ptrdiff_t.  Add argument.
(new_strinfo): Set new member.
(get_string_length): Handle alloca and VLA.
(dump_strlen_info): Dump more state.
(maybe_invalidate): Print more info.  Decrease indentation.
(unshare_strinfo): Set new member.
(valid_builtin_call): Handle alloca and VLA.
(maybe_warn_overflow): Check and set no-warning bit.  Improve
handling of offsets.  Print allocated objects.
(handle_builtin_strlen): Handle strinfo records with null lengths.
(handle_builtin_strcpy): Add argument.  Call maybe_warn_overflow.
(is_strlen_related_p): Handle dynamically allocated objects.
(get_range): Add argument.
(handle_builtin_malloc): Rename...
(handle_alloc): ...to this and handle all allocation functions.
(handle_builtin_memset): Call maybe_warn_overflow.
(count_nonzero_bytes): Handle more MEM_REF forms.
(strlen_check_and_optimize_call): Call handle_alloc_call.  Pass
arguments to more callees.
(handle_integral_assign): Add argument.  Create strinfo entries
for MEM_REF assignments.
(check_and_optimize_stmt): Handle more MEM_REF forms.

gcc/testsuite/ChangeLog:

PR middle-end/91582
* c-c++-common/Wrestrict.c: Adjust expected warnings.
* gcc/testsuite/c-c++-common/Wstringop-truncation-4.c: Enable more
warnings.
* gcc/testsuite/c-c++-common/Wstringop-truncation.c: Remove an xfail.
* gcc.dg/Warray-bounds-46.c: Disable -Wstringop-overflow.
* gcc.dg/Warray-bounds-47.c: Same.
* gcc.dg/Warray-bounds-52.c: New test.
* gcc.dg/Wstringop-overflow-27.c: New test.
* gcc.dg/Wstringop-overflow-28.c: New test.
* gcc.dg/Wstringop-overflow-29.c: New test.
* gcc.dg/attr-alloc_size.c (test): Disable -Warray-bounds.
* gcc.dg/attr-copy-2.c: Adjust expected warnings.
* gcc.dg/builtin-stringop-chk-5.c: Adjust text of expected messages.
* gcc.dg/strlenopt-86.c: Relax test.
* gcc.target/i386/pr82002-1.c: Prune expected warnings.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-52.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-28.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wrestrict.c
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c
trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-3.C
trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-47.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size.c
trunk/gcc/testsuite/gcc.dg/attr-copy-2.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-5.c
trunk/gcc/testsuite/gcc.dg/strlenopt-86.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-1.c
trunk/gcc/tree-ssa-strlen.c
trunk/gcc/tree-ssa-strlen.h
trunk/gcc/tree.c

[Bug middle-end/91582] missing heap overflow detection for strcpy

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Sat Dec 14 00:52:46 2019
New Revision: 279392

URL: https://gcc.gnu.org/viewcvs?rev=279392=gcc=rev
Log:
PR middle-end/91582 - missing heap overflow detection for strcpy
PR middle-end/92868 - ICE: tree check: expected integer_cst, have ssa_name

gcc/ChangeLog:

PR middle-end/91582
PR middle-end/92868
* builtins.c (addr_decl_size): New function.
(gimple_call_alloc_size): Add arguments.
(compute_objsize): Add an argument.  Set *PDECL even for allocated
objects.
Correct checking for negative wide_int.
Correct handling of negative outer offsets into unknown regions
or with unknown inner offsets.
Extend offsets to at most sizetype precision.
Only handle constant subobject sizes.
* builtins.h (gimple_call_alloc_size): Add arguments.
* tree.c (component_ref_size): Always return sizetype.
* tree-ssa-strlen.c (strinfo::alloc): New member.
(get_addr_stridx): Add argument.
(get_stridx): Use ptrdiff_t.  Add argument.
(new_strinfo): Set new member.
(get_string_length): Handle alloca and VLA.
(dump_strlen_info): Dump more state.
(maybe_invalidate): Print more info.  Decrease indentation.
(unshare_strinfo): Set new member.
(valid_builtin_call): Handle alloca and VLA.
(maybe_warn_overflow): Check and set no-warning bit.  Improve
handling of offsets.  Print allocated objects.
(handle_builtin_strlen): Handle strinfo records with null lengths.
(handle_builtin_strcpy): Add argument.  Call maybe_warn_overflow.
(is_strlen_related_p): Handle dynamically allocated objects.
(get_range): Add argument.
(handle_builtin_malloc): Rename...
(handle_alloc): ...to this and handle all allocation functions.
(handle_builtin_memset): Call maybe_warn_overflow.
(count_nonzero_bytes): Handle more MEM_REF forms.
(strlen_check_and_optimize_call): Call handle_alloc_call.  Pass
arguments to more callees.
(handle_integral_assign): Add argument.  Create strinfo entries
for MEM_REF assignments.
(check_and_optimize_stmt): Handle more MEM_REF forms.

gcc/testsuite/ChangeLog:

PR middle-end/91582
* c-c++-common/Wrestrict.c: Adjust expected warnings.
* gcc/testsuite/c-c++-common/Wstringop-truncation-4.c: Enable more
warnings.
* gcc/testsuite/c-c++-common/Wstringop-truncation.c: Remove an xfail.
* gcc.dg/Warray-bounds-46.c: Disable -Wstringop-overflow.
* gcc.dg/Warray-bounds-47.c: Same.
* gcc.dg/Warray-bounds-52.c: New test.
* gcc.dg/Wstringop-overflow-27.c: New test.
* gcc.dg/Wstringop-overflow-28.c: New test.
* gcc.dg/Wstringop-overflow-29.c: New test.
* gcc.dg/attr-alloc_size.c (test): Disable -Warray-bounds.
* gcc.dg/attr-copy-2.c: Adjust expected warnings.
* gcc.dg/builtin-stringop-chk-5.c: Adjust text of expected messages.
* gcc.dg/strlenopt-86.c: Relax test.
* gcc.target/i386/pr82002-1.c: Prune expected warnings.


Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-52.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-27.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-28.c
trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-29.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/builtins.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wrestrict.c
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation-4.c
trunk/gcc/testsuite/c-c++-common/Wstringop-truncation.c
trunk/gcc/testsuite/g++.dg/warn/Wstringop-overflow-3.C
trunk/gcc/testsuite/gcc.dg/Warray-bounds-46.c
trunk/gcc/testsuite/gcc.dg/Warray-bounds-47.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size.c
trunk/gcc/testsuite/gcc.dg/attr-copy-2.c
trunk/gcc/testsuite/gcc.dg/builtin-stringop-chk-5.c
trunk/gcc/testsuite/gcc.dg/strlenopt-86.c
trunk/gcc/testsuite/gcc.target/i386/pr82002-1.c
trunk/gcc/tree-ssa-strlen.c
trunk/gcc/tree-ssa-strlen.h
trunk/gcc/tree.c

[Bug middle-end/92936] New: missing warning on a past-the-end store to a PHI

[msebor at gcc dot gnu.org]

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

Bug ID: 92936
   Summary: missing warning on a past-the-end store to a PHI
   Product: gcc
   Version: 10.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: ---

Out of bounds stores to destinations that are the results of conditionals like
the one in g() below are not diagnosed.  They should be both by -Warray-bounds
and by -Wstringop-overflow (without duplicates) but they're not because PHI
expressions aren't handled.

$ cat b.c && gcc -O2 -S -Wall b.c
void sink (void*);

void f (int n)
{
  char a3[3], a5[5], *p;

  if (n <= 3)
{
  n = 3;
  p = a3;
  p[n] = 0;   // -Warray-bounds
}
  else
{
  n = 5;
  p = a5;
  p[n] = 0;   // -Warray-bounds
}

  sink (p);
}

void g (int n)
{
  char a3[3], a5[5], *p;

  if (n <= 3)
{
  n = 3;
  p = a3;
}
  else
{
  n = 5;
  p = a5;
}

  p[n] = 0;   // missing warning
  p[n + 1] = 1;   // missing warning
  p[n + 9] = 2;   // missing warning
  p[12345] = 3;   // missing warning

  sink (p);
}

b.c: In function ‘f’:
b.c:17:8: warning: array subscript 5 is outside array bounds of ‘char[5]’
[-Warray-bounds]
   17 |   p[n] = 0;   // -Warray-bounds
  |   ~^~~
b.c:5:15: note: while referencing ‘a5’
5 |   char a3[3], a5[5], *p;
  |   ^~
b.c:11:8: warning: array subscript 3 is outside array bounds of ‘char[3]’
[-Warray-bounds]
   11 |   p[n] = 0;   // -Warray-bounds
  |   ~^~~
b.c:5:8: note: while referencing ‘a3’
5 |   char a3[3], a5[5], *p;
  |^~

[Bug tree-optimization/92938] constprop function is assigned to a different section than the original function

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to jcmvbkbc from comment #1)
> The issue does not reproduce with the current gcc trunk after SVN revision
> 277054 (generalized IPA predicate on parameter), but it doesn't look like
> this change fixes the root cause, it just results in inlining of
> bitmap_replace() into the test_replace().

I DON'T think it is a GCC issue. The code is broken.  If bitmap_replace was
marked as always_inline, that would have worked or if it was marked as extern,
it would have worked. 

The inlining is not happening since test_replace is marked as cold so not
inlining is "expected".

[Bug tree-optimization/92938] constprop function is assigned to a different section than the original function

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #3)
> I DON'T think it is a GCC issue. The code is broken.

Even if I remove all attributes from this function I see this issue:

static void bitmap_replace(unsigned long *dst,
  const unsigned long *old,
  const unsigned long *new,
  const unsigned long *mask,
  unsigned int nbits)
{
 if ((__builtin_constant_p(nbits) && (nbits) <= 32 && (nbits) > 0))
  *dst = (*old & ~(*mask)) | (*new & *mask);
 else
  __bitmap_replace(dst, old, new, mask, nbits);
}

Why is it broken?

[Bug middle-end/91582] missing heap overflow detection for strcpy

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
The last patch in the series has been committed in r279392.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 91582 Summary: missing heap overflow detection for strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91582

   What|Removed |Added

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

[Bug fortran/92114] equivalence in module causes ICE

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Closing then.

[Bug tree-optimization/92938] New: constprop function is assigned to a different section than the original function

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 92938
   Summary: constprop function is assigned to a different section
than the original function
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47496=edit
test_bitmap.i

A bug is reported on the linux kernel mailing list:
https://lore.kernel.org/lkml/20191213211901.gl32...@smile.fi.intel.com/T/#t

In linux kernel there must be no references from .text* sections to data or
functions in .init* sections.

In the attached source there's no such reference:
__init test_replace calls regular bitmap_replace passing it a pointer to
__initconst exp2_to_exp3_mask variable.

But during optimization process such reference appears. When I look into
test_bitmap.i.085t.fixup_cfg3 I see the following:

__attribute__((no_instrument_function, unused, gnu_inline))
bitmap_replace.constprop (long unsigned int * dst, const long unsigned int *
old, const long unsigned int * new)
{ 
  ...
  __bitmap_replace (dst_11(D), old_3(D), new_6(D), _to_exp3_mask, 64);
  ...
}

__attribute__((cold, section (".init.text")))
test_replace ()
{
  ...
  bitmap_replace.constprop (, [0], [1]);
  ...
}

It looks like the function bitmap_replace.constprop should belong to the same
section as the function test_replace.

Compiler command line:

cc1 -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -std=gnu89
-ffreestanding -mlongcalls -mtext-section-literals -mforce-no-pic
-mno-serialize-volatile -fno-delete-null-pointer-checks -O2
-fstack-protector-strong -fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -g -femit-struct-debug-baseonly -fno-var-tracking
-fno-inline-functions-called-once -fno-strict-overflow -fno-merge-all-constants
-fmerge-constants -fno-stack-check -fconserve-stack test_bitmap.i

[Bug middle-end/92940] New: incorrect offset and size in -Wstringop-overflow for out-of-bounds store into VLA and two offset ranges

[msebor at gcc dot gnu.org]

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

Bug ID: 92940
   Summary: incorrect offset and size in -Wstringop-overflow for
out-of-bounds store into VLA and two offset ranges
   Product: gcc
   Version: 10.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: ---

With the last patch in the series for pr91582 applied () GCC prints the wrong
offset and size in the note that follows the (justified) -Wstringop-overflow
warning below.  The root cause is the same as in pr92939 but here the symptom
is different and the problem more apparent.

The note should print the range the out-of-bounds offset or index is in as well
as the range the size is in.

$ cat a.c && gcc -O2 -S -Wall a.c
void f (void*);

void g (int i, int j, int n)
{
  if (i < 1 || 2 < i) i = 1;
  if (j < 3 || 5 < j) j = 3;
  if (n < 3 || 4 < n) n = 3;

  char a[n];
  char *p = a;

  p += i;
  p[j] = 0;

  f (p);
}
a.c: In function ‘g’:
a.c:13:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   13 |   p[j] = 0;
  |   ~^~~
a.c:9:8: note: at offset 0 to an object with size 0 declared here
9 |   char a[n];
  |^

[Bug middle-end/92940] incorrect offset and size in -Wstringop-overflow for out-of-bounds store into VLA and two offset ranges

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||88443

--- Comment #1 from Martin Sebor  ---
The referenced patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00829.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392

[anlauf at gcc dot gnu.org]

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Using the LEN() intrinsic works fine, as the dump-tree shows for

  implicit none
  type t
 character :: c = "a"
  end type t
  type(t), parameter :: x = t()
  integer, parameter :: l = x%c%len   ! error and m=0
! integer, parameter :: l = len(x%c)  ! no error, m=1
  integer :: m = l
  print *, m
end

Also the following compiles/works fine:

  implicit none
  type t
 character :: c = "a"
  end type t
  type(t), parameter :: x = t()
  character(*), parameter :: d = x% c
  integer,  parameter :: l = d% len
  integer :: m = l
  print *, m
end

[Bug middle-end/92937] New: missing warning on a store with index >= malloc size

[msebor at gcc dot gnu.org]

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

Bug ID: 92937
   Summary: missing warning on a store with index >= malloc size
   Product: gcc
   Version: 10.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: ---

The -Wstringop-overflow logic for determining out of bounds stores into
variably sized objects (alloca, malloc, and VLAs) at offsets that are equal to
or greater than the size considers the ranges of the size and the offset
independently of one another.  When both the size is a range and the offset is
equal or greater than the size, the logic doesn't accurately reflect their
relationship: it uses the upper bound of the size but the lower bound of the
index.  This is necessary when the two are unrelated but gets in the way of
diagnosing bugs when they're the same or one is a function of the other like in
the test cases below.  In f(), it causes the warning to be issued only in the
last case.  In g(), because the upper bound of the size is INT_MAX (if n is
positive), no warning is issued even for the obviously excessive index.

$ cat b.c && gcc -O2 -S -Wall -ftrack-macro-expansion=0 b.c
void sink (void*);

void* f (int n)
{
  if (n < 3 || 5 < n) n = 3;

  char *p = __builtin_malloc (n);

  p[n] = 0;   // missing warning
  p[n + 1] = 0;   // missing warning
  p[n + 2] = 0;   // warning here

  return p;
}

void* g (int n)
{ 
  char *p = __builtin_malloc (n);

  p[n] = 0;  // missing warning
  p[n + 1] = 0;  // missing warning
  p[n + ] = 0;   // missing warning

  return p;
}
b.c: In function ‘f’:
b.c:11:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   11 |   p[n + 2] = 0;   // warning here
  |   ~^~~

[Bug tree-optimization/92868] [10 Regression] ICE: tree check: expected integer_cst, have ssa_name in to_wide, at tree.h:5855

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed by r279392.

[Bug tree-optimization/92938] constprop function is assigned to a different section than the original function

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #1 from jcmvbkbc at gcc dot gnu.org ---
The issue does not reproduce with the current gcc trunk after SVN revision
277054 (generalized IPA predicate on parameter), but it doesn't look like this
change fixes the root cause, it just results in inlining of bitmap_replace()
into the test_replace().

[Bug middle-end/92939] New: missing -Wstringop-overflow on negative index from the end of array

[msebor at gcc dot gnu.org]

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

Bug ID: 92939
   Summary: missing -Wstringop-overflow on negative index from the
end of array
   Product: gcc
   Version: 10.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: ---

Even with -Wno-array-bounds the out-of-bounds stores in the first assignment to
p[1] below and in the last assignment to p[-2] should be diagnosed by
-Wstringop-overflow.  But only the first is because the implementation of the
warning (the compute_objsize function) isn't prepared to handle negative
offsets.

$ cat b.c && gcc -O2 -S -Wall -Wno-array-bounds b.c
void sink (void*);

void f (int n, int i)
{
  if (n < 2 || 3 < n) n = 2;
  if (i < 1 || 2 < i) i = 1;

  char a[3], *p = a + n;

   // N=2  N=3
   // I=1 I=2  I=1 I=2
  p[1] = 0;// a[3]a[3] a[4]a[4]<< warns
  p[0] = 0;// a[2]a[2] a[3]a[3]<< should not warn
  p[-1] = 0;   // a[1]a[1] a[2]a[2]<< must not warn
  p -= i;
  p[0]  = 0;   // a[1]a[0] a[2]a[1]<< must not warn
  p[-1] = 0;   // a[0]a[-1]a[1]a[0]<< should not warn
  p[-2] = 0;   // a[-1]   a[-2]a[0]a[-1]   << should not warn
  p -= i;
  p[0] = 0;// a[0]a[-1]a[1]a[0]<< should not warn
  p[-1] = 0;   // a[-1]   a[-2]a[0]a[-1]   << should not warn
  p[-2] = 0;   // a[-2]   a[-3]a[-1]   a[-2]   << should warn

  sink (p);
}

b.c: In function ‘f’:
b.c:12:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   12 |   p[1] = 0;// a[3]a[3] a[4]a[4]<< warns
  |   ~^~~
b.c:8:8: note: at offset 0 to object ‘a’ with size 3 declared here
8 |   char a[3], *p = a + n;
  |^


Without -Wno-array-bounds GCC correctly diagnoses the out-of-bounds access:

b.c: In function ‘f’:
b.c:12:4: warning: array subscript [3, 4] is outside array bounds of ‘char[3]’
[-Warray-bounds]
   12 |   p[1] = 0;// a[3]a[3] a[4]a[4]<< warns
  |   ~^~~
b.c:8:8: note: while referencing ‘a’
8 |   char a[3], *p = a + n;
  |^
b.c:22:4: warning: array subscript [-4, -1] is outside array bounds of
‘char[3]’ [-Warray-bounds]
   22 |   p[-2] = 0;   // a[-2]   a[-3]a[-1]   a[-2]   << should warn
  |   ~^~~~
b.c:8:8: note: while referencing ‘a’
8 |   char a[3], *p = a + n;
  |^

[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute

[nightstrike at gmail dot com]

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #6 from nightstrike  ---
I still get this on gcc 9.1

[Bug fortran/49111] Unnecessary warning for private interfaces having the BIND(C) attribute

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to nightstrike from comment #6)
> I still get this on gcc 9.1

You forgot to attach your patch.  I have over
the years that bugs tend to to spontaneously 
fix themselves.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  ---
Thanks for feedback. Hopefully I can get to it next day or so.

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich+gccbug at gmail dot com]

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

--- Comment #18 from Thomas Henlich  ---
(In reply to Thomas Henlich from comment #13)
> For example:
> 
> gfc_notify_std (GFC_STD_F2018, "positive width required at %L",
> _locus)
> 
> should read
> gfc_notify_std (GFC_STD_F2018, "zero width at %L", _locus)

Even so, "zero width" is not the best choice of words, "E0.d editing" or "E0
editing" would be more appropriate; or "% in format at %L" to keep it
consisten with other uses.