[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-23 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

--- Comment #7 from Thomas Henlich  ---
This should have a test-case added, ideally by renaming an already existing
test-case containing Fortran 2018 features to .f18.

[Bug libfortran/93871] COTAN is slow for complex types

2020-02-23 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871

--- Comment #17 from Thomas Henlich  ---
The following should give an error message, not a ICE:

program test_dtrig2
  real, parameter :: d = asind(1.1)
  print *, d
end

gfortran -fdec-math test_dtrig2.f90
f951.exe: internal compiler error: Segmentation fault
...

program test_dtrig2
  real, parameter :: d = asin(1.1)
  print *, d
end

test_dtrig2.f90:2:30:

2 |   real, parameter :: d = asin(1.1)
  |  1
Error: Argument of ASIN at (1) must be between -1 and 1

[Bug analyzer/93899] New: ICE in make_region_for_type, at analyzer/region-model.cc:6094

2020-02-23 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93899

Bug ID: 93899
   Summary: ICE in make_region_for_type, at
analyzer/region-model.cc:6094
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d)
ICEs when compiling gcc/testsuite/g++.dg/abi/mangle55.C w/ -fanalyzer:

% g++-10.0.1 -fanalyzer -c gcc/testsuite/g++.dg/abi/mangle55.C
during IPA pass: analyzer
gcc/testsuite/g++.dg/abi/mangle55.C:14:1: internal compiler error: in
make_region_for_type, at analyzer/region-model.cc:6094
   14 | }
  | ^
0x7dbad7 make_region_for_type
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:6094
0x135b49c ana::region_model::add_region_for_type(ana::region_id, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:6104
0x135b49c ana::map_region::get_or_create(ana::region_model*, ana::region_id,
tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:1676
0x135b9b1 ana::root_region::push_frame(ana::region_model*, function*,
vec*, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:2920
0x133ba07 ana::exploded_graph::add_function_entry(function*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:1832
0x133bd32 ana::exploded_graph::build_initial_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:2151
0x133e5ec ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3667
0x133f09c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3727
0x13347d8 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/analyzer-pass.cc:84

[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Prathamesh Kulkarni
:

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

commit r10-6807-gf1a681a174cdfb82e62c246d6f4add9a25fc2e43
Author: Prathamesh Kulkarni 
Date:   Mon Feb 24 11:55:45 2020 +0530

PR47785: Add support for handling Xassembler/Wa options with LTO.

2020-02-24  Prathamesh Kulkarni  
Kugan Vivekandarajah  

PR driver/47785
* gcc.c (putenv_COLLECT_AS_OPTIONS): New function.
(driver::main): Call putenv_COLLECT_AS_OPTIONS.
* opts-common.c (parse_options_from_collect_gcc_options): New function.
(prepend_xassembler_to_collect_as_options): Likewise.
* opts.h (parse_options_from_collect_gcc_options): Declare prototype.
(prepend_xassembler_to_collect_as_options): Likewise.
* lto-opts.c (lto_write_options): Stream assembler options
in COLLECT_AS_OPTIONS.
* lto-wrapper.c (xassembler_options_error): New static variable.
(get_options_from_collect_gcc_options): Move parsing options code to
parse_options_from_collect_gcc_options and call it.
(merge_and_complain): Validate -Xassembler options.
(append_compiler_options): Handle OPT_Xassembler.
(run_gcc): Append command line -Xassembler options to
collect_gcc_options.
* doc/invoke.texi: Add documentation about using Xassembler
options with LTO.

testsuite/
* gcc.target/arm/pr78353-1.c: New test.
* gcc.target/arm/pr78353-2.c: Likewise.

[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

2020-02-23 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #16 from Peter Bergner  ---
Fixed everywhere.

[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658

--- Comment #15 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:53efbfe030a5fda41e5e7856d76ea827dd09f49c

commit r8-10050-g53efbfe030a5fda41e5e7856d76ea827dd09f49c
Author: Peter Bergner 
Date:   Sun Feb 23 22:04:44 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
address as being invalid, which causes LRA's process_address()  to go into
an infinite loop spilling the same address over and over again.
Include Mike's earlier commits that fix bugs this patch exposes.

Backport from master
2020-02-20  Peter Bergner  

PR target/93658
* config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
vector modes.

* gcc.target/powerpc/pr93658.c: New test.
* gcc.target/powerpc/vsx-vector-6-le.c: Update fragile insn count.

[Bug target/93568] [10 regression] r10-6418 causes many ICEs

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93568

--- Comment #5 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Peter Bergner
:

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

commit r8-10049-ge88c006ab2b919913fcdb5a5d9db147f372cd156
Author: Michael Meissner 
Date:   Sun Feb 23 21:57:11 2020 -0600

Adjust how variable vector extraction is done.

Backport from master
2020-02-03  Michael Meissner  

* config/rs6000/rs6000.c (get_vector_offset): New helper function
to calculate the offset in memory from the start of a vector of a
particular element.  Add code to keep the element number in
bounds if the element number is variable.
(rs6000_adjust_vec_address): Move calculation of offset of the
vector element to get_vector_offset.
(rs6000_split_vec_extract_var): Do not do the initial AND of
element here, move the code to get_vector_offset.

Fix PR 93568 (thinko)

Backport from master
2020-02-05  Michael Meissner  

PR target/93568
* config/rs6000/rs6000.c (get_vector_offset): Fix Q constraint assert
to use MEM.

[Bug target/93568] [10 regression] r10-6418 causes many ICEs

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93568

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:428a4feef8594142e5324c0f5cfc8281e43bf75a

commit r9-8268-g428a4feef8594142e5324c0f5cfc8281e43bf75a
Author: Michael Meissner 
Date:   Sun Feb 23 18:17:12 2020 -0600

Adjust how variable vector extraction is done.

Backport from master
2020-02-03  Michael Meissner  

* config/rs6000/rs6000.c (get_vector_offset): New helper function
to calculate the offset in memory from the start of a vector of a
particular element.  Add code to keep the element number in
bounds if the element number is variable.
(rs6000_adjust_vec_address): Move calculation of offset of the
vector element to get_vector_offset.
(rs6000_split_vec_extract_var): Do not do the initial AND of
element here, move the code to get_vector_offset.

Fix PR 93568 (thinko)

Backport from master
2020-02-05  Michael Meissner  

PR target/93568
* config/rs6000/rs6000.c (get_vector_offset): Fix Q constraint assert
to use MEM.

[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658

--- Comment #14 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:066184a282b622ac6880150eb4e42fe57881b606

commit r9-8269-g066184a282b622ac6880150eb4e42fe57881b606
Author: Peter Bergner 
Date:   Sun Feb 23 18:22:57 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
address as being invalid, which causes LRA's process_address()  to go into
an infinite loop spilling the same address over and over again.
Include Mike's earlier commits that fix bugs this patch exposes.

Backport from master
2020-02-20  Peter Bergner  

PR target/93658
* config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
vector modes.

* gcc.target/powerpc/pr93658.c: New test.

[Bug c++/93898] [9/10 Regression] internal compiler error: in output_constructor_regular_field

2020-02-23 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93898

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P2
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |9.3
Summary|internal compiler error: in |[9/10 Regression] internal
   |output_constructor_regular_ |compiler error: in
   |field   |output_constructor_regular_
   ||field

[Bug c++/93898] New: internal compiler error: in output_constructor_regular_field

2020-02-23 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93898

Bug ID: 93898
   Summary: internal compiler error: in
output_constructor_regular_field
   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: ---

struct empty { };

struct foo
{
  [[no_unique_address]]
  empty x;

  constexpr
  foo() : x{}
  { }
};

struct bar : foo
{
  using foo::foo;
  int i;
  constexpr bar() : i{1} {}
};

constexpr bar a{};

$ ./cc1plus -quiet x.C
x.C:20:18: internal compiler error: in output_constructor_regular_field, at
varasm.c:5230
   20 | constexpr bar a{};
  |  ^
0x1a28da5 output_constructor_regular_field
/home/mpolacek/src/gcc/gcc/varasm.c:5230
0x1a29cbe output_constructor
/home/mpolacek/src/gcc/gcc/varasm.c:5536
0x1a28617 output_constant
/home/mpolacek/src/gcc/gcc/varasm.c:5065
0x1a1e192 assemble_variable_contents
/home/mpolacek/src/gcc/gcc/varasm.c:2148
0x1a1ec30 assemble_variable(tree_node*, int, int, int)
/home/mpolacek/src/gcc/gcc/varasm.c:2327
0x1a3967c varpool_node::assemble_decl()
/home/mpolacek/src/gcc/gcc/varpool.c:587
0xe7a4fc output_in_order
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2564
0xe7ab82 symbol_table::compile()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2801
0xe7afd0 symbol_table::finalize_compilation_unit()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2984


Started with r9-5710-g7e574f68fa82e7c5f879fd468291ec8b5ebecc83

[Bug c++/93892] Aggregate initialisation of std::array takes forever to compile

2020-02-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93892

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Andrew Pinski  ---
This might be improved for GCC 10.

[Bug target/93897] Poor trivial structure initialization code with -O3

2020-02-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-23
Summary|Poor trivial structure  |Poor trivial structure
   |initialization code.|initialization code with
   ||-O3
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is a vector cost model.

[Bug tree-optimization/93893] MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR

2020-02-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93893

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-23
  Component|middle-end  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Mine for GCC 11.
I have a patch which fixes this but won't be included until GCC 11:
transpose_c:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
lw  $2,0($4)
lw  $3,0($5)
ins $3,$2,16,16
jr  $31
sw  $3,0($6)

[Bug tree-optimization/93896] Store merging uses SSE only for trivial types

2020-02-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-23
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
>  MEM[(struct M *)this_2(D)].p = 0B;
>  MEM  [(unsigned int *)this_2(D) + 8B] = 0;

Could be stored merged (but only because 0 is 0) into:
MEM [(struct M *)this_2(D)] = {}

[Bug tree-optimization/93896] Store merging uses SSE only for trivial types

2020-02-23 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896

--- Comment #1 from Marc Glisse  ---
Without the constructor, we get plain

  *this_2(D).a = {};

which is expanded as an __int128 store. With the constructor, we get

  MEM[(struct M *)this_2(D)].p = 0B;
  MEM[(struct M *)this_2(D)].sz = 0;
  MEM[(struct M *)this_2(D)].cz = 0;

and store merging turns it into

  MEM[(struct M *)this_2(D)].p = 0B;
  MEM  [(unsigned int *)this_2(D) + 8B] = 0;

but no further.

[Bug rtl-optimization/93564] [10 Regression] 470.lbm regresses by 25% on znver2 with -Ofast -march=native LTO and PGO since r10-6384-g2a07345c4f8dabc2

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d

commit r10-6804-g3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d
Author: Vladimir N. Makarov 
Date:   Sun Feb 23 16:20:05 2020 -0500

Changing cost propagation and ordering colorable bucket heuristics for
PR93564.

2020-02-23  Vladimir Makarov  

PR rtl-optimization/93564
* ira-color.c (struct update_cost_queue_elem): New member start.
(queue_update_cost, get_next_update_cost): Add new arg start.
(allocnos_conflict_p): New function.
(update_costs_from_allocno): Add new arg conflict_cost_update_p.
Add checking conflicts with allocnos_conflict_p.
(update_costs_from_prefs, restore_costs_from_copies): Adjust
update_costs_from_allocno calls.
(update_conflict_hard_regno_costs): Add checking conflicts with
allocnos_conflict_p.  Adjust calls of queue_update_cost and
get_next_update_cost.
(assign_hard_reg): Adjust calls of queue_update_cost.  Add
debugging print.
(bucket_allocno_compare_func): Restore previous version.

[Bug target/93897] New: Poor trivial structure initialization code.

2020-02-23 Thread maxim.yegorushkin at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897

Bug ID: 93897
   Summary: Poor trivial structure initialization code.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

The following code:

#include 

struct B {
std::int64_t x;
std::int32_t y;
std::int32_t z;
};

B f(std::int64_t x, std::int32_t y, std::int32_t z) { 
return {x, y, z}; 
}

Compiled with `gcc -O3 -std=gnu++17 -march=skylake` generates the following
assembly:

f(long, int, int):
mov QWORD PTR [rsp-16], 0
mov QWORD PTR [rsp-24], rdi
vmovdqa xmm1, XMMWORD PTR [rsp-24]
vpinsrd xmm0, xmm1, esi, 2
vpinsrd xmm2, xmm0, edx, 3
vmovdqa XMMWORD PTR [rsp-24], xmm2
mov rax, QWORD PTR [rsp-24]
mov rdx, QWORD PTR [rsp-16]
ret

Which looks a bit excessive.

Whereas when compiled with `clang-9.0 -O3 -std=gnu++17 -march=skylake` it
produces the expected:

f(long, int, int):
mov rax, rdi
shl rdx, 32
mov ecx, esi
or  rdx, rcx
ret

https://gcc.godbolt.org/z/udsiyF

[Bug tree-optimization/93896] New: Store merging uses SSE only for trivial types

2020-02-23 Thread msharov at users dot sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896

Bug ID: 93896
   Summary: Store merging uses SSE only for trivial types
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

struct M {
constexpr M() :p{},sz{},cz{}{}
public:
char* p;
unsigned sz;
unsigned cap;
};

struct A { M a,b,c; A(); };
A::A() :a{},b{},c{}{}

gcc 9.2.1 with -march=native -Os on Haswell generates:

_ZN1AC2Ev:
movq$0, (%rdi)
movq$0, 8(%rdi)
movq$0, 16(%rdi)
movq$0, 24(%rdi)
movq$0, 32(%rdi)
movq$0, 40(%rdi)
ret

Store merging is obviously working here, but does not use SSE movups. If the
constructor is removed or defaulted the output is:

_ZN1AC2Ev:
vpxor   %xmm0, %xmm0, %xmm0
vmovups %xmm0, (%rdi)
vmovups %xmm0, 16(%rdi)
vmovups %xmm0, 32(%rdi)
ret

Whether the type is trivial should not matter by the time store merging occurs,
but for some reason it does.

[Bug fortran/83118] [8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type

2020-02-23 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #28 from Paul Thomas  ---
(In reply to Damian Rouson from comment #27)
> Thanks, Paul!  We'll test the patch.
> 
> Damian

Hi Damian,

What was the outcome of the test?

I have spent much of today coming to grips with git and successfully submitted
and committed my first patch with it (PR57710). It still is not especially
obvious to me but I at least have a workflow that allows me to do things.

Regards

Paul

[Bug c++/93769] Slightly wrong diagnostic message for static_asserts with no message

2020-02-23 Thread gennaro.prota+gccbugzilla at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93769

--- Comment #2 from Gennaro Prota  
---
(In reply to Marek Polacek from comment #1)
> (In reply to Gennaro Prota from comment #0)
[...] 
> -std=c++20 implies -std=c++17.

I don't think viewing it this way is in general correct.

> I suppose we could say what you're
> suggesting but there are many places that would need changing.  I'm dubious
> if it's worth it.

Well, I thought this would require changing a single string literal in the
compiler source code.

[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic

2020-02-23 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895

--- Comment #3 from Marek Polacek  ---
The ICE started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb

[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic

2020-02-23 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-23
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ICE (segmentation fault) in |[10 Regression] ICE
   |use of __is_constructible   |(segmentation fault) in use
   |intrinsic   |of __is_constructible
   ||intrinsic
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.  G++ 9 doesn't ICE but spits tons of errors.

[Bug c++/93895] ICE (segmentation fault) in use of __is_constructible intrinsic

2020-02-23 Thread eric.niebler at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895

--- Comment #1 from Eric Niebler  ---
Here is the error:

repro.cpp.i: In instantiation of ‘bool bf::{anonymous}::bb, false> >’:
repro.cpp.i:158:67:   required from ‘df::operator Container() [with
Container = view_facade,
false>::outer_cursor::inner_view, bh>; bool dk = true; dd =
chunk_view_, false>; bg de = bh]’
repro.cpp.i:206:1:   required from ‘chunk_view_::outer_cursor::inner_view chunk_view_::outer_cursor::q()
[with cd = debug_input_view]’
repro.cpp.i:102:5:   required from ‘auto ci::q(ck) [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:123:6:   required from ‘auto cf::operator*() [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:57:1:   required from ‘void cm::is_iterator(bw) requires  t
[with bw = cf, false>::outer_cursor>]’
repro.cpp.i:129:12:   required from ‘auto cm::cp::operator()(bx) requires 
co [with bx = chunk_view >]’
repro.cpp.i:148:49:   required from here
repro.cpp.i:40:50: internal compiler error: Segmentation fault: 11
   40 | template  bool bb = __is_constructible(ah,
an...);
  | 
^

[Bug c++/93895] New: ICE (segmentation fault) in use of __is_constructible intrinsic

2020-02-23 Thread eric.niebler at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895

Bug ID: 93895
   Summary: ICE (segmentation fault) in use of __is_constructible
intrinsic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Created attachment 47892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47892=edit
result of creduce on the error

Happens with trunk. Compile the attached repro.cpp.i with:

  g++ -std=c++2a -xc++ -c repro.cpp.i

The attached file is the result of creduce which sadly made the code invalid,
but the original ICE happened on valid code.

[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits

2020-02-23 Thread andysem at mail dot ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101

--- Comment #2 from andysem at mail dot ru ---
Another use case is C++20 atomic_ref, which may be bound to an object whose
padding bits are in indeterminate state. An intrinsic to clear padding bits
without altering the object value could be useful.

[Bug fortran/93889] missing closing parenthesis in diagnostic

2020-02-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/93889] missing closing parenthesis in diagnostic

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889

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

https://gcc.gnu.org/g:92e8508edaccca6f33098972ce29679375c07cd6

commit r10-6803-g92e8508edaccca6f33098972ce29679375c07cd6
Author: Thomas König 
Date:   Sun Feb 23 17:22:26 2020 +0100

Add missing closing parenthises in error message.

2020-02-23  Thomas Koenig  

PR fortran/93889
* interface.c (compare_parameter): Fix error message.

[Bug fortran/93890] trailing space in diagnostic

2020-02-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

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

[Bug fortran/93890] trailing space in diagnostic

2020-02-23 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890

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

https://gcc.gnu.org/g:7260547dbffd8e6442f99da8adf98ab0ce294e4e

commit r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e
Author: Thomas König 
Date:   Sun Feb 23 17:04:06 2020 +0100

Fix error message.

2020-02-23  Thomas Koenig  

PR fortran/93890
* interface.c: Replace "can not" by "cannot" and remove trailing
space.

2020-02-23  Thomas Koenig  

PR fortran/93890
* gfortran.dg/argument_checking_24.f90: Correct test case.

[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK

2020-02-23 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed in r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299

Thanks for the report.

Paul

[Bug fortran/93889] missing closing parenthesis in diagnostic

2020-02-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-23
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Let's see.

[Bug fortran/93890] trailing space in diagnostic

2020-02-23 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-23
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Let's take this one as git practice.

[Bug tree-optimization/93891] CSE where clobber writes the same value

2020-02-23 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891

--- Comment #1 from Marc Glisse  ---
On the original code (I can attach it if needed, but it is large, it is
resizing a std::vector with reference-counted elements) FRE3 fails to simplify

  MEM[(struct Handle_for *)__cur_16] ={v} {CLOBBER};
  _17 = MEM[(const struct Handle_for &)__first_15].ptr_;
  MEM[(struct Handle_for *)__cur_16].ptr_ = _17;
  _18 = *_17.count;
  _19 = _18 + 1;
  *_17.count = _19;
  _20 = &__first_15->D.202020;
  _31 = MEM[(struct Handle_for *)__first_15].ptr_;

while FRE4 sees

  MEM[(struct Handle_for *)__cur_3] ={v} {CLOBBER};
  _17 = MEM[base: __first_20, offset: 0B];
  MEM[base: __cur_3, offset: 0B] = _17;
  _18 = *_17.count;
  _19 = _18 + 1;
  *_17.count = _19;
  _31 = MEM[base: __first_20, offset: 0B];

and replaces _31 with _17. That's confusing, since the main difference between
the 2 is removing a statement without VOP.

(optimizing in FRE4 is way too late in this case, I want the simplified version
before ldist, and it still requires at least DSE, some pass detecting a
self-assignment, and DCE before that)

Here is another simplified version of the testcase, but you need to compile it
with -fno-early-inlining to see the issue:

void g();
struct A {
  int*p;
  A(A const)noexcept:p(a.p){if(*p<=0)__builtin_unreachable();++*p;}
  ~A(){if(--*p==0)g();}
};

#include 

void f(std::vector){
  v.reserve(1<<20);
}

At the end of gimple, we still have

  _92 = *_91;
  *_91 = _92;

in the main loop, while I would want that gone before ldist.

[Bug c/93894] -Wimplicit-fallthrough false warning with operator %

2020-02-23 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, -Wimplicit-fallthrough is intentionally an early warning, so that it
isn't dependent on optimizations etc., and you are asking that it depends on
VRP or some poor man's VRP.  There will always be ways to obfuscate code so
that the compiler doesn't understand something can't fall through.

[Bug c/93894] -Wimplicit-fallthrough false warning with operator %

2020-02-23 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894

--- Comment #3 from Andrew Pinski  ---
The warning is not sensitive to what is being switched on.  That is the inner
most switch is considered as falling through as the switch is not checked for
the values it will be switched on.

[Bug c/93894] -Wimplicit-fallthrough false warning with operator %

2020-02-23 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894

--- Comment #2 from Dmitry G. Dyachenko  ---
`unsigned' changes nothing

$ cat xxu.i 
int f1(int j, unsigned k)
{
switch (j) {
case 0:
switch (k % 2) {
case 0:
return 0;
case 1:
return 1;
}
// return 3; // uncomment to fix warning
default:
return 2;
}
}

$ gcc -fpreprocessed -Wimplicit-fallthrough=2 -Og -c xxu.i 
xx.i: In function ‘f1’:
xx.i:5:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
5 |  switch (k % 2) {
  |  ^~
xx.i:12:5: note: here
   12 | default:
  | ^~~

[Bug c/93894] -Wimplicit-fallthrough false warning with operator %

2020-02-23 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894

--- Comment #1 from Andreas Schwab  ---
case -1 is missing.

[Bug c/82283] Wrong warning with -Wmissing-field-initializers

2020-02-23 Thread yann at droneaud dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283

--- Comment #5 from Yann Droneaud  ---
For a full combo, here's the almost original code that trigger the two errors
above with GLibc < 2.28, only one with newer Glibc.

#define _GNU_SOURCE 1

#include 
#include 
#include 

int test(int fd)
{
static const char message[] = "Hello world";

struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = htonl(INADDR_LOOPBACK),
.sin_port = htons(12345),
};

struct iovec vec = {
.iov_base = (void *)message,
.iov_len = sizeof(message),
};

struct mmsghdr mmsghdr = {
.msg_hdr = (struct msghdr) {
.msg_name = ,
.msg_namelen = sizeof(addr),
.msg_iov = ,
.msg_iovlen = 1,
},
};

return sendmmsg(fd, , 1, 0);
}

see https://godbolt.org/z/pwXyzE

[Bug c/93894] New: -Wimplicit-fallthrough false warning with operator %

2020-02-23 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894

Bug ID: 93894
   Summary: -Wimplicit-fallthrough false warning with operator %
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

SVN:r257061 8.0.1 20180125 FAIL
r10-6795 FAIL

$ cat xx.i
int f(int j, int k)
{
switch (j) {
case 0:
switch (k % 2) {
case 0:
return 0;
case 1:
return 1;
}
// return 3; // uncomment to fix warning
default:
return 2;
}
}

$ gcc -fpreprocessed -Wimplicit-fallthrough=2 -O[0123] -c xx.i
xx.i: In function ‘f’:
xx.i:5:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
5 |  switch (k % 2) {
  |  ^~
xx.i:12:5: note: here
   12 | default:
  | ^~~

[Bug c++/84364] [8 Regression] -Weffc++ warns on "return *this" in template after r253599

2020-02-23 Thread icegood1980 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84364

icegood1980 at gmail dot com  changed:

   What|Removed |Added

 CC||icegood1980 at gmail dot com

--- Comment #9 from icegood1980 at gmail dot com  
---
I obtained given issue on 9th version of compiler with the next code:

template 
inline Node& Node::operator=(const T& rhs) {
  Assign(rhs);
  return *this;
}


gcc --version
gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.



Please, reopen an issue

[Bug c/93893] New: MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR

2020-02-23 Thread siarhei.siamashka at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93893

Bug ID: 93893
   Summary: MIPS32r2: GCC is unable to figure out that it can use
a single INS instruction instead of SLL+OR
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siarhei.siamashka at gmail dot com
  Target Milestone: ---

Created attachment 47891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47891=edit
Testcase for a single INS instruction vs. SLL+OR

$ mipsel-unknown-linux-gnu-gcc -c -Os -march=mips32r2 testcase.c 
$ mipsel-unknown-linux-gnu-objdump -d testcase.o

testcase.o: file format elf32-tradlittlemips


Disassembly of section .text:

 :
   0:   8c82lw  v0,0(a0)
   4:   94a3lhu v1,0(a1)
   8:   00021400sll v0,v0,0x10
   c:   00431025or  v0,v0,v1
  10:   03e8jr  ra
  14:   acc2sw  v0,0(a2)

0018 :
  18:   8ca2lw  v0,0(a1)
  1c:   8c83lw  v1,0(a0)
  20:   7c62fc04ins v0,v1,0x10,0x10
  24:   03e8jr  ra
  28:   acc2sw  v0,0(a2)
  2c:   nop


The C implementation uses an extra instruction compared to the inline assembly
variant of the same function.

[Bug libstdc++/93892] New: Aggregate initialisation of std::array takes forever to compile

2020-02-23 Thread zoid at riseup dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93892

Bug ID: 93892
   Summary: Aggregate initialisation of std::array takes forever to compile
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zoid at riseup dot net
  Target Milestone: ---

Created attachment 47890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47890=edit
preprocessed mwe

Aggregate initialisation of a std::array with a non-trivial type and a large
number of elements, say 10, takes ages to compile and produces
correspondingly huge binaries on any optimisation level. Cranking up the size
parameter exacerbates the problem.

Note: There are similar bug reports of very old versions of gcc. This might be
a regression.

Minimal working example:

#include 

int main() {
  struct nontriv { nontriv() { } };
  std::array array = {}; // <- aggregate init
}
// g++ -Wall -Wextra -pedantic -std=c++17 -O1 mwe.cpp -save-temps -v

Attached mwe.ii of the above mwe.cpp.

g++ version information:
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-25'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-mutex
Thread model: posix
gcc version 9.2.1 20200123 (Debian 9.2.1-25)

[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression

2020-02-23 Thread kuzniar95 at o2 dot pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842

--- Comment #4 from kuzniar95 at o2 dot pl ---
I meant that dropping constness:

char ch = '='; // OK

results in an error:

lambda.cpp: In lambda function:
lambda.cpp:4:23: error: ‘ch’ is not captured
4 | [](auto) { return ch; }; // OK
  |   ^~
lambda.cpp:4:6: note: the lambda has no capture-default
4 | [](auto) { return ch; }; // OK
  |  ^
lambda.cpp:2:7: note: ‘char ch’ declared here
2 |  char ch = '=';
  |   ^~

which is actually good.