[Bug fortran/66575] Endless compilation on missing end interface

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
All of the testcases in this PR seem to generate an error now with trunk.
Can we add the one test mention by Jerry and close this PR?

[Bug c/91373] gcc6.2.0: ((U32)((U16 * U16)) >> 31) cannot always get correct result with gcc -O2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
U16_0 * U16_1
Is really:
((int)(U16_0)) * ((int)(U16_1))
Due to C/C++ promption rules.

Which means in this case, it overflows and since both were positive (due to u16
promoting to int) to begin with, shifting to get to the sign bit will always be
0.
If you want to unsigned 32 as the type, then you need to explictly cast it.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #8 from Brian T. Carcich  ---
Not exactly a page out of Dale Carnegie.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #7 from Brian T. Carcich  ---
Oh dear.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #5 from Brian T. Carcich  ---
S ... as does yours, probably

--- Comment #6 from Brian T. Carcich  ---
S ... as does yours, possibly.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #5 from Brian T. Carcich  ---
S ... as does yours, probably

--- Comment #6 from Brian T. Carcich  ---
S ... as does yours, possibly.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #4 from Brian T. Carcich  ---
PPPS I apologize; by way of ignorant excuse, my history with Fortran goes back
way more than 29y.

[Bug fortran/89943] Submodule functions are not allowed to have C binding

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||83113

--- Comment #3 from kargl at gcc dot gnu.org ---
This bug is similar to PR 83113.

It seems that attributes in general are flagged in
submodules as duplicates when an interface is given
in the module and the interface is copied to the 
submodule.  Add 83113 as "Depends On", but it's more
the same error.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
[Bug 83113] Bogus "duplicate allocatable attribute" error for submodule
character function

[Bug c++/41423] missing warning for an uncallable function template

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
Would this go under a new flag or an existing one?

[Bug fortran/87797] Enhancement: Warning for potential name clash of variables/intrinsics...

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Aug 06, 2019 at 02:37:25AM +, briantcarcich at gmail dot com wrote:
> 
> The issue is that this *is* a bug in GFORTRAN.
>

I never claimed that it wasn't a bug.

PS: The name of the compiler is gfortran.  The name of the programming
language is Fortran.  It's been Fortran for more than 29 years.  Give
your caps lock key a rest.

PPS: Thanks for giving me a reason to stop looking at how to fix
the problem.

[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #4 from Martin Sebor  ---
pr89797 reported a similar (but not quite the same) ICE in the aarch64
back-end.  Maybe the hppa64 back-end needs a similar tweak to keep the
assertion from failing.

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

--- Comment #2 from Brian T. Carcich  ---
Agreed that the options -finit-local-zero and -fno-automatic are extraneous;
sorry, they were dragged into here from my Makefile because I need them for the
larger project.

Also, I know how to do a workaround, several in fact, to trick GFORTRAN into
doing the correct thing, as demonstrated by the Github example; that is not the
issue.

The issue is that this *is* a bug in GFORTRAN:  the return on Line 3 (label
2) should cause GFORTRAN to generate a correct [return __result_zero;], and
not the incorrect naked [return;] that it does now.

Other FORTRAN compilers do that, also earlier version of GFORTRAN, because it
is correct.

If I get some free time I will work on a patch, but I suspect someone familiar
with the code could fix this before I suss out where the fix should be done.

Thanks,

Brian Carcich

[Bug c/91373] New: gcc6.2.0: ((U32)((U16 * U16)) >> 31) cannot always get correct result with gcc -O2

[qiang.fu at verisilicon dot com]

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

Bug ID: 91373
   Summary: gcc6.2.0: ((U32)((U16 * U16)) >> 31) cannot always get
correct result with gcc -O2
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qiang.fu at verisilicon dot com
  Target Milestone: ---

Created attachment 46676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46676=edit
main.c

Hi,

I met an issue with gcc6.2.0:  ((U16 * U16) >> 31) cannot always get expected
result for gcc optimization switch '-O2'.
e.g.
 (63139 * 36032) >> 30 = 0x2 // right
 (63139 * 36032) >> 31 = 0x0 // wrong, should be 0x1.

I create a test case for it, see the attachement(main.c). It passed on gcc
4.6.3, but failed with gcc6.2.0 + release build(gcc -O2) 


gcc -O2 main.c -o test
./test 63139 36032
data1: 0x879a1e40, data1 >> 31: 1, data1 >> 30: 2
data2: 0x879a1e40, data2 >> 31: 0, data1 >> 30: 2


This test passed if build with -O0 or -O1 with gcc6.2.0


GCC version: 6.2.0
 *
 gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
gcc version 6.2.0 (GCC)

[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize

[phd at phd dot re]

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

--- Comment #3 from Piotr Henryk Dabrowski  ---
Sent:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00325.html

[Bug target/91349] [9 regression] powerpc*-*-freebsd* defines _GNU_SOURCE

[amodra at gmail dot com]

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

--- Comment #9 from Alan Modra  ---
> I have no idea which parts are GNU-specific, and which parts power actually 
> needs.
Yeah, I was being cheeky in suggesting you provide the effort needed.

> I can just see that your change to include gnu-user.h on non-GNU targets 
> seems like a design smell, and the requirement to kluge around it by 
> #undef'ing things later confirms it.
If #undefs are a measure of "design smell" then rs6000/freebsd64.h already had
forty before I added two more.  Many of those are there due to including other
headers that define OS specific macros unsuitable for freebsd.

The mess is mostly due to rs6000/sysv4.h -mcall- support.  Without
that I may not have needed to include gnu-user.h before rs6000/sysv4.h
everywhere.  The -mcall stuff needs to disappear before any meaningful
untangling of OS-specific macros in the rs6000 header files can be done.

[Bug c++/91304] maybe_unused attribute ignored on variable declared in if declaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.0, 9.1.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  These forms work:

  int f();

  void g()
  {   
if (int i [[maybe_unused]] = f()) { }
  }

  void h()
  {   
if (auto i [[maybe_unused]] = f()) { }
  }

[Bug middle-end/50476] Warn of pointer set to object whose lifetime is limited

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Tue Aug  6 00:30:02 2019
New Revision: 274135

URL: https://gcc.gnu.org/viewcvs?rev=274135=gcc=rev
Log:
PR middle-end/50476 - Warn of pointer set to object whose lifetime is limited

gcc/testsuite/ChangeLog:
* gcc.dg/uninit-pr50476.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/uninit-pr50476.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/50476] Warn of pointer set to object whose lifetime is limited

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
  Known to work||10.0, 7.3.0, 8.3.0, 9.1.0
 Resolution|--- |FIXED
  Known to fail||4.5.2, 4.8.5, 4.9.4, 5.4.0,
   ||6.4.0

--- Comment #6 from Martin Sebor  ---
GCC 7 and later diagnose the test case:

pr50476.c: In function ‘main’:
pr50476.c:17:9: warning: ‘y’ is used uninitialized in this function
[-Wuninitialized]
   17 | printf("int: %d\n", *x);
  | ^~~

The warning is less from ideal because it doesn't point to the y it refers to
but that's a separate issue.

The change that added the warning is r245840 so this can be resolved as fixed.

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[msebor at gcc dot gnu.org]

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

--- Comment #26 from Martin Sebor  ---
Author: msebor
Date: Tue Aug  6 00:08:45 2019
New Revision: 274130

URL: https://gcc.gnu.org/viewcvs?rev=274130=gcc=rev
Log:
PR c++/60517 - warning/error for taking address of member of a temporary object

testsuite/ChangeLog:
* g++.dg/pr60517.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr60517.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/50476] Warn of pointer set to object whose lifetime is limited

[msebor at gcc dot gnu.org]

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

Bug 60517 Summary: warning/error for taking address of member of a temporary 
object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517

   What|Removed |Added

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

[Bug c/45821] no warning when returning a local variable address within a statement expression

[msebor at gcc dot gnu.org]

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

Bug 60517 Summary: warning/error for taking address of member of a temporary 
object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517

   What|Removed |Added

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

[Bug c++/51270] missed warning about returning reference to temporary

[msebor at gcc dot gnu.org]

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

Bug 60517 Summary: warning/error for taking address of member of a temporary 
object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517

   What|Removed |Added

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

[Bug c++/60517] warning/error for taking address of member of a temporary object

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Known to work||9.1.0
 Resolution|--- |FIXED
  Known to fail||4.9.1, 5.5.0, 6.4.0, 7.4.0,
   ||8.3.0

--- Comment #25 from Martin Sebor  ---
GCC 9 rejects the test case with the error below:

$ cat pr60517.C && gcc -Wall -S pr60517.C
class B {
public:
double x[2];
};
class A {
B b;
public:
B getB(void) { return b; }
};

double foo(A a) {
double * x = &(a.getB().x[0]);
return x[0];
}

pr60517.C: In function ‘double foo(A)’:
pr60517.C:12:33: error: taking address of rvalue [-fpermissive]
   12 | double * x = &(a.getB().x[0]);
  | ^

The change that introduced the error is r260621:

CWG 616, 1213 - value category of subobject references.

* tree.c (lvalue_kind): A reference to a subobject of a prvalue is
an xvalue.
* typeck2.c (build_m_component_ref): Likewise.
* typeck.c (cp_build_addr_expr_1, lvalue_or_else): Remove diagnostic
distinction between temporary and xvalue.

I don't see a test case for this error so let me add one and resolve the bug.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[msebor at gcc dot gnu.org]

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

Bug 91335 Summary: False positive "unused variable" warning with variable 
initialized in 'if' condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91335

   What|Removed |Added

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

[Bug c++/91335] False positive "unused variable" warning with variable initialized in 'if' condition

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Declaring the variable with attribute unused (or [[maybe_unused]]) is the
intended mechanism to suppress the warning when the variable is meant to be
declared but not otherwise referenced:

  int main() {
if (int *f __attribute__ ((unused)) = foo())
  return 1;
  }

I agree that the warning for the test case is not just by design but desirable,
and since there are several straightforward solutions I think this report
should be resolved invalid.

[Bug tree-optimization/91109] [10 regression][arm] gcc.c-torture/execute/20040709-1.c fails since r273135

[bernd.edlinger at hotmail dot de]

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

--- Comment #8 from Bernd Edlinger  ---
Patch is posted here: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00305.html

[Bug middle-end/91358] Wrong code with dynamic allocation and optional like class

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
No wrong code involved here.  The uninitialized register that valgrind
complains
about is only uninitialized in exactly the case when %ebp (aka .m_initialized)
is zero.  So the insn sequence

=> 0x004007af <+31>:test   %rbx,%rbx
   0x004007b2 <+34>:je 0x4007b9 )+41>
   0x004007b4 <+36>:test   %bpl,%bpl
   0x004007b7 <+39>:jne0x4007c0 )+48>
   0x004007b9 <+41>:add$0x8,%rsp

goes to 0x4007b9 no matter what.  (if %rbx==uninit happens to be zero, then
directly, otherwise via the not-taken jump at 0x4007b7, because %ebp is zero).

The read from the uninitialized memory itself (from .ptr) is harmless as well,
because the memory backing that access must be there, as the structure is
large enough.

So, if you've seen a real problem somewhere (and not just valgrind complaining
about uninitialized registers in comparisons), then you've reduced the testcase
too much.  (The abort() in the testcase leads me to think that this was once
a larger testcase where the abort was triggered unexpectedly.  I'll note that
it isn't triggered with this testcase.)

[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]

[phdofthehouse at gmail dot com]

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

JeanHeyd Meneide  changed:

   What|Removed |Added

 CC||phdofthehouse at gmail dot com

--- Comment #2 from JeanHeyd Meneide  ---
I'm the one who made the patch. I'd be happy to help field any questions or fix
anything!

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

[matz at gcc dot gnu.org]

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

--- Comment #3 from Michael Matz  ---
Also fixed by the patch at PR90796.

[Bug fortran/91372] Error: Unclassifiable statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed.  Sorry about the confusion.

[Bug middle-end/90796] [8/9/10 Regression] GCC: O2 vs O3 output differs on simple test

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz  ---
Created attachment 46675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46675=edit
potential patch

Actually I was barking up the wrong tree.  It's not as easy as the CFG
manipulation for loop fusion going wrong (like missing some last iterations
or so).  It's really a problem in the dependence analysis.  See the extensive
comment in the patch.

The fun thing is, there's a difference between these two loop nests:

   for (i) for (j) a[i][0] = f(a[i+1][0]);
   for (i) for (j) b[i][j] = f(a[i+1][j]);

Even though the distance vector for the read/write in the single statement
is (-1,0) for both loops, unroll-and-jam is valid for the second but not
for the first.

[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Mon Aug  5 19:34:23 2019
New Revision: 274123

URL: https://gcc.gnu.org/viewcvs?rev=274123=gcc=rev
Log:
PR c++/88095, CTAD for literal operator templates per P0732

This patch fixes PR c++/88095: class nontype template parameter UDL string
literals doesn't accepts deduction placeholder

It also addresses a latent issue; literal operator templates with template
parameter packs of literal class type were previously accepted.  The patch
corrects this and adds a test (udlit-class-nttp-neg.C).

This fix is needed for one of the char8_t remediation approaches documented
in P1423, and may be helpful for existing code bases impacted by the char8_t
changes adopted via P0482 for C++20.

gcc/cp/ChangeLog:

2019-08-02  Tom Honermann  

* parser.c (cp_parser_template_declaration_after_parameters): Enable
class template argument deduction for non-type template parameters
in literal operator templates.

gcc/testsuite/ChangeLog:

2019-08-02  Tom Honermann  

PR c++/88095
* g++.dg/cpp2a/udlit-class-nttp-ctad.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C: New test.
* g++.dg/cpp2a/udlit-class-nttp.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-neg.C: New test.
* g++.dg/cpp2a/udlit-class-nttp-neg2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg.C
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad-neg2.C
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-ctad.C
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg.C
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp-neg2.C
trunk/gcc/testsuite/g++.dg/cpp2a/udlit-class-nttp.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91372] Error: Unclassifiable statement

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Aug  5 19:24:31 2019
New Revision: 274122

URL: https://gcc.gnu.org/viewcvs?rev=274122=gcc=rev
Log:
2019-08-05  Steven g. Kargl  

PR fortran/91372
* decl.c (gfc_match_data): Allow an implied do-loop to nestle against
DATA.

2019-08-05  Steven g. Kargl  

PR fortran/91372
* gfortran.dg/pr91372.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91372.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91372] Error: Unclassifiable statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Severity|normal  |trivial

[Bug fortran/91372] Error: Unclassifiable statement

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Mon, Aug 05, 2019 at 06:44:31PM +, kargl at gcc dot gnu.org wrote:
> 
> The code is invalid.
> 
> Free-form source code requires whitespace after "DATA".
> 

So my reading to 

R837 data-stmt  is DATA data-stmt-set [ [ , ] data-stmt-set ] ...

may have been to strict.  The standard has

  A blank shall be used to separate names, constants, or labels
  from adjacent keywords, names, constants, or labels. 

The '(' isn't a name, constant, or label, so the blank may
be omitted.  Easy to fix.

[Bug c++/91338] Implement P1161R3: Deprecate a[b,c]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Implemented for 10.1.

[Bug c++/91338] Implement P1161R3: Deprecate a[b,c]

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Aug  5 19:01:15 2019
New Revision: 274121

URL: https://gcc.gnu.org/viewcvs?rev=274121=gcc=rev
Log:
PR c++/91338 - Implement P1161R3: Deprecate a[b,c].
* c-opts.c (c_common_post_options): Enable -Wcomma-subscript by
default for C++2a, unless -Wno-deprecated.
* c.opt (Wcomma-subscript): New warning.

* parser.c (cp_parser_postfix_open_square_expression): Warn about uses
of a comma operator within a subscripting expression.
(cp_parser_skip_to_closing_square_bracket_1): New function, made out
of...
(cp_parser_skip_to_closing_square_bracket): ...this.

* doc/invoke.texi: Document -Wcomma-subscript.

* g++.dg/cpp2a/comma1.C: New test.
* g++.dg/cpp2a/comma2.C: New test.
* g++.dg/cpp2a/comma3.C: New test.
* g++.dg/cpp2a/comma4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/comma1.C
trunk/gcc/testsuite/g++.dg/cpp2a/comma2.C
trunk/gcc/testsuite/g++.dg/cpp2a/comma3.C
trunk/gcc/testsuite/g++.dg/cpp2a/comma4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug fortran/90985] Wrong error message with variables named "DATA*"

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Blocks||91372

--- Comment #4 from H.J. Lu  ---
This may have caused PR 91372.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91372
[Bug 91372] Error: Unclassifiable statement

[Bug c++/91361] Implement P1152R4: Deprecating some uses of volatile

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Actually, no reason not to link R4: .

[Bug c/78155] missing warning on invalid isalpha et al.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||87403

--- Comment #5 from Eric Gallager  ---
ok, making this block the "new-warning" meta-bug then


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug fortran/91372] [10 Regression] Error: Unclassifiable statement

[kargl at gcc dot gnu.org]

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

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 H.J. Lu from comment #0)
> r274054 gave:
> 
> [hjl@gnu-skl-2 build_base_gcc-m64.]$ cat foo.f90 > 

> 
> 9 | data(sand(i), i=1,19)/92.,80.,66.,20.,5.,43.,60.,&


The code is invalid.

Free-form source code requires whitespace after "DATA".

[Bug fortran/91372] New: [10 Regression] Error: Unclassifiable statement

[hjl.tools at gmail dot com]

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

Bug ID: 91372
   Summary: [10 Regression] Error: Unclassifiable statement
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

r274054 gave:

[hjl@gnu-skl-2 build_base_gcc-m64.]$ cat foo.f90 
MODULE module_sf_lake

implicit none 
integer, parameter ::  r8 = selected_real_kind(12) 

integer, private  :: i  ! loop index 
real(r8) :: sand(19)   ! percent sand

data(sand(i), i=1,19)/92.,80.,66.,20.,5.,43.,60.,&
  10.,32.,51., 6.,22.,39.7,0.,100.,54.,17.,100.,92./

END MODULE module_sf_lake
[hjl@gnu-skl-2 build_base_gcc-m64.]$
/export/gnu/import/git/gcc-test-spec/usr/bin/gfortran  -m64 -c -o
module_sf_lake.fppized.o -I. -I./netcdf/include -I./inc
-fno-unsafe-math-optimizations -mfpmath=sse -march=native -O2
-fconvert=big-endian  foo.f90
foo.f90:9:4:

9 | data(sand(i), i=1,19)/92.,80.,66.,20.,5.,43.,60.,&
  |1
Error: Unclassifiable statement at (1)
[hjl@gnu-skl-2 build_base_gcc-m64.]$

[Bug fortran/91359] logical function X returns .TRUE. - Warning: spaghetti code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 CC||kargl at gcc dot gnu.org
Summary|GFORTRAN [N RETURN]  of |logical function X returns
   |.FALSE. logical function X  |.TRUE. - Warning:
   |returns .TRUE. after [if|spaghetti code
   |(.not.X) goto N] -  |
   |Warning:  spaghetti code|
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
The options -finit-local-zero and -fno-automatic are unimportant.

Compiling the code in comment #1 with -fdump-tree-original reveals
the problem as the function is translated into 

zero ()
{
  logical(kind=4) __result_zero;

  goto __label_02;
  __label_01:;
  return;
  __label_02:;
  __result_zero = 0;
  if (!__result_zero) goto __label_01;
  L.1:;
  return __result_zero;
  return __result_zero;
}

Notice the first 'return' statement has no value to return.
A work around to to introduce a RESULT variable.  This is
translated to

  function zero() result(a)
 logical a
 goto 2
1return
2a = .false.
 if (.not. a) goto 1
 return
  end

zero ()
{
  logical(kind=4) a;

  goto __label_02;
  __label_01:;
  return a;
  __label_02:;
  a = 0;
  if (!a) goto __label_01;
  L.1:;
  return a;
  return a;
}

[Bug target/88918] [meta-bug] x86 intrinsic issues

[jakub at gcc dot gnu.org]

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

Bug 91341 Summary: Missing AVX Intrinsics: load/store u2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91341

   What|Removed |Added

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

[Bug target/91341] Missing AVX Intrinsics: load/store u2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Implemented for 10.1.

[Bug c/80619] bad fix-it hint for GCC %lu directive with int argument: %wu

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00286.html

[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

--- Comment #4 from H.J. Lu  ---
This compiles:

---
#include 

__m256i
_mm256_zextsi128_si256 (__m128i x)
{
  return __extension__ (__m256i) { x[0], x[1], 0, 0 };
}

__m512i
_mm512_zextsi256_si512 (__m256i x)
{
  return __extension__ (__m512i) { x[0], x[1], x[2], x[3],
   0, 0, 0, 0 };
}

__m512i
_mm512_zextsi128_si512 (__m128i x)
{
  return _mm512_zextsi256_si512 (_mm256_zextsi128_si256 (x));
}
---

But combiner doesn't convert nested vec_concat into a single vec_concat:

Trying 12 -> 14: 
   12: r94:V4DI=vec_concat(r96:V2DI,const_vector)
  REG_DEAD r96:V2DI
   14: r87:V8DI=vec_concat(r94:V4DI,const_vector)
  REG_DEAD r94:V4DI
Failed to match this instruction:
(set (reg:V8DI 87) 
(vec_concat:V8DI (vec_concat:V4DI (reg:V2DI 96) 
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
]))
(const_vector:V4DI [
(const_int 0 [0]) repeated x4
])))

Also we don't have patterns for AVX/AVX512 instructions with zero
extension, like

(set (reg:V4DI 91)
(vec_concat:V4DI (subreg:V2DI (plus:V16QI (subreg:V16QI (reg:V2DI 97) 0)
(subreg:V16QI (reg:V2DI 96) 0)) 0)
(const_vector:V2DI [
(const_int 0 [0]) repeated x2
])))

[Bug c/91362] program compiled with O3 optimization give different output than without optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is an alias violation for sure.
You write ctx->c as uint64_t and then read it as uint32_t in a few places.
Even inside gascon_rotr64_interleaved2 too.

Either use an union of (array of uint32_t) and an uint64_t or use memcpy to
read as uint32_t.

[Bug target/58684] powerpc uses only unordered floating-point compares

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
*** Bug 91331 has been marked as a duplicate of this bug. ***

[Bug target/91331] new test case gcc.dg/torture/pr91323.c from r274005 fails

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #2 from Segher Boessenkool  ---
This is another instance of PR58684.

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

[Bug target/83250] _mm256_zextsi128_si256 missing for AVX2 zero extension

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||a-yee at u dot northwestern.edu

--- Comment #3 from H.J. Lu  ---
*** Bug 91340 has been marked as a duplicate of this bug. ***

[Bug target/88918] [meta-bug] x86 intrinsic issues

[hjl.tools at gmail dot com]

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

Bug 91340 Summary: Missing AVX and AVX512 Intrinsics: Zero-Extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91340

   What|Removed |Added

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

[Bug target/91340] Missing AVX and AVX512 Intrinsics: Zero-Extension

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Dup.

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

[Bug libstdc++/91371] New: std::bind and bind_front don't work with function with call convention

[roland at rschulz dot eu]

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

Bug ID: 91371
   Summary: std::bind and bind_front don't work with function with
call convention
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland at rschulz dot eu
  Target Milestone: ---

If a function with call convention function type attribute is passed to
bind/bind_front it fails.

Reproducer:
#include

int bar(int) __attribute__((ms_abi)); //same with fastcall, thiscall

void test() {
std::bind(bar, 5)(); //error: function returning a function
std::bind_front(bar, 5)(); //error: static assertion failed
}

Godbolt showing it works with libc++:
https://godbolt.org/z/3g7Vk7

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Marek Polacek  ---
Patch available:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01670.html

[Bug c/78155] missing warning on invalid isalpha et al.

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
I don't really see what existing warning this might fall under, except perhaps
-Wchar-subscripts because isalpha and friend use the argument as an index into
an array of 257 characters, but that seems like a stretch.

I think maybe adding a more general warning option, say something like
-Wargument-range, and using it to diagnose all such problems, might be the way
to go.  To generalize the solution I would even consider adding a new function
attribute, let's call it range, to specify the range of valid values of a
function argument.  Then isalpha (or any other such function) could be declared
like so:

  __attribute__ ((range (/* position = */1, -1, UCHAR_MAX)))
  int isalpha (int);

GCC would then check every call to the function to see if its argument is in
the expected range and, if not, issue a warning.  The attribute could even be
applied multiple times to specify disjoint ranges.  Position zero could denote
the return value so that toupper could be declared like so

  __attribute__ ((range (/* returns = */ 0, -1, UCHAR_MAX),
  range (/* position = */ 1, -1, UCHAR_MAX)))
  int toupper (int);

[Bug c++/91370] Implement P1041R4 and P1139R2: Stronger Unicode requirements

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91370] New: Implement P1041R4 and P1139R2: Stronger Unicode requirements

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91370
   Summary: Implement P1041R4 and P1139R2: Stronger Unicode
requirements
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per  and .

[Bug c++/91369] New: Implement P0784R7: constexpr new

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91369
   Summary: Implement P0784R7: constexpr new
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c++/91369] Implement P0784R7: constexpr new

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91368] New: Implement P1301R4: [[nodiscard("with reason")]]

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91368
   Summary: Implement P1301R4: [[nodiscard("with reason")]]
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91367] Implement P1099R5: using enum

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91367] New: Implement P1099R5: using enum

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91367
   Summary: Implement P1099R5: using enum
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c++/91366] Implement P1816R0: Class template argument deduction for aggregates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91366] New: Implement P1816R0: Class template argument deduction for aggregates

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91366
   Summary: Implement P1816R0: Class template argument deduction
for aggregates
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c/91362] program compiled with O3 optimization give different output than without optimization

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Looks like an aliasing violation.

[Bug c++/91364] Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91365] Implement P1814R0: Class template argument deduction for alias templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91365] New: Implement P1814R0: Class template argument deduction for alias templates

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91365
   Summary: Implement P1814R0: Class template argument deduction
for alias templates
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c++/91364] New: Implement P0388R4: Permit conversions to arrays of unknown bound

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91364
   Summary: Implement P0388R4: Permit conversions to arrays of
unknown bound
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug libstdc++/91356] Poor optimization of calls involving std::unique_ptr

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The ABI dictates the calling conventions and there's certainly nothing that
libstdc++ can do about it.

In any case, how common is it to have a pointless non-inline baz function which
does nothing but forward to another non-inline function? In practice the
callers of baz will be able to inline it, removing unnecessary null checks on
the moved-from variable, or baz will be able to inline bar, removing the
temporary entirely.

[Bug c++/91363] Implement P0960R3: Parenthesized initialization of aggregates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug c++/91363] New: Implement P0960R3: Parenthesized initialization of aggregates

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91363
   Summary: Implement P0960R3: Parenthesized initialization of
aggregates
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

As per .

[Bug c/91362] New: program compiled with O3 optimization give different output than without optimization

[matic at nimp dot co.uk]

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

Bug ID: 91362
   Summary: program compiled with O3 optimization give different
output than without optimization
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matic at nimp dot co.uk
  Target Milestone: ---

Created attachment 46674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46674=edit
test case, gcc --version output, lscpu output, binaries generated

The attached program give a different output when using O3 optimization level.
The problems seems related to the following piece of code.
if SAFE_AND_SLOW is defined, O3 gives the same results as no optimization
if it is not defined, O3 gives a different result.

for(unsigned int j = 0;j<2;j++){
ctx->c[0] ^= 0xf; 
ctx->c[2] ^= gascon_rotr64_interleaved2(ctx->c[2]) ^
gascon_rotr64_interleaved2(ctx->c[2]);

#ifndef SAFE_AND_SLOW
uint32_t*r32 = (uint32_t*)ctx->r;
uint32_t *cpart = ((uint32_t*)ctx->c);
for(unsigned int i=0;ic;
uint8_t*r8 = (uint8_t*)ctx->r;
for(unsigned int i=0;i ref output
0F00 -> ref output
0F00 -> O3 with
SAFE_AND_SLOW
0F00 -> O3 with
SAFE_AND_SLOW
 -> O3
 -> O3

the testcase is a reduced version of the code here:
https://github.com/sebastien-riou/DryGASCON/tree/master/Implementations/crypto_hash/drygascon128/le32

[Bug c++/91361] Implement P1152R4: Deprecating some uses of volatile

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-05
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
I'll take a look.  Should be mostly about adding a few warnings.

[Bug c++/91361] New: Implement P1152R4: Deprecating some uses of volatile

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91361
   Summary: Implement P1152R4: Deprecating some uses of volatile
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

R3 here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1152r3.html
R4 not yet publicly available so won't link it here.

[Bug libstdc++/91357] _GLIBCXX_ASSERTIONS rejects possibly-valid code

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
More specifically:

v.operator[](1); /* maybe okay -- forms a pointer one past end */

Not OK. **Dereferences** a past-the end iterator. That's UB. Go to jail. Go
directly to jail. Do not pass Go. Do not collect £200.

v[1]; /* highly suspicious but not obviously invalid or UB */

UB for the same reason.

int *ugly_end = [1]; /* hmm.  is this okay? */

No. v[1] is UB already, [1] doesn't make it unundefined.

std::cout << v[1] << std::endl;  /* definitely not okay */

v[2]; /* definitely not okay -- merely computing this pointer is UB */

There's no pointer. vector::operator[] is not specified in terms of pointers.
This is not C.

The assertion is entirely correct. Calling operator[] with an invalid value is
UB, it doesn't matter what you do (or don't do) with the result.

[Bug libstdc++/91357] _GLIBCXX_ASSERTIONS rejects possibly-valid code

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
It's UB, no question. The table of "Optional sequence container operations"
says a[n] is equivalent to *(a.begin() + n) so when n==a.size() you dereference
the past-the-end iterator, which is UB.

[Bug c++/91360] Implement P1143R2: constinit

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-08-05
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

[Bug c++/91360] New: Implement P1143R2: constinit

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91360
   Summary: Implement P1143R2: constinit
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

First revision available here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1143r1.md

[Bug fortran/91359] New: GFORTRAN [NNNNN RETURN] of .FALSE. logical function X returns .TRUE. after [if (.not.X) goto NNNNN] - Warning: spaghetti code

[briantcarcich at gmail dot com]

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

Bug ID: 91359
   Summary: GFORTRAN [N RETURN]  of .FALSE. logical function X
returns .TRUE. after [if (.not.X) goto N] -
Warning:  spaghetti code
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: briantcarcich at gmail dot com
  Target Milestone: ---

Created attachment 46673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46673=edit
Minimal test case; test_zero.f90 from gfortran -save-temps ... test_zero.f

This error does not appear with G77; I also tried it with GFORTRAN 4.4.7 and it
did not appear there. 

I attached a minimal test case (.f90, not .i*, as this is FORTRAN).  It was
generated from source file test_zero.f, which has the following contents:

  logical function zero()
  goto 2
1 return
2 zero = .false.
  if (.not.zero) goto 1
  return
  end
  program test_zero
  logical zero
  if (zero()) stop 'FAIL:  zero() returned .TRUE.'
  stop 'OKAY:  zero() returned .FALSE.'
  end

The simplest commands to produce the bug are preceded by [>] below; the
responses are as shown between the commands:

> gfortran -std=legacy -g -O0 -finit-local-zero -fno-automatic -Wall \
  test_zero.f  -o test_zero_gfortran.e -save-temps -v

Driving: gfortran -std=legacy -g -O0 -finit-local-zero -fno-automatic -Wall
test_zero.f -o test_zero_gfortran.e -save-temps -v -l gfortran -l m
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.11) 
COLLECT_GCC_OPTIONS='-std=legacy' '-g' '-O0' '-finit-local-zero'
'-fno-automatic' '-Wall' '-o' 'test_zero_gfortran.e' '-save-temps' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/f951 test_zero.f -ffixed-form -quiet -dumpbase
test_zero.f -mtune=generic -march=x86-64 -auxbase test_zero -g -O0 -Wall
-std=legacy -version -finit-local-zero -fno-automatic -fintrinsic-modules-path
/usr/lib/gcc/x86_64-linux-gnu/5/finclude -o test_zero.s
GNU Fortran (Ubuntu 5.4.0-6ubuntu1~16.04.11) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Ubuntu 5.4.0-6ubuntu1~16.04.11) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
test_zero.f:3:0:

 1 return
 ^
Warning: control reaches end of non-void function [-Wreturn-type]
COLLECT_GCC_OPTIONS='-std=legacy' '-g' '-O0' '-finit-local-zero'
'-fno-automatic' '-Wall' '-o' 'test_zero_gfortran.e' '-save-temps' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o test_zero.o test_zero.s
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.26.1
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/5/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-std=legacy' '-g' '-O0' '-finit-local-zero'
'-fno-automatic' '-Wall' '-o' 'test_zero_gfortran.e' '-save-temps' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/

[Bug middle-end/91358] New: Wrong code with dynamic allocation and optional like class

[antoshkka at gmail dot com]

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

Bug ID: 91358
   Summary: Wrong code with dynamic allocation and optional like
class
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

The issue is reproduced on GCCs from 5 to 9 with -O2 and -std=c++11. GCC-10
also generates wrong code with -O2 -std=c++11 -fno-allocation-dce.

Source code:

template
struct optional {
  optional() : m_initialized(false) {}

  ~optional() {
if (m_initialized)
  reinterpret_cast(m_storage).~T();
  }

  bool m_initialized;
  alignas(T) unsigned char m_storage[sizeof(T)];
};

struct NoPtr1 {
  void *ptr = nullptr;

  ~NoPtr1() {
if (ptr) {
  __builtin_abort();
}
  }
};

static void test(optional ) noexcept {
  delete new unsigned;
}

void process(optional state) {
  return test(state);
}

int main() {
  process({});
}


The above code generates a conditional jump that depends on uninitialised
value. valgrind complains:
==13823==at 0x4007B2: ~NoPtr1 (main.cpp:18)
==13823==by 0x4007B2: ~optional (main.cpp:7)
==13823==by 0x4007B2: process(optional) (main.cpp:29)
==13823==by 0x40067F: main (main.cpp:33)


Running the example under GDB confirms that the destructor of NoPtr1 is called:

(gdb) break main.cpp:18
Breakpoint 1 at 0x400686: main.cpp:18. (2 locations)
(gdb) r
Breakpoint 1, NoPtr1::~NoPtr1 (this=, __in_chrg=)
at main.cpp:18
18  if (ptr) {
(gdb) bt
#0  NoPtr1::~NoPtr1 (this=, __in_chrg=) at
main.cpp:18
#1  optional::~optional (this=, __in_chrg=) at main.cpp:7
#2  process (state=...) at main.cpp:29
#3  0x00400680 in main () at main.cpp:33
(gdb) disassemble 
Dump of assembler code for function process(optional):
   0x00400790 <+0>: push   %rbp
   0x00400791 <+1>: push   %rbx
   0x00400792 <+2>: sub$0x8,%rsp
   0x00400796 <+6>: mov0x8(%rdi),%rbx
   0x0040079a <+10>:movzbl (%rdi),%ebp
   0x0040079d <+13>:mov$0x4,%edi
   0x004007a2 <+18>:callq  0x400600 <_Znwm@plt>
   0x004007a7 <+23>:mov%rax,%rdi
   0x004007aa <+26>:callq  0x4005f0 <_ZdlPv@plt>
=> 0x004007af <+31>:test   %rbx,%rbx
   0x004007b2 <+34>:je 0x4007b9 )+41>
   0x004007b4 <+36>:test   %bpl,%bpl
   0x004007b7 <+39>:jne0x4007c0 )+48>
   0x004007b9 <+41>:add$0x8,%rsp
   0x004007bd <+45>:pop%rbx
   0x004007be <+46>:pop%rbp
   0x004007bf <+47>:retq   
   0x004007c0 <+48>:callq  0x4005e0 

[Bug c/80619] bad fix-it hint for GCC %lu directive with int argument: %wu

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
No, the bug is still there.  This patch fixes it without braking any of the
format.exp tests.

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 6363fa4f686..1fa551957d9 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -497,7 +497,7 @@ static const format_length_info printf_length_specs[] =
 static const format_length_info asm_fprintf_length_specs[] =
 {
   { "l", FMT_LEN_l, STD_C89, "ll", FMT_LEN_ll, STD_C89, 0 },
-  { "w", FMT_LEN_none, STD_C89, NO_FMT, 0 },
+  { "w", FMT_LEN_w, STD_C89, NO_FMT, 0 },
   { NO_FMT, NO_FMT, 0 }
 };

@@ -505,7 +505,7 @@ static const format_length_info asm_fprintf_length_specs[]
=
 static const format_length_info gcc_diag_length_specs[] =
 {
   { "l", FMT_LEN_l, STD_C89, "ll", FMT_LEN_ll, STD_C89, 0 },
-  { "w", FMT_LEN_none, STD_C89, NO_FMT, 0 },
+  { "w", FMT_LEN_w, STD_C89, NO_FMT, 0 },
   { NO_FMT, NO_FMT, 0 }
 };

diff --git a/gcc/c-family/c-format.h b/gcc/c-family/c-format.h
index 972ba46f109..6aa68dfe883 100644
--- a/gcc/c-family/c-format.h
+++ b/gcc/c-family/c-format.h
@@ -36,6 +36,7 @@ enum format_lengths
   FMT_LEN_H,
   FMT_LEN_D,
   FMT_LEN_DD,
+  FMT_LEN_w,   /* GCC's HOST_WIDE_INT.  */
   FMT_LEN_MAX
 };

[Bug c/91312] -Wconversion warning with += operator

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
We know that the warning is not so useful as is, that's why it isn't part of
Wall or Wextra, see the other bugs on the topic. It needs people with time and
motivation to work on it.

[Bug target/91349] [9 regression] powerpc*-*-freebsd* defines _GNU_SOURCE

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(assuming something like TARGET_REALLY_GNU existed)

[Bug target/91349] [9 regression] powerpc*-*-freebsd* defines _GNU_SOURCE

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
I have no idea which parts are GNU-specific, and which parts power actually
needs. I can just see that your change to include gnu-user.h on non-GNU targets
seems like a design smell, and the requirement to kluge around it by #undef'ing
things later confirms it.

The gnu-user.h file has several comments that talk about "GNU userspace" and
none at all that make it obvious it's also used on unrelated targets like
FreeBSD. So it's not obvious that changes to that file now need to consider the
effect on non-GNU targets.

Your comments in rs6000/freebsd.h and rs6000/freebsd64.h just say "Undef
gnu-user.h macros we don't want." Those comments would be more use if they
mentioned why gnu-user.h macros are defined in the first place for FreeBSD and
NetBSD.

And what about all the other non-GNU targets affected by r266496? Is
_GNU_SOURCE now defined for RTEMS? VxWorks?

A smaller (but still smelly) fix would be something like:

--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -90,9 +90,11 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If
not, see
 #define CC1_SPEC GNU_USER_TARGET_CC1_SPEC
 #endif

+#ifdef TARGET_REALLY_GNU
 /* The GNU C++ standard library requires that these macros be defined.  */
 #undef CPLUSPLUS_CPP_SPEC
 #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)"
+#endif

 #define GNU_USER_TARGET_NO_PTHREADS_LIB_SPEC \
   "%{shared:-lc} \
@@ -113,8 +115,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If not, see
   "%{static|static-pie:--start-group} %G %{!nolibc:%L} \
%{static|static-pie:--end-group}%{!static:%{!static-pie:%G}}"

+#ifdef TARGET_REALLY_GNU
 #undef LINK_GCC_C_SEQUENCE_SPEC
 #define LINK_GCC_C_SEQUENCE_SPEC GNU_USER_TARGET_LINK_GCC_C_SEQUENCE_SPEC
+#endif

 /* Use --as-needed -lgcc_s for eh support.  */
 #ifdef HAVE_LD_AS_NEEDED

[Bug sanitizer/91311] __attribute__ ((aligned (128))) results in stack-use-after-scope and stack-buffer-overflow

[Hi-Angel at yandex dot ru]

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

Konstantin Kharlamov  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Konstantin Kharlamov  ---
(In reply to Martin Liška from comment #3)
> Sorry, but I can't reproduce the issue with any of GCC 7,8,9 and clang8.

Okay, thanks you! I decided to update my system (including the compiler up to
9.1.0) before digging into it any further. So now the problem went away, and
there's no reason to keep this opened. If I manage to reproduce something
similar with 9.1.0, I'll make a separate report then.

That said, does anyone have any guesses about what could've been causing it?
I.e. what to look at if I stumble upon that again?

[Bug c/88451] No rounding in fixed-point arithmetic (Decimal to fixed-point conversion, multiplication)

[mantas.mikaitis at manchester dot ac.uk]

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

--- Comment #5 from Mantas Mikaitis  
---
Hello,

I am raising this again. Has anyone had a change to confirm my testcases fail
in the latest version of the compiler?

Kind regards,
Mantas Mikaitis

[Bug libstdc++/91357] New: _GLIBCXX_ASSERTIONS rejects possibly-valid code

[luto at kernel dot org]

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

Bug ID: 91357
   Summary: _GLIBCXX_ASSERTIONS rejects possibly-valid code
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luto at kernel dot org
  Target Milestone: ---

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

For a non-empty vector v, calling v.operator[](v.size()) fires this assertion:

/usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp, _Alloc>::reference
std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with
_Tp = int; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::reference =
int&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion
'__builtin_expect(__n < this->size(), true)' failed.

After some digging into the standard, I'm not entirely sure whether that
particular invocation of operator[] is UB or otherwise invalid.  It's certainly
poor form -- the right way in modern C++ to form a one-past-the-end pointer to
a vector is (v.data() + v.size()), but, if it's indeed legal, then
_GLIBCXX_ASSERTIONS should not be firing.

I suggest one of the following resolutions:

1. Determine that merely calling v.operator[](v.size()) is UB or that it is
otherwise permissible for a conforming implementation to crash when this
happens.  This would require some careful standard reading and maybe even a
change to the standard.

2. Weaken the assertion to only crash if the index is strictly greater than the
size.  Calling v.operator[](v.size() + 1) is definitely UB (except perhaps in
the pathological case where v.size() + 1 == 0, but I doubt it's possible to
make a vector that large on any supported platform).

3. Use compiler magic to only fire the assertion if the pointer returned by
operator[] is dereferenced for real, e.g. dereferenced and converted to an
lvalue.  Maybe gcc could gain a builtin like
__builtin_return_value_is_definitely_dereferenced().

4. Improve the assertion so that, when this assertion fires, a very clear
message is printed to stderr saying something like "This assertion fired due to
the formation of a one-past-the-end reference.  This may indicate a stylistic
issue with the program but is not necessarily a bug."

[Bug c/91312] -Wconversion warning with += operator

[kosotiro at yahoo dot gr]

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

--- Comment #7 from Kostas Sotiropoulos  ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Kostas Sotiropoulos from comment #4)
> > Any comments on my questions?
> 
> Yes go read the c standard about prompting to int here.

I had checked the standard from the following link:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

I suppose that you mean the following two sections that cover our case:

6.5.16.2

A compound assignment of the form E1 op=E2 is equivalent to the simple
assignment expression E1 = E1 op (E2), except that the lvalue E1
is evaluated only once, and with respect  to  an  indeterminately-sequenced 
function  call,  the  operation  of  a  compound assignment  is  a  single 
evaluation. 

6.3.1.1 Boolean, characters, and integers

2 The following may be used in an expression wherever an int or unsigned int
may be used:

—  An object  or  expression  with  an  integer  type  (other  than int
or unsigned int) whose  integer  conversion  rank  is  less  than  or  
equal  to  the  rank  of int and unsigned int.

—  A bit-field of type _Bool, int, signed int, or unsigned int.

If an int can  represent  all  values  of  the  original  type  
(as  restricted  by  the  width,  for  a bit-field),  the  value  is  
converted  to  an int; otherwise,  it  is  converted  to  an unsigned int. 
These  are  called  the integer promotions. All  other  types  are  
unchanged  by  the integer promotions.

So considering the above two sections, if we even cast 
i += (unsigned char) MACRO then this would be equal to
i = i + (unsigned char) MACRO.

But, what if I want to avoid this warning then the only way to get 
rid of it is the following way?

i = (unsigned char) (i + MACRO).

But we will lose on code optimization be this way, do not we? Especially
when we are talking about Embedded Systems software.

Please note that the same code snippet passes through clang compiler (clang
version 3.8.1-24) without any warning when -Werror=conversion is used during
compilation. I suppose that even this compiler follows C standard. In my 
opinion such kind of warnings are false positives that should not be reported
from gcc compiler too.

Maybe a change of this kind on gcc compiler opens the Pandora's Box for other
things but someone should not avoid of defining MACROS and use them on compound
statements (+=, -=, *= etc) and sacrifice code optimization by expanding them.

Waiting for your comments.

[Bug c++/82380] [concepts] Error when using requires constraint with attributes

[mateusz.pusz at gmail dot com]

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

Mateusz Pusz  changed:

   What|Removed |Added

 CC||mateusz.pusz at gmail dot com

--- Comment #3 from Mateusz Pusz  ---
Casey's workaround works but it is a workaround. It would be nice to fix it for
C++20 concepts.

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Note, I won't have time soon to work on this further, so if anyone wants to
take it over, reusing or not reusing the above patch, feel free.

[Bug libstdc++/91356] New: Poor optimization of calls involving std::unique_ptr

[nisse at lysator dot liu.se]

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

Bug ID: 91356
   Summary: Poor optimization of calls involving std::unique_ptr
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nisse at lysator dot liu.se
  Target Milestone: ---

The naïve understanding of unique_ptr, is that it is handled the same
way as a raw pointer, with just

* additional compile time safety checks, and

* automatic runtime calls to delete whenever a non-null unique_ptr
  goes out of scope.

However, the calling convention for unique_ptr implies a *lot* more
overhead than passing a raw pointer. For a start, a unique_ptr is not
passed in a register, but by "invisible reference". To make things
worse, the invisible reference refers to a temporary object that the
caller is responsible for destroying.

Consider a function just passing on a unique_ptr:

  void bar(std::unique_ptr p);
  void baz(std::unique_ptr p) { bar(std::move(p)); }

This compiles (with g++-8 -O3 --fno-exceptions, on gnu/linux x86_64)
to

  _Z3bazSt10unique_ptrIiSt14default_deleteIiEE:
  subq$24, %rsp
  movq(%rdi), %rax
  movq$0, (%rdi)
  leaq8(%rsp), %rdi
  movq%rax, 8(%rsp)
  call_Z3barSt10unique_ptrIiSt14default_deleteIiEE@PLT
  movq8(%rsp), %rdi
  testq   %rdi, %rdi
  je  .L6
  movl$4, %esi
  call_ZdlPvm@PLT
  .L6:
  addq$24, %rsp
  ret

As I read this, the steps are

1. Allocate a new temporary unique_ptr on the stack.

2. Move-construct it from the input argument (pointed to by %rdi).

3. Put the address of the object in %rdi, and invoke the bar function.

4. Destroy the temporary object, including a null test and a branch,
   and a call to the destructor of the underlying type if appropriate.

This can be compared to the raw pointer version,

  void bar(int* p);
  void baz(int* p) { bar(p); }

which compiles to a single jump instruction:

_Z3bazPi:
jmp _Z3barPi@PLT

As far as I understand, it's not possible to really fix this in just
the compiler or library, it's also an ABI issue. I see two somewhat
independent things needed to make the calling convention for
unique_ptr more efficient:

1. Move responsibility for destructing the temporary object from
   caller to callee. This is particularly nice for unique_ptr, since
   the callee often knows statically that the unique_ptr is null when
   going out of scope, and then both the null test and the destructor
   call should be optimized away completely. I don't fully understand
   C++ rules on destruction order, but I've been told that
   callee-destruction is allowed by the language specification (and
   used in the i386-pc-win32 abi). It's less clear if a forwarding
   function like baz(std::unique_ptr p) can delegate
   responsibility further.

2. Make it possible to pass small objects in registers, even if they
   have a non-trivial destructor or copy-constructor. In particular,
   invoke the unique_ptr destructor with the object to be destructed
   in a register. 

   The callee may then need to move the object to memory if it for any
   reason needs a pointer to it. To allow that move, one may need
   something like a "relocatable" property,
   https://quuxplusone.github.io/draft/d1144-object-relocation.html, or
   https://en.cppreference.com/w/cpp/language/attributes/no_unique_address

[Bug c++/91355] [8/9/10 Regression] optimized code does not call destructor while unwinding after exception

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Reduced:

extern "C" int printf(const char*, ...);

unsigned int Depth = 0;


class Bar {
public:
  Bar() { Depth++; }
  ~Bar() { Depth--; }
};

void Foo(int i) throw(int)
{
  if (i == 0) {
throw 3;
  }

  Bar Depth;

  throw 3;
}

int main()
{
  try {
Foo(1);
  } catch (...) {
  }

  printf("%u\n", Depth);

  return 0;
}


Behaviour changed with r254698:

* tree-ssa-sink.c (select_best_block): Do not use frequencies.

[Bug tree-optimization/91240] [8/9/10 Regression] Wrong code with -O3 due to unroll and jam pass

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Matz  ---
Mine.

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-05
 Ever confirmed|0   |1

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
Richi corrected me -- this is not vectorization, but use of SSE on lane zero to
do scalar computation.