https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #6 from David ---
Created attachment 37621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621&action=edit
Patch for missing clobber validations
I have created a patch (attached) that does the check I am describing. And
while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
Oleg Endo changed:
What|Removed |Added
Target|sh-unknown-linux|sh*-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #10 from Alexander Monakov ---
If always using r0 is not an issue, I think it's possible to just use
operands[0] (casting it to the right size with subreg:SI, if needed) to avoid
using a potentially-reserved hardreg. This would allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #3 from bastian.beisc...@rwth-aachen.de ---
Jonathan, maybe so but it should be mentioned on the page nevertheless, right?
My issue is that we are using (as an example):
#if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||
(define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #11 from Oleg Endo ---
(In reply to Alexander Monakov from comment #10)
> If always using r0 is not an issue, I think it's possible to just use
> operands[0] (casting it to the right size with subreg:SI, if needed) to
> avoid using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #12 from Alexander Monakov ---
> Do you have anything in particular in mind?
I mostly wonder why does sh.md change RTL representation of a sibcall that way,
instead of simply generating the required relative address load upfront, dur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #13 from Oleg Endo ---
(In reply to Alexander Monakov from comment #12)
>
> I mostly wonder why does sh.md change RTL representation of a sibcall that
> way, instead of simply generating the required relative address load
> upfront,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
--- Comment #2 from Oleg Endo ---
Looks like an SH specific issue. The bounds check is there, but it's in the
wrong place:
_lookup_user_key:
mov.l r8,@-r15
mov #0,r3
mov.l r9,@-r15
mov #15,r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
--- Comment #3 from Oleg Endo ---
It seems that one of the loop optimizations pulls the casesi_0 and
casesi_worker_0 insns apart and then things go wrong from there on. Compiling
the test case with -fno-move-loop-invariants results in the correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #4 from Jonathan Wakely ---
(In reply to bastian.beischer from comment #3)
> Jonathan, maybe so but it should be mentioned on the page nevertheless,
> right?
Yes, although I plan to deprecate that macro.
> My issue is that we are us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699
--- Comment #5 from bastian.beisc...@rwth-aachen.de ---
Thanks for your comments. Does this mean that such a macro does not exist at
the present time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #16 from Manuel López-Ibáñez ---
You can also just match the locations and the columns with dg-error. Placing
dg-error at the expected lines will match the expected output as explained in
comment 12. Fixing dg-begin-multiline-output f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Manuel López-Ibáñez changed:
What|Removed |Added
Depends on||43486, 61534
--- Comment #9 from M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
Mikael Morin changed:
What|Removed |Added
Keywords|accepts-invalid |wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Gerald Pfeifer changed:
What|Removed |Added
CC||gerald at pfeifer dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650
--- Comment #6 from Manuel López-Ibáñez ---
Note that it is ok to completely ignore such an invalid line directive and:
line-map.c: file "" left but not entered
should actually be an error or an ICE. As the code says:
/* Depending upon w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
--- Comment #11 from Manuel López-Ibáñez ---
(In reply to Gerald Pfeifer from comment #10)
> (In reply to Jakub Jelinek from comment #8)
> > if (errno == EAGAIN || (EWOULDBLOCK != EAGAIN && errno == EWOULDBLOCK))
> > could be better workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555
--- Comment #7 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Feb 7 20:15:55 2016
New Revision: 233203
URL: https://gcc.gnu.org/viewcvs?rev=233203&root=gcc&view=rev
Log:
2016-02-07 Jerry DeLisle
PR fortran/50555
* primar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555
--- Comment #8 from Jerry DeLisle ---
Closing, fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007
--- Comment #6 from Harald Anlauf ---
(In reply to Harald Anlauf from comment #5)
> The patch of comment #4 appears to be easily extendible to reject
> arrays as loop variables (I hope I got this right):
>
> Index: gcc/fortran/match.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007
--- Comment #7 from Harald Anlauf ---
The patch in comment #6 requires adapting the testsuite accordingly:
gfortran.dg/coarray_8.f90:149:7:
do i = 1, 5 ! { dg-error "cannot be a sub-component" }
needs to be changed to:
do i = 1, 5 ! { d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #14 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #13)
> Good question indeed. Kaz, maybe you remember anything?
With my vague recollection, they were already there when I had looked
into them for the first time.
I g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69139
--- Comment #3 from TC ---
Another test case, slightly modified from the original in the linked SO
question:
struct X {
auto get(int) const & -> int { return {}; }
auto get(int) && -> long { return {}; }
};
template auto f(auto (X::*)(int)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69714
Bug ID: 69714
Summary: [5 Regression] ffmpeg crc.c test miscompiled
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: midd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713
--- Comment #4 from Oleg Endo ---
(In reply to Oleg Endo from comment #3)
>
> One option could be to merge the casesi_0 and casesi_worker_0 /
> casesi_worker_1 patterns somehow into one pattern, so that the block remains
> in one place.
>
> Ano
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786
--- Comment #5 from Patrick Palka ---
Looks like the field LAMBDA_TYPE_EXTRA_SCOPE has what we need. I am testing
this patch:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4d405cf..5c344c1 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -369,16 +3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260
--- Comment #15 from Rich Felker ---
Is it related to the fact that the relative address load is tied to a specific
call site and that the call can't be cloned without producing a new relative
address load to go with the clone?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
Bug ID: 69715
Summary: g++ crash dump on building SoftFloatWrapper.cpp
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
--- Comment #1 from Kip Warner ---
Created attachment 37623
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37623&action=edit
Complete build log (very big, 11 MB decompressed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
Kip Warner changed:
What|Removed |Added
CC||kip at thevertigo dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69716
Bug ID: 69716
Summary: asm generates invalid register name
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #3 from Chen Gang ---
Created attachment 37625
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37625&action=edit
Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for
long wide type will cause issue.
Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717
Bug ID: 69717
Summary: std::pair is incompatible with std::is_constructible
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68886
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109
--- Comment #14 from David ---
I understand that stage 3 is now closed too. I don't have svn write access, so
I can't check this in myself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69718
Bug ID: 69718
Summary: [concepts] cc1plus segfault on invalid
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695
--- Comment #3 from Joost VandeVondele
---
(In reply to Mikael Morin from comment #2)
> This seems to be allowed, see 12.5.2.7:
Interesting, so that's a F2008 feature. The Cray compiler indeed gets this
right.
> So this is probably a plain wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
--- Comment #4 from Kirill Yukhin ---
Created attachment 37628
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37628&action=edit
Reproducer input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
--- Comment #3 from Kirill Yukhin ---
Created attachment 37627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37627&action=edit
Reproducer src
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
--- Comment #5 from Kirill Yukhin ---
A bug in fortran's IO RT has emerged during 21 Apr 2016,
between r54 and r92;
looks like it's caused by the same revision –r71
(libgfortran/io/list_read.c ), which probably just triggers
another
model: posix
gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.2 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ gcc-5.3 -O3 small.c
$ ./a.out
Aborted (core dumped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697
--- Comment #4 from raidl at ac dot tuwien.ac.at ---
Problem is still present in gcc 5.3.0.
Furthermore, it also appears when the thread_local variable is a static class
member.
: posix
gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC)
$
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.3 -O3 small.c; ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$
-
int a, b, c, e, f;
long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601
Joost VandeVondele changed:
What|Removed |Added
CC||gerald at pfeifer dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
49 matches
Mail list logo
