[Bug target/545] -std=c89 defines macros it shouldn't

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #17 from Eric Gallager  ---
(In reply to Ben Elliston from comment #16)
> Not much has changed.  For r131688:
> 
> ./ptx4.h
> ./svr4.h
> ./cris/aout.h
> ./rs6000/aix53.h
> ./rs6000/aix51.h
> ./rs6000/aix52.h
> ./rs6000/aix43.h
> ./rs6000/aix41.h
> ./i386/sco5.h

This first batch of headers no longer exists.

> ./sol2.h

In this header, the check for "ansi" also checks for "std=c" and "std=i" so I
think that means it should be considered fixed.

> ./rs6000/sysv4.h

This header no longer references "ansi" so it can be ignored.

> ./rs6000/aix.h
> ./i386/cygwin.h

These last 2 headers still need to be fixed.

[Bug c++/58999] sizeof ...(T) is very slow than clang

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Paolo Carlini from comment #5)
> Probably a meta-bug about this sort of issue would also make sense. We have
> got a few bugs already.

Which ones do you mean?

[Bug fortran/52274] [Meta-bug] Fortran translation related issues: Typos and more

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
Are the "Depends on" and "Blocks" fields swapped here? Normally meta-bugs
depend on more bugs than they block

[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level

[egallager at gcc dot gnu.org]

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

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=15484
 Blocks|16797, 16802|
 Depends on||16797, 16802

--- Comment #3 from Eric Gallager  ---
I think this is another one of those meta-bugs that falls victim to the change
in the way meta-bugs are done; swapping the "blocks" and "depends on" fields


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16797
[Bug 16797] Opportunity to remove unnecessary load instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16802
[Bug 16802] PowerPC - Unnecessary extsw

[Bug c++/70462] Unnecessary "base object constructor" for final classes

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Jun 26 04:56:07 2019
New Revision: 272669

URL: https://gcc.gnu.org/viewcvs?rev=272669=gcc=rev
Log:
PR c++/70462 - unnecessary base ctor variant with final.

As pointed out in the PR, we don't need base 'tor variants for a final
class, since it can never be a base.  I tried also dropping complete
variants for abstract classes, but that runs into ABI compatibility problems
with older releases that refer to those symbols.

* optimize.c (populate_clone_array): Skip base variant if
CLASSTYPE_FINAL.
(maybe_clone_body): We don't need an alias if we are only defining
one clone.

Added:
trunk/gcc/testsuite/g++.dg/other/final8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/optimize.c

[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to sduguay from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > In any case, I agree with confirming this as a bug: all warnings should be
> > controllable by a -Wxxx option.
> > 
> > Adding such an option is quite easy, and a good first contribution to GCC.
> > For an example of adding a new option see https://gcc.gnu.org/r192968
> 
> I was going to propose looking into it. I'll try to find some time.

Have you found some time yet?

[Bug fortran/90988] Wrong error message with variables named "PUBLIC*"

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
fixed

[Bug fortran/90988] Wrong error message with variables named "PUBLIC*"

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Jun 26 04:31:14 2019
New Revision: 272667

URL: https://gcc.gnu.org/viewcvs?rev=272667=gcc=rev
Log:
2019-06-24  Steven G. Kargl  

PR Fortran/90988
* decl.c (access_attr_decl): Use temporary variable to reduce
unreadability of code.  Normalize jumping to return.
(gfc_match_protected): Fix parsing error.  Add comments to 
explain code.  Remove dead code.
(gfc_match_private): Use temporary variable to reduce unreadability 
of code. Fix parsing error.  Move code to test for blank PRIVATE.
Remove dead code.
(gfc_match_public): Move code to test for blank PUBLIC.  Fix
parsing error.  Remove dead code.

2019-06-24  Steven G. Kargl  

PR Fortran/90988
* gfortran.dg/pr90988_1.f90: New test.
* gfortran.dg/pr90988_2.f90: Ditto.
* gfortran.dg/pr90988_3.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr90988_1.f90
trunk/gcc/testsuite/gfortran.dg/pr90988_2.f90
trunk/gcc/testsuite/gfortran.dg/pr90988_3.f90
Modified:
trunk/gcc/fortran/decl.c

[Bug debug/47819] [meta-bug] LTO debug information issues

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Gallager  ---
(In reply to rguent...@suse.de from comment #2)
> On Tue, 25 Jun 2019, egallager at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
> > 
> > Eric Gallager  changed:
> > 
> >What|Removed |Added
> > 
> >  Status|NEW |WAITING
> >  CC||egallager at gcc dot 
> > gnu.org
> > 
> > --- Comment #1 from Eric Gallager  ---
> > All the bugs that this one depends upon have been closed, ok to close this 
> > too?
> 
> Please leave it open.

OK.

[Bug target/89021] Implement mmintrin.h in SSE

[hjl.tools at gmail dot com]

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

--- Comment #54 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #53)
> (In reply to H.J. Lu from comment #52)
> > (In reply to Uroš Bizjak from comment #51)
> > > How about:
> > Many V2SF, V8QI, V4HI and V2SI operations are missing.
> True, but why not use the ones that are usable?

We can give it a try.

[Bug target/90991] [9/10 Regression] _mm_loadu_ps instrinsic translates to vmovaps in combination with _mm512_insertf32x4

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/89021] Implement mmintrin.h in SSE

[ubizjak at gmail dot com]

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

--- Comment #53 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #52)
> (In reply to Uroš Bizjak from comment #51)
> > How about:
> Many V2SF, V8QI, V4HI and V2SI operations are missing.
True, but why not use the ones that are usable?

[Bug target/89021] Implement mmintrin.h in SSE

[hjl.tools at gmail dot com]

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

--- Comment #52 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #51)
> How about:
> 
> Index: config/i386/i386.c
> ===
> --- config/i386/i386.c  (revision 272656)
> +++ config/i386/i386.c  (working copy)
> @@ -21380,6 +21380,9 @@ ix86_autovectorize_vector_sizes (vector_sizes *siz
>sizes->safe_push (16);
>sizes->safe_push (32);
>  }
> +
> +  if (TARGET_MMX_WITH_SSE)
> +sizes->safe_push (8);
>  }
>  
>  /* Implemenation of targetm.vectorize.get_mask_mode.  */

Many V2SF, V8QI, V4HI and V2SI operations are missing.

[Bug target/90991] [9/10 Regression] _mm_loadu_ps instrinsic translates to vmovaps in combination with _mm512_insertf32x4

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-25
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |9.2
Summary|_mm_loadu_ps instrinsic |[9/10 Regression]
   |translates to vmovaps in|_mm_loadu_ps instrinsic
   |combination with|translates to vmovaps in
   |_mm512_insertf32x4  |combination with
   ||_mm512_insertf32x4
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with my r260039.  I'll have a look.

[Bug c++/70462] Unnecessary "base object constructor" for final classes

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-25
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/91000] New: noexcept in constexpr context with std=c++11 and std=c++14

[federico.kircheis at gmail dot com]

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

Bug ID: 91000
   Summary: noexcept in constexpr context with std=c++11 and
std=c++14
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.kircheis at gmail dot com
  Target Milestone: ---

I've used following snippet of code for testing if inside a constepxr context:


template constexpr void test_constexpr_helper(T&&) {}
constexpr bool test_fun(bool expr) {
return noexcept(test_constexpr_helper(expr));
}
static_assert(test_fun(true), "inside static_assert it's always constexpr");
int main(){}



But since g++9 (I've tested with different version on compiler explorer, with
-std=c++14 and -std=c++11) this piece of code does not compile anymore.

>From what I've seen from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603,
the new behaviour is not accidental, at least for -std=c++17.

But since I'm compiling with -std=c++11 and -std=c++14, the code should behave
as it did with g++-8, fro reading the comments further, this breaking change
has not been an accident.


So:
 * Does g++-9 provide a mechanism/extension that also works with c++11 and
c++14? If not, is it possible to restore the "old" behaviour?
 * Is there an extension that works for c++17 too?

Thanks

Federico

[Bug preprocessor/90927] [10 Regression] f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241

[kristopher.kuhlman at gmail dot com]

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

Kris  changed:

   What|Removed |Added

 CC||kristopher.kuhlman at gmail 
dot co
   ||m

--- Comment #6 from Kris  ---
I now get this same internal compiler error when I build petsc
(https://www.mcs.anl.gov/petsc/), using a configuration that works with version
7.4 of gcc.

  FC tgcc-c-debug/obj/sys/f90-mod/petscsysmod.o
f951: internal compiler error: in deps_add_target, at libcpp/mkdeps.c:241
0x1798897 deps_add_target(mkdeps*, char const*, int)
../../gcc-trunk/libcpp/mkdeps.c:241
0x1798897 deps_add_target(mkdeps*, char const*, int)
../../gcc-trunk/libcpp/mkdeps.c:236
0x868d5f dump_module
../../gcc-trunk/gcc/fortran/module.c:6227
0x868f30 gfc_dump_module(char const*, int)
../../gcc-trunk/gcc/fortran/module.c:6302
0x88131e gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6284
0x8ca48f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
gmakefile:164: recipe for target 'tgcc-c-debug/obj/sys/f90-mod/petscsysmod.o'
failed

[Bug target/89021] Implement mmintrin.h in SSE

[ubizjak at gmail dot com]

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

--- Comment #51 from Uroš Bizjak  ---
How about:

Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 272656)
+++ config/i386/i386.c  (working copy)
@@ -21380,6 +21380,9 @@ ix86_autovectorize_vector_sizes (vector_sizes *siz
   sizes->safe_push (16);
   sizes->safe_push (32);
 }
+
+  if (TARGET_MMX_WITH_SSE)
+sizes->safe_push (8);
 }

 /* Implemenation of targetm.vectorize.get_mask_mode.  */

[Bug c++/90999] New: [MSYS2/MINGW64] std::experimental::net is broken

[matheus-catarino at hotmail dot com]

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

Bug ID: 90999
   Summary: [MSYS2/MINGW64] std::experimental::net is broken
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matheus-catarino at hotmail dot com
  Target Milestone: ---

Created attachment 46519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46519=edit
gcc output error

I've been testing a simple example in using io_context and several errors occur
during the compile attempt. However in linux it works normally.

Test code:

#include 
namespace net = std::experimental::net;

int main()
{
net::io_context io;
}

[Bug target/89021] Implement mmintrin.h in SSE

[ubizjak at gmail dot com]

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

--- Comment #50 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #49)
> (In reply to Uroš Bizjak from comment #48)
> > (In reply to H.J. Lu from comment #4)
> > > That sounds right.  We can even vectorize
> > > 
> > > void
> > > foo (char* restrict r, char* restrict a){
> > > for (int i = 0; i < 8; i++){
> > > r[i] += a[i];
> > > }
> > > }
> > 
> > This loop is still not vectorized:
> > 
> > pr89021.c:3:5: missed:  not vectorized: iteration count smaller than
> > vectorization factor.
> > pr89021.c:3:5: missed:  Loop costings not worthwhile.
> > pr89021.c:3:5: missed: couldn't vectorize loop
> > pr89021.c:3:5: missed: Loop costings not worthwhile.
> > pr89021.c:2:1: note: vectorized 0 loops in function.
> 
> To enable V2SF vectorizer, we need to add V2SF patterns with SSE.

No, these are integer arguments.

[Bug target/89021] Implement mmintrin.h in SSE

[hjl.tools at gmail dot com]

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

--- Comment #49 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #48)
> (In reply to H.J. Lu from comment #4)
> > That sounds right.  We can even vectorize
> > 
> > void
> > foo (char* restrict r, char* restrict a){
> > for (int i = 0; i < 8; i++){
> > r[i] += a[i];
> > }
> > }
> 
> This loop is still not vectorized:
> 
> pr89021.c:3:5: missed:  not vectorized: iteration count smaller than
> vectorization factor.
> pr89021.c:3:5: missed:  Loop costings not worthwhile.
> pr89021.c:3:5: missed: couldn't vectorize loop
> pr89021.c:3:5: missed: Loop costings not worthwhile.
> pr89021.c:2:1: note: vectorized 0 loops in function.

To enable V2SF vectorizer, we need to add V2SF patterns with SSE.

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[pthaugen at gcc dot gnu.org]

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

pthaugen at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #20 from pthaugen at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #17)
> sched2 swaps the two insns (37 and 40 for me -- use -dp to see the numbers
> in your .s file, use -da if you want lots of dumps, -dap together).
> 
> So why did sched2 decide it can swap these?  They are in the same aliasing
> set, so it shouldn't do this.  Hrm.

I'm looking into this...

MongoDB Potential Business Lead

[Susan Jackson]

Hi, 

Hope you are doing well!

I wanted to check if you'd be interested in purchasing 2019 updated MongoDB
User List for your marketing initiatives?

We also have related technology users like: Schneider, Salesforce, Oracle,
IBM, Cisco, Microsoft and many more...

Let me know if you are interested and I will get back to you with the
Counts, Pricing and Samples for your review.

Thanks and I look forward to hearing from you soon!

Regards 

Susan Jackson 

Sr. Marketing Manager



If you are not interested please reply with "Not Interested" In the Subject
Line.

 

[Bug c++/90997] [9/10 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-25
 CC||msebor at gcc dot gnu.org
Summary|[9/10 Regression] ICE in|[9/10 Regression] ICE on a
   |tsubst_copy_and_build, at   |memset in a template in
   |cp/pt.c:18480   |tsubst_copy_and_build, at
   ||cp/pt.c:18480
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE was introduced in r261238 committed to fix another ICE:

PR c++/85710 - ICE with -Wmemset-elt-size.
c-family/
* c-warn.c (warn_for_memset): Don't crash on incomplete element type.
cp/
* semantics.c (finish_call_expr): Call warn_for_memset here.
* parser.c (cp_parser_postfix_expression): Not here.
(literal_integer_zerop): No longer static.
* pt.c (build_non_dependent_expr): Don't wrap CONST_DECL.

[Bug target/89021] Implement mmintrin.h in SSE

[ubizjak at gmail dot com]

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

--- Comment #48 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #4)
> That sounds right.  We can even vectorize
> 
> void
> foo (char* restrict r, char* restrict a){
> for (int i = 0; i < 8; i++){
> r[i] += a[i];
> }
> }

This loop is still not vectorized:

pr89021.c:3:5: missed:  not vectorized: iteration count smaller than
vectorization factor.
pr89021.c:3:5: missed:  Loop costings not worthwhile.
pr89021.c:3:5: missed: couldn't vectorize loop
pr89021.c:3:5: missed: Loop costings not worthwhile.
pr89021.c:2:1: note: vectorized 0 loops in function.

[Bug c++/90998] New: [Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17

[dimitar.yordanov at sap dot com]

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

Bug ID: 90998
   Summary: [Regression] ICE (segfalut) in gcc/cp/call.c
compare_ics() with -std=c++17
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimitar.yordanov at sap dot com
  Target Milestone: ---

Regression appeared first with:

PR c++/86521 - C++17 copy elision in initialization by constructor.

Reproducer:

cat << EOF > a.cpp

unsigned char a[1];
struct b {};
struct c : b {
  c(b);
  c(b &&);
};
struct B {
  operator c();
  static B d(unsigned char *, short, short, bool);
};
struct e {
  unsigned short f(bool) const;
};
#pragma GCC diagnostic error "-Wconversion"
short g, h;
unsigned short e::f(bool i) const {
  c(B::d(a, g, h, i));
  return 0;
}

EOF


$ g++ -std=c++17 a.cpp

a.cpp: In member function ‘short unsigned int e::f(bool) const’:
a.cpp:17:21: internal compiler error: Segmentation fault
   17 |   c(B::d(a, g, h, i));
  | ^
0xde01df crash_signal
../.././gcc/toplev.c:326
0x13049c2 compare_ics
../.././gcc/cp/call.c:10083
0x1307168 joust
../.././gcc/cp/call.c:10696
0x1307beb tourney
../.././gcc/cp/call.c:11085
0x130c18e build_new_method_call_1
../.././gcc/cp/call.c:9764
0x130c18e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../.././gcc/cp/call.c:9932
0x1312853 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../.././gcc/cp/call.c:9356
0x1326db3 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../.././gcc/cp/call.c:11273
0x1326db3 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../.././gcc/cp/call.c:11252
0x11f8fa9 build_static_cast_1
../.././gcc/cp/typeck.c:7185
0x11fb217 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:7981
0x11fb217 cp_build_c_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck.c:7898
0x11fb7da build_functional_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck2.c:2263
0x11fb7da build_functional_cast(tree_node*, tree_node*, int)
../.././gcc/cp/typeck2.c:2151
0x126c346 cp_parser_functional_cast
../.././gcc/cp/parser.c:28332
0x1265725 cp_parser_postfix_expression
../.././gcc/cp/parser.c:7098
0x12668e8 cp_parser_unary_expression
../.././gcc/cp/parser.c:8469
0x126764f cp_parser_cast_expression
../.././gcc/cp/parser.c:9355
0x1267d12 cp_parser_binary_expression
../.././gcc/cp/parser.c:9457
0x12684d7 cp_parser_assignment_expression
../.././gcc/cp/parser.c:9754

[Bug c++/67184] Missed optimization with C++11 final specifier

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  ---
With Jason's r272656 remains to be handled what I had as other/final4.C.
final.3.C and final5.C are fine, I'm probably going to add those two to the
testsuite.

[Bug c++/90997] New: [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18480

[gs...@t-online.de]

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

Bug ID: 90997
   Summary: [9/10 Regression] ICE in tsubst_copy_and_build, at
cp/pt.c:18480
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180527 and 20180610 :


$ cat z1.cc
template void f ()
{ __builtin_memset (0, 0, int(0.)); }


$ g++-8   -c z1.cc
$ g++-10-20180527 -c z1.cc
$
$ g++-10-20190623 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:2:34: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:18480
2 | { __builtin_memset (0, 0, int(0.)); }
  |  ^
0x6e4601 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18480
0x619bfc fold_non_dependent_expr_template
../../gcc/cp/constexpr.c:5670
0x6630ac fold_for_warn(tree_node*)
../../gcc/cp/expr.c:372
0x7a8c84 warn_for_memset(unsigned int, tree_node*, tree_node*, int)
../../gcc/c-family/c-warn.c:2060
0x710734 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2580
0x6b7b68 cp_parser_postfix_expression
../../gcc/cp/parser.c:7384
0x6c4235 cp_parser_unary_expression
../../gcc/cp/parser.c:8470
0x6a0c9f cp_parser_cast_expression
../../gcc/cp/parser.c:9355
0x6a1472 cp_parser_binary_expression
../../gcc/cp/parser.c:9457
0x6a21e9 cp_parser_assignment_expression
../../gcc/cp/parser.c:9754
0x6a2472 cp_parser_expression
../../gcc/cp/parser.c:9923
0x6a5394 cp_parser_expression_statement
../../gcc/cp/parser.c:11524
0x6b16e5 cp_parser_statement
../../gcc/cp/parser.c:11320
0x6b2540 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11667
0x6b25ef cp_parser_compound_statement
../../gcc/cp/parser.c:11621
0x6c89c8 cp_parser_function_body
../../gcc/cp/parser.c:22645
0x6c89c8 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22696
0x6c8cd6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:28010
0x6c9993 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:27926
0x6c9993 cp_parser_init_declarator
../../gcc/cp/parser.c:20282

[Bug c++/90996] New: [8/9/10 Regression] ICE in gimplify_expr, at gimplify.c:13495

[gs...@t-online.de]

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

Bug ID: 90996
   Summary: [8/9/10 Regression] ICE in gimplify_expr, at
gimplify.c:13495
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 (before 20180525) :


$ cat z1.cc
struct S
{
  int &
  int b[1] {a};
};
S c[] {{2}};


$ g++-7 -c z1.cc7
$
$ g++-10-20190623 -c z1.cc
z1.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
z1.cc:6:11: internal compiler error: in gimplify_expr, at gimplify.c:13495
6 | S c[] {{2}};
  |   ^
0x96cbdb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13495
0x96b74a gimplify_compound_lval
../../gcc/gimplify.c:3017
0x96b74a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12677
0x96c8fc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12846
0x9740c2 gimplify_modify_expr
../../gcc/gimplify.c:5706
0x96a34d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12725
0x96ccb8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6754
0x96aa33 gimplify_cleanup_point_expr
../../gcc/gimplify.c:6496
0x96aa33 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13102
0x96ccb8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6754
0x96ac3b gimplify_statement_list
../../gcc/gimplify.c:1827
0x96ac3b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13154
0x96ccb8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6754
0x96f438 gimplify_cond_expr
../../gcc/gimplify.c:4183
0x96a2d1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12682
0x96ccb8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6754
0x96f438 gimplify_cond_expr
../../gcc/gimplify.c:4183
0x96a2d1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:12682
0x96ccb8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6754
0x96e0da gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:13944

[Bug c++/90995] New: [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024

[gs...@t-online.de]

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

Bug ID: 90995
   Summary: [8/9/10 Regression] ICE in grokdeclarator, at
cp/decl.c:12024
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with early versions of gcc-8 (before 20180525) :


$ cat z1.cc
bool f ()
{ enum : int a alignas; }


$ g++-7 -c z1.cc
$
$ g++-10-20190623 -c z1.cc
z1.cc: In function 'bool f()':
z1.cc:2:16: internal compiler error: in grokdeclarator, at cp/decl.c:12024
2 | { enum : int a alignas; }
  |^~~
0x6411e6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:12024
0x644fd6 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5081
0x6c923c cp_parser_init_declarator
../../gcc/cp/parser.c:20378
0x6af10e cp_parser_simple_declaration
../../gcc/cp/parser.c:13546
0x6b0c49 cp_parser_declaration_statement
../../gcc/cp/parser.c:12976
0x6b16a7 cp_parser_statement
../../gcc/cp/parser.c:11305
0x6b2540 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11667
0x6b25ef cp_parser_compound_statement
../../gcc/cp/parser.c:11621
0x6c89c8 cp_parser_function_body
../../gcc/cp/parser.c:22645
0x6c89c8 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:22696
0x6c8cd6 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:28010
0x6c9993 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:27926
0x6c9993 cp_parser_init_declarator
../../gcc/cp/parser.c:20282
0x6af10e cp_parser_simple_declaration
../../gcc/cp/parser.c:13546
0x6cecf4 cp_parser_declaration
../../gcc/cp/parser.c:13243
0x6cf451 cp_parser_translation_unit
../../gcc/cp/parser.c:4699
0x6cf451 c_parse_file()
../../gcc/cp/parser.c:41489
0x78ec40 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[hubicka at ucw dot cz]

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

--- Comment #6 from Jan Hubicka  ---
> Tell me how and I can ;)

I think we want to know how the statement gets created
So i would just watchpoint its LHS and see when the component refs
sneeks in.

Honza

[Bug target/82182] m68k slow code: u16/u8 division calls divsi3

[cand at gmx dot com]

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

Lauri Kasanen  changed:

   What|Removed |Added

Version|7.2.0   |8.3.0
  Known to fail||7.2.0

--- Comment #3 from Lauri Kasanen  ---
8.3.0 produces the exact same slow code.

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Jason Merrill from comment #4)
> Hmm, I can't easily reproduce this, -flto -m32 doesn't work with my build. 

Do you have a problem with LTO plugin? Or something else?

> Could someone else analyze it more?

Tell me how and I can ;)

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Hmm, I can't easily reproduce this, -flto -m32 doesn't work with my build. 
Could someone else analyze it more?

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/90969] [10 Regression] ICE: tree check: expected array_type, have vector_type in array_ref_low_bound, at tree.c:13570

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 25 14:05:13 2019
New Revision: 272654

URL: https://gcc.gnu.org/viewcvs?rev=272654=gcc=rev
Log:
PR c++/90969
* constexpr.c (cxx_eval_array_reference): Don't look through VCE from
vector type if lval.

* g++.dg/ext/vector38.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/vector38.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64958] Warn if INTENT(IN) is changed by passing to no-intent argument

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
As long as we use a single file, it would be possible to
warn about this.

What we could do is to analyze dusty and check that its argument
n may be redefined. If it appears in a variable definition
context, we could set it to a new intent like INTENT_UNKNOWN_REDEFINED,
which would for all intents and purposes be treated like INTENT_UNKNOWN
except that we would warn if such an argument were passed a
constant, or if it is passed an INTENT(OUT) variable.

This would not even break our module format.

We already warn for

subroutine rusty(n)
  integer, intent(out) :: n
end

module foo
  implicit none
contains
  subroutine bar(n)
integer, intent(in) :: n
print *,"bar before rusty", n
call rusty(n)
print *,"bar after rusty", n
  end subroutine bar
end module foo

program main
  use foo
  implicit none
  integer :: n
  n = 5
  call bar(n)
end program main

so most of the machinery is in place already.

[Bug c++/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #4 from Mark Wielaard  ---
Created attachment 46518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46518=edit
Don't emit debug_addr attribute or addr index if there is no addr table.

Testing the following patch that makes sure we don't try to emit a
DW_AT_addr_base and .debug_addr debug table if there is no (or an empty)
address table.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to adrien.hamelin from comment #5)
> The noexcept(false) is just to be extra obvious, we see the same behaviour
> if we don't mark the function at all.

Yes of course. I'm just suggesting that maybe the warning should be changed to
take that into account.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[adrien.hamelin at gmail dot com]

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

--- Comment #5 from adrien.hamelin at gmail dot com ---
The noexcept(false) is just to be extra obvious, we see the same behaviour
if we don't mark the function at all.


Regards,
Adrien Hamelin

Le mar. 25 juin 2019 à 14:30, redi at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> a écrit :

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992
>
> --- Comment #4 from Jonathan Wakely  ---
> This suppresses the second warning if the first is suppressed:
>
> --- a/gcc/cp/except.c
> +++ b/gcc/cp/except.c
> @@ -1158,11 +1158,11 @@ maybe_noexcept_warning (tree fn)
>  {
>if (TREE_NOTHROW (fn))
>  {
> -  warning (OPT_Wnoexcept, "noexcept-expression evaluates to %
> "
> -  "because of a call to %qD", fn);
> -  warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
> - "but %qD does not throw; perhaps "
> - "it should be declared %", fn);
> +  if (warning (OPT_Wnoexcept, "noexcept-expression evaluates to
> %
> "
> +  "because of a call to %qD", fn))
> +   warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
> +   "but %qD does not throw; perhaps "
> +   "it should be declared %", fn);
>  }
>  }
>
>
>
> And this makes the first warning depend on whether the second one is in a
> system header:
>
> --- a/gcc/cp/except.c
> +++ b/gcc/cp/except.c
> @@ -1158,11 +1158,20 @@ maybe_noexcept_warning (tree fn)
>  {
>if (TREE_NOTHROW (fn))
>  {
> +  location_t loc = DECL_SOURCE_LOCATION (fn);
> +
> +  const bool warn_in_system_headers =
> global_dc->dc_warn_system_headers;
> +  if (in_system_header_at (input_location) && !in_system_header_at
> (loc)
> + && !warn_in_system_headers)
> +   global_dc->dc_warn_system_headers = 1;
>warning (OPT_Wnoexcept, "noexcept-expression evaluates to %
> "
>"because of a call to %qD", fn);
> -  warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
> +  warning_at (loc, OPT_Wnoexcept,
>   "but %qD does not throw; perhaps "
>   "it should be declared %", fn);
> +  if (in_system_header_at (input_location) && !in_system_header_at
> (loc)
> + && !warn_in_system_headers)
> +   global_dc->dc_warn_system_headers = 0;
>  }
>  }
>
>
> I don't know which of these is preferable, because I'm not sure if the
> point of
> the warning is to suggest changing Automatic, or the code in the system
> header.
>
> Tangentially, maybe the warning should not be given when a function is
> explicitly marked noexcept(false). That's not the same as an implicit
> potentially-throwing exception specification, and presumably the author did
> that for a reason.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This suppresses the second warning if the first is suppressed:

--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1158,11 +1158,11 @@ maybe_noexcept_warning (tree fn)
 {
   if (TREE_NOTHROW (fn))
 {
-  warning (OPT_Wnoexcept, "noexcept-expression evaluates to % "
-  "because of a call to %qD", fn);
-  warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
- "but %qD does not throw; perhaps "
- "it should be declared %", fn);
+  if (warning (OPT_Wnoexcept, "noexcept-expression evaluates to %
"
+  "because of a call to %qD", fn))
+   warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
+   "but %qD does not throw; perhaps "
+   "it should be declared %", fn);
 }
 }



And this makes the first warning depend on whether the second one is in a
system header:

--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1158,11 +1158,20 @@ maybe_noexcept_warning (tree fn)
 {
   if (TREE_NOTHROW (fn))
 {
+  location_t loc = DECL_SOURCE_LOCATION (fn);
+
+  const bool warn_in_system_headers = global_dc->dc_warn_system_headers;
+  if (in_system_header_at (input_location) && !in_system_header_at (loc)
+ && !warn_in_system_headers)
+   global_dc->dc_warn_system_headers = 1;
   warning (OPT_Wnoexcept, "noexcept-expression evaluates to % "
   "because of a call to %qD", fn);
-  warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
+  warning_at (loc, OPT_Wnoexcept,
  "but %qD does not throw; perhaps "
  "it should be declared %", fn);
+  if (in_system_header_at (input_location) && !in_system_header_at (loc)
+ && !warn_in_system_headers)
+   global_dc->dc_warn_system_headers = 0;
 }
 }


I don't know which of these is preferable, because I'm not sure if the point of
the warning is to suggest changing Automatic, or the code in the system header.

Tangentially, maybe the warning should not be given when a function is
explicitly marked noexcept(false). That's not the same as an implicit
potentially-throwing exception specification, and presumably the author did
that for a reason.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.2

[Bug target/90993] simd integer division not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-25
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Implementation will be a bit awkward unless done as pattern where
it should be straight-forward.  I wouldn't suggest the backend lie and
implement
vector integer division patterns.


Referenced Bugs:

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

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Jun 25 11:50:12 2019
New Revision: 272651

URL: https://gcc.gnu.org/viewcvs?rev=272651=gcc=rev
Log:
Remove dead code in df-scan.c (PR tree-optimization/90978).

2019-06-25  Martin Liska  

PR tree-optimization/90978
* df-scan.c (df_update_entry_block_defs): Remove dead else
branch.
(df_update_exit_block_uses): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
This inconsistency is because the warning function uses one location, and the
following warning_at uses a different location:

static void
maybe_noexcept_warning (tree fn)
{
  if (TREE_NOTHROW (fn))
{
  warning (OPT_Wnoexcept, "noexcept-expression evaluates to % "
   "because of a call to %qD", fn);
  warning_at (DECL_SOURCE_LOCATION (fn), OPT_Wnoexcept,
  "but %qD does not throw; perhaps "
  "it should be declared %", fn);
}
}

I think we either want to suppress the second warning if the first one isn't
printed, or don't suppress the first one if DECL_SOURCE_LOCATION (fn) is not in
a system header.

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
If we inline the relevant code it reveals that t here are actually additional
warning lines that are being suppressed in system headers:

using size_t = decltype(sizeof(0));
void* operator new(size_t, void* p) { return p; }

struct allocator
{
  template
void
construct(T* p, Args... args)
noexcept(noexcept(::new((void*)p) T(args...)))
{ ::new((void*)p) T(args...); }

  template
void
destroy(T* p)
noexcept(noexcept(p->~T()))
{ p->~T(); }
};

class NotNoexcept {
public:
NotNoexcept() noexcept(false) {}
~NotNoexcept() noexcept(false) {}
};

class Automatic {
public:
Automatic(int bla) noexcept(false) : Bla(bla) {};

private:
int Bla;
NotNoexcept Dummy;
};

int main() {
  alignas(Automatic) unsigned char buf[sizeof(Automatic)];
  allocator a;
  a.construct((Automatic*)buf, 42);
  a.destroy((Automatic*)buf);
}


90992.cc: In instantiation of 'void allocator::construct(T*, Args ...) [with T
= Automatic; Args = {int}]':
90992.cc:37:34:   required from here
90992.cc:8:5: warning: noexcept-expression evaluates to 'false' because of a
call to 'void* operator new(size_t, void*)' [-Wnoexcept]
8 | construct(T* p, Args... args)
  | ^
90992.cc:2:7: warning: but 'void* operator new(size_t, void*)' does not throw;
perhaps it should be declared 'noexcept' [-Wnoexcept]
2 | void* operator new(size_t, void* p) { return p; }
  |   ^~~~
90992.cc:14:5: warning: noexcept-expression evaluates to 'false' because of a
call to 'Automatic::~Automatic()' [-Wnoexcept]
   14 | destroy(T* p)
  | ^~~
90992.cc:25:7: warning: but 'Automatic::~Automatic()' does not throw; perhaps
it should be declared 'noexcept' [-Wnoexcept]
   25 | class Automatic {
  |   ^


The first first line is being suppressed, but the second is not. This isn't a
front-end regression as it's always done this, but it gets triggered by new
changes in libstdc++ since GCC 9.1

[Bug ipa/90939] ICE in meet_with, at ipa-cp.c:1073

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Tue Jun 25 11:05:19 2019
New Revision: 272646

URL: https://gcc.gnu.org/viewcvs?rev=272646=gcc=rev
Log:
[PR 90939] Remove outdated assert in ipcp_bits_lattice::meet_with

2019-06-25  Martin Jambor  

PR ipa/90939
* ipa-cp.c (ipcp_bits_lattice::meet_with): Remove assert.

testsuite/
* g++.dg/lto/pr90939_[01].C: New test.


Added:
trunk/gcc/testsuite/g++.dg/lto/pr90939_0.C
trunk/gcc/testsuite/g++.dg/lto/pr90939_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/90930] Excessive memory consumption

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 25 10:59:48 2019
New Revision: 272644

URL: https://gcc.gnu.org/viewcvs?rev=272644=gcc=rev
Log:
2019-06-25  Richard Biener  

PR tree-optimization/90930
* tree-ssa-reassoc.c (reassociate_bb): Only rewrite expression
into parallel form in the last pass instance.

* gcc.dg/tree-ssa/reassoc-24.c: Adjust.
* gcc.dg/tree-ssa/reassoc-25.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-24.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-25.c
trunk/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/90994] New: Bogus Wmaybe-uninitialized with fnon-call-exceptions

[sagebar at web dot de]

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

Bug ID: 90994
   Summary: Bogus Wmaybe-uninitialized with fnon-call-exceptions
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Created attachment 46517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46517=edit
Minimal code that triggers the problem

Using a branch-dependent return value in an assembly block with at least 5
line-line or `;` characters, where one of the branches gets triggered by some
non-call-exception will result in values conditionally returned by only one of
the paths to be considered uninitialized.

This behavior seems to be _extremely_ specific, relying on any different
factors having to come together to actually trigger the problem. (The attached
file is a minimal code example that triggers this)

To proove to yourself just how inconsistent this problem appears to be, try
moving around the `asm`, or copying it after the second call to `readbyte` (or
even just deleting one of its empty lines), and you will see that the warning
will vanish.
The provided configuration seems to be the only one for which the problem can
be reproduced.

The problem surfaces with `-O[1-4]` and `-O`, however doesn't with `-Og` or no
`-O*` flag at all
Removing `-fnon-call-exceptions` and adding an external function call or a
conditional `throw`-statement within the `try`-block also seems to prevent the
problem.

Also note that the problem still happens when the assignment of `*presult` is
moved after the `try`-block within `readbyte`, so-long as the read from
`*(unsigned char volatile *)1234` stays inside the `try`-block.

Compile the attached file with: `g++ -O2 -Wall -fnon-call-exceptions -c
bogus.cc`

I can personally confirm this problem for:
 - i686-elf-g++(Version 9.1.0)
 - i686-pc-cygwin-g++  (Version 6.4.0)
 - i686-w64-mingw32-g++(Version 7.4.0)
 - x86_64-pc-cygwin-g++(Version 7.4.0)
 - x86_64-w64-mingw32-g++  (Version 7.4.0)

[Bug c++/90992] [9/10 Regression] -Wnoexcept produce false positive

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-25
  Known to work||8.3.0
Summary|-Wnoexcept produce false|[9/10 Regression]
   |positive|-Wnoexcept produce false
   ||positive
 Ever confirmed|0   |1
  Known to fail||10.0, 9.1.0

--- Comment #1 from Jonathan Wakely  ---
This seems to be caused by something in std::vector.

[Bug tree-optimization/90911] [10 Regression] 456.hmmer regression with r272239

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-06-25
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
So looking at perf the reason seems obvious:

Samples: 717K of event 'cycles:pu', Event count (approx.): 586330968682 
Overhead  Command  Shared Object  Symbol  
◆
  60.74%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] P7Viterbi   
▒
  31.35%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] P7Viterbi.cold  
▒
   2.32%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] FChoose 
▒
   2.02%  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.] sre_random   

and caused by

  /* ???  if-conversion uses profile_probability::always () but
 prob below is profile_probability::likely ().  */

thus we keep the profile from if-conversion which uses always () compared
to previously versioning the loop with the vectorized path being only
likely ().  The inconsistent profile from if-conversion persists and seems
to confuse us later:

  /* At this point we invalidate porfile confistency until IFN_LOOP_VECTORIZED
 is re-merged in the vectorizer.  */
  new_loop = loop_version (loop, cond, _bb,
   profile_probability::always (),
   profile_probability::always (),
   profile_probability::always (),
   profile_probability::always (), true);

Just updating the edge probability of the guard seems to avoid creating
the bogus hot/cold partitioning and should not affect further copying
from the scalar loop from prologue/epilogue peeling.

[Bug target/90993] New: simd integer division not optimized

[kretz at kde dot org]

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

Bug ID: 90993
   Summary: simd integer division not optimized
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Test case (https://godbolt.org/z/CYipz7):

template  using V [[gnu::vector_size(16)]] = T;

V f(V a, V b) { return a / b; }
V f(V a, V b) { return a / b; }
V f(V a, V b) { return a / b; }
V f(V a, V b) { return a / b; }
V f(V a, V b) { return a / b; }
V f(V a, V b) { return a / b; }

(You can extend the test case to 32 and 64 bit vectors.)

All these divisions have no SIMD instruction on x86. However, conversion to
float or double vectors is lossless (char & short -> float, int -> double) and
enables implementation via divps/divpd. This leads to a considerable speedup
(especially on divider throughput), even with the cost of the conversions. The
division by 0 case is UB (http://eel.is/c++draft/expr.mul#4), so it doesn't
matter that a potential SIGFPE turns into "whatever". ;-)

For reference, this is the result of my library implementation:
https://godbolt.org/z/Xgo9Pk.

And benchmark results on Skylake i7:
  TYPELatency Speedup Throughput
Speedup
[cycles/call]  [cycles/call]
 schar,  24.5   9.81
 schar, simd_abi::__sse  32.312.1   9.19   
17.1
 schar, vector_size(16)   1283.06125   
1.26
 schar, simd_abi::__avx  40.319.4   18.7   
16.8
 schar, vector_size(32)   2553.07256   
1.23

 uchar,  20.8   7.55
 uchar, simd_abi::__sse  31.910.49.5   
12.7
 uchar, vector_size(16)   1212.74116   
1.04
 uchar, simd_abi::__avx  39.916.7   18.8   
12.8
 uchar, vector_size(32)   230 2.9224   
1.08

 short,  22.76.4
 short, simd_abi::__sse  23.6 7.7   4.52   
11.3
 short, vector_size(16)  62.62.91   58.4  
0.877
 short, simd_abi::__avx  30.611.9   9.55   
10.7
 short, vector_size(32)   1203.03114
0.9

ushort,  19.4   7.37
ushort, simd_abi::__sse  23.76.55   4.55   
12.9
ushort, vector_size(16)  61.32.53   57.4   
1.03
ushort, simd_abi::__avx  30.610.1   8.86   
13.3
ushort, vector_size(32)   1162.67114   
1.03

   int,  23.2   7.14
   int, simd_abi::__sse  24.73.75   7.24   
3.95
   int, vector_size(16)  40.3 2.3   30.9  
0.924
   int, simd_abi::__avx  35.65.22   14.5   
3.95
   int, vector_size(32)  64.2 2.9   61.4   
0.93

  uint,  20.5   7.14
  uint, simd_abi::__sse441.86   7.73   
3.69
  uint, vector_size(16)  39.72.07   30.9  
0.925
  uint, simd_abi::__avx  56.92.89 16   
3.57
  uint, vector_size(32)  71.4 2.3   71.5  
0.798


I have not investigated whether the same optimization makes sense for other
targets than x86.

Since this optimization requires optimized vector conversions, PR85048 is
relevant.

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat godot.ii
class A {
public:
  float m_floats;
  A() {}
};
class B {
public:
  A operator[](int);
};
class C {
  B m_basis;

public:
  A operator()(A) {
m_basis[1] = m_basis[2];
A a;
return a;
  }
};
class D {
public:
  C m_fn1();
};
class F {
  A m_pivotInB;
  F(D &, const A &);
};
F::F(D , const A ) : m_pivotInB(p1.m_fn1()(p2)) {}

$ g++ godot.ii -O2 -flto -shared -m32
godot.ii: In member function ‘__ct_base ’:
godot.ii:28:1: error: ‘component_ref’ LHS in clobber statement
   28 | F::F(D , const A ) : m_pivotInB(p1.m_fn1()(p2)) {}
  | ^
*this_2(D).m_pivotInB
# .MEM_16 = VDEF <.MEM_15>
*this_2(D).m_pivotInB ={v} {CLOBBER};
during GIMPLE pass: fixup_cfg
godot.ii:28:1: internal compiler error: verify_gimple failed
0xcd23f1 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5426
0xbb212f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1963
0xbb305e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2017
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug fortran/64958] Warn if INTENT(IN) is changed by passing to no-intent argument

[mark.eggleston at codethink dot com]

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

--- Comment #7 from MarkEggleston  ---
(In reply to Dominique d'Humieres from comment #6)
> > Warning is output by gfortran 6.3.0.
> > ...
> 
> Not a warning, but an error as it shall. This PR is different: it is about
> the case where the INTENT(IN) is obfuscated by a subroutine.

Where no intent is specified in subroutine dusty(n) (see comment 1), producing
a warning is straight forward.

However, that would only apply to a small part of the problem.

Checking with intent specified in dusty shows that the program will compile
with intent(inout) and intent(out). It also allows the dummy variable with
intent(out) to be used as though it were intent(inout).

Checks on procedure calls in a procedure with its dummy variables would need to
made to determine the risk of a dummy variable with intent(in) being modified.

[Bug target/89838] [ARC] ICE building glibc testsuite

[claziss at gmail dot com]

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

--- Comment #2 from Claudiu Zissulescu  ---
Patch pushed to mainline r272643.

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
In theory it could, but it's a non-trivial change, and I don't know how much
testing it's had on mingw-w64 yet.

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Started with r272618.

[Bug c++/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  ---
(In reply to Martin Liška from comment #2)
> Btw. started with r259743.

Thanks. So that is mine:

commit ac7a2c61cf2ae7fcc948724ae179ac812c12186a
Author: mark 
Date:   Sat Apr 28 19:54:08 2018 +

DWARF: Add .debug_addr table header for dwarf_version >= 5.

GNU DebugFission didn't add table headers for the .debug_addr
tables, but DWARF5 does. The table header makes it possible
for a DWARF consumer to parse the address tables without having
to index all .debug_info CUs first.

We can keep using the .debug_addr section label as is, because the
DW_AT_[GNU_]addr_base attribute points at the actual address index,
which starts right after the table header. So the label is generated
at the correct location whether the header is added first or not.

Add DW_AT_addr_base instead of DW_AT_GNU_addr_base to the skeleton
CU DIE for DWARF5.

gcc/ChangeLog

* dwarf2out.c (dwarf2out_finish): Add .debug_addr table header for
dwarf_version >= 5.
(dwarf_AT): Handle DW_AT_addr_base.
(add_top_level_skeleton_die_attrs): Use dwarf_AT for DW_AT_addr_base.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259743
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/90992] New: -Wnoexcept produce false positive

[adrien.hamelin+gcc at gmail dot com]

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

Bug ID: 90992
   Summary: -Wnoexcept produce false positive
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adrien.hamelin+gcc at gmail dot com
  Target Milestone: ---

Created attachment 46516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46516=edit
Minimal case to reproduce, compile with "g++ -Wnoexcept gcc_bug.cpp"

We seem to have found a bug in g++, it generates a false warning that a
constructor could be noexcept when it has a member that is not.

See the attached file for a minimal test case, compiled with "g++ -Wnoexcept
gcc_bug.cpp", it generates:

/usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
Automatic; _Args = {int}; _Tp = Automatic]’:
/usr/include/c++/9/bits/alloc_traits.h:482:2:   required from ‘static void
std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = Automatic; _Args = {int}; _Tp = Automatic;
std::allocator_traits >::allocator_type =
std::allocator]’
/usr/include/c++/9/bits/vector.tcc:115:30:   required from ‘void
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {int}; _Tp =
Automatic; _Alloc = std::allocator]’
gcc_bug.cpp:25:25:   required from here
gcc_bug.cpp:16:5: warning: but ‘Automatic::Automatic(size_t)’ does not throw;
perhaps it should be declared ‘noexcept’ [-Wnoexcept]
   16 | Automatic(size_t bla) : Bla(bla) {};
  | ^
gcc_bug.cpp:14:7: warning: but ‘Automatic::~Automatic()’ does not throw;
perhaps it should be declared ‘noexcept’ [-Wnoexcept]
   14 | class Automatic {
  |   ^

In our case (in a more complex code base), the warning happens on the
automatically generated move constructor, which is not noexcept as it should
but still generates that warning. In our case also just declaring the move
constructor as default seems to hide the warning, though it doesn't in the
minimal test case I provide.

[Bug middle-end/90982] [9/10 Regression] ICE in make_decl_rtl, at varasm.c:1344

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
OK, so this is IPA SRAs fault which fails to rewrite the d.c[i] expression
with the parameter replacement.  After the cited rev. range-info makes d.c[i]
appear as d.c[2] from get_ref_base_and_extent analysis.

Evaluating PARAM group sizes for d (UID: 2336):
access { base = (2336)'d', offset = 128, size = 64, expr = d.c[i_4], type =
long int, non_addressable = 0, reverse = 0, grp_read = 0, grp_write = 0,
grp_assignment_read = 1, grp_assignment_write = 0, grp_scalar_read = 0,
grp_scalar_write = 0, grp_total_scalarization = 0, grp_hint = 0, grp_covered =
0, grp_unscalarizable_region = 0, grp_unscalarized_data = 0,
grp_same_access_path = 0, grp_partial_lhs = 0, grp_to_be_replaced = 0,
grp_to_be_debug_replaced = 0, grp_maybe_modified = 0,
grp_not_necessarilly_dereferenced = 0
will be split into 1 components
IPA param adjustments: 0. base_index: 0 - this, base: this, copy_param
 1. base_index: 1 - d, base: d, offset 128, type: 

...
S<3>::_ZN1SILi3EE1fES0_.isra.0 (struct SD.2331 * const thisD.2425, long intD.12
ISRA.1D.2429)
{
  intD.9 iD.2427;
  long intD.12 _3;
  long intD.12 _4;
  long intD.12 _5;

   :

   :

   :
  # i_2 = PHI <2(2), i_6(4)>
  _3 = this_1(D)->cD.2333[i_2];
  _4 = dD.2426.cD.2333[i_2];
  _5 = _3 & _4;
  this_1(D)->cD.2333[i_2] = _5;
  i_6 = i_2 + 1;


and now dD.2426 is stale.  With -fno-inline we ICE differently:

during IPA pass: cp
t.ii: In function ‘void S::f(S) [with int n = 3]’:
t.ii:21:1: internal compiler error: in visit_ref_for_mod_analysis, at
ipa-prop.c:2461
   21 | }
  | ^
0x112f91e visit_ref_for_mod_analysis
/space/rguenther/src/svn/trunk2/gcc/ipa-prop.c:2461
0x102985b walk_stmt_load_store_addr_ops(gimple*, void*, bool (*)(gimple*,
tree_node*, tree_node*, void*), bool (*)(gimple*, tree_node*, tree_node*,
void*), bool (*)(gimple*, tree_node*, tree_node*, void*))
/space/rguenther/src/svn/trunk2/gcc/gimple-walk.c:783
0x112f9e8 ipa_analyze_params_uses_in_bb
/space/rguenther/src/svn/trunk2/gcc/ipa-prop.c:2488
0x112fcbc analysis_dom_walker::before_dom_children(basic_block_def*)
/space/rguenther/src/svn/trunk2/gcc/ipa-prop.c:2568

probably because there's a PARAM_DECL in the IL that isn't an actual
parameter.

Somehow during ipa_get_adjustment_candidate the access appears
unconstrained by i_2 value-range.

Ah, this is because we do

  new_node = node->create_version_clone_with_body (redirect_callers, NULL,
   NULL, false, NULL, NULL,
   "isra");

and the inline machinery doesn't copy SSA name range info.

[Bug tree-optimization/90978] A suspicious code in df-scan.c since r160348

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
(In reply to Jan Hubicka from comment #3)
> > Guess this is https://gcc.gnu.org/ml/gcc-patches/2010-06/msg00410.html but 
> > the
> > gcc_unreachable () calls weren't in the patch posted to gcc-patches.
> 
> It indeed seems like debugging session leftover. Given we had the check
> there for 9 years, perhaps it is enough evidence that path does not
> execute?

Yes, let me prepare a patch for it.

[Bug tree-optimization/90973] A suspicious code in tree-vect-loop.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses

[marxin at gcc dot gnu.org]

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

Bug 90973 Summary: A suspicious code in tree-vect-loop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90973

   What|Removed |Added

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

[Bug tree-optimization/90973] A suspicious code in tree-vect-loop.c

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Jun 25 08:17:39 2019
New Revision: 272638

URL: https://gcc.gnu.org/viewcvs?rev=272638=gcc=rev
Log:
Properly sum costs in tree-vect-loop.c (PR tree-optimization/90973).

2019-06-25  Martin Liska  

PR tree-optimization/90973
* tree-vect-loop.c (vect_get_known_peeling_cost): Sum retval
of prologue and epilogue.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[hubicka at ucw dot cz]

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

--- Comment #1 from Jan Hubicka  ---
Thanks. I however do not know why we do not like component refs in
clobbers. It simply says that we are killing part of a structure?

Honza

[Bug libstdc++/85494] implementation of random_device on mingw is useless

[mimomorin at gmail dot com]

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

Michel Morin  changed:

   What|Removed |Added

 CC||mimomorin at gmail dot com

--- Comment #11 from Michel Morin  ---
Could this be back-ported to GCC-9.2?

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-25
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=51991
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
From pr51991 comment 15.

[Bug middle-end/90991] New: _mm_loadu_ps instrinsic translates to vmovaps in combination with _mm512_insertf32x4

[kronbichler.martin at gmail dot com]

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

Bug ID: 90991
   Summary: _mm_loadu_ps instrinsic translates to vmovaps in
combination with _mm512_insertf32x4
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kronbichler.martin at gmail dot com
  Target Milestone: ---

Created attachment 46515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46515=edit
Reduced C/C++ file for reproducing the bug

For the following code:

#include 
__m512 f(const float   *in,
 const unsigned*offsets)
{
  __m512 t0 = {};
  t0 = _mm512_insertf32x4(t0, _mm_loadu_ps(in + offsets[0]), 0);
  t0 = _mm512_insertf32x4(t0, _mm_loadu_ps(in + offsets[1]), 1);
  t0 = _mm512_insertf32x4(t0, _mm_loadu_ps(in + offsets[2]), 2);
  t0 = _mm512_insertf32x4(t0, _mm_loadu_ps(in + offsets[3]), 3);
  return t0;
}

compiled on x86-64 with "g++ -march=skylake-avx512 -O1 -S", I get the following
assembly:

movl(%rsi), %eax
vmovaps (%rdi,%rax,4), %xmm0
movl4(%rsi), %eax
vinsertf32x4$1, (%rdi,%rax,4), %zmm0, %zmm0
movl8(%rsi), %eax
vinsertf32x4$2, (%rdi,%rax,4), %zmm0, %zmm0
movl12(%rsi), %eax
vinsertf32x4$3, (%rdi,%rax,4), %zmm0, %zmm0
ret

For the lowest 128 bits done in the second line, gcc wrongly emits an aligned
load instruction vmovaps. This cannot be right because the offsets array could
be {0, 1, 2, 3} for example, in which case 3 of 4 loads are not 16-byte aligned
no matter the alignment of "in". And it indeed segfaults on simple tests. The
compiler hence ignores my unaligned load instruction "_mm_loadu_ps". According
to https://godbolt.org/z/j7T4Fy this wrong code has been introduced with gcc-9,
as compilation with gcc 8.3 gives the more sane code

movl(%rsi), %eax
vxorps  %xmm0, %xmm0, %xmm0
vinsertf32x4$0, (%rdi,%rax,4), %zmm0, %zmm0
movl4(%rsi), %eax
vinsertf32x4$1, (%rdi,%rax,4), %zmm0, %zmm0
movl8(%rsi), %eax
vinsertf32x4$2, (%rdi,%rax,4), %zmm0, %zmm0
movl12(%rsi), %eax
vinsertf32x4$3, (%rdi,%rax,4), %zmm0, %zmm0
ret

I guess the compiler merges the lowest vinsertf32x4 instruction with the vxorps
instruction. At this stage, it has already lost track of the original unaligned
load instruction hidden behind the vinsertf32x4 instruction which is is allowed
to have misaligned addresses whereas vmovaps does not. The correct solution
would have been to emit "vmovups (%rdi,%rax,4), %xmm0".

godbolt also reports the error on trunk, so I assume it has not been fixed yet.
It also appears with "-march=knl".

Here are my details of my compiler:

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/lnm/gcc9/libexec/gcc/x86_64-redhat-linux/9.1.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../gcc-9.1.0/configure --prefix=/lnm/gcc9 --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-languages=c,c++,fortran,lto
--disable-multilib --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.1.0 (GCC) 

I also attach a reduced variant for compilation with gcc/g++ without the
include to x86intrin.h for more easily reproducing the bug.

[Bug lto/90990] [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||9.1.1
   Keywords||needs-bisection,
   ||needs-reduction
   Last reconfirmed||2019-06-25
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
  Known to fail||10.0

[Bug lto/90990] New: [10 Regression] ICE: error: ‘component_ref’ LHS in clobber statement

[marxin at gcc dot gnu.org]

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

Bug ID: 90990
   Summary: [10 Regression] ICE: error: ‘component_ref’ LHS in
clobber statement
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

It's caused by a probably Honza's recent commit. I see it in godot package with
-m32:

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
modules/bullet/bullet_physics_server.cpp: In member function
‘joint_create_pin’:
modules/bullet/bullet_physics_server.cpp:1211:5: error: ‘component_ref’ LHS in
clobber statement
 1211 | RID BulletPhysicsServer::joint_create_pin(RID p_body_A, const Vector3
_local_A, RID p_body_B, const Vector3 _local_B) {
  | ^
MEM[(struct btPoint2PointConstraint *)_294].m_pivotInB
# .MEM_369 = VDEF <.MEM_368>
MEM[(struct btPoint2PointConstraint *)_294].m_pivotInB ={v} {CLOBBER};
during GIMPLE pass: fixup_cfg
modules/bullet/bullet_physics_server.cpp:1211:5: internal compiler error:
verify_gimple failed
0xcbdca1 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5426
0xb9d95f execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1963
0xb9e88e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2017

I'm going to reduce that.

[Bug fortran/64958] Warn if INTENT(IN) is changed by passing to no-intent argument

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Warning is output by gfortran 6.3.0.
> ...

Not a warning, but an error as it shall. This PR is different: it is about the
case where the INTENT(IN) is obfuscated by a subroutine.

[Bug tree-optimization/90930] Excessive memory consumption

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.1.1

--- Comment #14 from Richard Biener  ---
Fixed on the GCC9 branch as well.

[Bug tree-optimization/90930] Excessive memory consumption

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Tue Jun 25 07:30:44 2019
New Revision: 272636

URL: https://gcc.gnu.org/viewcvs?rev=272636=gcc=rev
Log:
2019-06-21  Richard Biener  

PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-processing them.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/90989] [9/10 Regression] incorrrect strlen result after second strcpy into the same destination

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |9.2
Summary|incorrrect strlen result|[9/10 Regression]
   |after second strcpy into|incorrrect strlen result
   |the same destination|after second strcpy into
   ||the same destination

[Bug middle-end/90982] [9/10 Regression] ICE in make_decl_rtl, at varasm.c:1344

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I will investigate then.

[Bug c++/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Known to work||8.3.0
  Known to fail||10.0, 9.1.0

--- Comment #2 from Martin Liška  ---
Btw. started with r259743.

[Bug fortran/64958] Warn if INTENT(IN) is changed by passing to no-intent argument

[mark.eggleston at codethink dot com]

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

--- Comment #5 from MarkEggleston  ---
Warning is output by gfortran 6.3.0.

program test
  implicit none
  integer :: b
  integer :: c

  b = 0
  c = 7

  call sub(b)
  call sub(c)
  write(*,*) b, c

contains
  subroutine sub(x)
integer, intent(in) :: x
integer :: y
x = 9
y = x
  end subroutine sub
end program test

results in:

 x = 9
1
Error: Dummy argument ‘x’ with INTENT(IN) in variable definition context
(assignment) at (1)

Warning also given by 7.4, 8.3, 9.1 and trunk.

[Bug middle-end/90982] [9/10 Regression] ICE in make_decl_rtl, at varasm.c:1344

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
  Known to work||8.3.0
  Known to fail||10.0, 9.1.0

--- Comment #2 from Martin Liška  ---
Btw. started with r260354.

[Bug sanitizer/90954] ICE: combining undefined behavior sanitizer with openmp

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jun 25 07:00:34 2019
New Revision: 272635

URL: https://gcc.gnu.org/viewcvs?rev=272635=gcc=rev
Log:
PR sanitizer/90954
* c-omp.c (c_finish_omp_atomic): Allow tree_invariant_p in addition
to SAVE_EXPR in first operand of a COMPOUND_EXPR.

* c-c++-common/gomp/pr90954.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr90954.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/47819] [meta-bug] LTO debug information issues

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Tue, 25 Jun 2019, egallager at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
> 
> Eric Gallager  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |WAITING
>  CC||egallager at gcc dot gnu.org
> 
> --- Comment #1 from Eric Gallager  ---
> All the bugs that this one depends upon have been closed, ok to close this 
> too?

Please leave it open.