date:20200229

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

Bug ID: 93981
   Summary: No EH information generated for asm statements
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwjagersma at gmail dot com
  Target Milestone: ---

No exception handling information is generated for asm statements:

```
$ cat unwind.cpp
void f()
{
try { asm ("nop #try"); }
catch (...) { asm ("nop #catch"); }
}

$ g++-9 -fnon-call-exceptions unwind.cpp -S -dA -o -
.file   "unwind.cpp"
.text
.globl  _Z1fv
.type   _Z1fv, @function
_Z1fv:
.LFB0:
.cfi_startproc
# BLOCK 2 seq:0
# PRED: ENTRY (FALLTHRU)
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
#APP
# 3 "unwind.cpp" 1
nop #try
# 0 "" 2
#NO_APP
nop
popq%rbp
.cfi_def_cfa 7, 8
# SUCC: EXIT [always] 
ret
.cfi_endproc
.LFE0:
.size   _Z1fv, .-_Z1fv
.ident  "GCC: (Ubuntu 9.2.1-17ubuntu1~18.04.1) 9.2.1 20191102"
.section.note.GNU-stack,"",@progbits
```

Since asms may contain trapping instructions, they should be covered by
an EH region in the unwind tables when compiling with
-fnon-call-exceptions.

[Bug inline-asm/93981] No EH information generated for asm statements

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

--- Comment #1 from jwjagersma at gmail dot com ---
Created attachment 47936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47936&action=edit
proposed patch

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-29 Thread ro at CeBiTec dot Uni-Bielefeld.DE

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
>> --- Comment #1 from Jakub Jelinek  ---
[...
>> Of course, trying to workaround kernel bugs this way is weird, but if it 
>> isn't
>> supported anymore or Apple isn't willing to fix their bugs...
>
> Mac OS X 10.7 is almost 9 years old by now and long past support.  I
> don't feel particularly inclined to reghunt which gcc/sanitizer change
> caused this, let alone debug the Darwin kernel either.

I've since experimented a bit more: 32-bit 10.7 is affected just the
same.  Afterwards, I've copied both the 32 and 64-bit
alloca_big_alignment.exe and the corresponding libasan.6.dylib and
libgcc_s.1.dylib to a 10.8 VM where they run just fine, so this is
obviously 10.7-only issue.

While working on this, I've created VirtualBox VMs for every single
macOS release between 10.7 and 10.15, each with the latest updates and
last supported Xcode version installed and ready for experiments if
needed.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-29 Thread iains at gcc dot gnu.org

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

--- Comment #8 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  > Uni-Bielefeld.DE> ---
> >> --- Comment #1 from Jakub Jelinek  ---
> [...
> >> Of course, trying to workaround kernel bugs this way is weird, but if it 
> >> isn't
> >> supported anymore or Apple isn't willing to fix their bugs...
> >
> > Mac OS X 10.7 is almost 9 years old by now and long past support.  I
> > don't feel particularly inclined to reghunt which gcc/sanitizer change
> > caused this, let alone debug the Darwin kernel either.
> 
> I've since experimented a bit more: 32-bit 10.7 is affected just the
> same.  Afterwards, I've copied both the 32 and 64-bit
> alloca_big_alignment.exe and the corresponding libasan.6.dylib and
> libgcc_s.1.dylib to a 10.8 VM where they run just fine, so this is
> obviously 10.7-only issue.

Yeah, I'm just waiting for the x86_64-darwin13 run to finish with libsanitizer
disabled
(the fault repeats for me on 64b).

It's early low on my priority list to look at this with the current sanitiser
output, since that is emitting a different ABI for Darwin than clang does (so
the emitted code would be the first thing to fix).

> While working on this, I've created VirtualBox VMs for every single
> macOS release between 10.7 and 10.15, each with the latest updates and
> last supported Xcode version installed and ready for experiments if
> needed.

VB is more reliable for some versions than others (which might have little to
do with VB, of course ;) ).  It's pretty hard to get anything < 10.6 to work
there, and obv. is no use of ppc.



Right now, I'm thinking to disable sanitzer by default for master <= 10.7 and
for 9.x for <= 10.6.  I'll do that today or tomorrow since I want to make the
9.3 deadline.

[Bug tree-optimization/93982] New: Assignment incorrectly omitted by -foptimize-strlen

2020-02-29 Thread nate at thatsmathematics dot com

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

Bug ID: 93982
Summary: Assignment incorrectly omitted by -foptimize-strlen
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---

Created attachment 47937
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47937&action=edit
Reduced testcase

If the attached testcase is compiled with `-O1 -foptimize-strlen' on amd64, the
function foo is miscompiled: the assignment to res.target[1] is omitted. It
also happens with -O2, but not with -O1 alone or -O3.

This bug is somewhat similar to bug 93213. It is a regression from 9.2.0.

The generated assembly is:

foo:
subq$8, %rsp
callmy_alloc
movq$.LC0, (%rax)
movq$.LC1, 16(%rax)
movq$.LC1, 24(%rax)
movq$.LC1, 32(%rax)
addq$8, %rsp
ret

Note the absence of `movq $.LC1, 8(%rax)'.

I tested with trunk, latest pull from git, revision 117baab8. In particular
the patch for bug 93213 (e13f37d9) is included. The program is compiled
correctly by gcc 9.2.0 with the same options (and all others I tried). I did a
git bisect and the offending commit is 34fcf41e.

The cast in foo() at first looked questionable from a strict aliasing
standpoint, but I believe the code is legal since the memory returned by calloc
has no declared type, and we never access this memory except as objects of type
`const char *'. Also, the miscompilation persists with -fno-strict-aliasing.

I am no gcc expert, but I dug into the source a little bit, out of curiosity.
It looks like the deletion happens in handle_store(), at
gcc/tree-ssa-strlen.c:5021. It seems that in this function, the code is being
treated as if the string "12345678" itself were being stored at address
res.target, rather than the address of the string; as if the code were
`strcpy(res.target, "12345678")'. In particular, it thinks the trailing null
was stored at address res.target+8. The following statement, `res.target[1] =
""', is likewise treated as if it were `strcpy(res.target+8, "")', which would
also just store a null byte at res.target+8, so it is seen as redundant and is
removed.

I would like to acknowledge StackOverflow user BrodieG for initially
discovering this bug and helping to investigate, as well as users KamilCuk and
John Bollinger for helpful comments. The original question is at
https://stackoverflow.com/q/60406042/634919.

Output of `gcc -v`:

Using built-in specs.
COLLECT_GCC=/home/nate/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/home/nate/do-not-backup/gcc-inst/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/nate/gcc --disable-bootstrap
--enable-languages=c
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200229 (experimental) (GCC)

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by John David Anglin :

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

commit r10-6936-gd4912dc76662ab434c897ab454e3285fbb6ca6df
Author: John David Anglin 
Date:   Sat Feb 29 16:13:23 2020 +

Fix baseline symbols on hppa-linux-gnu

2020-02-29  John David Anglin  

PR libstdc++/92906
* config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.

[Bug inline-asm/93981] No EH information generated for asm statements

2020-02-29 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
How do you propose the compiler can generate accurate asynchronous unwind
info for random inline assembler?  (Answer: that is impossible).

[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c

2020-02-29 Thread law at redhat dot com

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

--- Comment #7 from Jeffrey A. Law  ---
I didn't look at the history to see who marked it a P1.  I did consider the
possibility that this was being kept open because the test failures, while
seemingly innocuous, were actually something much more serious.

Thanks in advance for taking care of them when you're awake again :-)

[Bug target/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
I'm CCing Vlad, since I need some guidance/help for some LRA questions.

So this looks similar to PR93658, in that my patch exposed a latent bug.
However, in this case, the bugs seems to be in the LRA constraints fixup
code.

Jakub, I would normally just think reverting the 3 commits used to fix
PR93658 in GCC 8 would be the best course of action here, but if we do
that, then we're just reexposing the bug from PR93658.  But maybe that
is still preferable than applying an LRA fix (which we don't have yet)
that could affect all targets this late in the release process?  Thoughts?

So onto my findings.  After IRA, we have the following allocations and rtl:

Disposition:
6:r121 l0   mem5:r124 l0334:r125 l0340:r128 l014

(insn 34 (set (reg:DI 128) (const_int -32)))
...
(insn 39 (set (reg:V2DF 121 [ D.3415 ])
  (mem/c:V2DF (and:DI (plus:DI (reg/f:DI 110 sfp)
  (reg:DI 128))
  (const_int -16
 (expr_list:REG_EQUIV (mem/c:V2DF (and:DI (plus:DI (reg/f:DI 110 sfp)
(reg:DI 128)) (const_int -16)))
   (expr_list:REG_EQUAL (mem/c:V2DF (plus:DI (reg/f:DI 110 sfp) (const_int
-32))
...
(insn 15 (set (reg:DF 124)
  (subreg:DF (reg:V2DF 121) 0)))
(insn 16 (set (reg:DF 125 [+8 ])
  (subreg:DF (reg:V2DF 121) 8))
 (expr_list:REG_DEAD (reg:V2DF 121)))

When LRA processes insn 15, it replaces the subreg: reg with the mem from
insn 39 and we get:

(insn 15 (set (reg:DF 124)
  (mem/c:DF (and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
  (reg:DI 128))
 (const_int 64 [0x40]))
(const_int -16)

This is not a valid address, so LRA in process_address(), we pass the
following address to decompose_address():

(and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
  (reg:DI 128))
 (const_int 64))
(const_int -16))

Eventually, we end up with:

(insn 56 (set (reg:DI 136)
  (plus:DI (reg/f:DI 110 sfp)
   (const_int 64
(insn 57 (set (reg:DI 136)
  (plus:DI (reg:DI 136)
   (reg:DI 128
(insn 58 (set (reg:DI 136)
  (and:DI (reg:DI 136)
  (const_int -16
(insn 15 (set (reg:DF 124)
  (mem/c:DF (reg:DI 136

This isn't ideal, but looks correct.

The problem comes when we process insn 16.  It looks just like insn 15,
but its subreg is at an offset of 8.  In decompose_address(), we're
passed an address that looks like:

(plus:DI (and:DI (plus:DI (plus:DI (reg/f:DI 110 sfp)
   (reg:DI 128))
  (const_int 64))
 (const_int -16))
 (const_int 8))

Now strip_address_mutations() seems to expect seeing a "(and: ..." type
address, but it is completely confused by seeing a PLUS wrapped around
it, which is what eventually causes us to ICE in decompose_normal_address
because it doesn't look like we have a base_term or index_term type addr.

Vlad, do you have some guidance on what should be done when we see
an address like the above?  I tried hacking some changes to recognize
the extra PLUS, but ended up causing an infinite loop in LRA.
Do you have thoughts on how to fix this properly?

[Bug inline-asm/93981] No EH information generated for asm statements

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

--- Comment #3 from jwjagersma at gmail dot com ---
I don't think it needs to. The user can do this manually with .cfi directives.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-29 Thread iains at gcc dot gnu.org

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

--- Comment #9 from Iain Sandoe  ---
one additional point.

For earlier OS versions the 'atos' version installed is not sufficient to get
sensible output from the sanitizer (characterised by very long timeouts on
failed tests).

In that case, it is better to install llvm-symbolizer from a recentish LLVM and
to set ASAN_SYMBOLIZER_PATH=/path/to/llvm-symbolizer before running tests
(FWFW, I tend to do this about 50% of the time even on recent OS versions to
ensure that the fails seen are from the sanitiser not atos).  atos is
closed-source so we can't fix/rebuild it.

Unfortunately, the llvm-symbolizer exe is not part of the Xcode distributions,
so it has to be built from source.

In the case of the x86_64-darwin11 kernel panics, this made no difference to
the observed fails.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

2020-02-29 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #5 from Segher Boessenkool  ---
Not a target bug.  Andrew, please don't change classification unless you know
where the problem is.

[Bug inline-asm/93981] No EH information generated for asm statements

2020-02-29 Thread segher at gcc dot gnu.org

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

--- Comment #4 from Segher Boessenkool  ---
Pretending any asm can throw would be a pretty serious code degradation.

Any asm that is not volatile cannot throw (and be correct code).  But
most volatile asm in the wild can never throw, either.

[Bug fortran/92976] [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

2020-02-29 Thread pault at gcc dot gnu.org

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
I just posted the fix to the list.

Paul

[Bug inline-asm/93981] No EH information generated for asm statements

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

--- Comment #5 from jwjagersma at gmail dot com ---
(In reply to Segher Boessenkool from comment #4)
> Pretending any asm can throw would be a pretty serious code degradation.
> 
> Any asm that is not volatile cannot throw (and be correct code).  But
> most volatile asm in the wild can never throw, either.

The intention is to only produce EH info for volatile asms, and only if
-fnon-call-exceptions is given. Asms that take volatile memory operands
should be covered too. There are multiple instances in the gcc code
that suggest this should be possible, but it seems it was never
implemented fully. For example this comment in stmt_could_throw_p:

```
/* The only statements that can throw an exception are assignments,
 conditionals, calls, resx, and asms.  */
```

And the fact that tree_could_trap_p, stmt_could_throw_p, may_trap_p_1
have cases that return true for asm.

Do note that the proposed patch is still incomplete, I ran into an ICE
while building libgcc with -fnon-call-exceptions:

```
during GIMPLE pass: ehcleanup
../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c:107:1: internal
compiler error: in mark_reachable_handlers, at tree-eh.c:3929
  107 | }
  | ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
```

However I am not knowledgable enough about gcc's inner workings to know
what exactly is missing. I'm hoping someone can help me out with this.

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

2020-02-29 Thread pault at gcc dot gnu.org

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

--- Comment #30 from Paul Thomas  ---
(In reply to Damian Rouson from comment #29)
> Hi Paul,
> 
> The test case works with your patch applied.  Thanks!
> 
> Damian

Hi Damian,

I need to digest https://gcc.gnu.org/ml/fortran/2019-11/msg00098.html before
this is ready to go.

Regards

Paul

[Bug libstdc++/93983] New: std::filesystem::path is not concept-friendly

2020-02-29 Thread lyberta at lyberta dot net

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

Bug ID: 93983
   Summary: std::filesystem::path is not concept-friendly
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lyberta at lyberta dot net
  Target Milestone: ---

#include 
#include 

struct Foo
{
Foo(const std::filesystem::path& p);
};

static_assert(std::copyable);

Error:
In file included from :1:

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/stl_iterator_base_types.h:
In instantiation of 'struct std::iterator_traits':

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/fs_path.h:84:11:
  required by substitution of 'template using
__is_path_iter_src = std::__and_::type, char>,
std::is_same::type, char8_t>, std::is_same::type, wchar_t>,
std::is_same::type, char16_t>, std::is_same::type, char32_t> >,
std::is_base_of > [with _Iter = Foo; _Iter_traits =
std::iterator_traits]'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/fs_path.h:91:5:
  required by substitution of 'template
std::filesystem::__cxx11::__detail::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::__detail::__is_path_src(_Iter, int) [with _Iter =
Foo]'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/fs_path.h:115:29:
  required from 'struct
std::filesystem::__cxx11::__detail::__constructible_from'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:138:12:
  required from 'struct std::__and_ >,
std::filesystem::__cxx11::__detail::__constructible_from >'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:143:12:
  required from 'struct std::__and_ >, std::__not_ >,
std::filesystem::__cxx11::__detail::__constructible_from >'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/fs_path.h:119:11:
  required by substitution of 'template using _Path =
typename std::enable_if >::type,
std::filesystem::__cxx11::path> >, std::__not_::type> >,
std::filesystem::__cxx11::__detail::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = Foo; _Tp2 = void]'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/bits/fs_path.h:219:7:
  required by substitution of 'template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = Foo; _Require =
]'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:901:30:
  required from 'struct std::__is_constructible_impl'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:906:12:
  required from 'struct std::is_constructible'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:3107:25:
  required from 'constexpr const bool std::is_constructible_v'

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/concepts:139:30:  
required from here

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/concepts:139:30:
error: the value of 'std::is_constructible_v' is not usable in a
constant expression

  139 |   = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;

  |  ^

In file included from
/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/concepts:44,

 from :1:

/opt/compiler-explorer/gcc-trunk-20200229/include/c++/10.0.1/type_traits:3107:25:
note: 'std::is_constructible_v' used in its own initializer

 3107 |   inline constexpr bool is_constructible_v =

  | ^~

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

2020-02-29 Thread barry.revzin at gmail dot com

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #1 from Barry Revzin  ---
Here's a shorter reproduction without filesystem:

#include 
#include 

struct path {
template ::value_type,
char>>
>
path(Source const&);
};

struct Bar
{
Bar(const path& p);
};

#ifdef ADD_THIS
static_assert(!std::constructible_from);
#endif
static_assert(std::copyable);

If ADD_THIS isn't defined, the copyable check is a hard error. If it is
defined, compiles fine.

https://godbolt.org/z/FEoiwA

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

2020-02-29 Thread barry.revzin at gmail dot com

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

--- Comment #2 from Barry Revzin  ---
(From Tim) This is LWG 3244.

[Bug ipa/92548] FAIL: gcc.dg/ipa/ipa-sra-12.c scan-ipa-dump-times sra "Will split parameter" 2

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:38b1722d5d44c52e06a8694b8fa36793735e27d1

commit r10-6943-g38b1722d5d44c52e06a8694b8fa36793735e27d1
Author: John David Anglin 
Date:   Sat Feb 29 19:23:02 2020 +

XFAIL IPA tests that are not supported on 32-bit hppa*-*-hpux*.

2020-02-29  John David Anglin  

PR ipa/92548
* gcc.dg/ipa/ipa-sra-12.c: xfail parameter split test on 32-bit
hppa*-*-hpux*.
* gcc.dg/ipa/ipa-sra-14.c: Likewise.
* gcc.dg/ipa/ipcp-agg-12.c: xfail adding extra caller test.

[Bug ipa/92548] FAIL: gcc.dg/ipa/ipa-sra-12.c scan-ipa-dump-times sra "Will split parameter" 2

2020-02-29 Thread danglin at gcc dot gnu.org

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed on trunk.

[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by John David Anglin :

https://gcc.gnu.org/g:819852b98eb2451672b35bf4a35bcfd41071e26e

commit r10-6945-g819852b98eb2451672b35bf4a35bcfd41071e26e
Author: John David Anglin 
Date:   Sat Feb 29 20:36:49 2020 +

Disable gnat.dg/socket1.adb on hppa*-*-hpux*.

2020-02-29  John David Anglin  

PR ada/91100
* gnat.dg/socket1.adb: Disable on hppa*-*-hpux*.

[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by John David Anglin
:

https://gcc.gnu.org/g:11d93ca76c04f79e43b6e39ab8658b07c0475932

commit r9-8305-g11d93ca76c04f79e43b6e39ab8658b07c0475932
Author: John David Anglin 
Date:   Sat Feb 29 20:39:09 2020 +

Disable gnat.dg/socket1.adb on hppa*-*-hpux*.

2020-02-29  John David Anglin  

PR ada/91100
* gnat.dg/socket1.adb: Disable on hppa*-*-hpux*.

[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test

2020-02-29 Thread danglin at gcc dot gnu.org

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #5 from John David Anglin  ---
Fixed.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

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

--- Comment #6 from Jakub Jelinek  ---
My slight preference would be probably reversion, maybe even on both 8 and 9
branches, do the releases, fix on the trunk, give it two or three weeks to
settle and then backport again, but maybe I'm just trying to be too cautious
when ra is involved.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

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

--- Comment #7 from Peter Bergner  ---
Another option would be to release now without reverting.  If we revert and
then release, then we're shipping a compiler with bug PR93658 in it.  If we
release now without reverting, then PR93658 is fixed and we'll ship with this
bug in it.  Both bugs fail with -O3 -mcpu=power8 -fstack-protector-strong and
both can be worked around using -O2.  The only difference would be we either
ICE with this test case, or we go into an infinite loop in LRA.  I guess as a
user, I'd prefer the ICE.  Your choice though.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

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

--- Comment #8 from Jakub Jelinek  ---
Well, there is a significant difference, the other PR has been there for more
than 2 years before somebody discovered it, while this one was discovered much
quicker and there is a possibility there could be other issues too.
With a reversion we get to a known state, keeping it we remain in far less
tested state, so unless one bug is much more severe than the other one, I'd go
for the known state.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

2020-02-29 Thread xerofoify at gmail dot com

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #9 from Nicholas Krause  ---
Peter and Jakub,

Sorry if I'm misunderstanding the power code but is there a way to rewrite the
test to:
if (VECTOR_MEM_ALTIVEC(mode)
and another branch for VSX_P instructions.

I'm assuming that because its checking both we can get a infinite loop. I'm
assuming that in order to hand this off to the LRA we will need to
rewrite in to have two paths one for VSX_P and one for standard MEM_ALTIVEC. 

Maybe Vlad as mentioned has a better idea about the LRA issues. But I'm very
suspicious of checking both VSX and non VSX_P instructions in the same way for
legitimate_address_p.

Maybe I'm misunderstanding the issue outside of backporting,

[Bug libbacktrace/91908] New libbacktrace tests fail to build

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by John David Anglin
:

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

commit r9-8307-gfa8a705d1f86ca9e576244eb9ae259ed63db4786
Author: John David Anglin 
Date:   Sat Feb 29 22:25:04 2020 +

Fix libbacktrace build on hppa-hpux.

2020-02-29  John David Anglin  

Backport from mainline
2019-09-26  Ian Lance Taylor  

PR libbacktrace/91908
* pecoff.c (backtrace_initialize): Explicitly cast unchecked
__sync_bool_compare_and_swap to void.
* xcoff.c (backtrace_initialize): Likewise.

[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-29
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|Assignment incorrectly  |[10 Regression] Assignment
   |omitted by  |incorrectly omitted by
   |-foptimize-strlen   |-foptimize-strlen since
   ||r10-2528
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-2528-g34fcf41e30ff56155e996f5e04f6ca13948a19b6.
I'll have a look.

[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528

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

--- Comment #2 from Jakub Jelinek  ---
Simplified testcase:

struct A { const char **a; };
const char *buf[5];

__attribute__((noipa)) struct A
foo (char *p)
{
  struct A r = { (const char **) p };
  r.a[0] = "12345678";
  r.a[1] = "";
  r.a[2] = "";
  r.a[3] = "";
  r.a[4] = "";
  return r;
}

int
main ()
{
  struct A r = foo ((char *) &buf[0]);
  if (!r.a[1] || r.a[1][0] != '\0')
__builtin_abort ();
  return 0;
}

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

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

--- Comment #10 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #8)
> With a reversion we get to a known state, keeping it we remain in far less
> tested state, so unless one bug is much more severe than the other one, I'd
> go for the known state.

Ok, I pushed the reversions for both GCC 8 & 9.

[Bug c++/93984] New: spurious Wclass-conversion warning

2020-02-29 Thread stsp at users dot sourceforge.net

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

Bug ID: 93984
   Summary: spurious Wclass-conversion warning
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

#include 

struct D;
struct B {
virtual operator D() = 0;
};
struct D : B
{
operator D() override { std::cout << "conv" << std::endl; return D(); }
};
.
int main()
{
D obj;
B& br = obj;
(D)br; // calls D::operator D() through virtual dispatch
return 0;
}

$ LC_ALL=C g++ -Wall -o vconv vconv.cpp 
vconv.cpp:9:5: warning: converting 'D' to the same type will never use a type
conversion operator [-Wclass-conversion]
9 | operator D() override { std::cout << "conv" << std::endl; return
D(); }
  | ^~~~


$ ./vconv 
conv


The example above shows that the warning
is spurious. Converting to the same type
will indeed never use the conversion
operator. But the above case converts
from B to D, so the warning does not apply.
It may be quite difficult to check properly,
but in this particular example the "override"
keyword is a clear hint that it is going
to be used via the virtual dispatch.

[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528

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

--- Comment #3 from Jakub Jelinek  ---
bool is_char_store = is_char_type (type);
if (!is_char_store && TREE_CODE (lhs) == MEM_REF)
  {
/* To consider stores into char objects via integer types
   other than char but not those to non-character objects,
   determine the type of the destination rather than just
   the type of the access.  */
for (int i = 0; i != 2; ++i)
  {
tree ref = TREE_OPERAND (lhs, i);
type = TREE_TYPE (ref);
if (TREE_CODE (type) == POINTER_TYPE)
  type = TREE_TYPE (type);
if (TREE_CODE (type) == ARRAY_TYPE)
  type = TREE_TYPE (type);
if (is_char_type (type))
  {
is_char_store = true;
break;
  }
  }
  }
is completely bogus.  With pointer conversions being useless, the type of the
MEM_REF's first operand means nothing at all and the type of second MEM_REF
operand is for alias analysis, again nothing that should matter for how the
strlen pass optimizes code.

[Bug rtl-optimization/93974] [8/9/10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762