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 a-
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 D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949
Martin Uecker changed:
What|Removed |Added
CC||uecker at eecs dot berkeley.edu
--- Comm
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=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=92959
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assigne
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: in
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
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 w
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,
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)
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
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
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 s
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=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=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 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Segher Boessenkool changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #5 fro
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=92976
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assigne
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=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
/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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment
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=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
Da
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=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
Da
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 Ang
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=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 tryin
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
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 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
--- Comment
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 Ang
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=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=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
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=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
oth
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 instruc
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=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 -fno-fat-lto-obje
43 matches
Mail list logo
