https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71416
Chengnian Sun changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
Tim Shen changed:
What|Removed |Added
CC||timshen at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #5 from Bernd Edlinger ---
this seems to fix it:
Index: input.c
===
--- input.c (Revision 237323)
+++ input.c (Arbeitskopie)
@@ -1210,7 +1210,7 @@
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #6 from David Malcolm ---
(In reply to Bernd Edlinger from comment #5)
> this seems to fix it:
Thanks, and sorry for the breakage.
I wonder if it would be better to instead hardcode LANG=C in the Makefile.am
hooks that run the selft
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #7 from Bernd Edlinger ---
(In reply to David Malcolm from comment #3)
> Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00755.html
BTW: this patch seems not to remove the tempfile again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71481
--- Comment #8 from Bernd Edlinger ---
(In reply to David Malcolm from comment #6)
> I wonder if it would be better to instead hardcode LANG=C in the Makefile.am
> hooks that run the selftests? The DejaGnu-based testsuite does that.
Well, hopef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71466
--- Comment #10 from Jan Hubicka ---
Iterations bounds are computed at early optimization time and maintained
thorough. So the info is computed at thread2 time.
Looking into testcase I noticed that jump threading seems to be doing useless
work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67463
--- Comment #1 from Shlomi Fish ---
Ping! This bug still appears to happen with gcc-5.4.0-1.mga6 on Mageia Linux
x86-64 v6/Cauldron.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71501
Bug ID: 71501
Summary: printf %s error on str[5], for example: strncpy(str,
"12345", 5)
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170
--- Comment #16 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #10)
> Author: kugan
> Date: Tue May 24 00:14:13 2016
> New Revision: 236619
>
> URL: https://gcc.gnu.org/viewcvs?rev=236619&root=gcc&view=rev
> Log:
> gcc/ChangeLo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #3 from Michael Duggan ---
Still fails for the following code:
#include
#include
#include
using namespace std;
void check(const string& s, regex re) {
cout << s << " : " << (regex_match(s, re) ? "Match" : "Nope") << endl;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502
Bug ID: 71502
Summary: Fold expression unpacks (I < ...) the wrong way
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502
--- Comment #1 from Michele Caini ---
I notice that there is a flaw in the text.
I expect this to compile and run with no errors, as it happens indeed:
#include
int main() { assert((0 < 42) < 3); }
From what I wrote, it would seem that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502
--- Comment #2 from Michele Caini ---
Example on godbolt.org with GCC 6.1.0: https://godbolt.org/g/9meqv4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71502
Sleep tight pupper changed:
What|Removed |Added
CC||horridminded at mailinator dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71501
--- Comment #1 from Andreas Schwab ---
%s requires a zero-terminated string.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #4 from Tim Shen ---
(In reply to Michael Duggan from comment #3)
> regex re1 = regex("[T-f]+", regex::icase);
This regex actually doesn't compile in Boost, since boost interpret icase as
"transforming [T-f] to [t-f]", then throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #19 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jun 11 19:19:43 2016
New Revision: 237329
URL: https://gcc.gnu.org/viewcvs?rev=237329&root=gcc&view=rev
Log:
2016-06-11 Dominique d'Humieres
PR fortran/6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #20 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jun 11 19:21:22 2016
New Revision: 237330
URL: https://gcc.gnu.org/viewcvs?rev=237330&root=gcc&view=rev
Log:
2016-06-11 Dominique d'Humieres
PR target/60751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #5 from mwd at cert dot org ---
All of the ECMAScript engines I have found work with this , and the ECMAScript
specs seem to imply that this should work as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71061
--- Comment #1 from Jiong Wang ---
Author: jiwang
Date: Sat Jun 11 20:42:26 2016
New Revision: 237331
URL: https://gcc.gnu.org/viewcvs?rev=237331&root=gcc&view=rev
Log:
[ARM] length pop* pattern in epilogue correctly
PR target/71061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71061
Jiong Wang changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #25 from Alexander Cherepanov ---
On 06/10/2016 12:18 AM, joseph at codesourcery dot com wrote:
>> > For *scalar* assignment that would be fine because of TS 18661-1 saying
>> > "Whether C assignment (6.5.16) (and conversion as if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71501
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71475
--- Comment #7 from joseph at codesourcery dot com ---
On Fri, 10 Jun 2016, ch3root at openwall dot com wrote:
> Ok, what about this:
This bug is closed as INVALID. No-one will pay any attention to comments
on a closed bug proposing different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71460
--- Comment #26 from joseph at codesourcery dot com ---
On Sat, 11 Jun 2016, ch3root at openwall dot com wrote:
> > C11 does not
> > consider sNaNs, and TS 18661 is explicitly stating otherwise for them.
>
> You are talking about C11 + TS 18661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64955
--- Comment #4 from Manuel López-Ibáñez ---
For what is worth, Clang is already doing this:
prog.cc:5:19: warning: format specifies type 'int' but the argument has type
'long long' [-Wformat]
printf ("%i\n", ll);
~~ ^~
e --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 7.0.0 20160611 (experimental) [trunk revision 237328] (GCC)
$ gcc-trunk -O3 abc.c
abc.c: In function ‘fn1’:
abc.c:3:6: internal compiler error: in gen_phi_arg_conditio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #6 from Tim Shen ---
(In reply to mwd from comment #5)
> All of the ECMAScript engines I have found work with this , and the
> ECMAScript specs seem to imply that this should work as well.
I think you are right.
According to ECMAScr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #21 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jun 11 22:36:50 2016
New Revision: 237332
URL: https://gcc.gnu.org/viewcvs?rev=237332&root=gcc&view=rev
Log:
2016-06-12 Dominique d'Humieres
PR target/60751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71170
--- Comment #17 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #15)
> (In reply to David Binderman from comment #14)
> > (In reply to Jakub Jelinek from comment #12)
> > > Is it still broken?
> >
> > I think so. Attachment seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504
Bug ID: 71504
Summary: bogus error: accessing value through a glvalue in a
constant expression
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505
Bug ID: 71505
Summary: -O3 internal compiler error in
vect_analyze_data_ref_accesses, at
tree-vect-data-refs.c:2596
Product: gcc
Version: 5.3.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505
--- Comment #1 from Tony Kelman ---
Created attachment 38688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38688&action=edit
other local minima from creduce - 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71505
--- Comment #2 from Tony Kelman ---
Created attachment 38689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38689&action=edit
other local minima from creduce - 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #7 from Michael Duggan ---
"timshen at gcc dot gnu.org" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
>
> --- Comment #6 from Tim Shen ---
> (In reply to mwd from comment #5)
>> All of the ECMAScript engines I have f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #8 from Tim Shen ---
(In reply to Michael Duggan from comment #7)
> Hmm... Okay. For the sake of argument, I am going to make the
> following claims:
Yeah, thanks for the arguments, we should at least get this clear.
> a) Ignorin
39 matches
Mail list logo
