[Bug c/90478] New: ice in emit_case_dispatch_table at gcc/stmt.c:796

[dcb314 at hotmail dot com]

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

Bug ID: 90478
   Summary: ice in emit_case_dispatch_table at gcc/stmt.c:796
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 46358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46358&action=edit
C source code

For the attached code, gcc trunk does this:

$ ~/gcc/results/bin/gcc -c bug521.c
during RTL pass: expand
runtime.c: In function ‘dump_heap_state_2’:
runtime.c:12297:13: internal compiler error: Segmentation fault
0xe399d7 crash_signal
../../trunk/gcc/toplev.c:326
0xe25669 emit_case_dispatch_table
../../trunk/gcc/stmt.c:796
0xe27735 expand_case(gswitch*)
../../trunk/gcc/stmt.c:987
0x943e0a expand_gimple_stmt_1
../../trunk/gcc/cfgexpand.c:3693
$  ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.271150/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.271150
--disable-multilib --disable-werror --enable-checking=df,extra,fold,rtl,yes
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 10.0.0 20190514 (experimental) (GCC) 
$ 

I'll have my usual go at reducing the code and finding
a range of revisions where the problem starts.

[Bug c++/84916] Tweaks to template type elision

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to David Malcolm from comment #4)
> I have a patch for this, queuing for gcc 10 stage 1.

It's gcc 10 stage 1

[Bug c/90476] prepossessor should error if #line 0

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Segher Boessenkool from comment #3)
> Where is it documented (in GCC). then?  I can't find it.

¯\_(ツ)_/¯

I dunno where they got that idea; just reporting it because I thought it seemed
like it might be relevant

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[conradsand.arma at gmail dot com]

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

Conrad S  changed:

   What|Removed |Added

 CC||conradsand.arma at gmail dot 
com

--- Comment #28 from Conrad S  ---
More fallout, this time with C++ code:
https://bugzilla.redhat.com/show_bug.cgi?id=1709538

+1 for "Maintaining binary compatibility (even if it is bug compatibility) with
existing packages"

[Bug c/90476] prepossessor should error if #line 0

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Where is it documented (in GCC). then?  I can't find it.

[Bug c/90476] prepossessor should error if #line 0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
For reference, clang considers this a GNU extension and even has a specific
named flag to warn about it, -Wgnu-zero-line-directive:
https://clang.llvm.org/docs/DiagnosticsReference.html#wgnu-zero-line-directive

[Bug c++/90455] braced-init and incomplete type instantiation

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Reduced, clang++ compiles it.

struct B;
template  struct b {
  void operator()(a *) { sizeof(a); }
};
struct c {
  struct D {
using d = B *;
  };

  using e = D::d;
  e f();
};
template  class g {
  c h;
  using i = b;
public:
  ~g() {
auto j = h.f();
k()(j);
  }
  i k();
};
struct l {
  g m{};
};

[Bug c/90477] New: negative line numbers should not be displayed

[jg at jguk dot org]

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

Bug ID: 90477
   Summary: negative line numbers should not be displayed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Using godbolt trunk

gcc shows negative numbers, I don't know if it is any better to put a ceiling,
at least if the line number was stuck at 2147483646 that might be better than
wrapping to negative. 

Although making line numbers 64bit might be a nicer solution.

#pragma message "A1"
#line 2147483647

#pragma message "A1"



#1 with x86-64 gcc (trunk)
:1:17: note: #pragma message: A1

1 | #pragma message "A1"

  | ^~~~

:-2147483648:17: note: #pragma message: A1

Compiler returned: 0

[Bug c/90476] prepossessor should error if #line 0

[jg at jguk dot org]

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

--- Comment #1 from Jonny Grant  ---
Created attachment 46357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46357&action=edit
test case

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[bugzi...@poradnik-webmastera.com]

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

--- Comment #5 from Daniel Fruzynski  ---
Created attachment 46356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46356&action=edit
Valgrind log

Here is Valgrind log. It found multiple cases when uninitialized value vas
used. However in all cases callstack for place where this uninitialized memory
come from is the same. Here is log for 1st issue:

==18990== Conditional jump or move depends on uninitialised value(s)
==18990==at 0x86DAA7: sparseset_bit_p (sparseset.h:147)
==18990==by 0x86DAA7: mark_pseudo_regno_live(int) (ira-lives.c:289)
==18990==by 0x86EBC0: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1254)
==18990==by 0x8545C7: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1806)
==18990==by 0x86F751: ira_create_allocno_live_ranges() (ira-lives.c:1565)
==18990==by 0x855DFC: ira_build() (ira-build.c:3422)
==18990==by 0x84D7BA: ira (ira.c:5308)
==18990==by 0x84D7BA: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5619)
==18990==by 0x913B60: execute_one_pass(opt_pass*) (passes.c:2465)
==18990==by 0x914307: execute_pass_list_1(opt_pass*) (passes.c:2554)
==18990==by 0x914319: execute_pass_list_1(opt_pass*) (passes.c:2555)
==18990==by 0x914364: execute_pass_list(function*, opt_pass*)
(passes.c:2565)
==18990==by 0x691118: cgraph_node::expand() (cgraphunit.c:2042)
==18990==by 0x692633: expand_all_functions (cgraphunit.c:2178)
==18990==by 0x692633: symbol_table::compile() (cgraphunit.c:2536)
==18990==  Uninitialised value was created by a heap allocation
==18990==at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==18990==by 0x10EF387: xmalloc (xmalloc.c:147)
==18990==by 0x9B9F34: sparseset_alloc(unsigned long) (sparseset.c:33)
==18990==by 0x86F6DF: ira_create_allocno_live_ranges() (ira-lives.c:1557)
==18990==by 0x855DFC: ira_build() (ira-build.c:3422)
==18990==by 0x84D7BA: ira (ira.c:5308)
==18990==by 0x84D7BA: (anonymous namespace)::pass_ira::execute(function*)
(ira.c:5619)
==18990==by 0x913B60: execute_one_pass(opt_pass*) (passes.c:2465)
==18990==by 0x914307: execute_pass_list_1(opt_pass*) (passes.c:2554)
==18990==by 0x914319: execute_pass_list_1(opt_pass*) (passes.c:2555)
==18990==by 0x914364: execute_pass_list(function*, opt_pass*)
(passes.c:2565)
==18990==by 0x691118: cgraph_node::expand() (cgraphunit.c:2042)
==18990==by 0x692633: expand_all_functions (cgraphunit.c:2178)
==18990==by 0x692633: symbol_table::compile() (cgraphunit.c:2536)

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #25 from Jonny Grant  ---
(In reply to Segher Boessenkool from comment #24)
> (In reply to Jonny Grant from comment #23)
> > Would it be better if I created a separate PR for this?  #line 0  ?
> 
> Yes please, it's a separate issue, and will get lost here.  Thanks.

Ok, filed here

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

[Bug c/90476] New: prepossessor should error if #line 0

[jg at jguk dot org]

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

Bug ID: 90476
   Summary: prepossessor should error if #line 0
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

gcc should reject #line 0

As I understand

#line 
So it could actually only ever be 1 or above. As files start at line 1, not 0.


Although line 0 is invalid, gcc accepts and sets this.


$ gcc -o line5 line5.c
line5.c:0:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ at end of
input

$ cat line5.c
#line 0
mytypo

$

[Bug c++/68918] spurious "invalid use of incomplete type" in trailing return type

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 14 21:19:01 2019
New Revision: 271193

URL: https://gcc.gnu.org/viewcvs?rev=271193&root=gcc&view=rev
Log:
PR c++/68918
* g++.dg/cpp0x/decltype71.C: New test.

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

[Bug c++/68918] spurious "invalid use of incomplete type" in trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug middle-end/90248] [8/9/10 Regression] larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
(In reply to Andrew Pinski from comment #10)
> So I am trying to understand, the semantics here.
> HONOR_SIGNED_ZEROS says -0.0 won't exist or that the sign of -0.0 and 0.0
> don't matter? and what are the semantics if -0.0 shows up?

That sign of -0.0 and 0.0 doesn't matter IMHO, we certainly can't guarantee
that -0.0 won't show up, that is what the hw computes in various cases.
My understanding is that -fno-signed-zeros is user saying that if the result is
+/-0, then the user is not going to use e.g. copysign or signbit on that that
would turn that insignificant sign difference into something that changes the
behavior of the program.
The docs say:
 Allow optimizations for floating-point arithmetic that ignore the
 signedness of zero.  IEEE arithmetic specifies the behavior of
 distinct +0.0 and -0.0 values, which then prohibits simplification
 of expressions such as x+0.0 or 0.0*x (even with
 '-ffinite-math-only').  This option implies that the sign of a zero
 result isn't significant.

[Bug c++/70156] incorrect "incomplete type" error initializing a static const data member

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/70156] incorrect "incomplete type" error initializing a static const data member

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue May 14 21:10:58 2019
New Revision: 271192

URL: https://gcc.gnu.org/viewcvs?rev=271192&root=gcc&view=rev
Log:
PR c++/70156
* g++.dg/init/static5.C: New test.

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

[Bug c++/90466] Documentation: -Wconversion-extra not documented

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
That's a fortran option; it's documented in the gfortran manual:
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options

[Bug c++/63296] g++ reports incomplete type for static template member of template class

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Re-confirmed with today's trunk:

$ ./cc1plus -quiet 63296.C
63296.C: In instantiation of ‘struct list >’:
63296.C:8:26:   required from ‘struct myclass’
63296.C:11:14:   required from here
63296.C:3:7: error: ‘list::member’ has incomplete type
3 | c member;
  |   ^~
63296.C:7:8: note: declaration of ‘struct myclass’
7 | struct myclass {
  |^~~

[Bug tree-optimization/90474] [10 Regression] ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-14
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Known to work||9.1.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r270844.

[Bug c++/68918] spurious "invalid use of incomplete type" in trailing return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Fixed by r236221, I'll add the test.

[Bug target/82920] cet test failures on darwin

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
Author: iains
Date: Tue May 14 20:36:18 2019
New Revision: 271190

URL: https://gcc.gnu.org/viewcvs?rev=271190&root=gcc&view=rev
Log:
darwin, testsuite, fix more PR 82920

Darwin doesn't support mx32, and some tests were
failing because it was trying to do them.  When we
disable this it turns out that quite a few tests
requiring mx32 support were not guarded.

gcc/

2019-05-14  Iain Sandoe  

PR target/82920
* config/i386/darwin.h (CC1_SPEC): Report -mx32 as an error for
Darwin.

gcc/testsuite/

2019-05-14  Iain Sandoe  

PR target/82920
* gcc.target/i386/cet-sjlj-6b.c: Require effective target x32.
* gcc.target/i386/pr52146.c: Likewise.
* gcc.target/i386/pr52698.c: Likewise.
* gcc.target/i386/pr52857-1.c: Likewise.
* gcc.target/i386/pr52857-2.c: Likewise.
* gcc.target/i386/pr52876.c: Likewise.
* gcc.target/i386/pr53698.c: Likewise.
* gcc.target/i386/pr54157.c: Likewise.
* gcc.target/i386/pr55049-1.c: Likewise.
* gcc.target/i386/pr55093.c: Likewise.
* gcc.target/i386/pr55116-1.c: Likewise.
* gcc.target/i386/pr55116-2.c: Likewise.
* gcc.target/i386/pr55597.c: Likewise.
* gcc.target/i386/pr59929.c: Likewise.
* gcc.target/i386/pr66470.c: Likewise.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/darwin.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/cet-sjlj-6b.c
trunk/gcc/testsuite/gcc.target/i386/pr52146.c
trunk/gcc/testsuite/gcc.target/i386/pr52698.c
trunk/gcc/testsuite/gcc.target/i386/pr52857-1.c
trunk/gcc/testsuite/gcc.target/i386/pr52857-2.c
trunk/gcc/testsuite/gcc.target/i386/pr52876.c
trunk/gcc/testsuite/gcc.target/i386/pr53698.c
trunk/gcc/testsuite/gcc.target/i386/pr54157.c
trunk/gcc/testsuite/gcc.target/i386/pr55049-1.c
trunk/gcc/testsuite/gcc.target/i386/pr55093.c
trunk/gcc/testsuite/gcc.target/i386/pr55116-1.c
trunk/gcc/testsuite/gcc.target/i386/pr55116-2.c
trunk/gcc/testsuite/gcc.target/i386/pr55597.c
trunk/gcc/testsuite/gcc.target/i386/pr59929.c
trunk/gcc/testsuite/gcc.target/i386/pr66470.c

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-14
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
I can take a look tomorrow.

[Bug middle-end/90248] [8/9/10 Regression] larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
So I am trying to understand, the semantics here.
HONOR_SIGNED_ZEROS says -0.0 won't exist or that the sign of -0.0 and 0.0 don't
matter? and what are the semantics if -0.0 shows up?

If we treat -0.0 as 0.0, then all of the optimizations here should be removed.
If we treat -0.0 as undefined behavior if it shows up, then only two of the
lines need to be removed.

Which is correct semantics for HONOR_SIGNED_ZEROS?

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[bugzi...@poradnik-webmastera.com]

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

--- Comment #3 from Daniel Fruzynski  ---
Created attachment 46355
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46355&action=edit
Source code which triggers crash

I added code which causes crash when compiling. Here is command which I used on
CentOS 7:

../gcc-7.4.0-mingw64/bin/x86_64-w64-mingw32-g++ -O3 -ftree-vectorize -std=c++11
-Wall -pthread -I. -D_BSD_SOURCE -g -c RakeSearchOpenCL.cpp -o
RakeSearchOpenCL.o

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
I was able to reproduce crash using MinGW crosscompiler build for CentOS 7,
configured in following way:

../gcc-7.4.0/configure --prefix=/root/gcc-7.4.0-mingw64
--build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --with-gnu-as
--with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-languages=c,c++ --enable-threads=posix
--enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
--with-as=/usr/bin/x86_64-w64-mingw32-as
--with-ld=/usr/bin/x86_64-w64-mingw32-ld

Required prerequisites were downloaded using script from contrib dir. I also
have installed MinGW toolchain from EPEL repository, to get sysroot and other
things needed for build.

With this crosscompiler I got following crash report:

[out]
RakeSearchOpenCL.cpp: In member function 'bool RakeSearchOpenCL::init(int,
char**)':
RakeSearchOpenCL.cpp:99:1: internal compiler error: Segmentation fault
 }
 ^
0x9cd06f crash_signal
../../gcc-7.4.0/gcc/toplev.c:337
0x62ab33 lookup_page_table_entry
../../gcc-7.4.0/gcc/ggc-page.c:630
0x62ab33 ggc_set_mark(void const*)
../../gcc-7.4.0/gcc/ggc-page.c:1527
0x57bf97 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:133
0x57d337 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:523
0x59d6c3 gt_ggc_mx_cxx_binding(void*)
./gt-cp-name-lookup.h:60
0x57c1b7 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:648
0x57cf06 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:275
0x57c920 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:466
0x57c83b gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:440
0x57ce6c gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:264
0x57d337 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:523
0x57d329 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:522
0x57d329 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:522
0x57d353 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:525
0x57cc69 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:356
0x57ce96 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:267
0x7d78ce gt_ggc_mx_gimple(void*)
/root/gcc-7.4.0-mingw64-build/obj/gcc/gtype-desc.c:1316
0x7d5909 gt_ggc_mx_basic_block_def(void*)
/root/gcc-7.4.0-mingw64-build/obj/gcc/gtype-desc.c:1440
0x7d7565 gt_ggc_mx_gimple(void*)
/root/gcc-7.4.0-mingw64-build/obj/gcc/gtype-desc.c:1319
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[/out]

I tried to debut it using gdb, and got this callstack:

[out]
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 18062]
lookup_page_table_entry (p=p@entry=0x157cf6a4) at
../../gcc-7.4.0/gcc/ggc-page.c:630
630   while (table->high_bits != high_bits)
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-260.el7_6.5.x86_64
(gdb) i lo
L2 = 
high_bits = 0
base = 
L1 = 
table = 0x0
(gdb) bt
#0  lookup_page_table_entry (p=p@entry=0x157cf6a4) at
../../gcc-7.4.0/gcc/ggc-page.c:630
#1  ggc_set_mark (p=p@entry=0x157cf6a4) at ../../gcc-7.4.0/gcc/ggc-page.c:1527
#2  0x0057bf98 in gt_ggc_mx_lang_tree_node (x_p=0x157cf6a4) at
./gt-cp-tree.h:133
#3  0x0057d338 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:523
#4  0x0059d6c4 in gt_ggc_mx_cxx_binding (x_p=0x7fffe8d61550) at
./gt-cp-name-lookup.h:60
#5  0x0057c1b8 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:648
#6  0x0057cf07 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:275
#7  0x0057c921 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:466
#8  0x0057c83c in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:440
#9  0x0057ce6d in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:264
#10 0x0057d338 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:523
#11 0x0057d32a in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:522
#12 0x0057d32a in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:522
#13 0x0057d354 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:525
#14 0x0057cc6a in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:356
#15 0x0057ce97 in gt_ggc_mx_lang_tree_node (x_p=) at
./gt-cp-tree.h:267
#16 0x007d78cf in gt_ggc_mx_gimple (x_p=) at
gtype-desc.c:1316
#17 0x007d590a in gt_ggc_mx_basic_block_def (x_p=) at
gtype-desc.c:1440
#18 0x007d7566 in gt_ggc_mx_gimple (x_p=) at
gtype-desc.c:1319
#19 0x007d98d2 in gt_ggc_mx_cgraph_edge (x_p=) at
gtype-desc.c:2608
#20 0x007d93ee in gt_ggc_mx_symtab_node (x_p=) at
gtype-desc.c:1799
#21 0x0057ccc1 i

[Bug c++/70077] noexcept, inheriting constructors and the invalid use of an incomplete type that is actually complete

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Confirmed with trunk:

$ ./cc1plus -quiet 70077.C
70077.C:8:31: error: invalid use of incomplete type ‘struct D’
8 | D() noexcept(noexcept(D{42})): B{42} { }
  |   ^
70077.C:6:8: note: definition of ‘struct D’ is not complete until the closing
brace
6 | struct D: public B {
  |^

[Bug c++/70156] incorrect "incomplete type" error initializing a static const data member

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Since r254461:

70156.C:4:23: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const A<0> C::a’ of non-integral type [-fpermissive]
4 | static const A<0> a = { 0 };
  |   ^
70156.C:5:20: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const B C::b’ of non-integral type [-fpermissive]
5 | static const B b = { 1 };
  |^

which is also what clang++ says.  I'll add the test.

[Bug c++/78615] error: cannot decrement a pointer to incomplete type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
This is again accepted starting with r245612.  I haven't figured out yet if
it's valid or not (and whether we should add the test).

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek  ---
Note that both ifort and xlc fortran have the hidden string length arguments as
well.

[Bug c++/62244] Function parameter should be in scope in its own default argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-07-07 00:00:00 |2019-5-14
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=50479

--- Comment #1 from Jonathan Wakely  ---
Closely related to (maybe even a dup of) PR 50479

[Bug c++/50479] Unevaluated usage of parameters in function default arguments is accepted

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
It could even allow tailcalls in the character(len=*) cases because in those
cases if the caller omits the string length hidden argument, I see no reason to
try to workaround that, it will simply never work properly.
The only reason without tailcalls things appear to work is that the argument is
TREE_READONLY and nothing touches it, so there is some hope it won't be
modified either, when doing a tailcall if the tail callee needs any of those
stack slots for other arguments, it will be written into.  We could still allow
tail calls
if the callee needs fewer arguments than the caller and doesn't need to
overwrite any of the hidden string length arguments the buggy callers don't
provide.

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #35 from Than McIntosh  ---
I applied r271124 to the gcc-9 branch and re-ran the large testcase -- still
has the long compile time (2127 seconds), FWIW.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #25 from Jakub Jelinek  ---
(In reply to Thomas Koenig from comment #15)
> Hi Tomas,
> 
> > I understand the compiler may not know and typically does not whether the
> > called function accepts "character(len=1)" or "character(len=*)", so it may
> > have to pass the 1. But the situation where I suggest not writing the 1 is
> > more subtle (see my original post -
> > https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html).
> 
> I have given this some thought, and I don't think this can be done
> in the general case, unfortunately.
> 
> Consider
> 
>   program main
>   call foo("ab")
>   end
> 
>   subroutine foo(c)
>   character*1 c
>   call bar(c)
>   end
> 
>   subroutine bar(c)
>   character*(*) c
>   print *,len(c)
>   end
> 
> This is legal Fortran going back to F77, and it should print 1.
> 
> If your proposal was implemented, this would print 2, which would
> be a wrong-code bug :-(
> 
> So, what can we do?  Previously, the way of interfacing C
> with Fortran was fragile, non-conforming, and worked.  Now
> it is fragile, non-conforming, and does not work.
> 
> In your (excellent, by the way) debugging work, you have
> identified an option, -fno-optimize-sibling-calls, which
> restores the status quo because things would go back to
> being fragile, nonconforming, and they would work again.

You don't want to do that, that is way big hammer and in some cases, tail call
optimizations are essential for correct program behavior (without the
optimizations for deep recursions you won't fit on stack, while when using them
you will).

If you want some hack to workaround these buggy wrappers (but will their
maintainers then actually fix anything rather than ignoring the problem?),
then I could see tail-calls.c or calls.c punt if it sees DECL_ARTIFICIAL
PARM_DECLs passed on the stack at the end of argument list and it is the
fortran length (it would e.g. help if those arguments would be named with an
initial dot rather than underscore (I believe that used to be the case in the
past)), or we need some way to propagate the info that the argument is hidden
string length through LTO.

[Bug c++/90475] Diagnostic for designated initializer could be a lot better

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-14
 Ever confirmed|0   |1

[Bug c++/90475] New: Diagnostic for designated initializer could be a lot better

[barry.revzin at gmail dot com]

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

Bug ID: 90475
   Summary: Diagnostic for designated initializer could be a lot
better
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

gcc 8 and 9 have made dramatic improvements in diagnostics, but here's a case
where it could be a lot better: the "oops, I typoed my designated initializer"
case:

struct X { int i, j; };

X f() { return {.i=42, .k=17}; }

emits:

: In function 'X f()':
:3:29: error: could not convert '{42, 17}' from '' to 'X'
3 | X f() { return {.i=42, .k=17}; }
  | ^
  | |
  | 
Compiler returned: 1

Similarly:

struct X { int i, j; };

void g(X );
void h() {
g({.i=42, .k=17});
}

emits:

: In function 'void h()':
:5:21: error: could not convert '{42, 17}' from '' to 'X'
5 | g({.i=42, .k=17});
  | ^
  | |
  | 
Compiler returned: 1

Would be very cool if the diagnostic could somehow point to the "k"
initializer, rather than basically "I dunno what is this thing??"

(obviously not the most high priority thing, just a nice to have)

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #37 from Iain Sandoe  ---
fixed on all open branches.

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[segher at gcc dot gnu.org]

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

--- Comment #24 from Segher Boessenkool  ---
(In reply to Jonny Grant from comment #23)
> Would it be better if I created a separate PR for this?  #line 0  ?

Yes please, it's a separate issue, and will get lost here.  Thanks.

[Bug c/90472] “extern int i;” declaration inside function is allowed to shadow “static int i;” at file scope

[pascal_cuoq at hotmail dot com]

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

--- Comment #2 from Pascal Cuoq  ---
Thanks for this link.

So the bug report is that the file below is rejected by GCC 9.1 (and every GCC
version present on Compiler Explorer down to 4.1.2), whereas according to the
arguments in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14366 it should be
accepted.

int *p1, *p2;

static int i = 1;

void f(void) {
p1 = &i;
int i = 2;
{
extern int i;
p2 = &i;
}
}

[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |8.4

[Bug testsuite/81058] FAIL: gcc.target/i386/avx512bw-vpmovu?swb-1.c scan-assembler-times vpmovu?swb.*

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
Author: iains
Date: Tue May 14 17:41:36 2019
New Revision: 271186

URL: https://gcc.gnu.org/viewcvs?rev=271186&root=gcc&view=rev
Log:
darwin, testsuite, backport fixes for PR 81058

2019-05-14  Iain Sandoe  

Backport from mainline.
2019-05-11  Iain Sandoe  

PR testsuite/81058
* gcc.target/i386/avx512bw-vpmovswb-1.c: Use regular data section
for variables on Darwin, rather than common.
* gcc.target/i386/avx512bw-vpmovuswb-1.c: Likewise.
* gcc.target/i386/avx512bw-vpmovwb-1.c: Likewise.


Modified:
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovswb-1.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovuswb-1.c
branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/avx512bw-vpmovwb-1.c

[Bug d/88238] libphobos compile problems on Solaris 10

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
>> --- Comment #6 from Rainer Orth  ---
>> The patch consists primarily of additions to 
>> DRUNTIME_LIBRARIES_DL_ITERATE_PHDR
>> to detect the situation, the mapfile and libdruntime/Makefile.am code to 
>> create
>> the helper lib.
>
> Is a helper library really needed?  I think I'd prefer it to go in any
> of the existing libraries already built instead of adding more things
> to link in.

This otherwise won't work with -static-libphobos, unfortunately:

* The amd64 __tls_get_addr bug can only be avoided if the call to that
  function lives in a shared object (or a position independent
  executable, which Solaris 10 doesn't support), thus a helper lib is
  the only option.

* Likewise for the missing sparcv9 dl_iterate_phdr: the mapfile
  directing that call to ld.so.1 has only effect inside a shared
  object.

I know this is ugly as hell, but the Solaris linker engineer couldn't
come up with any other option.

It's clearly your call if this is acceptable for GCC 9 (the
dl_iterate_phdr part which isn't necessary on mainline with Solaris 10
support removed) or both GCC 9 and 10 (the __tls_addr_part which also
benefits Illumos even with Solaris 10 gone).

I just wanted to turn this into a patch which shows that the workarounds
are viable; if the resulting mess is really worth while is another
matter...

[Bug tree-optimization/90474] New: [10 Regression] ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF)

[asolokha at gmx dot com]

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

Bug ID: 90474
   Summary: [10 Regression] ICE: verify_gimple failed (error:
DECL_GIMPLE_REG_P set on a variable with address
taken; error: invalid address operand in MEM_REF)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20190512 snapshot (r27) ICEs when compiling the following
testcase at any optimization level (except -Og) and w/ -ftree-vectorize
-fno-tree-ccp -fno-tree-loop-optimize -fno-tree-sra --param
dse-max-alias-queries-per-store=0:

typedef int v8si __attribute__ ((vector_size (32)));

v8si
cl (v8si w4)
{
  while ((v8si) {0, w4[0]}[1])
{
}

  return w4;
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190512 -O1 -ftree-vectorize
-fno-tree-ccp -fno-tree-loop-optimize -fno-tree-sra --param
dse-max-alias-queries-per-store=0 -w -c uqwxndwh.c
uqwxndwh.c: In function 'cl':
uqwxndwh.c:4:1: note: the ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
4 | cl (v8si w4)
  | ^~
uqwxndwh.c:4:1: error: DECL_GIMPLE_REG_P set on a variable with address taken
uqwxndwh.c:4:1: error: invalid address operand in MEM_REF
MEM[(vector(8) int *)&D.1909];

# .MEM_19 = VDEF <.MEM_3>
MEM[(vector(8) int *)&D.1909] = vect_cst__18;
during GIMPLE pass: slp
uqwxndwh.c:4:1: internal compiler error: verify_gimple failed
0xd69d18 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190512/work/gcc-10-20190512/gcc/tree-cfg.c:5387
0xc45d29 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190512/work/gcc-10-20190512/gcc/passes.c:1963
0xc46ae1 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190512/work/gcc-10-20190512/gcc/passes.c:2017

[Bug c/90472] “extern int i;” declaration inside function is allowed to shadow “static int i;” at file scope

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
See PR 14366.

[Bug c++/90473] New: gcc does not call function in comma operator

[tiagomacarios at gmail dot com]

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

Bug ID: 90473
   Summary: gcc does not call function in comma operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiagomacarios at gmail dot com
  Target Milestone: ---

In the code below gcc should call f() prios to calling b(), but that does not
happen.

https://godbolt.org/z/e245vi

void f();

void b(void* p = (f(), nullptr));

void z()
{
b();
}

[Bug c/90472] New: “extern int i;” declaration inside function is allowed to shadow “static int i;” at file scope

[pascal_cuoq at hotmail dot com]

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

Bug ID: 90472
   Summary: “extern int i;” declaration inside function is allowed
to shadow “static int i;” at file scope
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

Consider the two compilation units below, that differ only in the name of the
automatic variable inside function f:


int *p1, *p2;

static int i = 1;

void f(void) {
p1 = &i;
int i = 2;
{
extern int i;
p2 = &i;
}
}

int *p1, *p2;

static int i = 1;

void f(void) {
p1 = &i;
int j = 2;
{
extern int i;
p2 = &i;
}
}


Using GCC 9.1, the first file is accepted and the “obvious” assembly code is
generated (the function f assigns the same value to p1 and p2). The second file
is rejected with the error message:

: In function 'f':
:9:20: error: variable previously declared 'static' redeclared 'extern'
9 | extern int i;
  |^


Compiler Explorer link: https://gcc.godbolt.org/z/wrvZ1d

I rather agree with the error message, and my understanding of C11 6.7:3
(https://port70.net/~nsz/c/c11/n1570.html#6.7p3 ) is that both compilation
units should be rejected. In any case, the two look equivalent, and they should
probably either be both accepted or both rejected.

(If you arrive to the conclusion that the C11 standard says they should both be
rejected, I will have a similar bug to report in Clang.)

[Bug debug/90471] ICE Segmentation fault when compiling with debug info

[bugzi...@poradnik-webmastera.com]

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

--- Comment #1 from Daniel Fruzynski  ---
Created attachment 46354
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46354&action=edit
MinGW package versions

[Bug c/90471] New: ICE Segmentation fault when compiling with debug info

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 90471
   Summary: ICE Segmentation fault when compiling with debug info
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

Created attachment 46353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46353&action=edit
Preprocessed code

I got ICE Segmentation fault when trying to build OpenCL BOINC app which I am
developing. This happen only when I use -g option, without it code compiles
fine.

I compiled code using MinGW crossompiler shipped with Cygwin. Exact versions of
all mingw packages are on attached screen. I also attached preprocessed source.
I use 64-bit Cygwin on 64-bit Win 10 Pro with latest patches.

When I was trying to remove unimportant parts of source code, I found
interesting thing: I was able to comment out boinc_opencl.h include and crash
still happen. However when I removed this line completely, gcc did not crash.
This part of code looks as follows:

[code]
#define __CL_ENABLE_EXCEPTIONS
#define CL_TARGET_OPENCL_VERSION 120
#define CL_USE_DEPRECATED_OPENCL_1_1_APIS
#include "CL/cl.hpp"
//#include "boinc_opencl.h"

class OclException : public std::exception
[/code]

I can attach original files and all relevant headers if you need them too.

$ x86_64-w64-mingw32-g++ -O3 -ftree-vectorize -std=c++11 -Wall -pthread
-I/cygdrive/c/rakesearch/_boinc -I/cygdrive/c/rakesearch/_boinc/lib
-I/cygdrive/c/rakesearch/_boinc/include/boinc -I. -D_BSD_SOURCE -g -c
RakeSearchOpenCL2.cpp -o RakeSearchOpenCL.o

RakeSearchOpenCL2.cpp: In member function ‘bool RakeSearchOpenCL::init(int,
char**)’:
RakeSearchOpenCL2.cpp:99:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 7.4.0
Copyright (C) 2017 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.

$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/7.4.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/mingw64-x86_64-gcc
--htmldir=/usr/share/doc/mingw64-x86_64-gcc/html -C --build=x86_64-pc-cygwin
--host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --without-libiconv-prefix
--without-libintl-prefix --with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib
--disable-win32-registry --enable-languages=c,c++,fortran,lto,objc,obj-c++
--enable-fully-dynamic-string --enable-graphite --enable-libgomp
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-version-specific-runtime-libs --enable-libgomp --enable-libada
--with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic
--with-cloog-include=/usr/include/cloog-isl --with-system-zlib
--enable-threads=posix --libexecdir=/usr/lib
Thread model: posix
gcc version 7.4.0 (GCC)

[Bug c/90470] New: internal compiler error after multiple declaration of alias in a custom section

[guillaume.bertholon at hotmail dot fr]

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

Bug ID: 90470
   Summary: internal compiler error after multiple declaration of
alias in a custom section
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guillaume.bertholon at hotmail dot fr
  Target Milestone: ---

Created attachment 46352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46352&action=edit
stderr output of 'gcc -v -c bug.c'

I have recently found a way to generate internal compiler errors with this
simple 2 line code snippet:
extern int alias __attribute__((alias("target")));
extern int alias __attribute__((section(".custom")));

While I admit that this minimal non-working example is useless (and would
generate a compile time error anyway), the exact same bug also occurs inside
more meaningful code with weak aliases inside custom sections, or just when
repeating the same alias declaration twice:

int target __attribute__((section(".custom")));
extern int alias __attribute__((alias("target"),section(".custom")));
extern int alias __attribute__((alias("target"),section(".custom")));

At least versions 10.0 (Debian 20190508-1), 8.3 and 6.3 are affected, 4.9 isn't
and compiles successfully the second code snippet above.
You can see as attachment the full error message with version 10 after
executing 'gcc -v -c bug.c', where bug.c is a file containing the second code
snippet (exact same output for the first one, apart from code quoting).

[Bug c/89410] [7/8 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1237 after #line

[jg at jguk dot org]

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

--- Comment #23 from Jonny Grant  ---
(In reply to Segher Boessenkool from comment #22)
> #line 0   isn't valid C code.  If it causes problems we should just
> error on it (and perhaps even when it doesn't (yet) cause problems).

Would it be better if I created a separate PR for this?  #line 0  ?

[Bug d/88238] libphobos compile problems on Solaris 10

[ibuclaw at gdcproject dot org]

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

--- Comment #7 from Iain Buclaw  ---
On Thu, 9 May 2019 at 20:11, ro at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88238
>
> Rainer Orth  changed:
>
>What|Removed |Added
> 
>   Attachment #46309|0   |1
> is obsolete||
>
> --- Comment #6 from Rainer Orth  ---
> Created attachment 46331
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46331&action=edit
> Fix libphobos compilation on Solaris 10 (PR d/88238)
>
> Apart from a few cleanups and minor bug fixes, this patch adds to the previous
> version a workaround for the lack of dl_iterate_phdr in 64-bit Solaris 
> 10/SPARC
> libdl.  The function is missing simply due to a packaging mistake: it actually
> lives in ld.so.1, libdl.so.1 only being a filter on that.  Since one cannot
> link
> to ld.so.1 directly and getting at dl_iterate_phdr using dlsym fails due to
> another
> bug, I'm again using a libgdc_s.so.1 helper library which implements that
> filter.
>
> Since it uses a Solaris ld-specific linker map file, it can only be built with
> ld directly, not the linker gcc was configured with, and thus not with 
> libtool.
> The patch consists primarily of additions to 
> DRUNTIME_LIBRARIES_DL_ITERATE_PHDR
> to detect the situation, the mapfile and libdruntime/Makefile.am code to 
> create
> the helper lib.
>

Is a helper library really needed?  I think I'd prefer it to go in any
of the existing libraries already built instead of adding more things
to link in.

> It was tested on sparc-sun-solaris2.10 and sparc-sun-solaris2.11 and as in the
> x86 case, testsuite results between the two are now almost identical.
>

Nice.

[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation

[sbergman at redhat dot com]

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

Stephan Bergmann  changed:

   What|Removed |Added

 CC||sbergman at redhat dot com

--- Comment #10 from Stephan Bergmann  ---
(In reply to Jason Merrill from comment #8)
> Author: jason
> Date: Wed Apr  3 20:12:00 2019
> New Revision: 270136
> 
> URL: https://gcc.gnu.org/viewcvs?rev=270136&root=gcc&view=rev
> Log:
>   PR c++/86586 - -fcompare-debug=-Wsign-compare.
> 
> This patch limits constexpr folding for -Wsign-compare to only cases that we
> would warn for without considering constant values, avoiding the folding in
> the testcase in question.

Starting with that commit,

  constexpr int f() { return 0; }
  bool b = f() != 0xU;

now emits a -Wsign-compare, while the similar

  constexpr int f() { return 0; }
  constexpr int n = f();
  bool b = n != 0xU;

still does not.

I assume that is an unintended regression?

[Bug tree-optimization/90460] Inefficient vector construction from pieces

[kretz at kde dot org]

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

--- Comment #1 from Matthias Kretz  ---
PR85048 and PR77399 are related

[Bug c++/90462] Internal compiler error with deprecated-copy and json diagnostics

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
The example reported here is fixed in 9.1.0, if you have a different example
maybe there's a different problem.

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

[hedayat.fwd at gmail dot com]

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

--- Comment #10 from Hedayat Vatankhah  ---
Isn't it expected to be fixed in Gcc 9.1.1? It seems to still affect GCC 9.1.1
(Fedora 30)

[Bug c/90469] New: -ftree-vrp optimizaion causes 'signed overflow' and 'unreachable code' assumptions without warning.

[prg.j.a.h at centrum dot cz]

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

Bug ID: 90469
   Summary: -ftree-vrp optimizaion causes 'signed overflow' and
'unreachable code' assumptions without warning.
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prg.j.a.h at centrum dot cz
  Target Milestone: ---

Compiling with and without -ftree-vrp produces different code. Although the
code mixes signed and unsigned conversions and the code is disputable I think
that the compiler should at least issue warnings. e.g. "warning: assuming
signed overflow does not occur when assuming that X < (c - Y) is always false
[-Wstrict-overflow]" and "warning: expression is always true..."

The discussed code is in the conversion.c:
```
#include 
#include 

bool convert(int32_t *ptr_data, int32_t offset_f);

bool convert(int32_t *ptr_data, int32_t offset_f)
{
  bool result = false;

  uint32_t data_uns = *((uint32_t*)ptr_data);

  if (offset_f >= 0)
  {
// TODO
  }
  else
  {
if (data_uns <= (uint32_t)(INT32_MAX - offset_f))
{
  result = true;
  *ptr_data = (int32_t)data_uns + offset_f;
}
  }

  return result;
}
```

"Unit" test:
```
#include 
#include 
#include 

extern bool convert(int32_t *ptr_data, int32_t offset_f);

int main(void)
{
  int32_t data = -300;
  int32_t offset = -INT32_MAX;
  const int32_t expected_data = 2147483349;
  const bool expected_result = true;

  bool result = convert(&data, offset);

  printf("Data: %d ?= %d\n", data, expected_data);
  printf("Result: %s ?= %s\n", result ? "true" : "false", expected_result ?
"true" : "false");

  return 0;
}
```

The code is compiled with command:
- for X86 gcc 8.3.0:
gcc-8 -std=c99 -save-temps=obj -O3 -Wall -Werror -o conversion.c.obj -c
conversion.c
gcc-8 -std=c99 -O3 -o main main.c conversion.c.obj

- for ARM cortex-m7 gcc 8.2.1:
arm-none-eabi-gcc -std=c99 -mthumb -mcpu=cortex-m7 -save-temps=obj -O3 -Wall
-Werror -o conversion.c.obj -c conversion.c

Workaround:
- option 1: replace 'if (data_uns <= (uint32_t)(INT32_MAX - offset_f))' with
'if (data_uns <= ((uint32_t)INT32_MAX - (uint32_t)offset_f))'
- option 2: use -fno-tree-vrp
- it works on gcc 7.3.0 (x86) and gcc 7.3.1 (arm)

The dissassembly for x86:
```
--- bad-x86.s   2019-05-13 17:20:19.655385900 +0200
+++ good-x86.s  2019-05-13 17:20:58.491385900 +0200
@@ -6,23 +6,25 @@
 convert:
 .LFB0:
.cfi_startproc
xorl%eax, %eax
testl   %esi, %esi
js  .L6
 .L1:
ret
.p2align 4,,10
.p2align 3
 .L6:
-   movl(%rdi), %edx
-   testl   %edx, %edx
-   js  .L1
-   addl%edx, %esi
+   movl$2147483647, %edx
+   movl(%rdi), %ecx
+   subl%esi, %edx
+   cmpl%ecx, %edx
+   jb  .L1
+   addl%ecx, %esi
movl$1, %eax
movl%esi, (%rdi)
ret
.cfi_endproc
 .LFE0:
.size   convert, .-convert
.ident  "GCC: (Ubuntu 8.3.0-6ubuntu1~18.04) 8.3.0"
.section.note.GNU-stack,"",@progbits
```

Disassembly for ARM:
```
--- bad-st.s2019-05-13 17:17:40.345885900 +0200
+++ good-st.s   2019-05-13 17:18:31.964385900 +0200
@@ -22,21 +22,23 @@
 convert:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r1, #0
blt .L6
 .L4:
movsr3, #0
mov r0, r3
bx  lr
 .L6:
-   ldr r3, [r0]
-   cmp r3, #0
-   blt .L4
-   add r1, r1, r3
+   mvn r3, #-2147483648
+   ldr r2, [r0]
+   subsr3, r3, r1
+   cmp r3, r2
+   bcc .L4
+   add r1, r1, r2
movsr3, #1
str r1, [r0]
mov r0, r3
bx  lr
.size   convert, .-convert
.ident  "GCC: (GNU Tools for Arm Embedded Processors 8-2018-q4-major)
8.2.1 20181213 (release) [gcc-8-branch revision 267074]"
```

[Bug libstdc++/90454] filesystem::path template constructor void* overload interference

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Please leave it open.

[Bug c++/90459] gcc-arm-none-eabi-8-2018-q4-major

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Earnshaw  ---
You've asked for both -p (prof format) and -pg (gprof) format profiling at the
same time.  I don't think you can have both - just pick one or the other.

[Bug c++/90468] Documentation: typo in the part that tells whether the positive or the negative form of an option is documented

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is correct as written.

[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
(In reply to krux from comment #18)
> (In reply to Iain Sandoe from comment #14)
> > current trunk (27), manual regeneration of the
> > firmware.elf.ltrans0.ltrans.o ->
> > 
> > (it's kinda frustrating that one can't see the link line, more tweaks are
> > still needed to help debug LTO
> 
> Tell me about it. The first time I tried -save-temps I expected
> firmware.elf.ltrans0.o to be compiled from firmware.elf.ltrans0.s of course.
> But it's not, -v shows the .s file is compiled to
> firmware.elf.ltrans0.ltrans.o and I still don't really know what the other
> one is.
> Some commandlines seem to be missing (and it's hard to find them in the
> verbose output, maybe some color could help) in the verbose output and the
> temporary files are gone already.

That's been fixed for collect2, and I'm testing (right now) a patch to fix it
for
the linker plugin.

For the record there's a somewhat magical incantation that should work even
now:

-Wl,-plugin-opt=-debug

(but the patch under test is to enable -save-temps to do the Usual Thing).

[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO

[hoganmeier at gmail dot com]

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

--- Comment #18 from krux  ---
(In reply to Iain Sandoe from comment #14)
> current trunk (27), manual regeneration of the
> firmware.elf.ltrans0.ltrans.o ->
> 
> (it's kinda frustrating that one can't see the link line, more tweaks are
> still needed to help debug LTO

Tell me about it. The first time I tried -save-temps I expected
firmware.elf.ltrans0.o to be compiled from firmware.elf.ltrans0.s of course.
But it's not, -v shows the .s file is compiled to firmware.elf.ltrans0.ltrans.o
and I still don't really know what the other one is.
Some commandlines seem to be missing (and it's hard to find them in the verbose
output, maybe some color could help) in the verbose output and the temporary
files are gone already.

[Bug libstdc++/90454] filesystem::path template constructor void* overload interference

[patrick.a.moran at gmail dot com]

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

--- Comment #4 from Patrick Moran  ---
I just did a clean build of gcc with the change linked from ViewVC and
confirmed that my reproduction is fixed. Thank you.

I admit I'm uncertain of the etiquette regarding this ticket itself - I'm not
changing the status yet in case that would mess with release management
conventions, but I can confirm that the patch fixes the reported issue.  If I
should mark as "RESOLVED", I'm happy to do so.

[Bug libgcc/86215] Exceptions are broken on OSX when linking with -static-libgcc

[simon at pushface dot org]

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

--- Comment #5 from simon at pushface dot org ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc-9.1.0/bin/../libexec/gcc/x86_64-apple-darwin15/9.1.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with: /Volumes/Miscellaneous/tmp/gcc-9.1.0/configure
--prefix=/Volumes/Miscellaneous/tmp/opt/gcc-9.1.0 --without-libiconv-prefix
--disable-libmudflap --disable-libstdcxx-pch --disable-libsanitizer
--disable-libcc1 --disable-libcilkrts --disable-multilib --disable-nls
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --host=x86_64-apple-darwin15
--target=x86_64-apple-darwin15 --build=x86_64-apple-darwin15
--with-boot-ldflags='-static-libstdc++ -static-libgcc
-Wl,-headerpad_max_install_names'
Thread model: posix
gcc version 9.1.0 (GCC) 


$ g++ demo.cc -static-libgcc -static-libstdc++
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/opt/gcc-9.1.0/bin/../lib/gcc/x86_64-apple-darwin15/9.1.0/../../../libstdc++.a(new_opvnt.o)'
to global weak symbol 'operator new[](unsigned long, std::nothrow_t const&)'
from file
'/opt/gcc-9.1.0/bin/../lib/gcc/x86_64-apple-darwin15/9.1.0/../../../libstdc++.a(new_opvnt.o)'
means the weak symbol cannot be overridden at runtime. This was likely caused
by different translation units being compiled with different visibility
settings.ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/opt/gcc-9.1.0/bin/../lib/gcc/x86_64-apple-darwin15/9.1.0/../../../libstdc++.a(new_opvnt.o)'
to global weak symbol 'operator new[](unsigned long, std::nothrow_t const&)'
from file
'/opt/gcc-9.1.0/bin/../lib/gcc/x86_64-apple-darwin15/9.1.0/../../../libstdc++.a(new_opvnt.o)'
means the weak symbol cannot be overridden at runtime. This was likely caused
by different translation units being compiled with different visibility
settings.


$ otool -L a.out
a.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1252.250.1)


$ DYLD_PRINT_LIBRARIES=1 ./a.out
dyld: loaded: /Users/simon/tmp/bugs/86215/./a.out
dyld: loaded: /usr/lib/libSystem.B.dylib
dyld: loaded: /usr/lib/system/libcache.dylib
dyld: loaded: /usr/lib/system/libcommonCrypto.dylib
dyld: loaded: /usr/lib/system/libcompiler_rt.dylib
dyld: loaded: /usr/lib/system/libcopyfile.dylib
dyld: loaded: /usr/lib/system/libcorecrypto.dylib
dyld: loaded: /usr/lib/system/libdispatch.dylib
dyld: loaded: /usr/lib/system/libdyld.dylib
dyld: loaded: /usr/lib/system/libkeymgr.dylib
dyld: loaded: /usr/lib/system/liblaunch.dylib
dyld: loaded: /usr/lib/system/libmacho.dylib
dyld: loaded: /usr/lib/system/libquarantine.dylib
dyld: loaded: /usr/lib/system/libremovefile.dylib
dyld: loaded: /usr/lib/system/libsystem_asl.dylib
dyld: loaded: /usr/lib/system/libsystem_blocks.dylib
dyld: loaded: /usr/lib/system/libsystem_c.dylib
dyld: loaded: /usr/lib/system/libsystem_configuration.dylib
dyld: loaded: /usr/lib/system/libsystem_coreservices.dylib
dyld: loaded: /usr/lib/system/libsystem_darwin.dylib
dyld: loaded: /usr/lib/system/libsystem_dnssd.dylib
dyld: loaded: /usr/lib/system/libsystem_info.dylib
dyld: loaded: /usr/lib/system/libsystem_m.dylib
dyld: loaded: /usr/lib/system/libsystem_malloc.dylib
dyld: loaded: /usr/lib/system/libsystem_networkextension.dylib
dyld: loaded: /usr/lib/system/libsystem_notify.dylib
dyld: loaded: /usr/lib/system/libsystem_sandbox.dylib
dyld: loaded: /usr/lib/system/libsystem_secinit.dylib
dyld: loaded: /usr/lib/system/libsystem_kernel.dylib
dyld: loaded: /usr/lib/system/libsystem_platform.dylib
dyld: loaded: /usr/lib/system/libsystem_pthread.dylib
dyld: loaded: /usr/lib/system/libsystem_symptoms.dylib
dyld: loaded: /usr/lib/system/libsystem_trace.dylib
dyld: loaded: /usr/lib/system/libunwind.dylib
dyld: loaded: /usr/lib/system/libxpc.dylib
dyld: loaded: /usr/lib/libobjc.A.dylib
dyld: loaded: /usr/lib/libc++abi.dylib
dyld: loaded: /usr/lib/libc++.1.dylib
abc123


NB, this GCC was built for darwin15, run on darwin18.

[Bug c++/90468] New: Documentation: typo in the part that tells whether the positive or the negative form of an option is documented

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90468
   Summary: Documentation: typo in the part that tells whether the
positive or the negative form of an option is
documented
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

From the manual:

  Each of these specific warning options also has a negative form beginning
  ‘-Wno-’ to turn off warnings; for example, -Wno-implicit.

This is missing "with" after "beginning".

[Bug c++/90467] New: Documentation: many warning options that are enabled by default are documented in the -Woption form, not -Wno-option

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90467
   Summary: Documentation: many warning options that are enabled
by default are documented in the -Woption form, not
-Wno-option
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

From the manual (emphasis mine):

  Each of these specific warning options also has a negative form
  beginning ‘-Wno-’ to turn off warnings; for example, -Wno-implicit.
  This manual lists only one of the two forms, *whichever is not the
  default*.

However, several warning options that are enabled by default are documented in
the positive form, e.g. -Wif-not-aligned.

Should I try to provide a list of such options? Or the issue just isn't worth
it?

[Bug c++/90466] New: Documentation: -Wconversion-extra not documented

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90466
   Summary: Documentation: -Wconversion-extra not documented
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

The option -Wconversion-extra, appearing in the output of

  g++ -Q --help=warnings | fgrep conversion

is not documented. Is this intentional?

[Bug c++/90465] New: Documentation: one of the meanings of -Q not described

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90465
   Summary: Documentation: one of the meanings of -Q not described
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

From the manual:

  -Q
  Makes the compiler print out each function name as it is compiled, and
  print some statistics about each pass when it finishes.

This does not include the (overloaded) meaning of -Q when it precedes
--help=option.

I propose to add the following to the description:

  "(For another meaning of the option, see --help=option.)"

[Bug c++/90464] New: Documentation: incorrect description of -Wunused

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90464
   Summary: Documentation: incorrect description of -Wunused
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

The documentation for the -Wunused option says:

  "All the above -Wunused options combined". (1)

This would include -Wunused-const-variable, which means
-Wunused-const-variable=2. The latter, however, must be explicitly requested
and is not enabled when -Wunused is enabled.

I propose to change (1) to:

  "All the above -Wunused options combined, except those for which this manual
says they must be explicitly requested."

[Bug c++/90463] New: Documentation: -Wunused not listed among the options enabled by -Wall

[gennaro.prota+gccbugzilla at gmail dot com]

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

Bug ID: 90463
   Summary: Documentation: -Wunused not listed among the options
enabled by -Wall
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gennaro.prota+gccbugzilla at gmail dot com
  Target Milestone: ---

The documentation for the -Wunused option says

  "note that -Wall implies -Wunused"

however the list of options enabled by -Wall does not include -Wunused (only
some of the various -Wunused-xyz options).

With g++ 7.4.0 under Cygwin:

g++ -Wall -Q --help=warnings | fgrep unused

  -Wunused  [enabled]
  -Wunused-but-set-parameter[disabled]
  -Wunused-but-set-variable [enabled]
  -Wunused-const-variable
  -Wunused-const-variable=  1
  -Wunused-dummy-argument   [disabled]
  -Wunused-function [enabled]
  -Wunused-label[enabled]
  -Wunused-local-typedefs   [enabled]
  -Wunused-macros   [disabled]
  -Wunused-parameter[disabled]
  -Wunused-result   [enabled]
  -Wunused-value[enabled]
  -Wunused-variable [enabled]

[Bug c/77817] -Wimplicit-fallthrough: cpp directive renders FALLTHRU comment ineffective

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||gcc-bugs at engestrom dot ch

--- Comment #19 from Eric Gallager  ---
*** Bug 90457 has been marked as a duplicate of this bug. ***

[Bug c/90457] -Wimplicit-fallthrough seems confused by #ifdef

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
dup of bug 77817

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

[Bug c++/90462] New: Internal compiler error with deprecated-copy and json diagnostics

[schopf.dan at gmail dot com]

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

Bug ID: 90462
   Summary: Internal compiler error with deprecated-copy and json
diagnostics
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schopf.dan at gmail dot com
  Target Milestone: ---

Created attachment 46351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46351&action=edit
source code which crashes

When using the new json diagnostics output there is an internal
compiler error due to a deprecated-copy warning. The original 
issue has been found in the Boost regex library, I have used
creduce to create a minimal test case.

It can be reproduced with GCC 9.1.0 and the attached code using
this command line:

$ g++ -Wdeprecated-copy -fdiagnostics-format=json deprecated-copy-crash.cc

Internal compiler error: Error reporting routines re-entered.
0x7f49dce76e4a __libc_start_main
../csu/libc-start.c:308



The regular text output works as expected:

$ g++ -Wdeprecated-copy -fdiagnostics-format=text deprecated-copy-crash.cc
...
deprecated-copy-crash.cc: In instantiation of ‘void h<
,  >::o(const i*, const i*,
unsigned int) [with i = char;  = int]’:
deprecated-copy-crash.cc:22:5:   required from ‘void b<
 >::assign() [with i = char]’
deprecated-copy-crash.cc:28:12:   required from ‘s& s >::p(const i*, const i*, f::g) [with i = char;
 = e; f::g = int]’
deprecated-copy-crash.cc:45:77:   required from here
deprecated-copy-crash.cc:43:5: warning: implicitly-declared ‘constexpr G&
G::operator=(const G&)’ is deprecated [-Wdeprecated-copy]
   43 |   a = r();
deprecated-copy-crash.cc:33:3: note: because ‘G’ has user-provided ‘G::G(G&)’
   33 |   G(G &);
  |   ^
...


Problem also seems to be reproducible on trunk: https://godbolt.org/z/5aT3K1

[Bug libstdc++/90440] [8/9 regression] Solaris/SPARC 10 fails to find

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

Summary|[8/9/10 regression] |[8/9 regression]
   |Solaris/SPARC 10 fails to   |Solaris/SPARC 10 fails to
   |find  |find 

--- Comment #11 from Rainer Orth  ---
Removing gcc 10 from the summary: Solaris 10 support is just being dropped.

[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from Jonathan Wakely  ---
> We just use the AC_PROG_LN_S test from autoconf, see
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html#index-AC_005fPROG_005fLN_005fS-287
>
> Ideally that test would detect the problem and force LN_S="cp -pR" instead of
> using symlinks.
>
> But I'm not sure it's worth adding anything if the problem is limited to GNU
> coreutils 8.31 on Solaris 10, as that OS is obsolete and most of its users are
> going to use Solaris ln anyway.

Indeed: I'd claim that this is just a waste of time.

[Bug c++/90458] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-14
 CC||law at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with Jeff's r252998.

[Bug fortran/90461] New: [F18] Allow opening same file on separate units

[jb at gcc dot gnu.org]

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

Bug ID: 90461
   Summary: [F18] Allow opening same file on separate units
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

Fortran 2018 removes the restriction that a file can be opened only on one unit
at a time.

[Bug libstdc++/69724] Unnecessary temporary object during std::thread construction

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
I'm leaving this open until std::async is changed too.

[Bug libstdc++/69724] Unnecessary temporary object during std::thread construction

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue May 14 12:01:15 2019
New Revision: 271166

URL: https://gcc.gnu.org/viewcvs?rev=271166&root=gcc&view=rev
Log:
PR libstdc++/69724 avoid temporary in std::thread construction

The std::thread constructor creates (and then moves) an unnecessary
temporary copy of each argument. Optimize it to only make the one copy
that is required.

PR libstdc++/69724
* include/std/thread (thread::_State_impl, thread::_S_make_state):
Replace single _Callable parameter with variadic _Args pack, to
forward them directly to the tuple of decayed copies.
* testsuite/30_threads/thread/cons/69724.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/30_threads/thread/cons/69724.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread

[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example

[thanm at google dot com]

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

--- Comment #34 from Than McIntosh  ---
GCC 8 and 9 branches -- I'll do that experiment later this morning. It's worth
noting that if the code in questing uses more modern Go constructs (things
introduced in Go 1.11/1.12) it may not compile properly, but I will at least
give it a shot.

[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Tue May 14 11:43:55 2019
New Revision: 271164

URL: https://gcc.gnu.org/viewcvs?rev=271164&root=gcc&view=rev
Log:
Reapply r270597.

2019-05-14  Paolo Carlini  

PR preprocessor/90382
* decl.c (grokdeclarator): Fix value assigned to typespec_loc, use
min_location.
2019-05-14  Paolo Carlini  

PR preprocessor/90382
* g++.dg/diagnostic/trailing1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/trailing1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Tue May 14 11:41:40 2019
New Revision: 271162

URL: https://gcc.gnu.org/viewcvs?rev=271162&root=gcc&view=rev
Log:
Do a refactoring in linemap (PR preprocessor/90382).

2019-05-14  Martin Liska  

PR preprocessor/90382
* include/line-map.h (get_data_from_adhoc_loc): Add const to
the first argument.
(get_location_from_adhoc_loc): Likewise.
* line-map.c(get_data_from_adhoc_loc):  Add const to
the first argument.
(get_location_from_adhoc_loc): Likewise.
(get_combined_adhoc_loc): Use get_location_from_adhoc_loc
(or get_data_from_adhoc_loc).
(get_range_from_adhoc_loc): Likewise.
(get_pure_location): Likewise.
(linemap_position_for_loc_and_offset): Likewise.
(linemap_lookup): Likewise.
(linemap_ordinary_map_lookup): Likewise.
(linemap_macro_map_lookup): Likewise.
(linemap_get_expansion_line): Likewise.
(linemap_get_expansion_filename): Likewise.
(linemap_location_in_system_header_p): Likewise.
(linemap_location_from_macro_expansion_p): Likewise.
(linemap_macro_loc_to_exp_point): Likewise.
(linemap_resolve_location): Likewise.
(linemap_unwind_toward_expansion): Likewise.
(linemap_unwind_to_first_non_reserved_loc): Likewise.
(linemap_expand_location): Likewise.
(linemap_dump_location): Likewise.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Tue May 14 11:41:53 2019
New Revision: 271163

URL: https://gcc.gnu.org/viewcvs?rev=271163&root=gcc&view=rev
Log:
Fix min_location usage in line-map.c (PR preprocessor/90382).

2019-05-14  Martin Liska  

PR preprocessor/90382
* line-map.c (first_map_in_common_1): Handle ADHOC
locations.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug tree-optimization/90460] New: Inefficient vector construction from pieces

[rguenth at gcc dot gnu.org]

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

Bug ID: 90460
   Summary: Inefficient vector construction from pieces
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Split out from PR90424

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

template 
V load(const void *p) {
  const T* q = static_cast(p);
  V r = {q[I]...};
  return r;
}

// movq or movsd
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);

// movd or movss
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);


ends up with IL like

load (const void * p)
{
  V r;
  int _1;
  int _2;

   [local count: 1073741824]:
  _1 = MEM[(const int *)p_3(D)];
  _2 = MEM[(const int *)p_3(D) + 4B];
  r_5 = {_1, _2};
  return r_5;

which looks like a job for bswap.

[Bug target/90424] memcpy into vector builtin not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Matthias Kretz from comment #2)
> I can't read the SSA code with certainty, but bit-inserting sounds like what
> I want to have. Alternatively, the partial vector load could be implemented
> like this - and looks even worse (https://godbolt.org/z/nJuTn-):
> template 
> using V [[gnu::vector_size(16)]] = T;
> 
> template 
> V load(const void *p) {
>   const T* q = static_cast(p);
>   V r = {q[I]...};
>   return r;
> }
> 
> // movq or movsd
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);
> 
> // movd or movss
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);
> template V load(const void *);

Those end up like

load (const void * p)
{
  V r;
  int _1;
  int _2;

   [local count: 1073741824]:
  _1 = MEM[(const int *)p_3(D)];
  _2 = MEM[(const int *)p_3(D) + 4B];
  r_5 = {_1, _2};
  return r_5;

it's not immediately clear where to optimize this - the loads would need to
be merged and the constructor adjusted to one from vectors.  The bswap
pass looks like a good candidate for this.  Split out to PR90460,

[Bug c++/90459] New: gcc-arm-none-eabi-8-2018-q4-major

[javier.ruano at edu dot uah.es]

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

Bug ID: 90459
   Summary: gcc-arm-none-eabi-8-2018-q4-major
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: javier.ruano at edu dot uah.es
  Target Milestone: ---

From Eclipse
Building target: Lancaster.elf
Invoking: GNU ARM Cross C++ Linker
arm-none-eabi-g++ -mcpu=cortex-a9 -mthumb -mfloat-abi=hard -O0
-fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -p
-pg -Xlinker --gc-sections -Wl,-Map,"Lancaster.map" -o "Lancaster.elf" 
./src/PCA.o ./src/main.o   
gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld:
cannot find -lc_p-lc_p
makefile:57: recipe for target 'Lancaster.elf' failed
collect2: error: ld returned 1 exit status
make: *** [Lancasterelf] Error 1
"make all" terminated with exit code 2. Build might be incomplete.

[Bug target/90424] memcpy into vector builtin not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
One complication is that V2SFmode isn't valid on the target so at least
lowpart sets of V4SFmode are not easily possible (stupid MMX?), for
V8QImode we get a corresponding integer mode which works in the end.

The thing is that on GIMPLE we are already restricting the destination
vector type to supported ones when triggering SSA rewrite via
BIT_INSERT_EXPR.

This also makes writing target independent testcases for this hard :/

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #22 from Fredrik Hederstierna 
 ---
Was "max_ratio_for_size = 2" as default changed?
Also changing this to "1" did not by far reach size of gcc-8.2 unfortunately,
I guess we are assuming this code growth depends on other regression from other
changes?

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

--- Comment #23 from Martin Liška  ---
(In reply to Fredrik Hederstierna from comment #22)
> Was "max_ratio_for_size = 2" as default changed?

No.

> Also changing this to "1" did not by far reach size of gcc-8.2 unfortunately,

Note that the growth calculation is an estimation, so even with "1" there will
so growths and shrinks possible.

> I guess we are assuming this code growth depends on other regression from
> other changes?

You mean in switch expansion?

[Bug c++/90458] New: mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection

[qantas94heavy at gmail dot com]

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

Bug ID: 90458
   Summary: mingw64: ICE in i386_pe_seh_unwind_emit, at
config/i386/winnt.c:1258 with -fstack-clash-protection
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qantas94heavy at gmail dot com
  Target Milestone: ---

Created attachment 46350
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46350&action=edit
Preprocessed minimal test case

Forwarded from: https://github.com/msys2/MINGW-packages/issues/5348

When compiling the following C++ file with -fstack-clash-protection, the
following error results:

$ g++ -fstack-clash-protection test.cpp^
during RTL pass: final
test.cpp:12:1: internal compiler error: in i386_pe_seh_unwind_emit, at
config/i386/winnt.c:1258
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This does not occur without the flag enabled. Attached is the preprocessed
minimal test case.

$ g++ -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.3.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev2, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 8.3.0 (Rev2, Built by MSYS2 project)

[Bug libgcc/86215] Exceptions are broken on OSX when linking with -static-libgcc

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug libgcc/86215] Exceptions are broken on OSX when linking with -static-libgcc

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Sandoe  ---
I repeated this on gcc-7.4.1 (271140)

[Bug c/90457] New: -Wimplicit-fallthrough seems confused by #ifdef

[gcc-bugs at engestrom dot ch]

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

Bug ID: 90457
   Summary: -Wimplicit-fallthrough seems confused by #ifdef
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at engestrom dot ch
  Target Milestone: ---

Consider the following code:

```
int main(int argc, char *argv[])
{
  switch (argc)
  {
#ifdef HAVE_FOO
case 1:
  if (argv[1])
return 1;
  /* fallthrough */
#endif
default:
return 0;
  }
}
```

```
$ gcc -Wimplicit-fallthrough foo.c -o foo
```
As expected.

```
$ gcc -Wimplicit-fallthrough foo.c -o foo -DHAVE_FOO
foo.c: In function ‘main’:
foo.c:7:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
   if (argv[1])
  ^
foo.c:11:5: note: here
 default:
 ^~~
```
This warning should have been suppressed by the comment purposefully left
there.

The same code with the `#ifdef` & `#endif` lines removed behaves as expected
(warning without the comment, no warning with the comment).

It looks like GCC is getting confused by the presence of the #ifdef lines.

[Bug rtl-optimization/90378] [9/10 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Hi Maxim, have you made a progress? What you can do is to mix no-LTO and LTO
objects file which will nail down the issue to subset of LTO units needed.

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #21 from Martin Liška  ---
As explained in #c17, I'm closing that as resolved.

[Bug target/90424] memcpy into vector builtin not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
OK, so the "easier" way to allow aligned sub-vector inserts produces for

typedef unsigned char v16qi __attribute__((vector_size(16)));
v16qi load (const void *p)
{
  v16qi r;
  __builtin_memcpy (&r, p, 8);
  return r;
}

load (const void * p)
{
  v16qi r;
  long unsigned int _3;
  v16qi _5;
  vector(8) unsigned char _7;

   :
  _3 = MEM[(char * {ref-all})p_2(D)];
  _7 = VIEW_CONVERT_EXPR(_3);
  r_9 = BIT_INSERT_EXPR ;
  _5 = r_9;
  return _5;

and unfortunately (as I feared)

load:
.LFB0:
.cfi_startproc
movq(%rdi), %rax
pxor%xmm1, %xmm1
movaps  %xmm1, -24(%rsp)
movq%rax, -24(%rsp)
movdqa  -24(%rsp), %xmm0
ret

via expanding to

(insn 8 7 9 2 (set (subreg:V8QI (reg:V16QI 89 [ r ]) 0)
(subreg:V8QI (reg:DI 88) 0)) "t.c":5:3 -1
 (nil))

RAed from

(insn 8 7 13 2 (set (subreg:V8QI (reg:V16QI 89 [ r ]) 0)
(mem:V8QI (reg:DI 90) [0 MEM[(char * {ref-all})p_2(D)]+0 S8 A8]))
"t.c":5:3 1088 {*movv8qi_internal}
 (expr_list:REG_DEAD (reg:DI 90)
(nil)))


It's still IMHO the most reasonable IL given the vector constructors
we allow.

Inserting 4 bytes is even worse though.  Inserting upper 8 bytes is
like the above.

Code generation isn't worse than unpatched and the GIMPLE is clearly
better (allowing for followup optimizations).

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
Author: marxin
Date: Tue May 14 10:00:53 2019
New Revision: 271156

URL: https://gcc.gnu.org/viewcvs?rev=271156&root=gcc&view=rev
Log:
Fix a test-case in PR middle-end/90340.

2019-05-14  marxin  

PR middle-end/90340
* gcc.dg/tree-ssa/pr90340-2.c: Add case-values-threshold
param.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr90340-2.c

[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška  ---
(In reply to Christophe Lyon from comment #18)
> The new test fails on aarch64:
> FAIL: gcc.dg/tree-ssa/pr90340-2.c scan-tree-dump switchlower1 ";; GIMPLE
> switch case clusters: 37 88 99 100 105 110 111 115 117 120"
> 
> I compiled the testcase manually, and I can read:
> ;; GIMPLE switch case clusters: 37 88 99 100 105 JT:110-117 120

Sorry for breakage, should be fixed now.