[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to Eric Botcazou from comment #5)
> > Eric - was the intent of the PR81351 fix that the dwarf2out_do_eh_frame ()
> > works per function?
> 
> No, dwarf2out_do_eh_frame is global but whether the CFI for EH is emitted is
> decided on a per-function basis in the end, see my explanation in:
>   https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00771.html

Hmm, that doesn't give a lot of detail.  Clearly it doesn't yet work.
I see dwarf2out_do_eh_frame is also used as gate for the "dwarf2" pass.
That probably should use per-function settings then, thus an alternate
predicate?  Because the global setting simply tells the assembler to either
emit everything into eh_frame or debug_frame (seems the assembler cannot
have different settings on a per function basis?).

So I guess an appropriate cleanup would be to pass a struct function
to dwarf2out_do_eh_frame but also deal with it being NULL?

[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Ian Lance Taylor from comment #2)
> I see now the fact that we are using exceptions is already being passed. 
> The problem seems to be that flag_exceptions is set when we read an
> exception region from an input function, by lto_init_eh.  But before we read
> any of the input functions, lto_main has already called symtab->compile
> which has called (*debug_hooks->assembly_start) which has checked
> flag_exceptions when deciding whether to emit a .cfi_sections directive.  So
> although flag_exceptions does get set, it gets set too late to fix this
> problem.

Hmm.  I guess we need to stream this as part of the callgraph instead.
And actually we do, gathering first_personality_decl, so we could conveniently
init EH there as well?

Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c   (revision 275798)
+++ gcc/lto/lto.c   (working copy)
@@ -106,7 +106,10 @@ lto_materialize_function (struct cgraph_
   if (node->clone_of)
return;
   if (DECL_FUNCTION_PERSONALITY (decl) && !first_personality_decl)
-   first_personality_decl = DECL_FUNCTION_PERSONALITY (decl);
+   {
+ first_personality_decl = DECL_FUNCTION_PERSONALITY (decl);
+ lto_init_eh ();
+   }
 }

   /* Let the middle end know about the function.  */

[Bug tree-optimization/91758] Clang fails to pass validation after r261089

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Eric Botcazou from comment #8)
> > I've got it. It's a usage of an uninitialize member variable in a class:
> > https://bugs.llvm.org/show_bug.cgi?id=40547#c38
> 
> Thanks for catching this!

You're welcome. It took me almost the whole day yesterday, but I learn more
about store merging (and read quite some RTL dumps).

[Bug fortran/91413] [F2018]: Procedures are recursive by default; switching from stack to static allocation is not safe

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

   Assignee|jb at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #4 from Janne Blomqvist  ---
Unassigning myself. Pointer to effort to start discussion on how to properly
solve this at https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00687.html

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[dragan.mladjeno...@rt-rk.com]

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

--- Comment #5 from Dragan Mladjenovic  ---
Hi,

I wasn't able to reproduce this issue which leds me to believe that this is the
r273174 is the probable fix. In either way, it should be backported to gcc-9
branch,
but it would be nice if you can confirm if it fixes the problem.

Thanks in advance.

[Bug driver/91794] exception and unwind state is not carried to LTO but controls EH vs debug frame

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> So I guess an appropriate cleanup would be to pass a struct function
> to dwarf2out_do_eh_frame but also deal with it being NULL?

You need to ask Jan, my fix for 81351 was minimal and based on his insight.

[Bug target/91702] [9/10 Regression] ICE with mips16

[dragan.mladjeno...@rt-rk.com]

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

--- Comment #1 from Dragan Mladjenovic  ---
Hi,

Same as with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91474#c5. Chould you
perhaps verify if r273174 fixes your issue?

Thanks in advance.

[Bug target/91804] [10 regression] r265398 breaks gcc.target/powerpc/vec-rlmi-rlnm.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[rearnsha at gcc dot gnu.org]

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

--- Comment #19 from Richard Earnshaw  ---
(In reply to Wilco from comment #18)
> (In reply to Richard Earnshaw from comment #17)
> > So do we have a testcase that shows the problem on older compilers?
> 
> Yes, the same testcase shows the same incorrect substitution in older
> compilers. I tried GCC9, but the MEM to MEM change dates back much further.

Right, but does it lead to wrong code?  It seemed to me that the compiler loses
the correct alignment internally, but the object is really still aligned so
nothing harmful happens.

[Bug tree-optimization/91776] `-fsplit-paths` generates slower code on arm

[rearnsha at gcc dot gnu.org]

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

--- Comment #3 from Richard Earnshaw  ---
(In reply to Wilco from comment #1)
> (In reply to yhr-_-yhr from comment #0)
> > I'm doing this test on a Raspberry Pi Model 3B+. The CPU is BCM2835 ARMv7.
> 
> I think it's BM2837, ie. Cortex-A53. Or did you mean a different Pi?

BCM2835 is the Linux driver name for the BCM2[78]xx and series.  You get the
same on a Pi4 as well, even though it uses a BCM2711.

[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
This one should be fixed now.

[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Sep 18 11:28:20 2019
New Revision: 275872

URL: https://gcc.gnu.org/viewcvs?rev=275872&root=gcc&view=rev
Log:
2019-09-18  Richard Biener  

PR lto/91763
* lto-streamer-in.c (input_eh_regions): Move EH init to
lto_materialize_function.
* tree-streamer-in.c (lto_input_ts_function_decl_tree_pointers):
Likewise.

lto/
* lto.c (lto_materialize_function): Initialize EH by looking
at the function personality and flag_exceptions setting.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c
trunk/gcc/tree-streamer-in.c

[Bug tree-optimization/91776] `-fsplit-paths` generates slower code on arm

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-18
 Ever confirmed|0   |1

--- Comment #4 from Wilco  ---
(In reply to yhr-_-yhr from comment #2)
> > I think it's BM2837, ie. Cortex-A53. Or did you mean a different Pi?
> oops you're right, I just got this pointed out when I showed this post to my
> friend. I just copied it from `cat /proc/cpuinfo`.
> 
> > Can you try using -mno-strict-it on your examples and see whether that 
> > helps?
> Did you mean -mno-restrict-it? I followed gcc's correction info.

Yes - but it looks like your compiler defaults to Arm (which is strange), so it
has no effect.

With GCC8 I can reproduce this for Arm, but not on newer compilers. On Thumb-2
it still is an issue due to -mrestrict-it (comment 1). Basically it shows how
important conditional execution is for performance even on modern CPUs.

[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
(In reply to Richard Earnshaw from comment #19)
> (In reply to Wilco from comment #18)
> > (In reply to Richard Earnshaw from comment #17)
> > > So do we have a testcase that shows the problem on older compilers?
> > 
> > Yes, the same testcase shows the same incorrect substitution in older
> > compilers. I tried GCC9, but the MEM to MEM change dates back much further.
> 
> Right, but does it lead to wrong code?  It seemed to me that the compiler
> loses the correct alignment internally, but the object is really still
> aligned so nothing harmful happens.

It's not the alignment that is the main issue but the aliasing is wrong - an
unaligned access will still execute correctly on a modern CPU.

[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[rearnsha at gcc dot gnu.org]

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

--- Comment #21 from Richard Earnshaw  ---
But dropping in a char* will give a more restrictive alias set, so that isn't
wrong, even if it is suboptimal

[Bug libstdc++/91807] New: [Regression] std::variant with multiple identical types assignment fail

[raplonu.jb at gmail dot com]

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

Bug ID: 91807
   Summary: [Regression] std::variant with multiple identical
types assignment fail
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raplonu.jb at gmail dot com
  Target Milestone: ---

Created attachment 46895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46895&action=edit
preprocessed file

Repro:
#include 

struct me_data {
me_data() = default;

me_data(const me_data &) {};
me_data(me_data &&) noexcept {};
me_data& operator=(const me_data &) = default;
};

int main() {
std::variant v1, v2;

v2 = v1;
}

Compiles with 8. Breaks with 9 (see bellow) and 10.0.0 201 (on wandbox :
https://wandbox.org/permlink/3GZeJzWMlElIgqGd ):

In file included from main.cpp:1:
/usr/include/c++/9/variant: In instantiation of
‘std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::
mutable [with auto:3 = const me_data&; auto:4 = std::integral_constant]’:
/usr/include/c++/9/bits/invoke.h:60:36:   required from ‘constexpr _Res
std::__invoke_impl(std::__invoke_other, _Fn&&, _Args&& ...) [with _Res =
std::__detail::__variant::__variant_idx_cookie; _Fn =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::;
_Args = {const me_data&, std::integral_constant}]’
/usr/include/c++/9/bits/invoke.h:95:40:   required from ‘constexpr typename
std::__invoke_result<_Functor, _ArgTypes>::type std::__invoke(_Callable&&,
_Args&& ...) [with _Callable =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::;
_Args = {const me_data&, std::integral_constant};
typename std::__invoke_result<_Functor, _ArgTypes>::type =
std::__detail::__variant::__variant_idx_cookie]’
/usr/include/c++/9/variant:961:24:   required from ‘static constexpr
decltype(auto) std::__detail::__variant::__gen_vtable_impl<__same_return_types,
std::__detail::__variant::_Multi_array<_Result_type (*)(_Visitor, _Variants
...)>, std::tuple<_Variants ...>, std::integer_sequence >::__visit_invoke_impl(_Visitor&&, _Variants ...) [with bool
__same_return_types = true; _Result_type =
std::__detail::__variant::__variant_idx_cookie; _Visitor =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::&&; _Variants = {const std::variant&}; long unsigned
int ...__indices = {0}]’
/usr/include/c++/9/variant:980:28:   required from ‘static constexpr
decltype(auto) std::__detail::__variant::__gen_vtable_impl<__same_return_types,
std::__detail::__variant::_Multi_array<_Result_type (*)(_Visitor, _Variants
...)>, std::tuple<_Variants ...>, std::integer_sequence >::__do_visit_invoke(_Visitor&&, _Variants ...) [with bool
__same_return_types = true; _Result_type =
std::__detail::__variant::__variant_idx_cookie; _Visitor =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::&&; _Variants = {const std::variant&}; long unsigned
int ...__indices = {0}]’
/usr/include/c++/9/variant:996:28:   required from ‘static constexpr
decltype(auto) std::__detail::__variant::__gen_vtable_impl<__same_return_types,
std::__detail::__variant::_Multi_array<_Result_type (*)(_Visitor, _Variants
...)>, std::tuple<_Variants ...>, std::integer_sequence >::__visit_invoke(_Visitor&&, _Variants ...) [with bool
__same_return_types = true; _Result_type =
std::__detail::__variant::__variant_idx_cookie; _Visitor =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::&&; _Variants = {const std::variant&}; long unsigned
int ...__indices = {0}]’
/usr/include/c++/9/variant:1005:28:   required from ‘static constexpr auto
std::__detail::__variant::__gen_vtable_impl<__same_return_types,
std::__detail::__variant::_Multi_array<_Result_type (*)(_Visitor, _Variants
...)>, std::tuple<_Variants ...>, std::integer_sequence >::_S_apply() [with bool __same_return_types = true;
_Result_type = std::__detail::__variant::__variant_idx_cookie; _Visitor =
std::__detail::__variant::_Copy_assign_base<,
_Types>::operator=(const
std::__detail::__variant::_Copy_assign_base<, _Types>&) [with bool
 = false; _Types = {me_data, me_data}]::&&; _Variants = {const std::variant&}; long unsigned
int ...__indices = {0}]’
/usr/includ

[Bug tree-optimization/18501] [7/8/9/10 Regression] Missing 'used uninitialized' warning (CCP)

[vlad at ispras dot ru]

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

--- Comment #91 from Vladislav Ivanishin  ---
> --- Comment #90 from Eric Gallager  ---
> At Cauldron, Vladislav Ivanishin said in his lightning talk that ISP
> RAS has a patch to fix this.

Well, I also said that this patch is not meant to go into the mainline
compiler, because it trades off compiler speed for fixing this
(actually, for suppressing tons of false positives that inevitably arise
from doing that; see comment 32 by Richi).  Adding / moving around
transformation passes also affects the resulting code, and I have no
data to see what the actual impact is.

We did this to have as few false negatives as possible (and a sane
number of false positives) - and GCC is prioritizing not having false
positives a.k.a. spurious warnings.

One possible solution would be to teach the CCP pass to lay off of
uninitialized values and not merge them into constants (I don't know
whether that's desirable and also I don't have a patch for that, though
it would be interesting to try).

Anyway, you are right in that this kind of effort should be documented
in this bug.  I've already sent the slides to Simon.  They should appear
shortly on the cauldron's wiki page.

Thanks

[Bug middle-end/91708] [10 regression][ARM] Bootstrap fails in gen_movsi, at config/arm/arm.md:5258

[wilco at gcc dot gnu.org]

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

--- Comment #22 from Wilco  ---
(In reply to Richard Earnshaw from comment #21)
> But dropping in a char* will give a more restrictive alias set, so that
> isn't wrong, even if it is suboptimal

The alias set could be anything given CSE changes one MEM to another without
any checks (it's not clear whether it even checks other attributes like
volatile).

[Bug tree-optimization/91789] Value ranges determined from comparisons not used transitively

[amacleod at redhat dot com]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #4 from Andrew Macleod  ---
The ranger isn't really about forwards vs backwards, its about an approach in
which the basics are understood without special casing, and when applied
properly, direction won't matter... eliminating this sort of ordering issue.

This is another example which we intend to just always "get", but requires
multiple components to work together:

It requires 2 different things. 
1) ranges to know that after the second conditional a = [0, MAX]
2) relationals such that the property b >= a is known after the first
conditional.

- For strictly ranges, the final conditional produces b = [MIN, -1] on the TRUE
edge.
- If the known relations are queried, and the known relation b >= a is applied
to a = [0, MAX], rangeops calculates b >= [0, MAX] and we get a range of [0,
MAX] for b

Since both must be true simultaneously, the results [MIN, -1] and [0, MAX] will
be intersected and produces an empty range on the TRUE edge, which in ranger
world means the range is impossible. Thus we know the edge is not executable
and can be removed. 

This range evaluation code is present in the ranger now and resolves the range
parts, but wont make trunk this release.  

The relational code is being developed for next stage 1, so does not exist yet.
It is required to replace VRP and the symbolic representation currently used by
value_range for equivalences and relations. This will be my focus over the next
few months.

I would anticipate this being fixed in the next release when the ranger goes
live. I will add this test to my testsuite to ensure it works as expected.

[Bug libstdc++/91807] [9/10 Regression] std::variant with multiple identical types assignment fail to compile

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||8.3.0
   Target Milestone|--- |9.3
Summary|[Regression] std::variant   |[9/10 Regression]
   |with multiple identical |std::variant with multiple
   |types assignment fail to|identical types assignment
   |compile |fail to compile

[Bug target/52593] Builtin sqrt on x86 is not correctly rounded

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #12 from Alexander Monakov  ---
Nothing, closing the bug.

[Bug c++/91808] New: Static definition rejected after extern declaration in anonymous namespace

[andrey.vihrov at gmail dot com]

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

Bug ID: 91808
   Summary: Static definition rejected after extern declaration in
anonymous namespace
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Consider the following C++11 sample:

namespace
{
extern int x;
static int x = 0;
}

Compiling this with "gcc -c test.cpp" gives

test.cpp:4:16: error: '{anonymous}::x' was declared 'extern' and later 'static'
[-fpermissive]
4 | static int x = 0;
  |^
test.cpp:3:16: note: previous declaration of '{anonymous}::x'
3 | extern int x;
  |^

According to [1], point 3.5.4, the "extern int x;" declaration has the same
linkage as its enclosing namespace, which is anonymous and thus has internal
linkage. According to point 3.1.2, this declaration is not a definition.

According to point 3.5.3, the "static int x = 0;" declaration has internal
linkage. It is also the first definition for the internal "int {anonymous}::x"
variable. Overall, this declaration doesn't conflict with the previous one.

Note: Clang (starting with version 6) and MSVC accept the code.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf

[Bug c++/91809] New: in c++ bit-field is not promoted to int in printf argument

[nsz at gcc dot gnu.org]

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

Bug ID: 91809
   Summary: in c++ bit-field is not promoted to int in printf
argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

may be a -Wformat bug only, but the c++ front-end seems
to use the wrong type:

#include 

struct X {
  unsigned long long a: 1;
} x;

void foo()
{
  printf("%d", x.a);
}

gcc -Wformat -xc++  says

a.c: In function 'void foo()':
a.c:9:12: warning: format '%d' expects argument of type 'int', but argument 2
has type 'long long unsigned int' [-Wformat=]
9 |   printf("%d", x.a);
  |   ~^   ~~~
  || |
  |int   long long unsigned int
  |   %lld

the warning is not present with -xc, which is
the expected behaviour: bit-field should be
promoted to int in this context, i don't think
c++ should behave differently.

(not a new regression, at least present since gcc-4.8)

[Bug go/91763] [10 regression] go.go-torture/execute/printnil.go FAILs

[ian at airs dot com]

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

--- Comment #7 from Ian Lance Taylor  ---
Thanks!

[Bug c++/55588] Failure to diagnose non-template-id prefixed by keyword template

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Ville Voutilainen from comment #2)
> > Also present in 4.9 trunk, and I recently got a user complaint about this
> > bug. How can I upvote? :)
> 
> If Bug 86315 is fixed, 

update: this has happened.

[Bug fortran/88632] [F08] function contained in module invisible to submodule unless declared public

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
(In reply to Paul Thomas from comment #2)
> Created attachment 45349 [details]
> A provisional patch that fixes the problem
> 
> The attached fixes this but causes regressions:
> 
> FAIL: gfortran.dg/module_private_2.f90   -O   scan-tree-dump-times optimized
> "priv" 0
> FAIL: gfortran.dg/public_private_module_7.f90   -O   scan-assembler-not
> __m_common_attrs_MOD_other
> FAIL: gfortran.dg/public_private_module_8.f90   -O   scan-assembler-not
> __m_MOD_myotherlen
> FAIL: gfortran.dg/public_private_module_2.f90   -O   scan-assembler-not two
> FAIL: gfortran.dg/public_private_module_2.f90   -O   scan-assembler-not six
> FAIL: gfortran.dg/warn_unused_function_2.f90   -O   (test for warnings, line
> 16)
> 
> I think that this is best dealt with by extending the patch by flagging the
> module as having a module function/subroutine, which implies that there is a
> submodule somewhere, and making all the module procedures TREE_PUBLIC. That
> will suppress the above regressions.
> 
> Otherwise, I will have to find someway of persuading the linker to find the
> symbol from the submodule.
> 
> First I must get the C-interop patch out of the way and then I will come
> back to this PR.
> 
> Paul

The C-interop patch is all but gone: just one bug to go. This PR is therefore
now on my radar.

Paul

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Sep 18 17:32:08 2019
New Revision: 275891

URL: https://gcc.gnu.org/viewcvs?rev=275891&root=gcc&view=rev
Log:
2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* frontend-passes.c (do_subscript): If step equals
zero, a previuos error has been reported; do nothing
in this case.
* resolve.c (gfc_resolve_iterator): Move error checking
after type conversion.

2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* gfortran.dg/do_subscript_6.f90: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/do_subscript_6.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/frontend-passes.c
branches/gcc-9-branch/gcc/fortran/resolve.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Sep 18 17:39:33 2019
New Revision: 275892

URL: https://gcc.gnu.org/viewcvs?rev=275892&root=gcc&view=rev
Log:
2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* frontend-passes.c (do_subscript): If step equals
zero, a previuos error has been reported; do nothing
in this case.
* resolve.c (gfc_resolve_iterator): Move error checking
after type conversion.

2019-09-18  Thomas Koenig  

Backport from trunk
PR fortran/91550
* gfortran.dg/do_subscript_6.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/do_subscript_6.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/frontend-passes.c
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/91550] [8/9 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2652

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Fixed. Thanks for the bug report!

[Bug fortran/69815] Don't always use BLOCKS for front-end optimization variables

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug fortran/48303] [Legacy] Support Character constants in DATA statement for non-character variables

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||documentation
 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #4)
> No activity since more than two years. IMO this should go under the section
> 
> 6.2 Extensions not implemented in GNU Fortran
> 
> of the manual. I can submit a draft patch for this PR if someone is will to
> fix
> my Frenglish and formatting issues and do the commit.

Hi,

just going through some WAITING bugs... do you still plan to do this?
If not, I can also do this.

[Bug fortran/81651] Enhancement request: have f951 print out fully qualified module file name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|WAITING |NEW

[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org
Summary|Reduce gfortran stack usage |[ABI cleanup] Reduce
   |for procedures doing IO |gfortran stack usage for
   ||procedures doing IO

--- Comment #6 from Thomas Koenig  ---
We could do this if we clean up the ABI.  If we do that, we could also
revisit PR 45715 :-)

Is there an ABI cleanup PR somewhere?

[Bug debug/91810] New: I do not know what is wrong

[lpsullivan at wpi dot edu]

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

Bug ID: 91810
   Summary: I do not know what is wrong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lpsullivan at wpi dot edu
  Target Milestone: ---

Arduino: 1.8.9 (Windows Store 1.8.21.0) (Windows 10), Board: "Arduino/Genuino
Uno"

In file included from
C:\Users\lsull\Documents\Arduino\libraries\grbl/grbl.h:43:0,

 from
C:\Users\lsull\Documents\Arduino\libraries\grbl\examples\grblUpload\grblUpload.ino:27:

C:\Users\lsull\Documents\Arduino\libraries\grbl/nuts_bolts.h:56:0: warning:
"max" redefined

 #define max(a,b) (((a) > (b)) ? (a) : (b))

 ^

In file included from sketch\grblUpload.ino.cpp:1:0:

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino/Arduino.h:93:0:
note: this is the location of the previous definition

 #define max(a,b) ((a)>(b)?(a):(b))

 ^

In file included from
C:\Users\lsull\Documents\Arduino\libraries\grbl/grbl.h:43:0,

 from
C:\Users\lsull\Documents\Arduino\libraries\grbl\examples\grblUpload\grblUpload.ino:27:

C:\Users\lsull\Documents\Arduino\libraries\grbl/nuts_bolts.h:57:0: warning:
"min" redefined

 #define min(a,b) (((a) < (b)) ? (a) : (b))

 ^

In file included from sketch\grblUpload.ino.cpp:1:0:

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino/Arduino.h:92:0:
note: this is the location of the previous definition

 #define min(a,b) ((a)<(b)?(a):(b))

 ^

In file included from
C:\Users\lsull\Documents\Arduino\libraries\grbl/grbl.h:43:0,

 from
C:\Users\lsull\Documents\Arduino\libraries\grbl\examples\grblUpload\grblUpload.ino:27:

C:\Users\lsull\Documents\Arduino\libraries\grbl/nuts_bolts.h:61:0: warning:
"bit" redefined

 #define bit(n) (1 << n)

 ^

In file included from sketch\grblUpload.ino.cpp:1:0:

C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino/Arduino.h:123:0:
note: this is the location of the previous definition

 #define bit(b) (1UL << (b))

 ^

C:\Users\lsull\Documents\Arduino\libraries\grbl\report.c: In function
'report_util_float_setting':

C:\Users\lsull\Documents\Arduino\libraries\grbl\report.c:103:1: internal
compiler error: Segmentation fault

 }

 ^

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

lto-wrapper.exe: fatal error: C:\Program
Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.21.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc
returned 1 exit status

compilation terminated.

c:/program
files/windowsapps/arduinollc.arduinoide_1.8.21.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe:
error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1
Error compiling for board Arduino/Genuino Uno.

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

[Bug target/91446] Wrong cost for scalar_load/scalar_store of vector type

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Sep 18 19:49:19 2019
New Revision: 275905

URL: https://gcc.gnu.org/viewcvs?rev=275905&root=gcc&view=rev
Log:
i386: Increase Skylake SImode pseudo register store cost

On Skylake, SImode store cost isn't less than half cost of 128-bit vector
store.  This patch increases Skylake SImode pseudo register store cost to
make it the same as QImode and HImode.

gcc/

PR target/91446
* config/i386/x86-tune-costs.h (skylake_cost): Increase SImode
pseudo register store cost from 3 to 6 to make it the same as
QImode and HImode.

gcc/testsuite/

PR target/91446
* gcc.target/i386/pr91446.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr91446.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune-costs.h
trunk/gcc/testsuite/ChangeLog

[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated

[hjl at gcc dot gnu.org]

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

--- Comment #8 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Sep 18 19:50:45 2019
New Revision: 275906

URL: https://gcc.gnu.org/viewcvs?rev=275906&root=gcc&view=rev
Log:
i386: Restore Skylake SImode hard register store cost

On Skylake, we should move integer register to SSE register without
going through memory.  This patch restores Skylake SImode hard register
store cost to 6.

gcc/

PR target/90878
* config/i386/x86-tune-costs.h (skylake_cost): Restore SImode
hard register store cost to 6.

gcc/testsuite/

PR target/90878
* gcc.target/i386/pr90878.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr90878.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/x86-tune-costs.h
trunk/gcc/testsuite/ChangeLog

[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823

[wilco at gcc dot gnu.org]

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

--- Comment #2 from Wilco  ---
Author: wilco
Date: Wed Sep 18 19:52:09 2019
New Revision: 275907

URL: https://gcc.gnu.org/viewcvs?rev=275907&root=gcc&view=rev
Log:
[ARM] Add logical DImode expanders

We currently use default mid-end expanders for logical DImode operations.
These split operations without first splitting off complex immediates or
memory operands.  The resulting expansions are non-optimal and allow for
fewer LDRD/STRD opportunities.  So add back explicit expanders which ensure
memory operands and immediates are handled more efficiently.

gcc/
PR target/91738
* config/arm/arm.md (di3): Expand explicitly.
(one_cmpldi2): Likewise.
* config/arm/arm.c (const_ok_for_dimode_op): Return true if one
of the constant parts is simple.
* config/arm/iterators.md (LOGICAL): Add new code iterator.
(logical_op): Add new code attribute.
(logical_OP): Likewise.
* config/arm/predicates.md (arm_anddi_operand): Add predicate.
(arm_iordi_operand): Add predicate.
(arm_xordi_operand): Add predicate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/iterators.md
trunk/gcc/config/arm/predicates.md

[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.4 |10.0

--- Comment #9 from H.J. Lu  ---
Fixed for GCC 10.

[Bug tree-optimization/91811] New: 256-bit vector store isn't used

[hjl.tools at gmail dot com]

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

Bug ID: 91811
   Summary: 256-bit vector store isn't used
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 xxx]$ cat y.i
typedef struct
{
  long long width, height;
  long long x, y;
} info;

extern void bar (info *);

void
foo (long long width, long long height,
 long long x, long long y)
{
  info t;
  t.width = width;
  t.height = height;
  t.x = x;
  t.y = y;
  bar (&t);
}
[hjl@gnu-cfl-1 xxx]$ 
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2
-march=skylake -ftree-slp-vectorize -mtune-ctrl=^sse_typeless_stores
-mprefer-vector-width=256  -S y.i
[hjl@gnu-cfl-1 xxx]$ cat y.s
.file   "y.i"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
vmovq   %rdi, %xmm1
subq$40, %rsp
.cfi_def_cfa_offset 48
vpinsrq $1, %rsi, %xmm1, %xmm0
vmovq   %rdx, %xmm2
vmovdqa %xmm0, (%rsp)
movq%rsp, %rdi
vpinsrq $1, %rcx, %xmm2, %xmm0
vmovdqa %xmm0, 16(%rsp)
callbar
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 10.0.0 20190918 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 xxx]$ 

Is it possible to use 256-bit YMM register store?

[Bug target/91446] Wrong cost for scalar_load/scalar_store of vector type

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
(In reply to Richard Biener from comment #2)
> On this ground the bug would be valid but not about costs (you may want
> to open a separate bug for this issue).

Fixed for GCC 10.  I opened PR 91811.

[Bug c++/91809] in c++ bit-field is not promoted to int in printf argument

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I thought I had saw a dup of this bug and closed as invalid before.

[Bug c++/91809] in c++ bit-field is not promoted to int in printf argument

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Or rather maybe fixed with the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30277 (which was done 3 days ago).

[Bug c++/70435] section attribute of a function template is not honored.

[fewix3000 at hotmail dot co.uk]

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

Felix Jones  changed:

   What|Removed |Added

 CC||fewix3000 at hotmail dot co.uk

--- Comment #6 from Felix Jones  ---
Related bug 88061

Here's a demonstration of the issue with GCC trunk x86-64 on godbolt:
https://godbolt.org/z/9GFWZR

Minimal example for reproducing:
>  template 
>  Type __attribute__( ( used, section( ".my_section" ) ) ) add_types( Type a, 
> Type b ) {
>return a + b;
>  }
>  
>  int main( int argc, char * argv[] ) {
>return test_class( s_value<3> ).add( add_types( 1, 2 ) );
>  }

Current behaviour: add_types within section .text
Desired behaviour: add_types within section .my_section

Clang trunk demonstrates the desired behaviour: https://godbolt.org/z/t8FNe0

[Bug c++/88061] section attributes of variable templates are ignored

[fewix3000 at hotmail dot co.uk]

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

Felix Jones  changed:

   What|Removed |Added

 CC||fewix3000 at hotmail dot co.uk

--- Comment #2 from Felix Jones  ---
Related bug 70435

Here's a demonstration of the issue with GCC trunk x86-64 on godbolt:
https://godbolt.org/z/9GFWZR

Minimal example for reproducing:
>  template
>  __attribute__( ( used, section( ".my_section" ) ) ) const int s_value { x };
>  
>  int main( int argc, char * argv[] ) {
>return s_value<3>;
>  }

Current behaviour: s_value within section .rodata
Desired behaviour: s_value within section .my_section

Clang trunk demonstrates the desired behaviour: https://godbolt.org/z/t8FNe0

[Bug c++/83818] g++ class template parameter deduction discards const qualifier

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Target Milestone|--- |7.4

[Bug c/91812] New: GCC ignores volatile modifier

[fuchedzhy at google dot com]

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

Bug ID: 91812
   Summary: GCC ignores volatile modifier
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fuchedzhy at google dot com
  Target Milestone: ---

GCC appears to ignore volatile modifier sometimes. C is probably wrong
component for the bug, but I'm not sure where else to put it.

$ arm-linux-gnueabi-gcc-8 -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/8/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib
--enable-multiarch --disable-sjlj-exceptions --with-arch=armv5te
--with-float=soft --disable-werror --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

This is a minimal example I could come up with:

volatile unsigned register1;
volatile unsigned register2;

void busy_wait_for_register(int x) {
  volatile unsigned* ptr;
  switch(x) {
case 0x:
  ptr = ®ister1;
  break;

case 0x:
  ptr = ®ister2;
  break;

default:
  return;
  }
  while (*ptr) {}
}

If compiled with following command:
$ arm-linux-gnueabi-gcc-8 -mcpu=cortex-m7 -Os -c main.c

Produces following binary:
$ arm-linux-gnueabi-objdump -d main.o

main.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   f241 1211   movwr2, #4369   ; 0x
   4:   4b08ldr r3, [pc, #32]   ; (28
)
   6:   4290cmp r0, r2
   8:   447badd r3, pc
   a:   d004beq.n   16 
   c:   f242    movwr2, #8738   ; 0x
  10:   4290cmp r0, r2
  12:   d006beq.n   22 
  14:   4770bx  lr
  16:   4a05ldr r2, [pc, #20]   ; (2c
)
  18:   589bldr r3, [r3, r2]
  1a:   681bldr r3, [r3, #0]
  1c:   2b00cmp r3, #0
  1e:   d1fdbne.n   1c 
  20:   4770bx  lr
  22:   4a03ldr r2, [pc, #12]   ; (30
)
  24:   e7f8b.n 18 
  26:   bf00nop
  28:   001c.word   0x001c
...

Note that generated while loop instructions:
  1c:   2b00cmp r3, #0
  1e:   d1fdbne.n   1c 
never reload the register making this effectively an infinite loop.
I believe volatile keyword should have prevented that.

[Bug fortran/91813] New: Derived types: Issues with user defined I/O and recursive function of abstract type

[m.diehl at mpie dot de]

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

Bug ID: 91813
   Summary: Derived types: Issues with user defined I/O and
recursive function of abstract type
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---

Created attachment 46896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46896&action=edit
Example code with user defined I/O (not working)

This bug is a hard to describe because it seems to results from a strange side
condition.

In brief, I have a abstract base class (tNode) and two derived classes (tScalar
and tList) which are used to build a tree-structure from a YAML file. This is
done with a recursive function which parses a string and has the class of the
abstract type:

recursive function YAML_parse(str) result(parsed)
  class(tNode), allocatable :: parsed
  character(len=*), intent(in) :: str
  type(tList) :: li
  integer :: e, s

  if (str(1:1) == '[') then
e = 1
do while (e < len(str))
  s = e
  e = s + find_end(str(s+1:))
  call li%append(YAML_parse(str(s+1:e-1)))! Bug in Gfortran:
This call to parse allocates parsed
enddo
allocate(parsed,source=li)! error message
appears here
  else
parsed = tScalar(trim(str))
  endif
end function

The function fails at the allocation with the message "'parsed' is already
allocated" even though this statement is called only once in each function
call. My guess is that there is a mix-up of YAML_parse and parsed (note that
the 'result' style is mandatory) due to the recursive invocation.

Now the strange thing: This happens only if the types have user defined I/O.
I.e. if line 8, 26, and 37 (and subsequently 108-148 and 163) are commented out
the code works to the extend that there is no run time error. Unfortunately, in
that case I can not easily figure out if the values are stored appropriately.

I'm running arch linux on a 64bit Intel i7

Note that bug 88768 migh be related.

[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #6)
> We could do this if we clean up the ABI.  If we do that, we could also
> revisit PR 45715 :-)
> 
> Is there an ABI cleanup PR somewhere?

WeE did some of the ABI cleanup already. I have often thought moving a lot into
the unit structure would make more sense since only the specific unit needs it,
if at all.

I would like to sugget we present here the structure changes first so all can
look t it and comment, then someone can implement once we are agreed. I could
take a crack at it if anyone would like my two cents worth.

[Bug target/91683] ICE: SIGSEGV at -O when compiling for riscv64

[wilson at gcc dot gnu.org]

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

--- Comment #20 from Jim Wilson  ---
Author: wilson
Date: Thu Sep 19 01:19:25 2019
New Revision: 275925

URL: https://gcc.gnu.org/viewcvs?rev=275925&root=gcc&view=rev
Log:
RISC-V: Fix more splitters accidentally calling gen_reg_rtx.

PR target/91683
* config/riscv/riscv-protos.h (riscv_split_symbol): New bool parameter.
(riscv_move_integer): Likewise.
* config/riscv/riscv.c (riscv_split_integer): Pass FALSE for new
riscv_move_integer arg.
(riscv_legitimize_move): Likewise.
(riscv_force_temporary): New parameter in_splitter.  Don't call
force_reg if true.
(riscv_unspec_offset_high): Pass FALSE for new riscv_force_temporary
arg.
(riscv_add_offset): Likewise.
(riscv_split_symbol): New parameter in_splitter.  Pass to
riscv_force_temporary.
(riscv_legitimize_address): Pass FALSE for new riscv_split_symbol
arg.
(riscv_move_integer): New parameter in_splitter.  New local
can_create_psuedo.  Don't call riscv_split_integer or force_reg when
in_splitter TRUE.
(riscv_legitimize_const_move): Pass FALSE for new riscv_move_integer,
riscv_split_symbol, and riscv_force_temporary args.
* config/riscv/riscv.md (low+1): Pass TRUE for new
riscv_move_integer arg.
(low+2): Pass TRUE for new riscv_split_symbol arg.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/riscv/riscv-protos.h
trunk/gcc/config/riscv/riscv.c
trunk/gcc/config/riscv/riscv.md

[Bug target/87007] [8 Regression] 10% slowdown with -march=skylake-avx512

[crazylht at gmail dot com]

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

--- Comment #11 from Hongtao.liu  ---
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=275926

Author: liuhongt
Date:   Thu Sep 19 01:21:39 2019 UTC (30 seconds ago)
Changed paths:  4
Log Message:
Extend pass rpad to handle avx512f vcvtusi2ss vcvtusi2ss
538.imagick_r improved by 4% with single copy run on SKYLAKE workstation.

gcc/
* config/i386/i386.md
(*floatuns2_avx512):
Add avx_partial_xmm_update.

gcc/testsuie
* gcc.target/i386/pr87007-3.c: New test.

[Bug fortran/48419] [ABI cleanup] Reduce gfortran stack usage for procedures doing IO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Created attachment 46897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46897&action=edit
Comments with my thoughts on ABI

Just my initial thoughts.  I would like to see some consensus before we jump
forward on this.

[Bug tree-optimization/81248] No ipa-sra optimization for small struct / class

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
I think this bug came up in Martin Jambor's IPA-SRA talk at Cauldron, but the
number went by too quickly for me to fully catch it, so I'm not sure...

[Bug c++/68230] Unused function parameters not reported by -Wunused-parameter when only used recursively (add -Wparameter-only-used-recursively instead?)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
Martin Jambor's IPA-SRA rewrite might be relevant here; it sounded like the new
IPA-SRA will remove parameters that are unused like this, but I didn't quite
catch if it'd also warn about them...

[Bug tree-optimization/86530] Vectorization failure for a simple loop

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=65930,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=88492
 Blocks||26163

--- Comment #4 from Eric Gallager  ---
(In reply to Tamar Christina from comment #3)
> I'll take this one as part of GCC10.

Reconfirmed at Cauldron, where it was also mentioned that this bug is related
to bug 65930 and bug 88492


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug tree-optimization/91246] vectorization failure for a small loop to search array element

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
 Blocks||26163

--- Comment #4 from Eric Gallager  ---
Tamar Christina brought this bug up at the SPEC BoF at Cauldron


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug regression/89733] [7/8/9/10 Regression] -Wuninitialized false positive with unclear message pointing to a class name

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> Please provide preprocessed source.

Reporter has provided this; moving bug out of WAITING

[Bug libquadmath/58327] Problem of quadmath in connection with SDL2

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Kai Tietz from comment #5)
> > This sounds a bit like an issue with OP-specific invocation of ld. How are
> > you invoke the linker?
> 
> WAITING on a reply to this

No reply; assuming this was a user error and closing

[Bug c/91812] GCC ignores volatile modifier

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
If you declare ptr like this instead, the assembly comes out looking different:
volatile unsigned int *volatile ptr;

[Bug c/91812] GCC ignores volatile modifier

[fuchedzhy at google dot com]

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

--- Comment #2 from Gregory Fuchedzhy  ---
(In reply to Eric Gallager from comment #1)
> If you declare ptr like this instead, the assembly comes out looking
> different:
> volatile unsigned int *volatile ptr;

Even seemingly unrelated code changes can hide this behavior. For example,
commenting out one of switch cases generates correct assembly.

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-19
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
On trunk we remove the loop because it has no side-effects (oops).

[Bug tree-optimization/91811] 256-bit vector store isn't used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 CC||rguenth at gcc dot gnu.org
 Blocks||53947

--- Comment #1 from Richard Biener  ---
0x4ef6030 width_2(D) 1 times vec_construct costs 32 in prologue
0x4ef6030 width_2(D) 1 times vector_store costs 24 in body
0x4f59760 width_2(D) 1 times scalar_store costs 12 in body
0x4f59760 height_4(D) 1 times scalar_store costs 12 in body
0x4f59760 x_6(D) 1 times scalar_store costs 12 in body
0x4f59760 y_8(D) 1 times scalar_store costs 12 in body
t2.c:18:3: note:  Cost model analysis:
  Vector inside of basic block cost: 24
  Vector prologue cost: 32
  Vector epilogue cost: 0
  Scalar cost of basic block: 48
t2.c:18:3: missed:  not vectorized: vectorization is not profitable.
t2.c:18:3: note: * Re-trying analysis with vector size 16

so target costs say that this isnt profitable.  Probably a dup of one of the
bugs saying we don't take into account function boundary ABI for costing.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
And the GCC 8 issue is phiprop doing bogus invariant motion of the load.

[Bug c/91812] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> On trunk we remove the loop because it has no side-effects (oops).

actually no, it's the same issue (phiprop).

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[kito at gcc dot gnu.org]

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

--- Comment #26 from Kito Cheng  ---
Author: kito
Date: Thu Sep 19 06:38:23 2019
New Revision: 275929

URL: https://gcc.gnu.org/viewcvs?rev=275929&root=gcc&view=rev
Log:
RISC-V: Fix bad insn splits with paradoxical subregs.

Shifting by more than the size of a SUBREG_REG doesn't work, so we either
need to disable splits if an input is paradoxical, or else we need to
generate a clean temporary for intermediate results.

Jakub wrote the first version of this patch, so gets primary credit for it.

gcc/
PR target/91635
* config/riscv/riscv.md (zero_extendsidi2, zero_extendhi2,
extend2): Don't split if
paradoxical_subreg_p (operands[0]).
(*lshrsi3_zero_extend_3+1, *lshrsi3_zero_extend_3+2): Add clobber and
use as intermediate value.

gcc/testsuite/
PR target/91635
* gcc.c-torture/execute/pr91635.c: New test.
* gcc.target/riscv/shift-shift-4.c: New test.
* gcc.target/riscv/shift-shift-5.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91635.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-4.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/riscv/shift-shift-5.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/riscv/riscv.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog