https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980
--- Comment #2 from Alexander Sergeyev ---
(In reply to Andrew Pinski from comment #1)
> Does -fno-use-linker-plugin help?
It seems to work with fat lto objects, but I suspect that no actual lto is
performed in this case.
With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980
--- Comment #1 from Andrew Pinski ---
Does -fno-use-linker-plugin help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #11 from Peter Bergner ---
(In reply to Nicholas Krause from comment #9)
> 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
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
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++
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
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] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93982
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
---
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91100
John David Anglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92548
John David Anglin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
--- Comment #2 from Barry Revzin ---
(From Tim) This is LWG 3244.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
---
/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&g
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/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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976
Paul Thomas changed:
What|Removed |Added
CC||pault 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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Segher Boessenkool changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Peter Bergner changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
/home/nate/gcc --disable-bootstrap
--enable-languages=c
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200229 (experimental) (GCC)
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
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
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
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=edit
proposed patch
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92959
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93980
Bug ID: 93980
Summary: use of lto breaks -Wl,--exclude-libs
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93966
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949
Martin Uecker changed:
What|Removed |Added
CC||uecker at eecs dot berkeley.edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785
--- Comment #6 from paul.richard.thomas at gmail dot com ---
Thanks! I'll change to STOP 1.
Paul
On Fri, 28 Feb 2020 at 20:08, drikosev at gmail dot com
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785
>
> --- Comment #5 from Ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #5 from Marc Glisse ---
It has never been very clear to me what restrict means on a struct member, but
I believe adding it to the pointer in vector means that in a function:
void f(vector*a, vector*b)
the compiler could assume that
43 matches
Mail list logo
