[Bug c/90042] New: [7.3 regression] Unreadable preprocessed files format

[zhongyunde at huawei dot com]

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

Bug ID: 90042
   Summary: [7.3 regression] Unreadable preprocessed files format
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

 the preprocessed file base gcc 7.3

# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   __builtin_sel(
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
   vhfInvL2
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   , 
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
   vhfInvL2
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   , 
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
   vhfSEL16Buff1
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   , 
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
   1
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   )
# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
  ;

 the preprocessed file base gcc 4.7

# 1570
"/usr1/bmtest/zhongyunde/SAC_C11/SAC/UT/linux_hcc_SD6186/../../CODE/SRS/SAC_SRSMEAS_EQSINR3I.c"
3 4
   __builtin_sel( vhfInvL2, vhfInvL2, vhfSEL16Buff1, 1) ;

[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file

[todd.freed at gmail dot com]

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

--- Comment #7 from Todd Freed  ---
Submitted a bug report to bug-bi...@gnu.org, as this seems to be a recent
behavior change in bison. It did not used to produce an output which induced
the hang when invoked like,

bison -o /dev/stdout parser.y | gcc -xc -

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pthaugen at linux dot 
ibm.com

--- Comment #4 from Segher Boessenkool  ---
power9.md has

(define_insn_reservation "power9-store" 0

whereas pretty much everything else has a non-zero number here.  This number
is only for true dependences, so read-after-write, so 0 does not make super
much sense anyway.

Assigning this to Pat.  Pat, feel free to kick it back to me, or to whoever
else you want ;-)

[Bug translation/90041] New: Command line option without proper quoting in translation message

[roland.illig at gmx dot de]

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

Bug ID: 90041
   Summary: Command line option without proper quoting in
translation message
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From rs6000.h:

  :%eMissing -mcpu option in ASM_CPU_SPEC?\n} \

I thought there were a linter checking that each option in the translatable
strings is enclosed in %<...%>. Apparently that linter missed this instance.

[Bug translation/89939] messages for translation must not contain embedded macro parameters

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
Would it be possible to teach exgettext that inside the _(...), the only
allowed tokens are string literals, and maybe the PRIU64 constants? There's
probably some more tokens that I just forgot, but a test run over the GCC
source should reveal most of them.

[Bug translation/89939] messages for translation must not contain embedded macro parameters

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
For this case, the solution is straightforward:

Index: frontend-passes.c
=== 
--- frontend-passes.c   (Revision 270182)   
+++ frontend-passes.c   (Arbeitskopie)  
@@ -3743,13 +3743,16 @@ 

 /* Macros for unified error messages.  */  

-#define B_ERROR(n) _("Incorrect extent in argument B in MATMUL intrinsic in "
\
-"dimension " #n ": is %ld, should be %ld")
+#define B_ERROR_1 _("Incorrect extent in argument B in MATMUL intrinsic in " \
+"dimension 1: is %ld, should be %ld")

-#define C_ERROR(n) _("Array bound mismatch for dimension " #n " of array " \
-"(%ld/%ld)")
+#define C_ERROR_1 _("Array bound mismatch for dimension 1 of array " \
+   "(%ld/%ld)")

+#define C_ERROR_2 _("Array bound mismatch for dimension 2 of array " \
+   "(%ld/%ld)")

+
 /* Inline assignments of the form c = matmul(a,b).
Handle only the cases currently where b and c are rank-two arrays.

@@ -3976,7 +3979,7 @@

  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
  a2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 2);
- test = runtime_error_ne (b1, a2, B_ERROR(1));
+ test = runtime_error_ne (b1, a2, B_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

@@ -3984,7 +3987,7 @@
{
  c1 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 1);
  a1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 1);
- test = runtime_error_ne (c1, a1, C_ERROR(1));
+ test = runtime_error_ne (c1, a1, C_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;
}
@@ -3994,7 +3997,7 @@

  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
  a1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 1);
- test = runtime_error_ne (b1, a1, B_ERROR(1));
+ test = runtime_error_ne (b1, a1, B_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

@@ -4002,7 +4005,7 @@
{
  c1 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 1);
  b2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 2);
- test = runtime_error_ne (c1, b2, C_ERROR(1));
+ test = runtime_error_ne (c1, b2, C_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;
}
@@ -4012,7 +4015,7 @@

  b1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 1);
  a2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 2);
- test = runtime_error_ne (b1, a2, B_ERROR(1));
+ test = runtime_error_ne (b1, a2, B_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

@@ -4020,13 +4023,13 @@
{
  c1 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 1);
  a1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 1);
- test = runtime_error_ne (c1, a1, C_ERROR(1));
+ test = runtime_error_ne (c1, a1, C_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

  c2 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 2);
  b2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 2);
- test = runtime_error_ne (c2, b2, C_ERROR(2));
+ test = runtime_error_ne (c2, b2, C_ERROR_2);
  *next_code_point = test;
  next_code_point = >next;
}
@@ -4037,7 +4040,7 @@
  b2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_b, 2);
  a2 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 2);
  /* matrix_b is transposed, hence dimension 1 for the error message. 
*/
- test = runtime_error_ne (b2, a2, B_ERROR(1));
+ test = runtime_error_ne (b2, a2, B_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

@@ -4045,13 +4048,13 @@
{
  c1 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 1);
  a1 = get_array_inq_function (GFC_ISYM_SIZE, matrix_a, 1);
- test = runtime_error_ne (c1, a1, C_ERROR(1));
+ test = runtime_error_ne (c1, a1, C_ERROR_1);
  *next_code_point = test;
  next_code_point = >next;

  c2 = get_array_inq_function (GFC_ISYM_SIZE, expr1, 2);
  

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #26 from anlauf at gcc dot gnu.org ---
Should be fixed on trunk, 8-branch and 7-branch.

Closing.

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #25 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Apr 10 21:02:02 2019
New Revision: 270268

URL: https://gcc.gnu.org/viewcvs?rev=270268=gcc=rev
Log:
2019-04-10  Harald Anlauf  

Backport from trunk
PR fortran/89904
* check.c (gfc_check_transfer): Reject procedures as actual
arguments for SOURCE and MOLD of TRANSFER intrinsic.

PR fortran/89904
* gfortran.dg/pr85797.f90: Adjust testcase.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/check.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90

[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302

[yann at droneaud dot fr]

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

--- Comment #3 from Yann Droneaud  ---
Created attachment 46138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46138=edit
Reduced reproducer sample

I've used creduce[1][2] to generate a smaller reproducer sample, see
https://godbolt.org/z/Ae2x_h

[1] http://embed.cs.utah.edu/creduce/
[2] https://github.com/csmith-project/creduce

[Bug target/89993] Inconsistent incoming stack boundary

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
hjl@gnu-cfl-1 pr89993]$ gcc -mstackrealign -O2  -S b.c
[hjl@gnu-cfl-1 pr89993]$ cat b.s
.file   "b.c"
.text
.p2align 4,,15
.globl  tst1Foo
.type   tst1Foo, @function
tst1Foo:
.LFB526:
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-16, %rsp  << Align stack without
-mincoming-stack-boundary=4
subq$16, %rsp
movq%rsp, %rcx
calltst2Foo
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE526:
.size   tst1Foo, .-tst1Foo
.ident  "GCC: (GNU) 8.3.1 20190311 (Red Hat 8.3.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr89993]$

gcc-bugs@gcc.gnu.org

[ildkagbxb]

gcc-bugs+
开各地正规普通增值税票，点优惠，包真。
详电：陈红{女士}
手机：135 9014 5089
业务QQ：1248802718
+++xqEeLMh+++
4:41旨费力姚绍举盾{!BSX携裔颜欧

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[sje at gcc dot gnu.org]

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

--- Comment #46 from Steve Ellcey  ---
Author: sje
Date: Wed Apr 10 20:29:57 2019
New Revision: 270267

URL: https://gcc.gnu.org/viewcvs?rev=270267=gcc=rev
Log:
2018-04-10  Steve Ellcey  

PR rtl-optimization/87763
* gcc.target/aarch64/combine_bfxil.c: Change some bfxil checks
to bfi.
* gcc.target/aarch64/combine_bfi_2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/combine_bfi_2.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/combine_bfxil.c

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[sje at gcc dot gnu.org]

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

--- Comment #45 from Steve Ellcey  ---
Author: sje
Date: Wed Apr 10 20:28:19 2019
New Revision: 270266

URL: https://gcc.gnu.org/viewcvs?rev=270266=gcc=rev
Log:
2018-04-10  Steve Ellcey  

PR rtl-optimization/87763
* config/aarch64/aarch64-protos.h (aarch64_masks_and_shift_for_bfi_p):
New prototype.
* config/aarch64/aarch64.c (aarch64_masks_and_shift_for_bfi_p):
New function.
* config/aarch64/aarch64.md (*aarch64_bfi5_shift):
New instruction.
(*aarch64_bfi5_shift_alt): Ditto.
(*aarch64_bfi4_noand): Ditto.
(*aarch64_bfi4_noand_alt): Ditto.
(*aarch64_bfi4_noshift): Ditto.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md

[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045

[anlauf at gcc dot gnu.org]

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

--- Comment #24 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Wed Apr 10 20:26:44 2019
New Revision: 270265

URL: https://gcc.gnu.org/viewcvs?rev=270265=gcc=rev
Log:
2019-04-10  Harald Anlauf  

Backport from trunk
PR fortran/89904
* check.c (gfc_check_transfer): Reject procedures as actual
arguments for SOURCE and MOLD of TRANSFER intrinsic.

PR fortran/89904
* gfortran.dg/pr85797.f90: Adjust testcase.

Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/check.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[juergen.reuter at desy dot de]

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

--- Comment #63 from Jürgen Reuter  ---
I confirm that the fix in comment #48 works also with MACOSX 10.14.4, XCode
10.2 on gcc trunk, as of r270245.

[Bug c++/89722] [8/9 regression] strange warning: type qualifiers ignored on cast result type [-Wignored-qualifiers]

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #12 from Marek Polacek  ---
Since this seems to work as designed, I'm going to close it.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #3)
> Why does sel-sched try to propagate hard registers into insns before RA? 
> The whole point of the combiner changes was not to do that, so that the RA
> can do better job.

That, and *correctness*.  Propagating hard registers can lead to things that
cannot be reloaded.  Even in the simple case here you cannot necessarily
replace the hard reg with a pseudo and end up with valid code.

[Bug c/90036] [8/9 Regression] false positive: directive argument is null [-Werror=format-overflow=]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.0
   Keywords||diagnostic
   Last reconfirmed||2019-04-10
 CC||msebor at gcc dot gnu.org
 Blocks||85741
 Ever confirmed|0   |1
Summary|False positive: directive   |[8/9 Regression] false
   |argument is null|positive: directive
   |[-Werror=format-overflow=]  |argument is null
   ||[-Werror=format-overflow=]
  Known to fail||8.3.0, 9.0

--- Comment #1 from Martin Sebor  ---
(When reporting bugs we ask for a test case.  Please see
https://www.gnu.org/software/gcc/bugs).

That said, I can reproduce the warning with the top of trunk and with GCC 8. 
The reason why the warning is issued for sprintf and not for strlen is because
it is implemented differently between the two functions (it runs on different
IL).

The null in the IL is the result of the jump threading optimization.  The
warning can be suppressed by adding 'assert (vstring)' just above the sprintf
call.

Here's the IL the warning code sees:

stab_start_class_type (void * p, const char * tag, unsigned int id, bfd_boolean 
structp, unsigned int size, bfd_boolean vptr, bfd_boolean ownvptr)
{
  ...
   [local count: 237404318]:
  if (ownvptr_24(D) != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
  ...
   [local count: 0]:
  _51 = strlen (0B);
  _59 = _51 + 3;
  vtable_16 = xmalloc (_59);
  sprintf (vtable_16, "~%%%s", 0B);
  _18 = MEM[(struct stab_write_handle *)p_22(D)].type_stack;
  _18->vtable = vtable_16;
  goto ; [100.00%]
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow

[Bug rtl-optimization/90040] New: [meta-bug] modulo-scheduler and partitioning issues

[zhroma at ispras dot ru]

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

Bug ID: 90040
   Summary: [meta-bug] modulo-scheduler and partitioning issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at ispras dot ru
  Target Milestone: ---

Here I want to discuss the situation with modulo scheduler pass when
-freorder-blocks-and-partition is also enabled.

TL;DR Kindly ask RTL folks to fix ICE happening in 
cfg_layout_redirect_edge_and_branch_force while trying to redirect a crossing
jump.

--
The problem here is not in modulo scheduler algorithm itself, but in pass
initialization (and finalization) procedures. It enter (and later finally
leaves) cfg_layout mode, it also calls loop_optimizer_init. And all this stuff
leads to many branch redirections, which should successfully happen after
partitioning in bbro pass.

This issue is not new, at least here
https://gcc.gnu.org/ml/gcc-patches/2011-07/msg01811.html
I found that entering cfg_layout broke things on x86 (where required doloop
pattern is absent), and introduce an idea to move the sms pass before bbro. But
later I got this thought from Richard
https://gcc.gnu.org/ml/gcc-patches/2011-10/msg01526.html
and I agree that we have to fix it in another way.

Now in 2019, we got at least five bugs about the same situation. I want to
connect them all into this discussion.

First to say, PR85408 and PR87329 are open now, PR87475 is fixed, but they all
are about the same assertion
«internal compiler error: in patch_jump_insn, at cfgrtl.c:1271». PR87475 was
fixed by Jakub back in November by r266219, and two other were later reported
unreproducible, so, IMHO, they are fixed now too.

Jakub's ChangeLog:
PR rtl-optimization/87475
* cfgrtl.c (patch_jump_insn): Allow redirection failure for
CROSSING_JUMP_P insns.
(cfg_layout_redirect_edge_and_branch): Don't ICE if ret is NULL.

Second, I want to discuss PR85426, where first buggy assertion was same as in
that three PRs, but after Jakub’s fix, Arseny reports another fallen assertion:
«internal compiler error: in cfg_layout_redirect_edge_and_branch_force, at
cfgrtl.c:4482»

And this last assertion is the real issue -- that happens when we call
redirect_edge_and_branch_force for crossing jump. I’m not familiar with
partitioning, so have no idea how to fix this.

Hopefully, if we find a fix for this, PR89116 would also be fixed, although
situation there in not absolutely the same — there we ICE on same assertion
only in split_edge_and_insert while running generate_prolog_epilog, so this
happens only after SMS succeeded to create a schedule.

[Appendix 1] I want to mention PR83886 also, which was fixed by Honza with the
following ChangeLog:
PR rtl/84058
* cfgcleanup.c (try_forward_edges): Do not give up on crossing
jumps; choose last target that matches the criteria (i.e.
no partition changes for non-crossing jumps).
* cfgrtl.c (cfg_layout_redirect_edge_and_branch): Add basic
support for redirecting crossing jumps to non-crossing.

So here we have also some change with crossing jumps redirection.

[Appendix 2] There are also some issues with entering/exiting cfg_layout.
Technically, all of them are fixed right now: PR83771, PR83475 (fixed together
with PR81791).
But I wonder maybe this all is just latent, because in other passes I see a
special check to prevent entering cfg_layout after partitioning.

For example in hw-doloop.c we have:
  /* We can't enter cfglayout mode anymore if basic block partitioning
 already happened.  */
  if (do_reorder && !crtl->has_bb_partition)

This condition were added back in 2014
https://gcc.gnu.org/ml/gcc-patches/2014-01/msg00282.html and that time it looks
like:
  if (do_reorder && !flag_reorder_blocks_and_partition)

And later were adjusted by Honza to current state:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg00515.html

But we dont have any check like this in modulo scheduler. There we certainly
can’t proceed without entering cfg_layout, so I’m not sure it would be a good
idea to add such a check. But maybe we have now some more latent bugs with
entering cfg_layout after partitioning?

[Appendix 3] Last month I spent a lot of time updating my patches described
here
https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01647.html
and have locally added several other patches to fix most of modulo-sched PRs
from bugzilla, but annoying issue described here prohibits me to test my branch
in all possible scenarios.
I'll try to add some comments into all other modulo scheduler bugzilla PRs this
or next week while we are on stage 4.

[Bug target/84369] test case gcc.dg/sms-10.c fails on power9

[zhroma at ispras dot ru]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #3 from Roman Zhuykov  ---
I compared modulo-sched DDGs in “power8 vs power9” modes and main difference is
not combined instruction mentioned by Peter, but movsi_internal1 dependencies
cost. For this two instructions:

(insn 23 22 25 4 (set (mem:SI (plus:DI (reg/f:DI 126 [
regstat_n_sets_and_refs.1_9 ])
(reg:DI 141 [ ivtmp.26 ])) [2 MEM[base:
regstat_n_sets_and_refs.1_9, index: ivtmp.26_35, offset: 0B]+0 S4 A32])
(reg:SI 148 [ _7->n_refs ])) "sms-10.c":50:40 502 {*movsi_internal1}
 (expr_list:REG_DEAD (reg:SI 148 [ _7->n_refs ])
(nil)))

(insn 32 31 33 4 (set (mem:SI (plus:DI (reg/f:DI 159)
(reg:DI 141 [ ivtmp.26 ])) [2 MEM[base: _44, index:
ivtmp.26_35, offset: 0B]+0 S4 A32])
(reg:SI 154)) "sms-10.c":51:40 502 {*movsi_internal1}
 (expr_list:REG_DEAD (reg:SI 154)
(nil)))

insn_default_latency (and then insn_sched_cost) function returns significantly
different values: 5 for power8, 0 for power9.

There are other movsi_internal1 instructions in this loop, their cost also
differ, but it’s only 1 cycle “3 vs 4” change, hopefully it is correct.

The same thing (“5 vs 0” cost) also broke this test on 32-bit powerpc. There
are no combining difference there, only the cost issue, but it also prevents
modulo-sched to succeed.

I’m not familiar with .md files, so I ask somebody to look at “5 vs 0” issue.
If such cost difference is correct, then it seems a good solution just to skip
this test on power9 cpus.

[Bug target/87979] ICE in compute_split_row at modulo-sched.c:2393

[zhroma at ispras dot ru]

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

--- Comment #2 from Roman Zhuykov  ---
Situation is same in the following tests on ia64 platform with -fmodulo-sched
enabled (with any of O1, O2, Os):
gcc.dg/torture/pr82762.c
gcc.c-torture/execute/20170419-1.c

We divide by zero when we try to schedule loop body in zero cycles. Both
res_mii and rec_mii estimations equals zero. We have to start with one cycle in
this situation.

Patch was successfully bootstrapped and regtested with few other patches on
x86_64. In cross-compiler mode to s390, spu, aarch64, arm, ia64, ppc and ppc64
patch was regtested, and also with -fmodulo-sched enabled by default.
All same testing also done on 8 branch. Mentioned ia64 tests were the only
difference.

diff --git a/gcc/modulo-sched.c b/gcc/modulo-sched.c
--- a/gcc/modulo-sched.c
+++ b/gcc/modulo-sched.c
@@ -1597,6 +1597,7 @@ sms_schedule (void)
   mii = 1; /* Need to pass some estimate of mii.  */
   rec_mii = sms_order_nodes (g, mii, node_order, _asap);
   mii = MAX (res_MII (g), rec_mii);
+  mii = MAX (mii, 1);
   maxii = MAX (max_asap, MAXII_FACTOR * mii);

   if (dump_file)

[Bug target/87979] ICE in compute_split_row at modulo-sched.c:2393

[zhroma at ispras dot ru]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #1 from Roman Zhuykov  ---
Created attachment 46137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46137=edit
Proposed patch

[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064

[zhroma at ispras dot ru]

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

--- Comment #4 from Roman Zhuykov  ---
There is the following mistake in logic behind the code.

We want to schedule the branch instructions only as a last instruction in a
row. But when branch was scheduled and we add other instructions into partial
schedule, we sometimes allow them to be in same row after the branch.

The issue happens later when we try to reschedule branch into another row,
algorithm there works like this:
(1) Remove branch from the row where it is (say, “previous row”)
(2) Try insert into the needed row
(3) If success – OK, continue scheduling other instructions
(4) But when inserting (2) was not done – insert it back into “previous row”
and this insertion must be certainly successful, which is checked by assertion.

But when on step (1) branch in not last in a row there is no guarantee, that on
step (4) we could insert it back, because there we will try only last-in-a-row
position for it.

Proposed patch solves this totally preventing other instructions to be
scheduled after branch in the same row.

Patch was successfully bootstrapped and regtested with few other patches on
x86_64. In cross-compiler mode to s390, spu, aarch64, arm, ia64, ppc and ppc64
patch was regtested, and also with -fmodulo-sched enabled by default.
All same testing also done on 8 branch. No new failures introduced.

diff --git a/gcc/modulo-sched.c b/gcc/modulo-sched.c
--- a/gcc/modulo-sched.c
+++ b/gcc/modulo-sched.c
@@ -2996,9 +2996,7 @@ ps_insn_find_column (partial_schedule_ptr ps, ps_insn_ptr
ps_i,
 last_must_precede = next_ps_i;
 }
   /* The closing branch must be the last in the row.  */
-  if (must_precede 
- && bitmap_bit_p (must_precede, next_ps_i->id)
- && JUMP_P (ps_rtl_insn (ps, next_ps_i->id)))
+  if (JUMP_P (ps_rtl_insn (ps, next_ps_i->id)))
return false;

last_in_row = next_ps_i;

[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064

[zhroma at ispras dot ru]

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

Roman Zhuykov  changed:

   What|Removed |Added

 CC||zhroma at ispras dot ru

--- Comment #3 from Roman Zhuykov  ---
Created attachment 46136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46136=edit
Proposed patch

[Bug demangler/90039] New: libiberty demangling _GLOBAL__sub_I__Z11print_tracev

[jg at jguk dot org]

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

Bug ID: 90039
   Summary: libiberty demangling _GLOBAL__sub_I__Z11print_tracev
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Created attachment 46135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46135=edit
binary elf

addr2line and c++filt rely upon libiberty demangling

Could it be improved to handle _GLOBAL_ symbols?

$ c++filt _GLOBAL__sub_I__Z11print_tracev
_GLOBAL__sub_I__Z11print_tracev
$
$ c++filt _Z11print_tracev
print_trace()
$
$ c++filt --version
GNU c++filt (GNU Binutils for Ubuntu) 2.30


$ addr2line -f -C -e exception4 0x1600
_GLOBAL__sub_I__Z11print_tracev
/home/jonny/code/crash/exception4.cpp:100


Maybe the "_GOBAL_" prefix just needs to be stripped?

I had filed this before on binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=24403

[Bug libfortran/90038] New: execute_command_line should not use fork()

[jb at gcc dot gnu.org]

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

Bug ID: 90038
   Summary: execute_command_line should not use fork()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

Occasionally there are problems like
https://stackoverflow.com/questions/55120720/fortran-execute-command-line-runtime-error-depends-on-memory-consumption
where execute_command_line (or system()) fails because the calling process uses
a lot of memory.

As of October 2018 glibc system() uses posix_spawn() instead of fork(), so this
problem should largely solve itself over time on Linux/glibc targets.

However, in execute_command_line there is still a usage of fork() remaining (in
case WAIT=.FALSE.). This should be fixed.

See also
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Patches should be pinged after a week if they aren't reviewed, furthermore, it
is better to CC explicitly relevant maintainers.

[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #4 from Paolo Carlini  ---
Clearly, an important difference between sfinae65.C (the test added in r269965
for c++/86932) and the new testcase is that here we have a type parameter pack,
which, as such, cannot  refer to another parameter. Thus I'm wondering if
restricting the fix for c++/86932 like:

Index: pt.c
===
--- pt.c(revision 270223)
+++ pt.c(working copy)
@@ -8475,7 +8475,8 @@ coerce_template_parms (tree parms,
arg = NULL_TREE;

   if (template_parameter_pack_p (TREE_VALUE (parm))
- && (arg || !(complain & tf_partial))
+ && (arg || !(complain & tf_partial)
+ || TREE_CODE (TREE_VALUE (parm)) == TYPE_DECL)
  && !(arg && ARGUMENT_PACK_P (arg)))
 {
  /* Some arguments will be placed in the

would not go a long way toward resolving the problem. Passes testing, seems a
safe change to me.

[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-10
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
I guess for this warning we don't have anything like predicate-aware analysis
that would find out that while we have:
...
   [local count: 484313586]:
  # unum_167 = PHI 
  # iftmp.1_152 = PHI 
  # PT = null { D.3872 D.3873 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  # u_154 = PHI <0B(39), u_87(41)>
  _19 = *iftmp.1_152;
...
  # PT = nonlocal
  iftmp.1_174 = separator_63(D) + 1;
...
  # PT = nonlocal null
  # iftmp.1_113 = PHI <0B(11), iftmp.1_119(42)>
we have also:
  _25 = iftmp.1_113 != 0B;
  _130 = error_msg_46 == 0B;
  _127 = _25 & _130;
  if (_127 != 0)
goto ; [100.00%]
  else
goto ; [0.00%]
in bb 41 and thus iftmp.1_113 is known to be non-NULL.

[Bug c++/69549] Named Address Spaces does not compile in C++

[js at alien8 dot de]

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

Julian Stecklina  changed:

   What|Removed |Added

 CC||js at alien8 dot de

--- Comment #3 from Julian Stecklina  ---
This is still an issue with 8.3.1.

[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
(In reply to Andreas Schwab from comment #4)
> You get the resolve part for free by opening it.

Thanks.

I'm wondering what the best cross-platform test ought to be.

Maybe something like this to input.c's add_file_to_cache_tab:

  int fd = fileno (fp);
  if (fstat (fd, ) == -1)
{
  /* reject due to error */
  fclose (fp);
  return NULL;
}
  if (!S_ISREG(buf.st_mode))
{
  /* reject: not a regular file */
  fclose (fp);
  return NULL;
}
  /* carry on */

input.c is re-reading the source file after the frontend has already opened it,
so this isn't going to work for pipes, and, as you mention, the resolution of
symlinks already happened when fp was opened.

[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
URL||https://bugzilla.redhat.com
   ||/show_bug.cgi?id=1698478
  Known to work||8.3.0
 Blocks||86172
  Known to fail||9.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r269302:

r269302 | rguenth | 2019-03-01 04:21:30 -0500 (Fri, 01 Mar 2019) | 16 lines

2019-03-01  Richard Biener  

PR middle-end/89497
* tree-cfgcleanup.h (cleanup_tree_cfg): Add SSA update flags
argument, defaulted to zero.
* passes.c (execute_function_todo): Pass down SSA update flags
to cleanup_tree_cfg.
* tree-cfgcleanup.c: Include tree-into-ssa.h and tree-cfgcleanup.h.
(cleanup_tree_cfg_noloop): After cleanup_control_flow_pre update SSA
form if requested.
(cleanup_tree_cfg): Get and pass down SSA update flags.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference

[Bug middle-end/90037] New: [9 Regression] -Wnull-dereference false positive after r269302

[msebor at gcc dot gnu.org]

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

Bug ID: 90037
   Summary: [9 Regression] -Wnull-dereference false positive after
r269302
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46134=edit
Test case.

The false positive for the attached test case was reported in 
https://bugzilla.redhat.com/show_bug.cgi?id=1698478:

$ gcc -O2 -S -Wall -Wextra -Wnull-dereference bz1698478.c
bz1698478.c: In function ‘parse_with_separator’:
bz1698478.c:121:14: warning: potential null pointer dereference
[-Wnull-dereference]
  121 |   grp = (*g == '+' ? 0 : getgrnam (g));
  |  ^~

[Bug preprocessor/89971] [8/9 Regression] ICE: unspellable token PADDING

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'm afraid I need to give up on this.  While PR30805 added some code not to
abort even earlier on this, it aborts during diagnostics later, while I believe
it should be accepted.  Unfortunately
#define a(x) int b /##x;
a()
doesn't even go through the paste_all_tokens path, the PASTE_LEFT is lost
somewhere much earlier and I can't figure out where.

[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(gdb) call fileno(c->fp)
$3 = 4
(gdb) info inferior
  Num  Description   Executable
* 1process 35251 /home/david/coding-3/gcc-git-bugfixing/build/gcc/cc1 
(gdb) shell ls -al /proc/35251/fd
total 0
dr-x--. 2 david david  0 Apr 10 12:02 .
dr-xr-xr-x. 9 david david  0 Apr 10 12:02 ..
lrwx--. 1 david david 64 Apr 10 12:02 0 -> /dev/pts/8
lrwx--. 1 david david 64 Apr 10 12:02 1 -> /dev/pts/8
lrwx--. 1 david david 64 Apr 10 12:02 2 -> /dev/pts/8
l-wx--. 1 david david 64 Apr 10 12:02 3 -> /tmp/ccE3XfON.s
lr-x--. 1 david david 64 Apr 10 12:02 4 -> /dev/pts/8

which shows that I can type at the terminal during the hang, and then Ctrl-D to
inject what the content of "/dev/stdout" should be:

$ ./xgcc -B. -c ../../src/pr90034.c
Hello world
/dev/stdout:1:2: error: invalid preprocessing directive #def; did you mean
#ifdef?
1 | Hello world
  |  ^~~
  |  ifdef

[Bug c++/51277] Feature request: improve C++ diagnostic for ambiguous overloads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

Summary|Feature request: C++|Feature request: improve
   |diagnostic for ambiguous|C++ diagnostic for
   |overloads   |ambiguous overloads

--- Comment #4 from Eric Gallager  ---
retitling to clarify that this isn't about adding a new diagnostic, but rather
improving an existing one

[Bug sanitizer/89832] confusing error message when there is a problem with ASAN_OPTIONS "ERROR: expected '='"

[qinzhao at gcc dot gnu.org]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
one question to Martin:
has the proposed patch been committed in gcc9 upstream?

my understanding is the proposed patch is for LLVM source base, not for GCC.
are you planning to port the patch to gcc9?

[Bug other/89395] libiberty: heap buffer overflow in nm

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nickc at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Nick Clifton  ---
The patch recently applied for PR 89394 also appears to fix this PR.

[Bug target/90024] [7/8 Regression] ICE on AArch32 NEON mov with TImode constant.

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

   Target Milestone|7.5 |7.6

[Bug c/90036] New: False positive: directive argument is null [-Werror=format-overflow=]

[dilyan.palauzov at aegee dot org]

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

Bug ID: 90036
   Summary: False positive: directive argument is null
[-Werror=format-overflow=]
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

See https://sourceware.org/bugzilla/show_bug.cgi?id=24440:

Compiling most recent binutils (git/master - commit
b05971a652c35ed72d3c95290e18) with gcc 8.3.1 20190330 fails with:

make[4]: Entering directory '/root/binutils/binutils'
gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/binutils  -I.
-I/git/binutils-gdb/binutils -I../bfd -I/git/binutils-gdb/binutils/..
/bfd -I/git/binutils-gdb/binutils/../include
-DLOCALEDIR="\"/usr/local/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulat
ion  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -Werror  -O2 -pipe -g -MT wrstabs.o -MD -M
P -MF .deps/wrstabs.Tpo -c -o wrstabs.o /git/binutils-gdb/binutils/wrstabs.c
/git/binutils-gdb/binutils/wrstabs.c: In function ‘stab_start_class_type’:
/git/binutils-gdb/binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is
null [-Werror=format-overflow=]
sprintf (vtable, "~%%%s", vstring);
 ^~
cc1: all warnings being treated as errors
make[4]: *** [Makefile:1061: wrstabs.o] Error 1

The code snippet is:
  vtable = (char *) xmalloc (strlen (vstring) + 3); 
  sprintf (vtable, "~%%%s", vstring);   
  free (vstring);   

Comment 1 (https://sourceware.org/bugzilla/show_bug.cgi?id=24440#c1) says:

> That doesn't make sense.  vstring must be non-null since it has been passed 
> to strlen already.

[Bug target/90024] [7/8 Regression] ICE on AArch32 NEON mov with TImode constant.

[matmal01 at gcc dot gnu.org]

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

Matthew Malcomson  changed:

   What|Removed |Added

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

--- Comment #5 from Matthew Malcomson  ---
Fixed

[Bug other/89394] libiberty :stack overflow in nm

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #8 from Nick Clifton  ---
The patch has now been committed.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[dimula73 at gmail dot com]

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

--- Comment #27 from Dmitry Kazakov  ---
As a workaround, one can either use __attribute__((always_inline)) for *all*
the functions accepting __m256 or pass *all* arguments by const-ref. Const-ref
arguments are passed correctly.

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[dimula73 at gmail dot com]

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

--- Comment #26 from Dmitry Kazakov  ---
Created attachment 46133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46133=edit
Test source for unaligned pass-by-value crash

Test file for the comment above

[Bug target/54412] minimal 32-byte stack alignment with -mavx on 64-bit Windows

[dimula73 at gmail dot com]

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

Dmitry Kazakov  changed:

   What|Removed |Added

 CC||dimula73 at gmail dot com

--- Comment #25 from Dmitry Kazakov  ---
Hi, all!

I would like to add one more test file, related to the problem. If GCC tries to
call a function, that accepts a __m256 register as a parameter, it unloads this
parameter into the stack using an **aligned** move (vmovaps), but the alignment
guarantee on Windows is only 16-byte. It means that the application will crash
because of unaligned memory access.

Affected versions: GCC 7.3.0 (MinGW64), GCC 8.1.0 (MinGW64)

Here is the testing source (see also in an attachment):

#include 

struct X { 
alignas(32) __m256 d;
};

void g1(X);
void g2(const X&);
void g3(const void *);

void f(float *ptr) {
X x = {_mm256_load_ps(ptr)};
g1(x);  // BUG: passes via unaligned (whatever rsp alignment is) stack
g2(x);  // OK: passes via aligned stack location
g3(); // OK: passes via aligned stack location
}


Compiled result (-O2 -march=skylake):

_Z1fPf:
.LFB5135:
pushq   %rbx
.seh_pushreg%rbx
addq$-128, %rsp
.seh_stackalloc 128
.seh_endprologue
vmovaps (%rcx), %ymm0
leaq95(%rsp), %rbx
leaq32(%rsp), %rcx
andq$-32, %rbx
vmovaps %ymm0, (%rbx)# %rbx is properly aligned 
vmovaps %ymm0, 32(%rsp)  # %rsp may be unaligned
vzeroupper
call_Z2g11X
movq%rbx, %rcx
call_Z2g2RK1X
movq%rbx, %rcx
call_Z2g3PKv
nop
subq$-128, %rsp
popq%rbx
ret

Related bug in Vc library: https://github.com/VcDevel/Vc/issues/241
Related bug in Krita: https://bugs.kde.org/show_bug.cgi?id=406209

[Bug other/89394] libiberty :stack overflow in nm

[nickc at gcc dot gnu.org]

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

--- Comment #7 from Nick Clifton  ---
Author: nickc
Date: Wed Apr 10 14:44:47 2019
New Revision: 270258

URL: https://gcc.gnu.org/viewcvs?rev=270258=gcc=rev
Log:
Fix a stack exhaustion bug in libiberty's demangler when decoding a
pathalogically constructed mangled name.

PR 89394
* cp-demangle.c (cplus_demangle_fill_name): Reject negative
lengths.
(d_count_templates_scopes): Replace num_templates and num_scopes
parameters with a struct d_print_info pointer parameter.  Adjust
body of the function accordingly.  Add recursion counter and check
that the recursion limit is not reached.
(d_print_init): Pass dpi parameter to d_count_templates_scopes.
Reset recursion counter afterwards, unless the recursion limit was
reached.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c

[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file

[sch...@linux-m68k.org]

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

--- Comment #4 from Andreas Schwab  ---
You get the resolve part for free by opening it.

[Bug preprocessor/90034] gcc hangs on wait4 after vfork after opening tmp file

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to Richard Biener from comment #2)
[...]
> 
> Smaller testcase that will hang:
> 
> #line 1 "/dev/stdout"
> #def xy

Presumably we're blocked, waiting on ourselves to write something to our
stdout so that we can read it.

I was able to reproduce this hang with gcc 4.8.3, so this isn't a regression.

> we should probably check whether the file we opened is a regular file
> before trying to read from it.
[...]

$ ll /dev/stdout
lrwxrwxrwx. 1 root root 15 Nov 26 09:29 /dev/stdout -> /proc/self/fd/1

$ ll /proc/self/fd/1
lrwx--. 1 david david 64 Apr 10 11:13 /proc/self/fd/1 -> /dev/pts/8

$ ll /dev/pts/8
crw--w. 1 david tty 136, 8 Apr 10 11:14 /dev/pts/8

Presumably we ought to support source "files" that are symlinks; should we
resolve all symlinks before opening, and then require the result to be a
regular file?

Or some other kind of sanity-checking?

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
CCing Segher and Vlad on this if they want to comment on that further.

[Bug translation/90035] Non-translatable C++ parser diagnostics

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-10
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46132=edit
gcc9-pr90035.patch

Untested fix.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
It is not a matter of efficiency, but primarily that RA can't do anything in
many cases after propagating hard registers into instructions.  This PR is just
one of the many cases.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Well, often sel-sched just does not discriminate hardregs and pseudos when
checking if renaming/substitution may be applied. Sure, as a matter of
efficiency we should probably disallow substitution through such mixed
pseudo=hardreg assignments.

Nevertheless, if it's not only a matter of optimization, but also of internal
consistency, then I'd like to understand it better. Hence the question in
comment #2.

[Bug target/90024] [7/8 Regression] ICE on AArch32 NEON mov with TImode constant.

[matmal01 at gcc dot gnu.org]

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

--- Comment #4 from Matthew Malcomson  ---
Author: matmal01
Date: Wed Apr 10 13:41:21 2019
New Revision: 270254

URL: https://gcc.gnu.org/viewcvs?rev=270254=gcc=rev
Log:
Backport of r270226 from mainline to gcc-8-branch


The "*neon_mov" patterns for 128 bit sized quantities uses the "Dn"
constraint to match vmov.f32 and vmov.i patterns.
This constraint boils down to using the `neon_immediate_valid` function.
Once the constraint has matched, the output C statement asserts that function
passes.

The output C statement calls `neon_immediate_valid` with the mode taken from
the
iterator, while the constraint takes the mode from the operand.
This can cause a discrepency when the operand is a CONST_INT, as the constraint
passes VOIDmode which `neon_immediate_valid` treats as DImode, while the C
statement passes the mode of the iterator which can be TImode.
When this happens, the `neon_immediate_valid` can fail in the second call (if
e.g. the CONST_INT is a valid immediate in DImode but not TImode) which would
trigger the assertion.

The testcase added with this patch triggers this when compiled with an arm
cross
compiler using the command line below.
gcc -march=armv8-a -c neon-immediate-timode.c -O1 -mfloat-abi=hard
-mfpu=neon-fp-armv8

This patch splits the original "Dn" constraint into three new constraints, "DN"
for TImode CONST_INT, "Dn" for DImode CONST_INT, and "Dm" for CONST_VECTOR.
Splitting things up this way requires using one extra alternative in the
"*neon_mov" patterns, but makes it clear from the constraint what mode is
being used.

We also remove the behaviour of treating VOIDmode as DImode in
`neon_valid_immediate` since the original "Dn" constraint was the only place
that functionality was used.  VOIDmode is now never passed to that function.
An assertion has been added to the function to ensure this problem is caught
earlier on.

bootstrapped and regtested on arm-none-linux-gnueabihf

gcc/ChangeLog:

2019-04-10  Matthew Malcomson  

PR target/90024
* config/arm/arm.c (neon_valid_immediate): Disallow VOIDmode parameter.
* config/arm/constraints.md (Dm, DN, Dn): Split previous Dn constraint
into three.
* config/arm/neon.md (*neon_mov): Account for TImode and DImode
differences directly.
(*smax3_neon, vashl3, vashr3_imm): Use Dm constraint.

gcc/testsuite/ChangeLog:

2019-04-10  Matthew Malcomson  

PR target/90024
* gcc.dg/torture/neon-immediate-timode.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/neon-immediate-timode.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/arm/arm.c
branches/gcc-8-branch/gcc/config/arm/constraints.md
branches/gcc-8-branch/gcc/config/arm/neon.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/90024] [7/8 Regression] ICE on AArch32 NEON mov with TImode constant.

[matmal01 at gcc dot gnu.org]

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

--- Comment #3 from Matthew Malcomson  ---
Author: matmal01
Date: Wed Apr 10 13:34:54 2019
New Revision: 270253

URL: https://gcc.gnu.org/viewcvs?rev=270253=gcc=rev
Log:
Backport of r270226 from mainline to gcc-7-branch

The "*neon_mov" patterns for 128 bit sized quantities uses the "Dn"
constraint to match vmov.f32 and vmov.i patterns.
This constraint boils down to using the `neon_immediate_valid` function.
Once the constraint has matched, the output C statement asserts that function
passes.

The output C statement calls `neon_immediate_valid` with the mode taken from
the
iterator, while the constraint takes the mode from the operand.
This can cause a discrepency when the operand is a CONST_INT, as the constraint
passes VOIDmode which `neon_immediate_valid` treats as DImode, while the C
statement passes the mode of the iterator which can be TImode.
When this happens, the `neon_immediate_valid` can fail in the second call (if
e.g. the CONST_INT is a valid immediate in DImode but not TImode) which would
trigger the assertion.

The testcase added with this patch triggers this when compiled with an arm
cross
compiler using the command line below.
gcc -march=armv8-a -c neon-immediate-timode.c -O1 -mfloat-abi=hard
-mfpu=neon-fp-armv8

This patch splits the original "Dn" constraint into three new constraints, "DN"
for TImode CONST_INT, "Dn" for DImode CONST_INT, and "Dm" for CONST_VECTOR.
Splitting things up this way requires using one extra alternative in the
"*neon_mov" patterns, but makes it clear from the constraint what mode is
being used.

We also remove the behaviour of treating VOIDmode as DImode in
`neon_valid_immediate` since the original "Dn" constraint was the only place
that functionality was used.  VOIDmode is now never passed to that function.
An assertion has been added to the function to ensure this problem is caught
earlier on.

bootstrapped and regtested on arm-none-linux-gnueabihf

gcc/ChangeLog:

2019-04-10  Matthew Malcomson  

PR target/90024
* config/arm/arm.c (neon_valid_immediate): Disallow VOIDmode parameter.
* config/arm/constraints.md (Dm, DN, Dn): Split previous Dn constraint
into three.
* config/arm/neon.md (*neon_mov): Account for TImode and DImode
differences directly.
(*smax3_neon, vashl3, vashr3_imm): Use Dm constraint.

gcc/testsuite/ChangeLog:

2019-04-10  Matthew Malcomson  

PR target/90024
* gcc.dg/torture/neon-immediate-timode.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/neon-immediate-timode.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm.c
branches/gcc-7-branch/gcc/config/arm/constraints.md
branches/gcc-7-branch/gcc/config/arm/neon.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug translation/90035] New: Non-translatable C++ parser diagnostics

[jakub at gcc dot gnu.org]

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

Bug ID: 90035
   Summary: Non-translatable C++ parser diagnostics
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

tmp = concat ("types may not be defined in %<",
IDENTIFIER_POINTER (ridpointers[keyword]),
"%> expressions", NULL);
is not translatable.

[Bug tree-optimization/90018] [7/8/9 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Created attachment 46131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46131=edit
patch for GCC 9

So trunk, instead of grouping (a) and (b) groups (d) and (b), leaving (a)
alone.

  for (int i = 0; i < n; ++i)
{
  /* We may not apply interleaving to the group (a), (b) because of (c). 
*/
  double tem1 = a4[i*4] + a4[i*4+n*4] /* (a) */;
  double tem2 = a4[i*4+2*n*4+1];
  a4[i*4+n*4+1] = tem1; /* (c) */
  a4[i*4+1] = tem2;
  double tem3 = a4[i*4] - tem2;
  double tem4 = tem3 + a4[i*4+n*4];
  a4[i*4+n*4+1] = tem4 + a4[i*4+n*4+1] /* (b) */;
}

[Bug c++/89875] [7/8/9 Regression] invalid typeof reference to a member of an incomplete struct accepted at function scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-10
 CC||jakub at gcc dot gnu.org,
   ||paolo at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/90030] Fortran OMP array data alignment

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openmp
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-10
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
Summary|Fortran OpenACC subarray|Fortran OMP array data
   |data alignment  |alignment
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Reduced test case, added OpenMP variant.

.

[Bug tree-optimization/90018] [7/8/9 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
Created attachment 46130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46130=edit
patch for GCC 8

I am testing the attached, now forward-porting to GCC 9.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[iains at gcc dot gnu.org]

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

--- Comment #62 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #61)
> (In reply to Jonathan Wakely from comment #60)
> > PR 81797 was the relevant bug, which apparently is still present for darwin
> > when using the buggy new APFS filesystem
> 
> so, from discussion on IRC, and notes above, this seems to be a known issue
> (with AFPS only) and the current remedy is to continue the bootstrap.
> 
> Let's consider that we have a viable work-around and then please can we wait
> for a response from Apple and the clang devs before making a final fix?
> 
> (i.e. this is enough of a work-around to prevent folks from being blocked
> right now)

BTW if you look at
https://godbolt.org/z/7nwoLN
and flip between C and C++, you will see that clang++ is not generating the
same code for _Atomic int x, as clang (C).  In fact, it looks like the
storage-class might well be accepted but ignored.  If that's the case, the the
right fix is probably to substitute volatile unconditionally for C++.

(that is, the right guard would be Jakub's suggestion from comment #48)

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Why does sel-sched try to propagate hard registers into insns before RA?  The
whole point of the combiner changes was not to do that, so that the RA can do
better job.

[Bug rtl-optimization/89965] [8/9 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Created attachment 46129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46129=edit
gcc9-pr89965.patch

Untested fix.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[iains at gcc dot gnu.org]

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

--- Comment #61 from Iain Sandoe  ---
(In reply to Jonathan Wakely from comment #60)
> PR 81797 was the relevant bug, which apparently is still present for darwin
> when using the buggy new APFS filesystem

so, from discussion on IRC, and notes above, this seems to be a known issue
(with AFPS only) and the current remedy is to continue the bootstrap.

Let's consider that we have a viable work-around and then please can we wait
for a response from Apple and the clang devs before making a final fix?

(i.e. this is enough of a work-around to prevent folks from being blocked right
now)

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[redi at gcc dot gnu.org]

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

--- Comment #60 from Jonathan Wakely  ---
PR 81797 was the relevant bug, which apparently is still present for darwin
when using the buggy new APFS filesystem.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #21 from Ferruh YIGIT  ---
(In reply to Jakub Jelinek from comment #19)
> Upstream 2.31 and 2.31.1 is affected too, but 2.31 branch starting with
> August 2018 is not affected.  As the fix has been backported also to 2.30
> branch, I guess 2.30 is affected too, 2.32 is not affected.  Dunno about
> older binutils, you'll need to try.

Thanks.

We already have another problem with 2.30 and disabling avx512 for that case,
it seems we will need to extend it to 2.31 & 2.31.1 too, thanks.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #20 from Ferruh YIGIT  ---
Confirmed that issue is fixed with the latest assembler [1].

[1]
as --version
GNU assembler (GNU Binutils) 2.32.51.20190410?

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[juergen.reuter at desy dot de]

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

--- Comment #59 from Jürgen Reuter  ---
Yes, to me this looks also like an independent problem, and it appears to me
like a sort of race condition. I also just restarted the bootstrap (without a
parallel make). Now I have to do some theoretical physics, will know more
tonight.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[dominiq at lps dot ens.fr]

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

--- Comment #58 from Dominique d'Humieres  ---
> No such file or directory
>31 | #include 
>   |  ^~~~
> compilation terminated.

I think this is an older issue (on SSD?) for which there is already a filed PR.

When I hit this snag, I just resume the bootstrap process.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[iains at gcc dot gnu.org]

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

--- Comment #57 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #56)
> I tried the fix, but now I get another error:
> /libstdc++-v3/../libgcc
> -I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/
> libstdc++-v3/include/x86_64-apple-darwin18.5.0
> -I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/
> libstdc++-v3/include
> -I/usr/local/packages/gcc_9.0_fixincl/libstdc++-v3/libsupc++ -std=gnu++17
> -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
> -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
> -fdata-sections -frandom-seed=fs_dir.lo -fimplicit-templates -g -O2 -m32 -c
> ../../../../../../libstdc++-v3/src/c++17/fs_dir.cc  -fno-common -DPIC
> -D_GLIBCXX_SHARED -o fs_dir.o
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:31:10: fatal error:
> filesystem: No such file or directory
>31 | #include 
>   |  ^~~~
> compilation terminated.

so, to be clear, it worked for the 8.x branch and you see a different issue for
trunk.

what stage is this at, and what version of trunk is it?

[Bug gcov-profile/89959] gcov: "--long-file-names" is ignored when used in combination with "--hash-filenames"

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Documentation fix applied, closing.

[Bug gcov-profile/89959] gcov: "--long-file-names" is ignored when used in combination with "--hash-filenames"

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Wed Apr 10 11:44:08 2019
New Revision: 270251

URL: https://gcc.gnu.org/viewcvs?rev=270251=gcc=rev
Log:
Make gcov docs more precise (PR gcov-profile/89959).

2019-04-10  Martin Liska  

PR gcov-profile/89959
* doc/gcov.texi: Make documentation of -x option
more precise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi

[Bug tree-optimization/90018] [7/8/9 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.4 |7.5
Summary|[8 Regression] r265453  |[7/8/9 Regression] r265453
   |miscompiled 527.cam4_r in   |miscompiled 527.cam4_r in
   |SPEC CPU 2017   |SPEC CPU 2017

--- Comment #16 from Richard Biener  ---
The patch was backported further.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Upstream 2.31 and 2.31.1 is affected too, but 2.31 branch starting with August
2018 is not affected.  As the fix has been backported also to 2.30 branch, I
guess 2.30 is affected too, 2.32 is not affected.  Dunno about older binutils,
you'll need to try.

[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
So the issue is really that for

  for (int i = 0; i < n; ++i)
{
  double tem1 = a4[i*4] + a4[i*4+n*4] (**);
  double tem2 = a4[i*4+2*n*4+1];
  a4[i*4+n*4+1] = tem1;
  a4[i*4+1] = tem2;
  double tem3 = a4[i*4] - tem2;
  double tem4 = tem3 + a4[i*4+n*4];
  a4[i*4+n*4+1] = tem3 + a4[i*4+n*4+1] (**);
}

we detect an interleaving load for (**) and emit it before the
later strided store to a4[i*4+n*4+1].

This issue is that vect_preserves_scalar_order_p expects to the
vectorization will happen via SLP but we will end up doing interleaving
which does not perform the load in place of the last load but in place
of ->first_element.  Unfortunately SLP analysis is done _after_
dependence analysis.  That means we have to conservatively assume both
paths may happen.

Fixed testcase:

void __attribute__((noinline,noclone))
foo (double *a4, int n)
{
  for (int i = 0; i < n; ++i)
{
  double tem1 = a4[i*4] + a4[i*4+n*4];
  double tem2 = a4[i*4+2*n*4+1];
  a4[i*4+n*4+1] = tem1;
  a4[i*4+1] = tem2;
  double tem3 = a4[i*4] - tem2;
  double tem4 = tem3 + a4[i*4+n*4];
  a4[i*4+n*4+1] = tem4 + a4[i*4+n*4+1];
}
}
int main(int argc, char **argv)
{
  int n = 11;
  double a4[4 * n * 8];
  double a42[4 * n * 8];
  for (int i = 0; i < 4 * n * 8; ++i)
a4[i] = a42[i] = i;
  foo (a4, n);
  for (int i = 0; i < n; ++i)
{
  double tem1 = a42[i*4] + a42[i*4+n*4];
  double tem2 = a42[i*4+2*n*4+1];
  a42[i*4+n*4+1] = tem1;
  a42[i*4+1] = tem2;
  double tem3 = a42[i*4] - tem2;
  double tem4 = tem3 + a42[i*4+n*4];
  a42[i*4+n*4+1] = tem4 + a42[i*4+n*4+1];
  __asm__ volatile ("": : : "memory");
}
  for (int i = 0; i < 4 * n * 8; ++i)
if (a4[i] != a42[i])
  __builtin_abort ();
  return 0;
}

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #18 from Ferruh YIGIT  ---
(In reply to Nick Clifton from comment #17)
> (In reply to Jakub Jelinek from comment #8)
> > Fedora binutils-2.31.1-24.fc29.x86_64 has the bug, haven't checked upstream
> > 2.31.1 nor which exact patch fixed it.
> 
> FYI - binutils-2.31.1-25.fc29.x86_64 now contains the patch.
> 
> Cheers
>   Nick

Thanks Nick.

Can it be possible to get range of affected versions, so that we can provide
protection for them?

btw, are all binutils-2.31 affected, or fedora packge only?

Thanks,
ferruh

[Bug rtl-optimization/90026] [8/9 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
So it's a bit older:

$ cat pr90026.cc
void *operator new(__SIZE_TYPE__, void *) {__builtin_unreachable (); }
struct e {
  int *b;
  ~e() { delete b; }
};
void bar();
void foo() {
  e a;
  if (a.b)
a.b = new int();
  bar();
  new (0) void *;
}

$ g++ -c -fnon-call-exceptions -ftracer -O2 -fchecking pr90026.cc
pr90026.cc: In function ‘void foo()’:
pr90026.cc:13:1: error: missing barrier after block 2
   13 | }
  | ^
during RTL pass: outof_cfglayout
pr90026.cc:13:1: internal compiler error: verify_flow_info failed
0xb0309b verify_flow_info()
/home/marxin/Programming/gcc/gcc/cfghooks.c:265
0xb1c961 execute
/home/marxin/Programming/gcc/gcc/cfgrtl.c:3622

Started with r249070, but it's probably just a tracer influencing commit.
I'm unassigning.

[Bug libstdc++/89851] [9 Regression] std::variant comparison operators violate [variant.relops]

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Wed Apr 10 10:43:39 2019
New Revision: 270249

URL: https://gcc.gnu.org/viewcvs?rev=270249=gcc=rev
Log:
PR libstdc++/89851 Add testcase for std::variant equality

Add a test for the regression introduced with r269422 and fixed with
r270056.

PR libstdc++/89851
* testsuite/20_util/variant/89851.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/variant/89851.cc
Modified:
trunk/libstdc++-v3/ChangeLog

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at gcc dot gnu.org

--- Comment #17 from Nick Clifton  ---
(In reply to Jakub Jelinek from comment #8)
> Fedora binutils-2.31.1-24.fc29.x86_64 has the bug, haven't checked upstream
> 2.31.1 nor which exact patch fixed it.

FYI - binutils-2.31.1-25.fc29.x86_64 now contains the patch.

Cheers
  Nick

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[bernd.edlinger at hotmail dot de]

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

--- Comment #37 from Bernd Edlinger  ---
If a non-general-regs-only function is called from here,
it will only preserve d8-d15, and the call-clobbered registers
d0-d7 would of course be modified.
But is that a problem at all, if the call-clobbered registers are not restored?

[Bug target/90016] aarch64: reference to undeclared N in help for command line option

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Earnshaw  ---
Fixed

[Bug target/90016] aarch64: reference to undeclared N in help for command line option

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
Author: rearnsha
Date: Wed Apr 10 09:51:16 2019
New Revision: 270248

URL: https://gcc.gnu.org/viewcvs?rev=270248=gcc=rev
Log:
[aarch64] PR90016 - aarch64: reference to undeclared N in help for command line
option

'to N' is now redundant and misleading given the earlier change to use
.

Removed.

PR target/90016
* config/aarch64/aarch64.opt (msve-vector-bits): Remove redundant and
obsolete reference to N.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.opt

[Bug tree-optimization/90018] [8 Regression] r265453 miscompiled 527.cam4_r in SPEC CPU 2017

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #14 from Richard Biener  ---
So the important difference when comparing patched/unpatched is the unpatched
compiler rejected vectorization with

mapz_module.fppized.f90:730:0: note: dependence distance == 0 between
*a4_627(D)[_196] and *a4_627(D)[_196]
mapz_module.fppized.f90:730:0: note: READ_WRITE dependence in interleaving.
mapz_module.fppized.f90:730:0: note: bad data dependence.

while the patched compiler is happy.  That points to the patched function
and it's call here:

static bool
vect_analyze_data_ref_dependence (struct data_dependence_relation *ddr,
  loop_vec_info loop_vinfo,
  unsigned int *max_vf)
{ 
...
  if (dist == 0) 
{   
...
  if (!vect_preserves_scalar_order_p (DR_STMT (dra), DR_STMT (drb)))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "READ_WRITE dependence in interleaving.\n");
  return true;

it's probably failure to factor in unrolling that breaks this case.

The unvectorized loop body looks like (all but relevant loads/stores elided):

   [local count: 118111594]:
  # i_313 = PHI <_1(19), i_293(24)>
  _146 = *a4_255(D)[_145];
  _152 = *a4_255(D)[_151];
  _165 = *a4_255(D)[_164];
  *a4_255(D)[_194] = _195;
  *a4_255(D)[_201] = _202;
  _203 = *a4_255(D)[_145];
  _290 = *a4_255(D)[_151];
  _291 = *a4_255(D)[_194];
  *a4_255(D)[_194] = M.42_316;
  i_293 = i_313 + 1;
  if (_2 < i_293)

final runtime alias checks are:

create runtime check for data references *a4_255(D)[_151] and *a4_255(D)[_201]
create runtime check for data references *a4_255(D)[_194] and *a4_255(D)[_164]
create runtime check for data references *a4_255(D)[_194] and *a4_255(D)[_145]
create runtime check for data references *a4_255(D)[_164] and *a4_255(D)[_201]

and groups are

note: Detected interleaving load *a4_255(D)[_151] and *a4_255(D)[_194]
note: Detected interleaving load of size 4 starting with _152 =
*a4_255(D)[_151];
note: There is a gap of 2 elements after the group
note: Detected single element interleaving *a4_255(D)[_151] step 32
note: not consecutive access *a4_255(D)[_194] = _195;
note: using strided accesses
note: not consecutive access *a4_255(D)[_194] = M.42_316;
note: using strided accesses
note: Detected single element interleaving *a4_255(D)[_164] step 32
note: Detected single element interleaving *a4_255(D)[_145] step 32
note: Detected single element interleaving *a4_255(D)[_145] step 32
note: not consecutive access *a4_255(D)[_201] = _202;
note: using strided accesses

so there's no SLP involved.

The respective loop doesn't involve a reduction so -ffast-math shouldn't be
required here, only -ffinite-math-only for min/max recognition.

A C testcase mimicing the memory accesses and failing is

void __attribute__((noinline,noclone))
foo (double *a4, int n)
{
  for (int i = 0; i < n; ++i)
{
  double tem1 = a4[i*4] + a4[i*4+n];
  double tem2 = a4[i*4+2*n+1];
  a4[i*4+n+1] = tem1;
  a4[i*4+1] = tem2;
  double tem3 = a4[i*4] - a4[i*4+1];
  double tem4 = tem3 + a4[i*4+n];
  a4[i*4+n+1] = tem3 + a4[i*4+n+1];
}
}

int main()
{
  const int n = 5;
  double a4[4 * n * 8];
  double a42[4 * n * 8];
  for (int i = 0; i < 4 * n * 8; ++i)
a4[i] = a42[i] = i;
  foo (a4, n);
  for (int i = 0; i < n; ++i)
{
  double tem1 = a42[i*4] + a4[i*4+n];
  double tem2 = a42[i*4+2*n+1];
  a42[i*4+n+1] = tem1;
  a42[i*4+1] = tem2;
  double tem3 = a42[i*4] - a42[i*4+1];
  double tem4 = tem3 + a42[i*4+n];
  a42[i*4+n+1] = tem3 + a42[i*4+n+1];
  __asm__ volatile ("": : : "memory");
}
  for (int i = 0; i < 4 * n * 8; ++i)
if (a4[i] != a42[i])
  __builtin_abort ();
  return 0;
}

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=24434
 Resolution|--- |MOVED

--- Comment #16 from Martin Liška  ---
Moved.

[Bug tree-optimization/65930] Reduction with sign-change not handled

[tnfchris at gcc dot gnu.org]

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

--- Comment #12 from Tamar Christina  ---
> If you have some clever ideas make sure to outline a patch
> before finalizing it so you won't be disappointed by negative feedback ;)

I'll be sure to do that with this and the other changes I intend to tackle! :)

[Bug tree-optimization/88259] vectorization failure for a typical loop for getting max value and index

[tnfchris at gcc dot gnu.org]

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

--- Comment #7 from Tamar Christina  ---
> Note that ripping out non-SLP support from the vectorizer will turn
> reduction support upside down ... which means the work will heavily
> conflict, either me or you needing to re-do stuff.

Fair enough, thanks for the heads up!

[Bug tree-optimization/86504] vectorization failure for a nest loop

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/86504] vectorization failure for a nest loop

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #7 from Tamar Christina  ---
Cheers, Thanks Richard, I'll grab this one too then.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
Fixed in bintuils with:

commit 629cfaf1b0fbb32a985607c774bd8e7870b9fa94 (HEAD, refs/bisect/bad)
Author: Jan Beulich 
Date:   Mon Jul 30 17:25:05 2018 +0200

x86: don't mistakenly scale non-8-bit displacements

In commit b5014f7af2 I've removed (instead of replaced) a conditional,
resulting in addressing forms not allowing 8-bit displacements to now
get their displacements scaled under certain circumstances. Re-add the
missing conditional.

Minimal reproducer:

$ cat min.s
.text
foo:
vpgatherqq  8(,%ymm1,1), %ymm0{%k2}

$ ./gas/as-new --64 min.s -o avx512.o && ./binutils/objdump -S avx512.o

avx512.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   62 f2 fd 2a 91 04 0dvpgatherqq 0x1(,%ymm1,1),%ymm0{%k2}
   7:   01 00 00 00

[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #35)
> (In reply to Bernd Edlinger from comment #33)
> > (In reply to Ramana Radhakrishnan from comment #32)
> > > 
> > > Either I drop the warning or I keep the hunk in eh_personality.cc - any
> > > preferences / thoughts ?
> > 
> > It would feel safer, if only the functions that need it
> > had a target attribute like:
> > 
> > _Unwind_Reason_Code
> > #ifdef __ARM_EABI_UNWINDER__
> > __attribute__((target("general-regs-only")))
> > PERSONALITY_FUNCTION (_Unwind_State state,
> >   struct _Unwind_Exception* ue_header,
> >   struct _Unwind_Context* context)
> 
> Agreed - will this work instead?

Aren't there many functions that are inlined into it (then it would be fine)
but could not be inlined (and then it would be a problem, at least in theory)?
Though, if there are inlines that are used in other TUs and those TUs are not
general-regs-only and we decide not to inline, then it might be pure luck if
COMDAT is won bu eh-personality.o versions or some other ones.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
$ as --version
GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.32

is fine:

$ as --64 avx512.s -o avx512.o && objdump -S avx512.o | grep gather
234b:   62 f2 fd 2a 91 04 0dvpgatherqq 0x8(,%ymm1,1),%ymm0{%k2}
235e:   62 f2 fd 2b 91 14 0dvpgatherqq 0x0(,%ymm1,1),%ymm2{%k3}

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #13 from Ferruh YIGIT  ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Ferruh YIGIT from comment #1)
> > Created attachment 46115 [details]
> > 19.05-rc1 -mno-avx512f gcc build on skylake
> > 
> > The build is done with changing the lib/librte_kni/Makefile as following:
> > 
> > + CFLAGS += -mno-avx512f
> 
> (In reply to Ferruh YIGIT from comment #5)
> > Tested with latest gcc [1], same output.
> > 
> > [1] Compiled from source:
> > gcc (GCC) 9.0.1 20190409 (experimental)
> 
> I built rte_kni.i with latest gcc and got
> 
> ...
>   vmovdqu64   (%rsi,%rax), %zmm1
>   kmovw   %k1, %k2
>   vpgatherqq  8(,%zmm1,1), %zmm0{%k2}
>   vpaddq  %zmm1, %zmm0, %zmm0
>   kmovw   %k1, %k3
>   vpgatherqq  0(,%zmm1,1), %zmm2{%k3}
>   vpsubq  %zmm2, %zmm0, %zmm0
>   vmovdqu64   %zmm0, (%rcx,%rax)
> ...
> 
> Can't reproduce the issue you mentioned.
> 
> Could you please upload *.s and *.o with both version(with and without
> -mno-avx512f).

Attached:
gcc_avx512_rte_kni.o
gcc_avx512_rte_kni.s
gcc_NO_avx512_rte_kni.o
gcc_NO_avx512_rte_kni.s

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #12 from Ferruh YIGIT  ---
Created attachment 46128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46128=edit
19.05-rc1 -mno-avx512f gcc build on skylake .s file via --save-temp

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #11 from Ferruh YIGIT  ---
Created attachment 46127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46127=edit
19.05-rc1 -mno-avx512f gcc build on skylake .o file

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #10 from Ferruh YIGIT  ---
Created attachment 46126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46126=edit
19.05-rc1 default gcc build (avx512 enabled) on skylake .s file via
--save-temps

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[ferruh.yigit at intel dot com]

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

--- Comment #9 from Ferruh YIGIT  ---
Created attachment 46125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46125=edit
19.05-rc1 default gcc build (avx512 enabled) on skylake .o file

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[juergen.reuter at desy dot de]

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

--- Comment #56 from Jürgen Reuter  ---
I tried the fix, but now I get another error:
/libstdc++-v3/../libgcc
-I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/libstdc++-v3/include/x86_64-apple-darwin18.5.0
-I/usr/local/packages/gcc_9.0_fixincl/_build/x86_64-apple-darwin18.5.0/i386/libstdc++-v3/include
-I/usr/local/packages/gcc_9.0_fixincl/libstdc++-v3/libsupc++ -std=gnu++17
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=fs_dir.lo -fimplicit-templates -g -O2 -m32 -c
../../../../../../libstdc++-v3/src/c++17/fs_dir.cc  -fno-common -DPIC
-D_GLIBCXX_SHARED -o fs_dir.o
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:31:10: fatal error:
filesystem: No such file or directory
   31 | #include 
  |  ^~~~
compilation terminated.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Fedora binutils-2.31.1-24.fc29.x86_64 has the bug, haven't checked upstream
2.31.1 nor which exact patch fixed it.  But as I said, there is no testcase
coverage for this, so it might break any time again.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Looks like gas bug to me:
vpgatherqq  8(,%ymm1,1), %ymm0{%k2}
vpgatherqq  8(%rcx,%ymm1,1), %ymm0{%k2}
vpgatherqq  %ymm2, 8(,%ymm1,1), %ymm0
vpgatherqq  %ymm2, 8(%rcx,%ymm1,1), %ymm0
when assembled with gas and objdump -d:
   0:   62 f2 fd 2a 91 04 0dvpgatherqq 0x1(,%ymm1,1),%ymm0{%k2}
   7:   01 00 00 00 
   b:   62 f2 fd 2a 91 44 09vpgatherqq 0x8(%rcx,%ymm1,1),%ymm0{%k2}
  12:   01 
  13:   c4 e2 ed 91 04 0d 08vpgatherqq %ymm2,0x8(,%ymm1,1),%ymm0
  1a:   00 00 00 
  1d:   c4 e2 ed 91 44 09 08vpgatherqq %ymm2,0x8(%rcx,%ymm1,1),%ymm0
while when assembled with clang and objdump -d:
   0:   62 f2 fd 2a 91 04 0dvpgatherqq 0x8(,%ymm1,1),%ymm0{%k2}
   7:   08 00 00 00 
   b:   62 f2 fd 2a 91 44 09vpgatherqq 0x8(%rcx,%ymm1,1),%ymm0{%k2}
  12:   01 
  13:   c4 e2 ed 91 04 0d 08vpgatherqq %ymm2,0x8(,%ymm1,1),%ymm0
  1a:   00 00 00 
  1d:   c4 e2 ed 91 44 09 08vpgatherqq %ymm2,0x8(%rcx,%ymm1,1),%ymm0
But trying current binutils trunk assembles it correctly too:
   0:   62 f2 fd 2a 91 04 0dvpgatherqq 0x8(,%ymm1,1),%ymm0{%k2}
   7:   08 00 00 00 
   b:   62 f2 fd 2a 91 44 09vpgatherqq 0x8(%rcx,%ymm1,1),%ymm0{%k2}
  12:   01 
  13:   c4 e2 ed 91 04 0d 08vpgatherqq %ymm2,0x8(,%ymm1,1),%ymm0
  1a:   00 00 00 
  1d:   c4 e2 ed 91 44 09 08vpgatherqq %ymm2,0x8(%rcx,%ymm1,1),%ymm0
That said, strangely even current binutils trunk doesn't have any test coverage
for the EVEX encoded v*gather* instructions with no base register (i.e.
disp(,%[xyz]mm*,*) ) while it has coverage for such AVX2 gathers.

[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong

[crazylht at gmail dot com]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Ferruh YIGIT from comment #1)
> Created attachment 46115 [details]
> 19.05-rc1 -mno-avx512f gcc build on skylake
> 
> The build is done with changing the lib/librte_kni/Makefile as following:
> 
> + CFLAGS += -mno-avx512f

(In reply to Ferruh YIGIT from comment #5)
> Tested with latest gcc [1], same output.
> 
> [1] Compiled from source:
> gcc (GCC) 9.0.1 20190409 (experimental)

I built rte_kni.i with latest gcc and got

...
vmovdqu64   (%rsi,%rax), %zmm1
kmovw   %k1, %k2
vpgatherqq  8(,%zmm1,1), %zmm0{%k2}
vpaddq  %zmm1, %zmm0, %zmm0
kmovw   %k1, %k3
vpgatherqq  0(,%zmm1,1), %zmm2{%k3}
vpsubq  %zmm2, %zmm0, %zmm0
vmovdqu64   %zmm0, (%rcx,%rax)
...

Can't reproduce the issue you mentioned.

Could you please upload *.s and *.o with both version(with and without
-mno-avx512f).

[Bug tree-optimization/65930] Reduction with sign-change not handled

[rguenther at suse dot de]

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

--- Comment #11 from rguenther at suse dot de  ---
On Tue, 9 Apr 2019, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65930
> 
> Tamar Christina  changed:
> 
>What|Removed |Added
> 
>  CC||tnfchris at gcc dot gnu.org
> 
> --- Comment #10 from Tamar Christina  ---
> Hi Richard,
> 
> Do you still plan on working on this? Otherwise I'd like to add it to my list
> of things to do for GCC 10.

I failed to come up with a "nice" way to handle this - everything I
did inside the vectorizer turned out to be a hack (and I don't like
hacks).  If you have some clever ideas make sure to outline a patch
before finalizing it so you won't be disappointed by negative feedback ;)