[Bug tree-optimization/91181] [10 Regression] Failing as_as type conversion in vect_build_slp_tree_1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug tree-optimization/91181] [10 Regression] Failing as_as type conversion in vect_build_slp_tree_1

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 17 07:07:21 2019
New Revision: 273542

URL: https://gcc.gnu.org/viewcvs?rev=273542&root=gcc&view=rev
Log:
2019-07-17  Richard Biener  

PR tree-optimization/91181
* tree-vect-slp.c (vect_build_slp_tree_1): Do not compare
IFN_LOADs as calls.

* gcc.dg/pr91181.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr91181.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-slp.c

[Bug tree-optimization/91157] [10 Regression] ICE: verify_gimple failed (error: position plus size exceeds size of referenced object in 'bit_field_ref')

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 17 07:13:17 2019
New Revision: 273543

URL: https://gcc.gnu.org/viewcvs?rev=273543&root=gcc&view=rev
Log:
PR tree-optimization/91157
* tree-vect-generic.c (expand_vector_comparison): Handle lhs being
a vector boolean with scalar mode.
(expand_vector_condition): Handle first operand being a vector boolean
with scalar mode.
(expand_vector_operations_1): For comparisons, don't bail out early
if the return type is vector boolean with scalar mode, but comparison
operand type is not.

* gcc.target/i386/avx512f-pr91157.c: New test.
* gcc.target/i386/avx512bw-pr91157.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512bw-pr91157.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr91157.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug tree-optimization/91157] [10 Regression] ICE: verify_gimple failed (error: position plus size exceeds size of referenced object in 'bit_field_ref')

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 17 07:15:30 2019
New Revision: 273545

URL: https://gcc.gnu.org/viewcvs?rev=273545&root=gcc&view=rev
Log:
PR tree-optimization/91157
* tree-vect-generic.c (expand_vector_comparison): Handle lhs being
a vector boolean with scalar mode.
(expand_vector_condition): Handle first operand being a vector boolean
with scalar mode.
(expand_vector_operations_1): For comparisons, don't bail out early
if the return type is vector boolean with scalar mode, but comparison
operand type is not.

* gcc.target/i386/avx512f-pr91157.c: New test.
* gcc.target/i386/avx512bw-pr91157.c: New test.

Modified:
trunk/gcc/tree-vect-generic.c

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
(In reply to Richard Earnshaw from comment #10)

Thank you Richard for help.

> I'm not particularly familiar with how LTO is supposed to work.  I can
> reproduce the crash on ARM as Martin described (but not on AArch64). 

Interesting.

> The
> problem seems to be an assert that the number of files to analyse passed on
> the command line matches the number of files described in the resolution
> file.  We have:
> 
> lto1 -quiet -dumpbase  -mcpu=cortex-a72 -mfloat-abi=hard
> -mtls-dialect=gnu -mcpu=cortex-a72 -mfloat-abi=hard -mtls-dialect=gnu -marm
> -march=armv8-a+crc+simd -auxbase  -version -fno-openmp -fno-openacc
> -fno-pie -fltrans-output-list=/tmp/ccoC6W9f.ltrans.out -fwpa
> -fresolution=main.res -flinker-output=exec @/tmp/ccHCf4bh
> 
> Where ccHCf4bh contains:
> 
> main.o
> 
> and main.res contains:
> 1
> main.o 1
> 195 4bf9aa6f81679e65 PREVAILING_DEF main
> 
> So if I've understood this correctly, the resolution file says to expect one
> file to analyse, but two are passed.  It looks like something is
> interpreting  as an additional file.

Yes, I see the same that the file '' is passed as an input file.

> 
> Going back another step, we see
> 
> /home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/libexec/gcc/armv8l-
> unkno
> wn-linux-gnueabihf/9.1.0/lto-wrapper -fresolution=main.res
> -flinker-output=exec 
> main.o 
> /home/rearnsha/scratch/gnu/gcc-install/armv8l/gcc-9.1.0/bin/gcc
> @/tmp/cc8Su59l
> 
> where cc8Su59l contains:
> -xlto
> -c
> -fno-openmp
> -fno-openacc
> -fno-pie
> -mcpu=cortex-a72
> -mfloat-abi=hard
> -mtls-dialect=gnu
> -marm
> -march=armv8-a+crc+simd
> -v
> 

Yep, one should not see this file here.

> -save-temps
> -mcpu=cortex-a72
> -mfloat-abi=hard
> -mtls-dialect=gnu
> -marm
> -march=armv8-a+crc+simd
> -fltrans-output-list=/tmp/ccoC6W9f.ltrans.out
> -fwpa
> -fresolution=main.res
> -flinker-output=exec
> main.o
> 
> I think the problem is that '' mid-way through the list of options.  It
> looks as though it has had a preceding -MF gobbled but not its argument.

I have the same feeling that somewhere the argument of -MF should be eaten.

I'm also not able to fully debug that to be honest.

> 
> Does this help any?

Partially, it confirms what I can see. But I'm still not able to deduce why
that happens only for ARM-targets.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||ian at airs dot com

--- Comment #14 from Martin Liška  ---
I'm looking at the difference in between -dumpspecs of GCC 8 (works) and GCC 9
(fails) and I see only cosmetic changes. One bigger is the newly added '@'
directive added by Erik (%@{I*&F*}) (r261474). I'll try to build GCC 9 with
this patch disabled.

Anyway, can please Eric or Ian help me how can we debug processing of the SPEC
directives?

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #31 from Martin Liška  ---
*** Bug 91186 has been marked as a duplicate of this bug. ***

[Bug lto/91186] gcc-9.1.0 fails to find a .symver symbol

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Martin Liška  ---
It's a known limitation.

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

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
My bet is that this has something to do with the -MMD option, which is one of
the 4? NoDriverArg options, where supposedly the user when using that option
doesn't supply the argument but the specs add it.  Perhaps during the LTO
option handling at some point NoDriverArg isn't handled right and we have at
that point still no argument after it, but it thinks it is in the context where
it must have an argument and so uses the following -MF as the argument and thus
the -MF argument is then an option.

[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Romain Geissler from comment #3)
> Hi,
> 
> @Martin (and @Richard), I have seen you submitted this patch
> https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01059.html which I guess would
> fix this bug.

Reading your motivation, yes, it can hopefully fix your problem.

 If accepted in gcc 10, do you think it is safe to backport in
> gcc 8/9 (I can patch my gcc's locally, but I would like to know if that
> removal relies on other commits which are only in gcc 10).

No, I'm not planning to backport that as it's potentially dangerous. And you
know, we take the stability of our stable builds seriously :)

Can you please test my patch in your workflow?

> 
> Thanks,
> Romain

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

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

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

--- Comment #16 from Andreas Schwab  ---
Then why does it only happen on arm?  All the LTO option handling should be
target independent.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
No idea, that has to be debugged.
But I'd suggest in the two spots that cl_driver_no_arg is tested to add
debugging printout of what the next argv is and whether CL_DRIVER is in
lang_mask or not, and run it on arm as well as x86_64 and compare.

[Bug c++/58993] incorrectly accept access of protected member method from derived class template

[dennis at felsin9 dot de]

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

dennis at felsin9 dot de  changed:

   What|Removed |Added

 CC||dennis at felsin9 dot de

--- Comment #7 from dennis at felsin9 dot de  ---
Another example, no warnings in G++ 9.1.0, fails in Clang++ as expected:

class C
{
struct Print
{
const class C& c;
};
};

template
struct D : public C
{
void create()
{
[[maybe_unused]] C::Print p{*this};
}
};

int main()
{
D d;
d.create();
}

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #3 from Harald van Dijk  ---
If the header files can be modified, there is no need to put any pragmas in
there, the header files can just be modified to not use a literal 0.

If the header files cannot be modified, the -isystem command-line option also
causes included files to be treated as system headers where warnings are
suppressed.

If there is going to be some other way to suppress
-Wzero-as-null-pointer-constant, it should not simply depend on extern "C". The
problem here isn't that it's in an extern "C" block, it's that it's in a header
you cannot change, and you propose using the presence of an extern "C" block to
detect that. The problem with that is that it will also suppress the warning
for extern "C" blocks that you can change. (Of course, in headers meant to be
compatible with C, you cannot use nullptr, but you do not need to: you can
include  and use NULL, which will not trigger this warning.)

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #2)
> maybe try putting #pragma GCC system_header in your headers? idk

Please no, that's for marking a header as part of "the implementation" not a
diagnostic-suppression mechanism for user code!

[Bug tree-optimization/91180] [10 Regression] wrong code at -O and above with __builtin_memset()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Just for the record, started with r273194.

[Bug tree-optimization/91180] [10 Regression] wrong code at -O and above with __builtin_memset()

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 17 09:35:04 2019
New Revision: 273548

URL: https://gcc.gnu.org/viewcvs?rev=273548&root=gcc&view=rev
Log:
2019-07-17  Richard Biener  

PR tree-optimization/91180
* tree-ssa-sccvn.c (vn_reference_lookup_3): Fix offset
computation for memset partial defs.

* gcc.dg/torture/pr91180.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr91180.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/91180] [10 Regression] wrong code at -O and above with __builtin_memset()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
Created attachment 46607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46607&action=edit
Debugging patch

Using the patch, I see the following difference:
https://www.diffchecker.com/J7lpu1Kv

But to be honest I don't see any change that will show the difference.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 Status|ASSIGNED|NEW
  Component|tree-optimization   |rtl-optimization
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org
Summary|[10 Regression] 456.hmmer   |[10 Regression] 456.hmmer
   |regression on Haswell   |regression on Haswell
   ||caused by r272922

--- Comment #4 from Richard Biener  ---
For the Jul 1st regression the DOM change causes us to recognize MIN/MAX
patterns
way earlier (they are exposed by conditional store elimination).  While before
the change we have to if-convert 5 loops of P7Viterbi after the change only
one is remaining.  This naturally affects the scalar fallback.  perf shows
(base is r272921, peak is r272922)

  41.37%611991  hmmer_peak.amd6  hmmer_peak.amd64-m64-gcc42-nn  [.]
P7Viterbi
  29.84%441484  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.]
P7Viterbi
  15.32%226646  hmmer_base.amd6  hmmer_base.amd64-m64-gcc42-nn  [.]
P7Viterbi.cold
   6.74% 99771  hmmer_peak.amd6  hmmer_peak.amd64-m64-gcc42-nn  [.]
P7Viterbi.cold

so the cold part is way faster but somehow the hot part quite a bit slower,
I suspect profile changes in the end, sums are 668130 vs. 711762 samples.
-fopt-info-loop doesn't show any changes, vectorizer cost-model estimates
(and thus runtime niter checks) are the same.

Note the Jul 1st regression is in the range PR90911 was present which should
be the observed Jun 13th regression (r272239).

perf points to a sequence of two cmovs being slow compared to one cmove
and a conditional branch.  Fast:

   │dc[k] = dc[k-1] + tpdd[k-1];
  7.42 │ fd0:   mov-0x80(%rbp),%rbx 
  0.08 │add-0x8(%rbx,%rax,4),%ecx   
   │if ((sc = mc[k-1] + tpmd[k-1]) > dc[k]) dc[k] = sc; 
  0.24 │mov-0xa0(%rbp),%rbx 
   │dc[k] = dc[k-1] + tpdd[k-1];
  0.07 │mov%ecx,-0x4(%rdx,%rax,4)   
   │if ((sc = mc[k-1] + tpmd[k-1]) > dc[k]) dc[k] = sc; 
  7.41 │mov-0x8(%r15,%rax,4),%esi   
  2.69 │add-0x8(%rbx,%rax,4),%esi   
  3.31 │cmp%ecx,%esi
  2.85 │cmovge %esi,%ecx
 12.17 │mov%ecx,-0x4(%rdx,%rax,4)   
   │if (dc[k] < -INFTY) dc[k] = -INFTY; 
  7.43 │cmp$0xc521974f,%ecx 
   │jge1060 
  0.01 │movl   $0xc521974f,-0x4(%rdx,%rax,4)
   │  for (k = 1; k <= M; k++) {
  0.02 │mov%eax,%esi
  0.02 │inc%rax 
  0.01 │cmp%rax,%rdi
   │je 106e 
   │if (dc[k] < -INFTY) dc[k] = -INFTY; 
  0.01 │mov$0xc521974f,%ecx 
  0.01 │jmpfd0
...
  0.00 │1060:   mov%eax,%esi
  0.03 │inc%rax 
  0.00 │cmp%rdi,%rax
  0.00 │jnefd0 
  0.06 │106e:   cmp-0x64(%rbp),%esi 
   │jg 1508  

slow:

   │dc[k] = dc[k-1] + tpdd[k-1];
  0.06 │13b0:   add-0x8(%r9,%rcx,4),%eax
  0.07 │mov%eax,-0x4(%r13,%rcx,4)   
   │if ((sc = mc[k-1] + tpmd[k-1]) > dc[k]) dc[k] = sc; 
  6.81 │mov-0x8(%r8,%rcx,4),%esi
  0.04 │add-0x8(%rdx,%rcx,4),%esi   
  1.46 │cmp%eax,%esi
  0.29 │cmovge %esi,%eax
   │ 

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
So the first interesting difference appears in the options lto-wrapper.c
(run_gcc) emits it seems to me (based on -xlto being the very first option). 
So I'd do a debugging session of lto-wrapper in both cases on the run_gcc
routine, see what options are added to the obstack by append_compiler_options,
what are added by append_linker_options, if there are any differences in
fdecoded_options/fdecoded_options_count or
decoded_options/decoded_options_count etc.

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] Infinite  |[9 Regression] Infinite
   |recursion in|recursion in
   |split_constant_offset in|split_constant_offset in
   |slp after r260289   |slp after r260289
  Known to fail|10.0|9.1.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/91178] [9/10 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 17 10:26:25 2019
New Revision: 273549

URL: https://gcc.gnu.org/viewcvs?rev=273549&root=gcc&view=rev
Log:
2019-07-17  Richard Biener  

PR tree-optimization/91178
* tree-vect-stmts.c (get_group_load_store_type): For SLP
loads with a gap larger than the vector size always use
VMAT_STRIDED_SLP.
(vectorizable_load): For VMAT_STRIDED_SLP with a permutation
avoid loading vectors that are only contained in the gap
and thus are not needed.

* gcc.dg/torture/pr91178.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr91178.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug driver/91172] Command line option for a wrong language is not reported with -Werror=warning_name syntax

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Liška  ---
Patch candidate:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg01148.html

[Bug tree-optimization/91178] [9 Regression] Infinite recursion in split_constant_offset in slp after r260289

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Jul 17 11:21:49 2019
New Revision: 273550

URL: https://gcc.gnu.org/viewcvs?rev=273550&root=gcc&view=rev
Log:
2019-07-17  Richard Biener  

PR tree-optimization/91178
* tree-ssa.c (release_defs_bitset): Iterate from higher to
lower SSA names to avoid quadratic behavior in the common case.
* tree-data-ref.c (split_constant_offset): Add limit argument
and pass it down.  Initialize it from PARAM_SSA_NAME_DEF_CHAIN_LIMIT.
(split_constant_offset_1): Add limit argument and use it to
limit SSA def walking.  Optimize the common plus/minus case.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-data-ref.c
trunk/gcc/tree-ssa.c

[Bug target/91188] New: strict_low_part operations do not work

[ubizjak at gmail dot com]

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

Bug ID: 91188
   Summary: strict_low_part operations do not work
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following test case:

--cut here--
struct S1
{
  unsigned char val;
  unsigned char pad1;
  unsigned short pad2;
};

struct S1
__attribute__((noinline))
test_andb (struct S1 a, unsigned char b)
{
  a.val &= b;

  return a;
}
--cut here--

compiles on x86_64 with -O2 to:

test_andb:
movl%edi, %eax  # 2 [c=4 l=2]  *movsi_internal/0
andl%edi, %esi  # 21[c=4 l=2]  *andsi_1/0
movb%sil, %al   # 9 [c=4 l=3]  *movstrictqi_1/0
ret # 24[c=0 l=1]  simple_return_internal

Expected code:

test_andb:
movl%edi, %eax
andb%sil, %al
ret

[Bug target/91188] strict_low_part operations do not work

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-17
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
._slp patterns should be written in this way, e.g. *and_1_slp:

(define_insn "*and_1_slp"
  [(set (strict_low_part (match_operand:SWI12 0 "register_operand" "+"))
(and:SWI12 (match_operand:SWI12 1 "nonimmediate_operand" "%0")
   (match_operand:SWI12 2 "general_operand" "mn")))
   (clobber (reg:CC FLAGS_REG))]
  "(!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun))
   /* FIXME: without this LRA can't reload this pattern, see PR82524.  */
   && (rtx_equal_p (operands[0], operands[1])
   || rtx_equal_p (operands[0], operands[2]))"
  "and{}\t{%2, %0|%0, %2}"
  [(set_attr "type" "alu")
   (set_attr "mode" "")])

The above pattern handles QImode, as well as HImode.

[Bug target/91188] strict_low_part operations do not work

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
The patched gcc compiles to:

test_andb:
movl%edi, %eax  # 2 [c=4 l=2]  *movsi_internal/0
andb%sil, %al   # 9 [c=4 l=3]  *andqi_1_slp
ret # 23[c=0 l=1]  simple_return_internal

The patch also handles memory:

--cut here--
struct S1
{
  unsigned char val;
  unsigned char pad1;
  unsigned short pad2;
};

unsigned char m;

struct S1
__attribute__((noinline))
test_andb (struct S1 a)
{
  a.val &= m;

  return a;
}
--cut here--

gcc -O2:

test_andb:
movl%edi, %eax  # 2 [c=4 l=2]  *movsi_internal/0
andbm(%rip), %al# 7 [c=8 l=6]  *andqi_1_slp
ret # 20[c=0 l=1]  simple_return_internal

and immediate operands:

--cut here--
struct S1
{
  unsigned char val;
  unsigned char pad1;
  unsigned short pad2;
};

struct S1
__attribute__((noinline))
test_andb (struct S1 a)
{
  a.val &= 0x2a;

  return a;
}
--cut here--

gcc -O2:

test_andb:
movl%edi, %eax  # 2 [c=4 l=2]  *movsi_internal/0
andb$42, %al# 7 [c=4 l=2]  *andqi_1_slp
ret # 20[c=0 l=1]  simple_return_internal

[Bug target/91188] strict_low_part operations do not work

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
The testcase involving HImode pattern:

--cut here--
struct S1
{
  unsigned short val;
  unsigned short pad1;
};

struct S1
__attribute__((noinline))
test_andw (struct S1 a, unsigned short b)
{
  a.val &= b;

  return a;
}
--cut here--

gcc -O2:

test_andw:
movl%edi, %eax  # 2 [c=4 l=2]  *movsi_internal/0
andw%si, %ax# 9 [c=4 l=3]  *andhi_1_slp
ret # 23[c=0 l=1]  simple_return_internal

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
One x86 option is to peephole

(insn 635 632 637 17 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 0 ax [1735])
(const_int -987654321 [0xc521974f]))) 11 {*cmpsi_1}
 (nil))
(insn 637 635 638 17 (set (reg:SI 0 ax [1737])
(if_then_else:SI (ge (reg:CCGC 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax [1735])
(reg:SI 3 bx [2395]))) 947 {*movsicc_noc}
 (expr_list:REG_DEAD (reg:CCGC 17 flags)
(expr_list:REG_EQUAL (if_then_else:SI (ge (reg:CCGC 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax [1735])
(const_int -987654321 [0xc521974f]))
(nil

into a compare-and-jump sequence.

Benchmarking on a more recent microarchitecture is probably also in order.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So pretty much undo all ifcvt into conditional moves (aka pretend the target
doesn't have cmov) or something else?
The problem is that cmov isn't unconditionally bad or unconditionally good and
moving in either direction usually results in significant regressions.  cmov is
good if the branch will be often badly predicted, so when the branch prediction
is close to 50%, and is bad when it is usually well predicted.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
This is PR 56309, again and again.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #6)
> So pretty much undo all ifcvt into conditional moves (aka pretend the target
> doesn't have cmov) or something else?
> The problem is that cmov isn't unconditionally bad or unconditionally good
> and moving in either direction usually results in significant regressions. 
> cmov is good if the branch will be often badly predicted, so when the branch
> prediction is close to 50%, and is bad when it is usually well predicted.

I'd only do it for MAX and MIN.  There's
also another conditional move a few instructions up, not sure if cmove
density would be another thing to key on.

If target costing generally favors the cmp + if-then-else then we may also
simply advertise [us]{min,max} patterns here?  That said, RTL expansion
doesn't look at cost but only asks can_conditionally_move_p (mode) but
hopefully if-conversion considers actual rtx-cost.

Other ideas welcome of course.

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||85559

--- Comment #9 from Richard Biener  ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #6)
> > So pretty much undo all ifcvt into conditional moves (aka pretend the target
> > doesn't have cmov) or something else?
> > The problem is that cmov isn't unconditionally bad or unconditionally good
> > and moving in either direction usually results in significant regressions. 
> > cmov is good if the branch will be often badly predicted, so when the branch
> > prediction is close to 50%, and is bad when it is usually well predicted.
> 
> I'd only do it for MAX and MIN. 
> There's
> also another conditional move a few instructions up, not sure if cmove
> density would be another thing to key on.

And if I read the refrenced PR56309 then the issue might be that for

cmpl%eax, %esi
cmovge  %esi, %eax
movl%ecx, %esi
cmpl%ebx, %eax
cmovl   %ebx, %eax

the second compare uses the cmov destination.  But todays micro architectures
are too complex to really tell what the issue is (still constraining a
peephole quite strictly could be possible, on either or both of the
patterns that appear here).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85559
[Bug 85559] [meta-bug] Improve conditional move

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Note that on Haswell the conditional moves are two uops while on Broadwell and
up
they are only one uop (overall loop 16 uops vs. 18 uops).  IACA doesn't show
any particular issue (the iterations shoud neatly interleave w/o inter
iteration
dependences), but it says the throughput bottleneck is dependency chains
(not sure if it models conditional moves very well).

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #20 from Richard Earnshaw  ---
Running under gdb I see:
(gdb) 
decode_cmdline_option (argv=0x15170c, lang_mask=4095, decoded=0x1506e8)
at /home/rearnsha/gnusrc/gcc/gcc-9.1.0/gcc/opts-common.c:523
...
gdb) p *option
$5 = {opt_text = 0xb7484 "-MMD", 
  help = 0xb748c "Like -MD but ignore system header files.", 
  missing_argument_error = 0xb6aa4 "missing filename after %qs", 
  warn_message = 0x0, alias_arg = 0x0, neg_alias_arg = 0x0, 
  alias_target = 1451, back_chain = 1451, opt_len = 3 '\003', neg_index = -1, 
  flags = 8391920, cl_disabled = 0, cl_separate_nargs = 0, 
  cl_separate_alias = 0, cl_negative_alias = 0, cl_no_driver_arg = 1, 
  cl_reject_driver = 0, cl_reject_negative = 0, cl_missing_ok = 0, 
  cl_uinteger = 0, cl_host_wide_int = 0, cl_tolower = 0, cl_report = 0, 
  cl_byte_size = 0, flag_var_offset = 65535, var_enum = 0, 
  var_type = CLVC_STRING, var_value = 0, range_min = -1, range_max = -1}
...
(gdb) p separate_arg_flag
$6 = true

The result is that -MMD swallows the subsequent -MF flag as it's own argument
and  leaks through as a file to process

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #21 from Richard Earnshaw  ---
FWIW in the environment:

COLLECT_GCC_OPTIONS = '-B' '.' '-v' '-flto' '-MMD' '-MF' ''
'-mcpu=cortex-a72' '-mfloat-abi=hard' '-mtls-dialect=gnu' '-marm'
'-march=armv8-a+crc+simd'

So is this correct, or should an extra argument have been inserted after the
-MMD option at this point?

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

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

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

--- Comment #22 from Andreas Schwab  ---
-MMD doesn't take an argument as a driver option.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #23 from Jakub Jelinek  ---
Sure, the question is if what is in COLLECT_GCC_OPTIONS are driver options or
backend options, if the former, something needs to parse those with CL_DRIVER
and perform the magic that is in %(cpp_unique_options) on those to turn them
into backend options, if the latter, then it is a bug that it doesn't have
already the argument.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #24 from Richard Earnshaw  ---
It would appear that the handling of -MMD is the same on both Arm and X86 - in
both cases it swallows the subsequent -MF option when digested by lto-wrapper. 
I'm not sure yet why the two compilers then diverge in later behaviour, but the
bug would appear to be the handling of this option rather then the subsequent
divergence in behaviour.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #25 from Richard Earnshaw  ---
Created attachment 46608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46608&action=edit
possible patch

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #26 from Richard Earnshaw  ---
On the basis that COLLECT_GCC_OPTIONS are the options to add if reinvoking gcc,
then that environment variable is really a set of driver options.  As such, I
suspect the right fix for this is to add CL_DRIVER to the lang_mask value
passed into get_options_from_collect_gcc_options.  As such, the patch for this
is something like the attached.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #27 from Jakub Jelinek  ---
So shouldn't it pass CL_DRIVER rather than CL_LANG_ALL | CL_DRIVER ?
If both are needed, ()s around it are unnecessary.
CCing Joseph as option handling maintainer.

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[rearnsha at gcc dot gnu.org]

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

--- Comment #28 from Richard Earnshaw  ---
Not sure.  I presumed the LANG_ALL was about handing all language-specific
options, rather than say, just fortran as would be done if gcc were invoked as
g95.

[Bug tree-optimization/91189] New: 20% binary size regression in avr-gcc 9.1.0 from 8.3.0

[larsch at belunktum dot dk]

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

Bug ID: 91189
   Summary: 20% binary size regression in avr-gcc 9.1.0 from 8.3.0
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: larsch at belunktum dot dk
  Target Milestone: ---

There seem to be a severe ~20% code size regression on AVR target (atmega328p)
in gcc 9.1.0.

I'm building https://github.com/gnea/grbl, which need to fit in 32k. This used
to work just fine (29786 bytes), but with 9.1.0 it is way over target size
(35492 bytes).

Compile options are the default '-Os -flto' on both.

gcc 8.3.0

% avr-gcc --version
avr-gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% avr-size grbl.hex 
   textdata bss dec hex filename
  0   29786   0   29786745a grbl.hex

gcc 9.1.0:

% avr-gcc --version

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

% avr-size grbl.hex
   textdata bss dec hex filename
  0   35492   0   354928aa4 grbl.hex

[Bug target/91130] [9/10 Regression] -MF clashes with -flto on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
CL_DRIVER should be covering all languages too, after all, if it is not, then
the gcc.c CL_DRIVER option processing would complain on options for specific
languages.
So I'd expect both CL_LANG_ALL in lto-wrapper.c should be CL_DRIVER instead, if
COLLECT_GCC_OPTIONS is indeed the original command line, without the usual
driver processing on it.

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[aacid at kde dot org]

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

--- Comment #5 from Albert Astals Cid  ---
(In reply to Harald van Dijk from comment #3)
> If the header files cannot be modified, the -isystem command-line option
> also causes included files to be treated as system headers where warnings
> are suppressed.

The thing is, this isn't happening. If you compile the attached main-glib.cpp
with

g++ -c -Wzero-as-null-pointer-constant main.cpp -isystem /usr/include/glib-2.0/
-isystem /usr/lib/glib-2.0/include

i still get

main.cpp: In function ‘GType poppler_annot_get_type()’:
main.cpp:17:1: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
   17 | G_DEFINE_TYPE (PopplerAnnot, poppler_annot, G_TYPE_OBJECT)
  | ^

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[aacid at kde dot org]

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

--- Comment #6 from Albert Astals Cid  ---
Created attachment 46609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46609&action=edit
the said main-glib.cpp file

well the line has to be
g++ -c -Wzero-as-null-pointer-constant main-glib.cpp -isystem
/usr/include/glib-2.0/ -isystem /usr/lib/glib-2.0/include
and not
g++ -c -Wzero-as-null-pointer-constant main.cpp -isystem /usr/include/glib-2.0/
-isystem /usr/lib/glib-2.0/include

also you need to have glib2 installed somewhere, may be different paths than
mine

[Bug tree-optimization/91183] strlen of a strcpy result with a conditional source not folded

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-07-17
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The solution I'm testing also makes it possible to remove the XFAIL in
strlenopt-8.c:

diff --git a/gcc/testsuite/gcc.dg/strlenopt-8.c
b/gcc/testsuite/gcc.dg/strlenopt-8.c
index 85c6d38a965..f43b809ed02 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-8.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-8.c
@@ -43,13 +43,7 @@ main ()
   return 0;
 }

-/* On non-strict-align targets we inline the memcpy that strcat is turned
-   into and end up with a short typed load / store which strlenopt is not
-   able to analyze.  */
-
-/* { dg-final { scan-tree-dump-times "strlen \\(" 0 "strlen" { xfail
non_strict_align } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 2 "strlen" { target {
non_strict_align } } } } */
-/* { dg-final { scan-tree-dump-times "memcpy \\(" 4 "strlen" { target { !
non_strict_align } } } }  */
+/* { dg-final { scan-tree-dump-times "strlen \\(" 0 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "strcpy \\(" 0 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "strcat \\(" 0 "strlen" } } */
 /* { dg-final { scan-tree-dump-times "strchr \\(" 0 "strlen" } } */

[Bug lto/84579] __gnu_lto_v1 should be removed when linking with -fno-lto

[romain.geissler at amadeus dot com]

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

--- Comment #5 from Romain Geissler  ---
Hi,

Your patch applies cleanly to both gcc 8 and 9. I was able to bootstrap two
toochains gcc 8 and 9 with it, however it caused regression in the binutils
testsuite:

FAIL: ld-plugin/lto-3r
FAIL: ld-plugin/lto-5r

For which I have no more details, but it should be easy to reproduce. I will go
past these regression in the binutils and try to build some of our open source
components with it to have a bigger test surface.

Cheers,
Romain

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

[harald at gigawatt dot nl]

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

--- Comment #7 from Harald van Dijk  ---
(In reply to Albert Astals Cid from comment #5)
> (In reply to Harald van Dijk from comment #3)
> > If the header files cannot be modified, the -isystem command-line option
> > also causes included files to be treated as system headers where warnings
> > are suppressed.
> 
> The thing is, this isn't happening. If you compile the attached
> main-glib.cpp with
> 
> g++ -c -Wzero-as-null-pointer-constant main.cpp -isystem
> /usr/include/glib-2.0/ -isystem /usr/lib/glib-2.0/include

Huh, indeed. It works with the Ubuntu-provided GCC 8.3.0. It does not work with
the Ubuntu-provided GCC 9.1.0.

$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.3.0-6ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1) 
$ g++-9 -v
Using built-in specs.
COLLECT_GCC=g++-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.1.0-2ubuntu2~19.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.1.0 (Ubuntu 9.1.0-2ubuntu2~19.04) 
$ g++-8 -c -Wzero-as-null-pointer-constant main.cpp -isystem
/usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include
$ g++-9 -c -Wzero-as-null-pointer-constant main.cpp -isystem
/usr/include/glib-2.0 -isystem /usr/lib/x86_64-linux-gnu/glib-2.0/include
main.cpp: In function ‘GType poppler_annot_get_type()’:
main.cpp:16:1: warning: zero as null pointer constant
[-Wzero-as-null-pointer-constant]
   16 | G_DEFINE_TYPE (PopplerAnnot, poppler_annot, G_TYPE_OBJECT)
  | ^

With GCC 9 without -isystem, it still shows the warning as coming from the
header ("/usr/include/glib-2.0/glib/gthread.h:250:42: warning: zero as null
pointer constant"), but when -isystem is used like that, the warning location
is moved to main.cpp, so no longer suppressed.

I do not know at this moment whether this is an intentional change in GCC 9.

[Bug c++/91104] auto... in lambda expression reorders parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Seems to be fixed by

commit 3a9560cbae7f59d5b280a7858bdb150e27d447ad
Author: mpolacek 
Date:   Tue May 28 14:00:29 2019 +

PR c++/90548 - ICE with generic lambda and empty pack.
* pt.c (tsubst_copy_and_build): Handle pack expansion properly.

* g++.dg/cpp1y/lambda-generic-90548.C: New test.


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

$ xg++ 91104.C ; ./a.out 
1 2 3
1 2 3

[Bug c++/91104] auto... in lambda expression reorders parameters

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
But the testcase is useful.

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jul 17 18:10:14 2019
New Revision: 273553

URL: https://gcc.gnu.org/viewcvs?rev=273553&root=gcc&view=rev
Log:
PR c++/90455
* g++.dg/cpp0x/nsdmi-list6.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-list6.C
Modified:
trunk/gcc/testsuite/ChangeLog

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/91190] New: ICE on valid code: in hashtab_chk_error, at hash-table.c:137

[su at cs dot ucdavis.edu]

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

Bug ID: 91190
   Summary: ICE on valid code: in hashtab_chk_error, at
hash-table.c:137
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It appears to be a recent regression. 

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/suz/software/gcctk/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --disable-multilib
--enable-languages=c,c++,lto --prefix=/home/suz/software/gcctk/gcc-trunk
--disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190717 (experimental) [trunk revision 273554] (GCC) 
$ 
$ gcctk -O2 small.
gcctk: error: small.: No such file or directory
gcctk: fatal error: no input files
compilation terminated.
$ gcctk -O2 small.c
$ gcc-9.1.0 -O3 small.c
$ 
$ gcctk -O3 small.c
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
during RTL pass: expand
small.c: In function ‘main’:
small.c:8:5: internal compiler error: in hashtab_chk_error, at hash-table.c:137
8 | int main ()
  | ^~~~
0x60d20c hashtab_chk_error()
../../gcc-source-trunk/gcc/hash-table.c:137
0x94d34b hash_table::verify(temp_slot_address_entry* const&, unsigned int)
../../gcc-source-trunk/gcc/hash-table.h:1036
0x94d4a4 hash_table::find_with_hash(temp_slot_address_entry* const&, unsigned int)
../../gcc-source-trunk/gcc/hash-table.h:937
0x949b41 find_temp_slot_from_address
../../gcc-source-trunk/gcc/function.c:749
0x94abd2 update_temp_slot_address(rtx_def*, rtx_def*)
../../gcc-source-trunk/gcc/function.c:1103
0x8b92a5 memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
../../gcc-source-trunk/gcc/explow.c:510
0x89dbd4 change_address_1
../../gcc-source-trunk/gcc/emit-rtl.c:2312
0x8a1cd5 offset_address(rtx_def*, rtx_def*, unsigned long)
../../gcc-source-trunk/gcc/emit-rtl.c:2550
0x8db417 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:10778
0x8dde48 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-source-trunk/gcc/expr.c:9952
0x82976b expand_normal
../../gcc-source-trunk/gcc/expr.h:287
0x82976b do_jump
../../gcc-source-trunk/gcc/dojump.c:610
0x7a6cf3 expand_gimple_cond
../../gcc-source-trunk/gcc/cfgexpand.c:2548
0x7a6cf3 expand_gimple_basic_block
../../gcc-source-trunk/gcc/cfgexpand.c:5770
0x7a893e execute
../../gcc-source-trunk/gcc/cfgexpand.c:6538
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ 

-

int printf (const char *, ...);

unsigned a[1], c;
long d, h;
int e[2], f, g;
char i;

int main ()
{
  char k = 0;
  int l;
  while (i || d)
{
  if (g)
while (1)
  ;
  e[1] = 0;
  long m[2], n = ~(3 & (5 | (h | 9) * 2237420170));
  g = 90 * n;
  char b = m[3], j = 0;
  c = 5 ^ a[c ^ (b & 5)];
  int o = d;
  k = o ? : j;
  if (k)
for (l = 0; l < 3; l++)
  if (m[20]) 
printf ("%d", f);
}
  return 0; 
}

[Bug c/81824] Warn for missing attributes with function aliases

[aoliva at gcc dot gnu.org]

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

--- Comment #18 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Jul 18 00:38:45 2019
New Revision: 273563

URL: https://gcc.gnu.org/viewcvs?rev=273563&root=gcc&view=rev
Log:
-Wmissing-attributes: check that we avoid duplicates and false positives

The initial patch for PR 81824 fixed various possibilities of
-Wmissing-attributes reporting duplicates and false positives.  The
test that avoided them was a little obscure, though, so this patch
rewrites it into a more self-evident form.

The patch also adds a testcase that already passed, but that
explicitly covers some of the possibilities of reporting duplicates
and false positives that preexisting tests did not cover.


for  gcc/ChangeLog

PR middle-end/81824
* attribs.c (decls_mismatched_attributes): Simplify the logic
that avoids duplicates and false positives.

for  gcc/testsuite/ChangeLog

PR middle-end/81824
* g++.dg/Wmissing-attributes-1.C: New.  Some of its fragments
are from Martin Sebor.

Added:
trunk/gcc/testsuite/g++.dg/Wmissing-attributes-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/attribs.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/91191] New: vrp and boolean arguments

[wilson at gcc dot gnu.org]

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

Bug ID: 91191
   Summary: vrp and boolean arguments
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wilson at gcc dot gnu.org
  Target Milestone: ---

It appears that vrp isn't propagating the ranges of incoming boolean arguments.
 Given this example:

unsigned char reg(_Bool b) {
union U {
unsigned char f0;
_Bool f1;
};
union U u;
u.f1 = b;
if (u.f0 > 1) { 
// This cannot happen
// if b is only allowed
// to be 0 or 1:
return 42;   
}
return 13;
}

clang optimizes this to unconditionally return 13, but gcc does a compare and
conditionally returns either 42 or 13 depending on the result of the compare.
This happens with both x86_64 and RISC-V.

Looking at the vrp dumps, I see
b_3(D): VARYING

[Bug tree-optimization/80519] if(p)free(p) with -Os

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Martin Sebor from comment #5)
> In some (many?) cases the null test is eliminated by
> -fdelete-null-pointer-checks as a consequence of the pointer having been
> dereferenced.  What remains is the cases where GCC doesn't see any such
> dereferences.  It would be interesting to get an idea of what proportion
> they constitute and how much they or their removal might contribute to the
> size and efficiency of code.  David Malcolm's remarks could help reveal some
> of these data points.

cc-ing him

[Bug preprocessor/91192] New: [9 regression] non-deterministic ICE on invalid

[dimhen at gmail dot com]

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

Bug ID: 91192
   Summary: [9 regression] non-deterministic ICE on invalid
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

gcc -fpreprocessed -c x.i can
-- report error
-- ICE in linemap_macro_map_lookup, at libcpp/line-map.c:1003
-- crash_signal in get_location_from_adhoc_loc libcpp/line-map.c:257

r266365 PASS (?)
r266815 FAIL
r273505 FAIL

$ cat x.i
a() {
   b; 0( sizeof

$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --with-tune=native
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190716 (experimental) [trunk revision 273505] (GCC) 


$ /usr/local/gcc_current/bin/gcc -fpreprocessed -c x.i
x.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() {
  | ^
x.i: In function ‘a’:
x.i:2:4: error: ‘b’ undeclared (first use in this function)
2 |b; 0( sizeof
  |^
x.i:2:4: note: each undeclared identifier is reported only once for each
function it appears in
x.i:2:4: error: expected expression at end of input
x.i:2:7: error: called object is not a function or function pointer
2 |b; 0( sizeof
  |   ^
x.i:2:4: error: expected declaration or statement at end of input
2 |b; 0( sizeof
  |^


$ /usr/local/gcc_current/bin/gcc -fpreprocessed -c x.i
x.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() {
  | ^
x.i: In function ‘a’:
x.i:2:4: error: ‘b’ undeclared (first use in this function)
2 |b; 0( sizeof
  |^
x.i:2:4: note: each undeclared identifier is reported only once for each
function it appears in
x.i:2:4: error: expected expression at end of input
x.i:2:4: internal compiler error: in linemap_macro_map_lookup, at
libcpp/line-map.c:1003
0x1a996ac linemap_macro_map_lookup
/home/dimhen/src/gcc_current/libcpp/line-map.c:1003
0x1a996ac linemap_lookup(line_maps*, unsigned int)
/home/dimhen/src/gcc_current/libcpp/line-map.c:937
0x1a9a29b get_pure_location(line_maps*, unsigned int)
/home/dimhen/src/gcc_current/libcpp/line-map.c:331
0x1a7b43d get_pure_location
/home/dimhen/src/gcc_current/gcc/input.h:147
0x1a7b43d make_location(unsigned int, unsigned int, unsigned int)
/home/dimhen/src/gcc_current/gcc/input.c:891
0xa7c5b1 c_expr::get_location() const
/home/dimhen/src/gcc_current/gcc/c/c-tree.h:159
0xa7c5b1 c_parser_expr_list
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:9854
0xa7d03c c_parser_postfix_expression_after_primary
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:9588
0xa6e5e1 c_parser_postfix_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:9293
0xa782df c_parser_unary_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:7403
0xa79a6f c_parser_cast_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:7245
0xa79ce3 c_parser_binary_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:7048
0xa7ac15 c_parser_conditional_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:6782
0xa7b250 c_parser_expr_no_commas
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:6699
0xa7b4b1 c_parser_expression
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:9754
0xa7bbd7 c_parser_expression_conv
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:9787
0xa8b3c3 c_parser_statement_after_labels
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5616
0xa8d481 c_parser_compound_statement_nostart
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:5154
0xa8da18 c_parser_compound_statement
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:4988
0xa8f33e c_parser_declaration_or_fndef
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:2360
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


[dimhen:dim E1]$ /usr/local/gcc_current/bin/gcc -fpreprocessed -c x.i
x.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | a() {
  | ^
x.i: In funct

[Bug c/91193] New: [8 regression] ICE on invalid: tree check: expected class ‘type’, have ‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956

[dimhen at gmail dot com]

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

Bug ID: 91193
   Summary: [8 regression] ICE on invalid: tree check: expected
class ‘type’, have ‘declaration’ (function_decl) in
grokdeclarator, at c/c-decl.c:5956
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r257061 FAIL
r273505 FAIL

$ cat x.i
typedef a;
void a() a b;

$ /usr/local/gcc_current/bin/gcc -fpreprocessed x.i
x.i:1:9: warning: type defaults to ‘int’ in declaration of ‘a’ [-Wimplicit-int]
1 | typedef a;
  | ^
x.i:2:6: error: ‘a’ redeclared as different kind of symbol
2 | void a() a b;
  |  ^
x.i:1:9: note: previous declaration of ‘a’ was here
1 | typedef a;
  | ^
x.i: In function ‘a’:
x.i:2:1: internal compiler error: tree check: expected class ‘type’, have
‘declaration’ (function_decl) in grokdeclarator, at c/c-decl.c:5956
2 | void a() a b;
  | ^~~~
0x7a948e tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/tree.c:9953
0x5db72d tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/dimhen/src/gcc_current/gcc/tree.h:3340
0x5db72d grokdeclarator
/home/dimhen/src/gcc_current/gcc/c/c-decl.c:5956
0xa39e3b start_decl(c_declarator*, c_declspecs*, bool, tree_node*)
/home/dimhen/src/gcc_current/gcc/c/c-decl.c:4872
0xa8e114 c_parser_declaration_or_fndef
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:2159
0xa8f16a c_parser_declaration_or_fndef
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:2321
0xa963cf c_parser_external_declaration
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1658
0xa96e19 c_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:1539
0xa96e19 c_parse_file()
/home/dimhen/src/gcc_current/gcc/c/c-parser.c:20010
0xaecfcb c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1160
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --enable-checking=yes,df,fold,rtl,extra
--enable-languages=c,c++,lto --disable-multilib --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --with-tune=native
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190716 (experimental) [trunk revision 273505] (GCC)