[Bug target/88630] Incorrect float negating together with convertion to int on SH4

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 CC||olegendo at gcc dot gnu.org

--- Comment #6 from Oleg Endo  ---
(In reply to Zavadovsky Yan from comment #3)
> Created attachment 45301 [details]
> main820.s: assembler output from GCC-8.2.0

I have tried to reproduce the same problem here on trunk but with a non-linux
sh-elf toolchain.

Compiling  attachment 45299 with
  sh-elf-gcc -x c -m4 -ml -Os -save-temps -fexceptions sh_tmp.cpp

results in the same code as your GCC-8-2.0.  There seems nothing wrong with the
code that is generated for function NegateFloatToInt.

Running it with sh-sim produces the expected result.

Yes, there have been some changes how fpscr is handled, but that shouldn't have
any effect.  In both cases (GCC 4.9 and GCC 8) what it does is switching the
FPU mode from the default double-precision to single-precision before the
execution of the ftrc instruction.  And then back to double-precision before
the function returns.

The difference is that in GCC 4.9, the fpscr switch is done before fneg and
later it's done after fneg.  That is OK because fneg does not use and does not
modify any of the fpscr bits.

Are you testing this on real hardware or on some emulator/simulator?



BTW, your posted disassembly doesn't seem to match the actual source that you
have posted.  The assert doesn't check for value -12 but instead for the value
123:

mov r8,r0
cmp/eq  #123,r0
bt  .L6

And the float constant in the code 3270901760 is -123.0f

I have tried to replace the 12 with the 123 but it doesn't trigger any problem
either of course.

[Bug rtl-optimization/91931] New: [10 Regression] ICE in decompose, at rtl.h:2277

[asolokha at gmx dot com]

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

Bug ID: 91931
   Summary: [10 Regression] ICE in decompose, at rtl.h:2277
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-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-alpha20190922 snapshot (r276031) ICEs when compiling
gcc/testsuite/gcc.dg/vect/pr32216.c w/ -mavx -O1 -ftree-loop-vectorize:

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190922 -mavx -O1
-ftree-loop-vectorize -c gcc/testsuite/gcc.dg/vect/pr32216.c
during RTL pass: expand
gcc/testsuite/gcc.dg/vect/pr32216.c: In function 'SetSoundVariables':
gcc/testsuite/gcc.dg/vect/pr32216.c:11:17: internal compiler error: in
decompose, at rtl.h:2277
   11 | wlookup2[x] = (double) 16 / x;
  | ^
0x688272 wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/rtl.h:2277
0x688272 wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/wide-int.h:1022
0x688272 generic_wide_int
>::generic_wide_int >(std::pair const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/wide-int.h:782
0x688272 native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/simplify-rtx.c:6210
0xd40ada native_encode_rtx(machine_mode, rtx_def*, vec&, unsigned int, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/simplify-rtx.c:6180
0xd4c051 simplify_const_vector_subreg
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/simplify-rtx.c:6529
0xd4c051 simplify_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/simplify-rtx.c:6643
0xd4cdae simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, poly_int<1u,
unsigned long>)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/simplify-rtx.c:6873
0xd12693 gen_lowpart_general(machine_mode, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/rtlhooks.c:48
0x10d0fe3 ix86_expand_vector_logical_operator(rtx_code, machine_mode,
rtx_def**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/config/i386/i386-expand.c:999
0x141ab1a gen_andv8si3(rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/config/i386/sse.md:12944
0xc74be4 expand_binop_directly
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/optabs.c:1122
0xc727c2 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/optabs.c:1209
0x10d25cf ix86_expand_adjust_ufix_to_sfix_si(rtx_def*, rtx_def**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/config/i386/i386-expand.c:1699
0x13fc71b gen_vec_pack_ufix_trunc_v4df(rtx_def*, rtx_def*, rtx_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/config/i386/sse.md:7106
0xc74be4 expand_binop_directly
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/optabs.c:1122
0xc727c2 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/optabs.c:1209
0xa3b50b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/expr.c:9790
0xa28c41 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/expr.c:9993
0xa3807e expand_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190922/work/gcc-10-20190922/gcc/expr.h:281

[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition

[postmas...@trippelsdorf-de.bounceio.net]

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

--- Comment #9 from postmas...@trippelsdorf-de.bounceio.net ---
Created attachment 46976
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46976&action=edit
attachment-52942-1.eml

[Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition

[postmas...@trippelsdorf-de.bounceio.net]

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

--- Comment #8 from postmas...@trippelsdorf-de.bounceio.net ---
   Your email was bounced...
   -

   ... because something went wrong between you and your recipient. Ugh!


   What to do next?
   

   Well, your specific problem was a *5.1.2 * error.

   Which means you should: Check the "trippelsdorf.de" part of
   "mar...@trippelsdorf.de" for misspellings or missing letters. If you
   find an error, correct it in your contacts list or address book for
   next time.

   Or further: It is possible that the domain is temporarily inactive. If
   the spelling looks correct, contact your mail provider and if
   necessary, contact your recipient another way (e.g., phone or text
   message).

   Get more Bounce Intelligence ™ on 5.1.2 errors here![1]

   Thanks, have a lovely day.

   Yours truly, betterbounces.net[2]

   Rate this email: Helpful[3] :) or... Not Helpful[4] :(

   Advertisement | Prefer no ads?[5]

   YOU MIGHT LIKE

   [6]

   [7]

   [8]

   Learn more about RevenueStripe...[9]

   -

   © 2017 betterbounces.net, All rights reserved. Privacy[10]

   [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

   1.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CvthgAWSiSkVAq.Xh9KqEh0IIBaMeh2A6Zqsjph6KAZunV7ed1_vpngXZcB3cPzS6bZPGryGPm5DbVtqa8vn8sp11z5mu4xJrpb6MFkpr.YwdNH_ixiJQc7vTN6N6rBxKrIMnPDXXXz.kCd0EXtBAA1_2oX3K38wv_85UXzFOla6LYrU.dViNedLD7OK9stgDyCxeRW.imOyZ1kr60z0PkS6s5uVi4kH.Wpkjy0B_0IESGIr9PA9yvlNX0NU0ZeAzDlAWrk7Ry0Jpp3BLORpQmKsliDkA5czvVmF3tE2wFu6A--
   2.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_Cv9tYrf0dZuYQtiO9.kFZNq_4JoRDLf.3kJPtQ_X.ATaXcguetEUJBeda9ItrafeZNHTMPUQ_HnehmCpbP6BG7.xwa_gukynzZHNFjL2RRKzQUZDwgOcfQeuhkZ7n07bMFfoG0eII9.00VbC2sUEuUfo98PjjUAaWw-
   3.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CvthgAWSiSkVPKsg1edrIqpNl8XUjo5uK9MqX0F_8BTlk0XQkPFdnEphtt93P40cJsFrt1IYTRjV37vEn43k5R_Z0FowjKqeoGlb.8Za22MDuRzVdfyeCKWatj9sg0pamUqiUCG3YDkPj5m6u2__VNicFxchu8._GsejbbeQ3AaOEPhX9R5a_6guQLm1cKeJ6S1cfkiVDfPQMbECjzZ29.96ChhDLeZWMfAYpf6OPi2Kr8Kd94C06XNIYiv08D3K_U1fQ1TRl4DMOUBauTtHLQmmncEs5GlCYqyWIOQDlzO9WYXe0TbAW7o
   4.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CvthgAWSiSkVPKsg1edrIqpNl8XUjo5uK9MqX0F_8BTlk0XQkPFdnEphtt93P40cJsFrt1IYTRjV37vEn43k5R_Z0FowjKqeoGlb.8Za22MDuRzVdfyeCKWatj9sg0pamUqiUCG3YDkPj5m6u2__VNitlaDbWioSEtxxlQ4tG3MoAo1zGBukLj0MX8r6IcThHBNJW92YsgE1jth7GpaA9CDK0lP3.H_tKq_NGQ9P6FSiCJHVp.dzyqgjROBbE9G0kpdj.79oDi8HYiM_YnHnUWZige82dgPbiZW3tKTdch1twAw1cJAvVDGUaTt5RyMBqQ-
   5.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CuucUOtJWH8tH5Rg1hLC21dSKxJ7da9cTmyFWTvhu1lgyMS3FqP0WKAeBXkJyf8_DcZkZmjdyR2w3SCAZ25_gdCwkpDCyb4dkplrXGpCgHToFrm1WjHkddMKBkKf_hl5aaJEBJkHu7JpkoO.Tm.IoL_HbMxZBhGSrgKP0wCm7025tSP3V_Bzv8ivY5C_TG3Sy4zhaTnF.1CvN1ZC0WpPNgR2CqIiNRJV_RxW11JL.7Uqounb7lD01nYLLVW1RpgLaJ7ZUlQIapZqTaDJWUZwhV3vFgcBzir1QX2.ldNtKxjBJg6ZOJBNaQJCRDK8MCes8GKvv_5pM3ta1.rP_ts3mLPUTCnqEy5yTT31OmlOuBzMBrlISJshnhtOp50ydN3R58CiH7mm.rXuGQ2VbFkguep7Oml52gBCxoYEu2pIjwj0f_CH8XZCND6zHurIInfnTousRVi6LHwW4rpbuUShxo1Ny5wuMhxAHHPSIa1p5uj04974JzBRXJ4gOmguQxdWii.4GyPAw945baoHXYAQpCSz0cmc4KKoUWlb.8Za22MDuRzVdfyeCKWatj9sg0pamUqiUCG3YDkPi5B29w3qLPw
   6.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CtxsmdRK3bqiLI_DYCrQqeYl4X5YwBlEl5KCjMqCtZrvhoT2p2Zq8ISGeBG8dhNCgjnhvldbBa8A1o7sBlI70W8oDjZ.vezDYfJQSC938e6uO35tZsUcZN5p6EoGHj_juMYb49EUuZ7zgtwBhkzpX0DO8pUJGySoH.gMdRGcDdR5Tcskb1o5jBbaHUS2hbxrpDYlq9o_jJa3KbI.WmD0x4iNy5wuMhxAHHPSIa1p5uj04974JzBRXJ4gOmguQxdWii.4GyPAw945baoHXYAQpCSz0cmc4KKoUWlb.8Za22MDuRzVdfyeCKWatj9sg0pamUqiUCG3YDkPi5B29w3qLPw
   7.
https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsYz6BSAduUDUOX259ENsI7e3HBFe_L9qqkswLxxp.9W4Mz9nic1fEk3b_JEBlfwrWyjYIBRM6OLFt_OXq_MrKuT9FbPDZoBNzGNE4gztylPle8NHh464vf7InJwo.9V_CtxsmdRK3bqiLI_DYCrQqeYl4X5YwBlEl5KCjMqCtZrvhoT2p2Zq8ISGeBG8dhNCgjnhvldbBa8A1o7sBl

[Bug other/89860] liboffloadmic/runtime/offload_target.cpp:332]: (style) Array index 'i' is used before limits check.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iverbin at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
svn blame says Ilya Verbin wrote this code; cc-ing

[Bug plugins/86358] Plugin extension not stripped on Mac OS due to use of strip_off_ending()

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing Iain

[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Converting the FDPIC from bsrf back to jsr sounds like quite some work. 
However, I think chances of success are higher of it does the same thing as the
normal PIC code.

Do you know what the main reason was to use bsrf for FDPIC?  How does FDPIC
differ from regular PIC?

[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.

[bugdal at aerifal dot cx]

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

--- Comment #7 from Rich Felker  ---
I think all the FDPIC work done to use bsrf like this was probably a mistake.
It ends up greatly enlarging functions that make a lot of such calls, for
example soft-float that does it for each floating point operation. We actually
encountered this in production usage. I think the bulk of the FDPIC patch was
adding this stuff, and I wouldn't be opposed to removing all that (just
generating jsr) if we can determine that it fixes bugs and results in better
codegen.

[Bug target/89012] SH2 (FDPIC) duplicate symbols in generated assembly.

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #6 from Oleg Endo  ---
The ashlsi3_d_call insn, alternative 1 seems to be the problem here, but I
think the same problem could happen for all other libcalls that expand to a
bsrf sequence.

In this particular case, something in the optimizers decides that moving the
shift instruction out of the loop is a good idea.  To do that, it copies the
shift instruction only -- which is "ashlsi3_d_call", which is the bsrf plus the
following label.  The label is generated once during RTL expansion.

This works for normal PIC code which calculates the call address and puts it in
a register first.  This happens only once during RTL expansion and the address
remains fixed.  Subsequent copies of the shift instruction (which is just a
jsr) work, because they re-use the calculated address.

In case of FDPIC, the use of bsrf will always require a unique address/offset
in the symbols.  It can't just make arbitrary copies of the shift instruction
(which is a bsrf) because the pre-calculated address/offset will be wrong.


1) If not already there, something needs to be added that allows re-generating
the address/offset of the copied/cloned instruction and also re-emitting the
constant load.  This is probably not so easy to do, as instructions can be
copied in many places during the compilation.

2) Postpone the calculation and emission of symbols and constant loads until a
very late stage of the compilation using very late splitters.

3) Use jsr instead of bsrf in the compiler and let the linker post-optimize
calls via relaxation (although linker relaxation on SH has been broken for a
long time).


I don't know much about PIC/FDPIC, but one thing I've noticed looks strange.
The right-shift pattern "ashrsi3_n" will result in

bsrfr1  ! 268   [c=5 l=2]  call_valuei_pcrel
...

.long   ___ashrsi3@PLT-(.LPCS0+2-.)



While the left-shift pattern "ashlsi3_d_call" will result in

bsrfr6  ! 24[c=80 l=2]  ashlsi3_d_call/1
...

.long   ___ashlsi3_r0-(.LPCS0+2)

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Sep 29 02:35:58 2019
New Revision: 276265

URL: https://gcc.gnu.org/viewcvs?rev=276265&root=gcc&view=rev
Log:
2019-09-28  Jerry DeLisle  

PR fortran/91802
* decl.c (attr_decl1): Return MATCH_ERROR without free to avoid
bad expression type in free_expr0() ICE in rank+corank check.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c

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

[joey.dumont at gmail dot com]

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

--- Comment #6 from Joey Dumont  ---
Sorry for the delay, had trouble setting up the test toolchain. 

>From what I can see, this does not solve the issue. In fact, the generated
paralle_settings.ii is identical to the one generated before.

To test this, I compiled the d57faea9337 commit of gcc-git, which corresponds
to r273174 according to this commit message. I configured it with
--prefix=~/software-test/ and removed options with references to system
directories in the options listed above. Otherwise I kept the rest the same. To
compile the cross-compiler, I exported PATH and LD_LIBRARY_PATH, like so

export PATH="/home/valandil/software-test/bin:${PATH}"
export LD_LIBRARY_PATH="/home/valandil/software-test/lib:${PATH}"

and did the rest as usual.

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
namespace std {
template  class initializer_list {
  int *_M_array;
  unsigned long _M_len;

public:
  int *begin();
  int *end();
};
template  class A { void insert(initializer_list<_CharT>); };
} // namespace std

void s() {
  for (auto flag : {s})
;
}

[Bug c++/91867] Internal compiler error in simple for(auto) loop when using -std=c++11 with -fconcepts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/91930] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |10.0

[Bug c++/91930] New: [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:2423 with -fconcepts

[mpolacek at gcc dot gnu.org]

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

Bug ID: 91930
   Summary: [10 Regression] internal compiler error: in
lazily_declare_fn, at cp/method.c:2423 with -fconcepts
   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: ---

Trying to compile range-v3 with current trunk turned up this ICE.  Started with
r274534.

namespace std {
template  struct A { static constexpr _Tp value = __v;
};
template  using __bool_constant = A;
auto declval();
struct B {
  template  static __bool_constant __test(int);
};
template  struct __is_nt_destructible_impl : B {
  typedef decltype(__test<_Tp>(0)) type;
};
template 
struct is_nothrow_destructible : __is_nt_destructible_impl::type {};
} // namespace std
namespace meta {
namespace detail {
template  struct require_constant;
}
template  concept trait = requires {
  typename detail::require_constant;
};
template  using _t = T::type;
} // namespace meta

template 
concept destructible = std::is_nothrow_destructible::value;
template  concept constructible_from = destructible;
template  concept default_constructible = constructible_from;
namespace ranges {
template  struct static_const { static constexpr T value{}; };
namespace detail {
int as_const;
template  using as_const_t = decltype(as_const);
} // namespace detail
template  struct G;
namespace detail {
template  struct C;
}
template  using reverse_iterator = G>;
struct range_access {
  template  static T::mixin mixin_base_2_(int);
  template  struct mixin_base_ {
using type = decltype(mixin_base_2_(2));
  };
  template  using mixin_base_t = meta::_t>;
  auto read();
};
template  concept readable_cursor = requires { range_access::read; };
template  struct basic_mixin {
  basic_mixin() requires default_constructible;
};
namespace detail {
template  struct H : range_access::mixin_base_t {
  using range_access::mixin_base_t::mixin_base_t;
};
template 
using iterator_associated_types_base = H>;
} // namespace detail
template 
struct G : detail::iterator_associated_types_base {};
namespace detail {
template  struct C {
  struct mixin : basic_mixin {
using basic_mixin::basic_mixin;
  };
};
} // namespace detail
namespace _rbegin_ {
struct fn {
  struct D {
template  auto operator()(R r) noexcept(noexcept(r.rbegin()))
{}
  };
  template  using impl = D;
  template  auto operator()(R r) noexcept(noexcept(impl{}(r)))
{}
};
template  using _t = decltype(fn{});
} // namespace _rbegin_
auto rbegin = static_const<_rbegin_::fn>::value;
namespace _crbegin_ {
struct fn {
  template 
  _rbegin_::_t>
  operator()(R r) noexcept(noexcept(rbegin(r)));
};
} // namespace _crbegin_
auto crbegin = static_const<_crbegin_::fn>::value;
} // namespace ranges

struct F {
  using value_type = int;
  using const_iterator = value_type;
  using const_reverse_iterator = ranges::reverse_iterator;
  const_reverse_iterator rbegin();
};
template  auto test_crits(Sequence1234 a) {
  ranges::crbegin(a);
}

auto test_array() {
  F a;
  test_crits(a);
}

$ ./cc1plus -quiet r.C -std=c++2a -fconcepts
r.C: In instantiation of ‘struct ranges::detail::H,
false>’:
r.C:59:8:   required from ‘struct ranges::G >’
r.C:70:74:   required from ‘auto ranges::_rbegin_::fn::D::operator()(R) [with R
= F]’
r.C:73:73:   required from ‘auto ranges::_rbegin_::fn::operator()(R) [with R =
F]’
r.C:82:43:   required from ‘ranges::_rbegin_::_t
> ranges::_crbegin_::fn::operator()(R) [with R = F;
ranges::_rbegin_::_t > = ranges::_rbegin_::fn]’
r.C:95:18:   required from ‘auto test_crits(Sequence1234) [with Sequence1234 =
F]’
r.C:100:15:   required from here
r.C:53:42: internal compiler error: in lazily_declare_fn, at cp/method.c:2423
   53 |   using range_access::mixin_base_t::mixin_base_t;
  |  ^~~~
0xa16904 lazily_declare_fn(special_function_kind, tree_node*)
/home/marek/src/gcc/gcc/cp/method.c:2423
0xa1cfdf get_class_binding(tree_node*, tree_node*, bool)
/home/marek/src/gcc/gcc/cp/name-lookup.c:1286
0xb4431c lookup_field_r
/home/marek/src/gcc/gcc/cp/search.c:990
0xb45736 dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
/home/marek/src/gcc/gcc/cp/search.c:1430
0xb44b26 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
/home/marek/src/gcc/gcc/cp/search.c:1144
0xa2a533 do_class_using_decl(tree_node*, tree_node*)
/home/marek/src/gcc/gcc/cp/name-lookup.c:4651
0xae6c8f tsubst_decl
/home/marek/src/gcc/gcc/cp/pt.c:13720
0xae9b5a tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marek/src/gcc/gcc/cp/pt.c:14398
0xad9165 instantiate_class_template_1
/home/marek/src/gcc/gcc/cp/pt.c:11284
0xad9c90 instantiate_class_template(

[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 #23 from Iain Sandoe  ---
Author: iains
Date: Sat Sep 28 20:05:38 2019
New Revision: 276259

URL: https://gcc.gnu.org/viewcvs?rev=276259&root=gcc&view=rev
Log:
[X86, Darwin] Backport fix for pr82920 (part 4).

As part of the backport for pr82920, the following three testcases
that are only present on the 7 and 8 branch, also needed amendment.

2019-09-28  Iain Sandoe  

PR target/82920
* gcc.target/i386/indirect-thunk-bnd-1.c: Adjust scan-asms for Darwin,
do not use -fno-pic on Darwin.
* gcc.target/i386/indirect-thunk-bnd-2.c: Likewise.
* gcc.target/i386/ret-thunk-25.c: Skip for Darwin, which has a
different ABI for returning this category of complex value.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-bnd-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-bnd-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/ret-thunk-25.c

[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 #22 from Iain Sandoe  ---
Author: iains
Date: Sat Sep 28 20:00:22 2019
New Revision: 276258

URL: https://gcc.gnu.org/viewcvs?rev=276258&root=gcc&view=rev
Log:
[X86, Darwin] Backport fix for pr82920 (part 2).

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-09-28  Iain Sandoe  

Backport from mainline.
2019-05-12  Iain Sandoe  

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

gcc/testsuite/

2019-09-28  Iain Sandoe  

Backport from mainline.
2019-05-14  Iain Sandoe  

PR target/82920
* gcc.target/i386/pr52146.c: Require effective target x32.
* 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:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/darwin.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr52146.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr52698.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr52857-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr52857-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr52876.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr53698.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr54157.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr55049-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr55093.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr55116-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr55116-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr55597.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr59929.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr66470.c

[Bug libstdc++/91906] std::timed_mutex::try_lock_until may not wait for timeout to expire when called with user-defined clock

[mac at mcrowe dot com]

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

--- Comment #1 from Mike Crowe  ---
Proposed fix for std::timed_mutex and std::shared_timed_mutex in series posted
for review at https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01646.html .

[Bug libstdc++/78237] std::timed_mutex::try_lock_for/until affected by system realtime clock

[mac at mcrowe dot com]

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

--- Comment #3 from Mike Crowe  ---
Proposed fix for std::timed_mutex and std::shared_timed_mutex in series posted
for review at https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01646.html .

[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 #21 from Iain Sandoe  ---
Author: iains
Date: Sat Sep 28 19:54:00 2019
New Revision: 276257

URL: https://gcc.gnu.org/viewcvs?rev=276257&root=gcc&view=rev
Log:
[X86, Darwin] Backport fix for pr82920 (part 1).

The various thunks output codes have inconsistent output
mechanisms. The patch factors out some common code that
writes out the jumps and uses the regular output scheme
that accounts for __USER_LABEL_PREFIX__.

The testsuite changes are largely mechanical compensation
for the revised output (and the fact that Darwin doesn't
use non-PIC by default).

gcc/

2019-09-28  Iain Sandoe  

Backport from mainline.
2019-05-12  Iain Sandoe  

PR target/82920
* config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): New.
(ix86_output_indirect_branch_via_reg): Use output mechanism
accounting for __USER_LABEL_PREFIX__.
(ix86_output_indirect_branch_via_push): Likewise.
(ix86_output_function_return): Likewise.
(ix86_output_indirect_function_return): Likewise.

gcc/testsuite/

2019-09-28  Iain Sandoe  

Backport from mainline.
2019-05-12  Iain Sandoe  
Dominique d'Humieres  

PR target/82920
* gcc.target/i386/indirect-thunk-1.c: Adjust scan-asms for Darwin,
do not use -fno-pic on Darwin.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-8.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* gcc.target/i386/indirect-thunk-register-1.c: Likewise.
* gcc.target/i386/indirect-thunk-register-2.c: Likewise.
* gcc.target/i386/indirect-thunk-register-3.c: Likewise.
* gcc.target/i386/indirect-thunk-register-4.c: Likewise.
* gcc.target/i386/ret-thunk-1.c: Likewise.
* gcc.target/i386/ret-thunk-10.c: Likewise.
* gcc.target/i386/ret-thunk-11.c: Likewise.
* gcc.target/i386/ret-thunk-12.c: Likewise.
* gcc.target/i386/ret-thunk-13.c: Likewise.
* gcc.target/i386/ret-thunk-14.c: Likewise.
* gcc.target/i386/ret-thunk-15.c: Likewise.
* gcc.target/i386/ret-thunk-16.c: Likewise.
* gcc.target/i386/ret-thunk-2.c: Likewise.
* gcc.target/i386/ret-thunk-22.c: Likewise.
* gcc.target/i386/ret-thunk-23.c: Likewise.
* gcc.target/i386/ret-thunk-24.c: Likewise.
* gcc.target/i386/ret-thunk-3.c: Likewise.
* gcc.target/i386/ret-thunk-4.c: Likewise.
* gcc.target/i386/ret-thunk-5.c: Likewise.
* gcc.target/i386/ret-thunk-6.c: Likewise.
* gcc.target/i386/ret-thunk-7.c: Likewise.
* gcc.target/i386/ret-thunk-8.c: Likewise.
* gcc.target/i386/ret-thunk-9.c: Likewise.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-3.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-4.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-5.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-6.c
branches/gcc-7-branch/gc

[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Sep 28 19:14:47 2019
New Revision: 276255

URL: https://gcc.gnu.org/viewcvs?rev=276255&root=gcc&view=rev
Log:
2019-09-28  Jerry DeLisle  

PR libfortran/91593
* io/io.h: Add gcc_unreachable().
* io/transfer.c (file_mode, current_mode,
formatted_transfer_scalar_read, formatted_transfer_scalar_write,
pre_position, next_record_r, next_record_w): Add and use
FORMATTED_UNSPECIFIED to enumeration.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/transfer.c

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Looks like this fix worked:

$ ./b2 toolset=gcc-10 -a
[...]
The Boost C++ Libraries were successfully built!

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[msebor at gcc dot gnu.org]

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

Bug 54582 Summary: gap in FORTIFY checking of buffer lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/49905] Better sanity checking on sprintf src & dest to produce warning for dodgy code ?

[msebor at gcc dot gnu.org]

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

--- Comment #24 from Martin Sebor  ---
*** Bug 54582 has been marked as a duplicate of this bug. ***

[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
  Known to work||10.0, 7.3.0, 8.3.0, 9.1.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86349
 Resolution|--- |DUPLICATE
  Known to fail||6.3.0

--- Comment #18 from Martin Sebor  ---
Starting with r240298, GCC 7 and later diagnose the buffer overflow in both
calls so this request can be resolved as a duplicate of pr49905.  The output
with the current trunk at -O0 is below.

$ gcc -S -Wall pr54582.c
pr54582.c: In function ‘f’:
pr54582.c:8:18: warning: ‘%d’ directive writing between 1 and 11 bytes into a
region of size 0 [-Wformat-overflow=]
8 |  sprintf(buf, "ab%d", n);
  |  ^~
pr54582.c:8:2: note: ‘sprintf’ output between 4 and 14 bytes into a destination
of size 2
8 |  sprintf(buf, "ab%d", n);
  |  ^~~
pr54582.c:11:18: warning: ‘sprintf’ writing a terminating nul past the end of
the destination [-Wformat-overflow=]
   11 |  sprintf(buf, "ab");
  |  ^
pr54582.c:11:2: note: ‘sprintf’ output 3 bytes into a destination of size 2
   11 |  sprintf(buf, "ab");
  |  ^~

With -D_FORTIFY_SOURCE, both calls are still instrumented.

;; Function f (f, funcdef_no=23, decl_uid=2524, cgraph_uid=24, symbol_order=23)

f (int n)
{
  char buf[2];

   [local count: 1073741824]:
  __builtin___sprintf_chk (&buf, 1, 2, "ab%d", n_2(D));
  __builtin_puts (&buf);
  __builtin___sprintf_chk (&buf, 1, 2, "ab");
  __builtin_puts (&buf);
  buf ={v} {CLOBBER};
  return;

}


What still doesn't work is the overflow detection/prevention for dynamically
allocated objects and VLAs.  Bug 86349 records this limitation.  The strlen
pass tracks dynamic allocation and uses it for optimization but not yet to
detect buffer overflow.  Making use of it is a relatively simple enhancement. 
Now that the sprintf checker runs as part of the strlen pass, with the
enhancement in place, exposing the dynamic allocation sizes to it to detect the
overflow should be straightforward (and is on my list of things to do).

$ cat t.c && gcc -O2 -D_FORTIFY_SOURCE=2 -S -Wall
-fdump-tree-optimized=/dev/stdout t.c
#include 

int n = 2;

void f (int n)
{
  char buf[n];

  sprintf (buf, "abcdef");
  printf ("%s\n", buf);
}

;; Function f (f, funcdef_no=23, decl_uid=2525, cgraph_uid=24, symbol_order=24)

f (int n)
{
  char[0:D.2530] * buf.1;
  sizetype _1;

   [local count: 1073741824]:
  _1 = (sizetype) n_2(D);
  buf.1_7 = __builtin_alloca_with_align (_1, 8);
  __builtin_memcpy (buf.1_7, "abcdef", 7);
  __builtin_puts (buf.1_7);
  return;

}

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

[Bug fortran/91926] assumed rank optional

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-28
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Paul Thomas  ---
Created attachment 46974
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46974&action=edit
Fix for the PR

Thanks for the report. I was aware when I committed the IS_Fortran_binding
patch that I had not taken care of optional args. The speed of response is
generated by a feeling of mea cupla

Regards

Paul

[Bug fortran/91802] ICE in mio_name_expr_t, at fortran/module.c:2141

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 28 17:10:34 2019
New Revision: 276254

URL: https://gcc.gnu.org/viewcvs?rev=276254&root=gcc&view=rev
Log:
2019-09-28  Steven G. Kargl  

PR fortran/91802
* decl.c (attr_decl1): Check if rank+corank > 15.

2019-09-28  Steven G. Kargl  

PR fortran/91802
* gfortran.dg/pr91802.f90: New test.

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

[Bug fortran/91864] [9/10 Regression] ICE in gfc_check_do_variable, at fortran/parse.c:4405

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 28 16:26:43 2019
New Revision: 276253

URL: https://gcc.gnu.org/viewcvs?rev=276253&root=gcc&view=rev
Log:
2019-09-28  Steven G. Kargl  

PR fortran/91864
* gcc/fortran/io.c (match_io_element): An inquiry parameter cannot be
read into.
* gcc/fortran/match.c (gfc_match_allocate): An inquiry parameter 
can be neither an allocate-object nor stat variable.
(gfc_match_deallocate): An inquiry parameter cannot be deallocated.

2019-09-28  Steven G. Kargl  

PR fortran/91864
* gcc/testsuite/gfortran.dg/pr91864.f90

Added:
trunk/gcc/testsuite/gfortran.dg/pr91864.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91588] ICE in check_inquiry, at fortran/expr.c:2673

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on 8- through 10-branches.

Thanks for the report.

Paul

[Bug fortran/91588] ICE in check_inquiry, at fortran/expr.c:2673

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Author: pault
Date: Sat Sep 28 15:48:35 2019
New Revision: 276252

URL: https://gcc.gnu.org/viewcvs?rev=276252&root=gcc&view=rev
Log:
2019-09-28  Paul Thomas  

Backport from mainline
PR fortran/91588
* expr.c (check_inquiry): Remove extended component refs by
using symbol pointers. If a function argument is an associate
variable with a constant target, copy the target expression in
place of the argument expression. Check that the charlen is not
NULL before using the string length.

2019-09-28  Paul Thomas  

Backport from mainline
PR fortran/91588
* gfortran.dg/associate_49.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_49.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #14 from Marek Polacek  ---
Hopefully fixed.

[Bug c++/91889] [10 Regression] error: call of overloaded ‘to_value_ptr(B*&)’ is ambiguous

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Author: mpolacek
Date: Sat Sep 28 15:35:37 2019
New Revision: 276251

URL: https://gcc.gnu.org/viewcvs?rev=276251&root=gcc&view=rev
Log:
PR c++/91889 - follow-up fix for DR 2352.
* call.c (involves_qualification_conversion_p): New function.
(direct_reference_binding): Build a ck_qual if the conversion
would involve a qualification conversion.
(convert_like_real): Strip the conversion created by the ck_qual
in direct_reference_binding.

* g++.dg/cpp0x/ref-bind3.C: Add dg-error.
* g++.dg/cpp0x/ref-bind4.C: New test.
* g++.dg/cpp0x/ref-bind5.C: New test.
* g++.dg/cpp0x/ref-bind6.C: New test.
* g++.old-deja/g++.pt/spec35.C: Revert earlier change.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/ref-bind4.C
trunk/gcc/testsuite/g++.dg/cpp0x/ref-bind5.C
trunk/gcc/testsuite/g++.dg/cpp0x/ref-bind6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/ref-bind3.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/spec35.C

[Bug target/69286] trunk/libgcc/config/s390/tpf-unwind.h: 28 redundant condition ?

[uweigand at gcc dot gnu.org]

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

--- Comment #2 from Ulrich Weigand  ---
Yes, it does appear I checked in this code, but the tpf-unwind.h changes were
actually provided by Jim Johnston on the IBM TPF team:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02104.html

In any case, feel free to make the obvious change here :-)

[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Right, place_field hasn't been called for that FIELD_DECL yet and I meant to
fix it similarly.

[Bug c++/91923] [9 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/91923] [9 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Sat Sep 28 11:50:11 2019
New Revision: 276250

URL: https://gcc.gnu.org/viewcvs?rev=276250&root=gcc&view=rev
Log:
PR c++/91923 - failure-to-SFINAE with class type NTTP in C++17.
* pt.c (invalid_nontype_parm_type_p): Only emit errors when
tf_error.

* g++.dg/cpp0x/nontype5.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nontype5.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/pt.c

[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 46973
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46973&action=edit
gcc10-pr91925.patch

Perhaps we should just punt on FIELD_DECLs that haven't been laid out yet?

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed in GCC 10.

[Bug c++/91921] Incomplete -Woverloaded-virtual warning when base class is in system header

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sat Sep 28 11:46:33 2019
New Revision: 276249

URL: https://gcc.gnu.org/viewcvs?rev=276249&root=gcc&view=rev
Log:
PR c++/91921 - stray warning with -Woverloaded-virtual.
* class.c (warn_hidden): Only emit the second part of
-Woverloaded-virtual if the first part was issued.  Use inform instead
warning_at.

* g++.dg/warn/Woverloaded-2.C: New.
* g++.dg/warn/Woverloaded-2.h: New.
* g++.dg/warn/pr61945.C: Turn dg-warning into dg-message.
* g++.old-deja/g++.mike/warn6.C: Likewise.
* g++.old-deja/g++.warn/virt1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/warn/Woverloaded-2.C
trunk/gcc/testsuite/g++.dg/warn/Woverloaded-2.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/pr61945.C
trunk/gcc/testsuite/g++.old-deja/g++.mike/warn6.C
trunk/gcc/testsuite/g++.old-deja/g++.warn/virt1.C

[Bug c++/91923] [9 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9 Regression]
   |Failure-to-SFINAE with  |Failure-to-SFINAE with
   |class type NTTP in C++17|class type NTTP in C++17

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Sat Sep 28 11:36:36 2019
New Revision: 276248

URL: https://gcc.gnu.org/viewcvs?rev=276248&root=gcc&view=rev
Log:
PR c++/91923 - failure-to-SFINAE with class type NTTP in C++17.
* pt.c (invalid_nontype_parm_type_p): Only emit errors when
tf_error.

* g++.dg/cpp0x/nontype5.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nontype5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/91929] missing inline subroutine information in build using sin/cos

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|missing inline subroutine   |missing inline subroutine
   |information in static build |information in build using
   |using sin/cos   |sin/cos

--- Comment #3 from Andrew Pinski  ---
PRE is removing the line numbers for some reason.

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that:
1) *arm_movsi_insn uses =rk <- rk constraints
2) *arm_cmpsi_insn uses r, r constraints
3) *movsi_compare0 uses =0,r <- r,r constraints
4) define_peephole2s support predicates and conditions, but don't support
constraints

We have

; This pattern is never tried by combine, so do it as a peephole

(define_peephole2
  [(set (match_operand:SI 0 "arm_general_register_operand" "")
(match_operand:SI 1 "arm_general_register_operand" ""))
   (set (reg:CC CC_REGNUM)
(compare:CC (match_dup 1) (const_int 0)))]
  "TARGET_ARM"
  [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int 0)))
  (set (match_dup 0) (match_dup 1))])]
  ""
)

Now, if we have (set sp r6) followed by (set cc (compare r6 (const_int 0)))
this peephole2 makes a *movsi_compare0 with sp destination and r6 input out of
it, but while that satisfies the s_register_operand predicate on
*movsi_compare0, it doesn't satisfy the "=r" constraint.  I can't find a
predicate in arm.md that would accurately match the r constraint only, so
either one should be added, or we could do something like:
--- gcc/config/arm/arm.md.jj2019-09-27 17:48:19.898511815 +0200
+++ gcc/config/arm/arm.md   2019-09-28 13:18:56.930913514 +0200
@@ -10398,7 +10398,7 @@
(match_operand:SI 1 "arm_general_register_operand" ""))
(set (reg:CC CC_REGNUM)
(compare:CC (match_dup 1) (const_int 0)))]
-  "TARGET_ARM"
+  "TARGET_ARM && REG_P (operands[0]) && REGNO (operands[0]) != SP_REGNUM"
   [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int
0)))
  (set (match_dup 0) (match_dup 1))])]
   ""
which fixes the ICE.

[Bug debug/91929] missing inline subroutine information in static build using sin/cos

[mail at milianw dot de]

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

--- Comment #2 from Milian Wolff  ---
the binary exceeds the 1mb size threshold, but I hope it's easy enough to
reproduce directly from the source code

[Bug debug/91929] missing inline subroutine information in static build using sin/cos

[mail at milianw dot de]

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

--- Comment #1 from Milian Wolff  ---
Created attachment 46972
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46972&action=edit
code to reproduce the issue

[Bug debug/91929] New: missing inline subroutine information in static build using sin/cos

[mail at milianw dot de]

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

Bug ID: 91929
   Summary: missing inline subroutine information in static build
using sin/cos
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail at milianw dot de
  Target Milestone: ---

Hey there,

take the attached C++ code sample and compile it with `g++ -O2 -g -static` to
produce the attached binary. Sampling it with perf produces strange backtraces
even when including inline frames - it seems like the information is simply
lacking from the generated binary? See e.g.:

```
$ addr2line -i -C -f -p -e vector_static_gcc_v9.1.0 -a 418790
0x00418790: __cos_fma at ??:?

$ addr2line -i -C -f -p -e vector_static_gcc_v9.1.0 -a 401572
0x00401572: generate_n >,
int, main():: > at /usr/include/c++/9.1.0/bits/stl_algo.h:4449
 (inlined by) main at /.../vector.cpp:16
```

Here's a backtrace from GDB showing this odd behavior:

```
(gdb) b __cos_fma
Breakpoint 2 at 0x418790
(gdb) c
Continuing.

Breakpoint 2, 0x00418790 in __cos_fma ()
(gdb) bt
#0  0x00418790 in __cos_fma ()
#1  0x00401573 in
std::generate_n >, int,
main():: > (__n=10, __gen=..., 
__first=...) at /usr/include/c++/9.1.0/new:174
#2  main () at ../../../manual/clients/vector.cpp:16
```

I'm missing inline frames for the lambda and `std::cos` or similar. When
replacing g++ with clang++ 8.0.1 this looks better:

```
(gdb) bt
#0  0x004191d0 in __cos_fma ()
#1  0x00402663 in std::cos (__x=)
at
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/cmath:197
#2  main::$_0::operator() (this=) at ./vector.cpp:14
#3  std::generate_n > >, int, main::$_0> (__first=..., __n=10, 
__gen=...) at
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../include/c++/9.1.0/bits/stl_algo.h:4450
#4  main () at ./vector.cpp:12
```

[Bug c++/70885] Use MSB/LSB pointer-tagging for pointer-to-member representation

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  ---
Actually this could be useful on every (embedded) target, where functions can
be aligned on 2 byte boundaries.  Then either the MSB or LSB can be used for
the tag.

[Bug libitm/86712] libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #5 from Oleg Endo  ---
This has also been fixed on then-trunk GCC 9, but the commit message was
missing the PR number.

[Bug libitm/86712] libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 09:12:34 2019
New Revision: 276247

URL: https://gcc.gnu.org/viewcvs?rev=276247&root=gcc&view=rev
Log:
libitm/
2019-09-28  Oleg Endo  

Backport from mainline
2018-08-03  Sergei Trofimovich  

PR target/86712
* config/sh/sjlj.S: Adjust to use PIC vs normal code to avoid
absolute relocation in a shared library.


Modified:
branches/gcc-7-branch/libitm/ChangeLog
branches/gcc-7-branch/libitm/config/sh/sjlj.S

[Bug libitm/86712] libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 09:11:02 2019
New Revision: 276246

URL: https://gcc.gnu.org/viewcvs?rev=276246&root=gcc&view=rev
Log:
libitm/
2019-09-28  Oleg Endo  

Backport from mainline
2018-08-03  Sergei Trofimovich  

PR target/86712
* config/sh/sjlj.S: Adjust to use PIC vs normal code to avoid
absolute relocation in a shared library.


Modified:
branches/gcc-8-branch/libitm/ChangeLog
branches/gcc-8-branch/libitm/config/sh/sjlj.S

[Bug target/86805] sh port needs updating for CVE-2017-5753

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #4 from Oleg Endo  ---
Fixed on trunk and GCC 9.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

[olegendo at gcc dot gnu.org]

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

Bug 86805 Summary: sh port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86805

   What|Removed |Added

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

[Bug target/86805] sh port needs updating for CVE-2017-5753

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:55:03 2019
New Revision: 276245

URL: https://gcc.gnu.org/viewcvs?rev=276245&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

Backport from mainline
2019-09-28  Oleg Endo  

PR target/86805
* config/sh/sh.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/sh/sh.c

[Bug target/86805] sh port needs updating for CVE-2017-5753

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:53:27 2019
New Revision: 276244

URL: https://gcc.gnu.org/viewcvs?rev=276244&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

PR target/86805
* config/sh/sh.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #9 from Oleg Endo  ---
Although the use of string::find most likely doesn't have any performance
impact in this case in a real-world usage, it also doesn't hurt to use
string::compare.

Fixed on trunk (GCC 10) and backported to GCC 9, 8, 7.

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[olegendo at gcc dot gnu.org]

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

Bug 80672 Summary: gcc/config/sh/sh.c:716: prefer compare to find.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80672

   What|Removed |Added

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

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:41:09 2019
New Revision: 276243

URL: https://gcc.gnu.org/viewcvs?rev=276243&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

Backport from mainline
2019-09-28  Oleg Endo  

PR target/80672
* config/sh/sh.c (parse_validate_atomic_model_option): Use
std::string::compare instead of std::string::find.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh.c

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:39:40 2019
New Revision: 276242

URL: https://gcc.gnu.org/viewcvs?rev=276242&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

Backport from mainline
2019-09-28  Oleg Endo  

PR target/80672
* config/sh/sh.c (parse_validate_atomic_model_option): Use
std::string::compare instead of std::string::find.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/sh/sh.c

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:37:23 2019
New Revision: 276241

URL: https://gcc.gnu.org/viewcvs?rev=276241&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

Backport from mainline
2019-09-28  Oleg Endo  

PR target/80672
* config/sh/sh.c (parse_validate_atomic_model_option): Use
std::string::compare instead of std::string::find.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/sh/sh.c

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 08:33:31 2019
New Revision: 276240

URL: https://gcc.gnu.org/viewcvs?rev=276240&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

PR target/80672
* config/sh/sh.c (parse_validate_atomic_model_option): Use
std::string::compare instead of std::string::find.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c

[Bug jit/91928] New: libgccjit fails on subsequent compilations in ipa-cp

[andrea.corallo at arm dot com]

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

Bug ID: 91928
   Summary: libgccjit fails on subsequent compilations in ipa-cp
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: andrea.corallo at arm dot com
  Target Milestone: ---

Created attachment 46971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46971&action=edit
repro.c gziped (3Mb uncompressed)

libgccjit get ice in subsequent compilations.
the attached reproducer compiles code A then B and then recompiling A crash.
I struggle to create a minimal artificial reproducer so I attach the
auto-generated one that is rather big.
I'm quite sure this is related to static structures we store into
gcc/ipa-prop.c and I'm currently looking into it.

$ gcc repro.c -O0 -g3 -o repro -lgccjit
$ ./repro 
compiling A
compiling B
compiling A
during IPA pass: cp
libgccjit.so: error: in operator[], at vec.h:859
0x7f54abfc412f vec::operator[](unsigned int)
../../gcc/vec.h:859
0x7f54abfc412f vec::operator[](unsigned int)
../../gcc/vec.h:1425
0x7f54abfc412f ipcp_update_bits
../../gcc/ipa-prop.c:5026
0x7f54abfc412f ipcp_transform_function(cgraph_node*)
../../gcc/ipa-prop.c:5202
0x7f54ac6888e4 execute_one_ipa_transform_pass
../../gcc/passes.c:2231
0x7f54ac688a59 execute_all_ipa_transforms(bool)
../../gcc/passes.c:2270
0x7f54ac107000 cgraph_node::expand()
../../gcc/cgraphunit.c:2187
0x7f54ac1076d4 expand_all_functions
../../gcc/cgraphunit.c:2332
0x7f54ac1083dc symbol_table::compile()
../../gcc/cgraphunit.c:2688
0x7f54ac10887d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This reproducer output was run on the current trunk (gcc 10 37584e9) but I see
it affect at least also the gcc-9-branch.

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Oleg Endo from comment #3)
> 
> That's a dup of PR 85993, which was reported by you already and has been
> fixed in GCC 9 some time ago.  I have backported the fix to GCC 7 and GCC 8
> for your convenience.

Oh wow .. obviously I got lost in time.  This PR is from 2017 which predates PR
85993.

[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
(In reply to David Binderman from comment #1)
> Unrelated issue in the same file:
> 
> trunk/gcc/config/sh/sh.c:10817]: (style) Expression is always false because
> 'else if' condition matches previous condition at line 10803.
> 
>   else if (scratch0 != scratch1)
> {
>   else if (scratch0 != scratch1)
> {

That's a dup of PR 85993, which was reported by you already and has been fixed
in GCC 9 some time ago.  I have backported the fix to GCC 7 and GCC 8 for your
convenience.

[Bug target/85993] config/sh/sh.c:10878: suspicious if .. else chain

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 07:29:06 2019
New Revision: 276239

URL: https://gcc.gnu.org/viewcvs?rev=276239&root=gcc&view=rev
Log:
gcc/
2019-09-28  Oleg Endo  

Backport from mainline
2018-07-15  Jeff Law  

PR target/85993
* config/sh/sh.c (output_mi_thunk): Remove dead conditional
block.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh.c

[Bug target/85993] config/sh/sh.c:10878: suspicious if .. else chain

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Author: olegendo
Date: Sat Sep 28 07:23:10 2019
New Revision: 276237

URL: https://gcc.gnu.org/viewcvs?rev=276237&root=gcc&view=rev
Log:
gcc/
2018-09-28  Oleg Endo  

Backport from mainline
2018-07-15  Jeff Law  

PR target/85993
* config/sh/sh.c (output_mi_thunk): Remove dead conditional
block.


Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/sh/sh.c

[Bug testsuite/91676] new test case gcc.dg/torture/pr91656-1.c in r275406 fails on powerpc64 BE

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #4 from Alan Modra  ---
Patch applied.

[Bug rtl-optimization/91656] [10 Regression] wrong code with -fgcse-after-reload

[amodra at gcc dot gnu.org]

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

--- Comment #12 from Alan Modra  ---
Author: amodra
Date: Sat Sep 28 07:12:14 2019
New Revision: 276236

URL: https://gcc.gnu.org/viewcvs?rev=276236&root=gcc&view=rev
Log:
Fix endian issue in pr91656 testcases

PR testsuite/91676
PR rtl-optimization/91656
* gcc.dg/torture/pr91656-1.c: Correct for big and pdp endian.
* gcc.dg/torture/pr91656-2.c: Likewise.
* gcc.dg/torture/pr91656-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr91656-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr91656-2.c
trunk/gcc/testsuite/gcc.dg/torture/pr91656-3.c

[Bug testsuite/91676] new test case gcc.dg/torture/pr91656-1.c in r275406 fails on powerpc64 BE

[amodra at gcc dot gnu.org]

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

--- Comment #3 from Alan Modra  ---
Author: amodra
Date: Sat Sep 28 07:12:14 2019
New Revision: 276236

URL: https://gcc.gnu.org/viewcvs?rev=276236&root=gcc&view=rev
Log:
Fix endian issue in pr91656 testcases

PR testsuite/91676
PR rtl-optimization/91656
* gcc.dg/torture/pr91656-1.c: Correct for big and pdp endian.
* gcc.dg/torture/pr91656-2.c: Likewise.
* gcc.dg/torture/pr91656-3.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr91656-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr91656-2.c
trunk/gcc/testsuite/gcc.dg/torture/pr91656-3.c