https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49551
Prathamesh changed:
What|Removed |Added
CC||bilbotheelffriend at gmail dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #6 from howarth at bromo dot med.uc.edu ---
Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02664.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #12 from joseph at codesourcery dot com ---
On Thu, 29 Jan 2015, tromey at gcc dot gnu.org wrote:
> E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
> strings. This extension means that printf checking can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #4 from joseph at codesourcery dot com ---
Note also that gcc.dg/format tests are run both with and without -DWIDE -
the intent there is that wide string formats should be tested, when
supported, with essentially the same tests as n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
--- Comment #7 from mrs at gcc dot gnu.org ---
Author: mrs
Date: Thu Jan 29 22:09:16 2015
New Revision: 220264
URL: https://gcc.gnu.org/viewcvs?rev=220264&root=gcc&view=rev
Log:
2015-01-29 Jack Howarth
PR libffi/64855
* testsuite/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64855
mrs at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #5 from Dominique d'Humieres ---
Note that the error is detected if the code is compiled with
-fsanitize=address. And IMO the right way to use the array in a 'contains' is
a(:) (for which -fcheck=bounds works).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #6 from Harald Anlauf ---
(In reply to Lorenz Hüdepohl from comment #4)
> > The right way to fix the problem is to fix the program
> > by using an appropriate programming style. Writing
> >
> > real:: a(n1:) ! not: real :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64803
--- Comment #6 from Dodji Seketeli ---
Created attachment 34622
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34622&action=edit
Refined candidate fix patch with regression test and cover letter
I have successfully tested this refined patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Jan Hubicka changed:
What|Removed |Added
Last reconfirmed|2014-12-02 00:00:00 |2015-1-29
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880
--- Comment #6 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Jan 30 00:35:44 2015
New Revision: 220268
URL: https://gcc.gnu.org/viewcvs?rev=220268&root=gcc&view=rev
Log:
compiler: Fix -fgo-prefix handling.
There was bug in the fix for P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880
--- Comment #7 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Jan 30 00:36:14 2015
New Revision: 220269
URL: https://gcc.gnu.org/viewcvs?rev=220269&root=gcc&view=rev
Log:
compiler: Fix -fgo-prefix handling.
There was bug in the fix for P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64869
Bug ID: 64869
Summary: "use all type" clause is ineffective
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386
Damiano changed:
What|Removed |Added
CC||dmonax at hotmail dot com
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64365
--- Comment #13 from Brooks Moses ---
FWIW, if you haven't done the 4.9 backport yet, this is what I ended up with.
I'm not sure it's optimal, but it seems to work.
Index: gcc/tree-data-ref.c
===
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #5 from Jan Hubicka ---
OK,
I get:
(gdb) bt
#0 _IO_fread (buf=0x77fe6740 <__gcov_var+32>, size=size@entry=1,
count=count@entry=4096, fp=0x0) at iofread.c:43
#1 0x77fe1719 in gcov_read_words (words=words@entry=2) at
../..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
--- Comment #6 from Jan Hubicka ---
Note that -fno-ipa-icf does not seem to solve the crash for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Jan Hubicka changed:
What|Removed |Added
CC||xur at google dot com
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580
--- Comment #11 from Segher Boessenkool ---
Author: segher
Date: Fri Jan 30 05:35:52 2015
New Revision: 220272
URL: https://gcc.gnu.org/viewcvs?rev=220272&root=gcc&view=rev
Log:
PR target/64580
* config.rs6000/rs6000.c (compute_vrsave_ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Bug ID: 64870
Summary: value not set via reference
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Marc Glisse changed:
What|Removed |Added
Severity|major |normal
--- Comment #1 from Marc Glisse --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580
--- Comment #12 from Markus Trippelsdorf ---
Fixed for gcc-5. Many thanks.
I'll leave this bug open for possible backports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #31 from amker at gcc dot gnu.org ---
So cand_value_at (loop, cand, use->stmt, desc->niter, &bnd) with arguments as
below:
cand->iv->base:
(unsigned long) ((char *) &A + (sizetype) i_6(D))
cand->iv->step:
0xFFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64871
Bug ID: 64871
Summary: inline assembly neon
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #2 from Conrad ---
Notwithstanding loopholes in C++ legalese, the expected result is to evaluate
things left to right, just like reading words and sentences.
clang produces the least surprising result. With gcc we end up with "wtf?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64858
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #3 from Marc Glisse ---
(In reply to Conrad from comment #2)
> Notwithstanding loopholes in C++ legalese,
No loopholes, this was a deliberate choice in C.
> the expected result is to
> evaluate things left to right, just like readin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
--- Comment #4 from Conrad ---
(In reply to Marc Glisse from comment #3)
>
> Except when there is an = sign, where you expect the right hand side to be
> evaluated before the left? And maybe a few other cases?
For iostreams which use the << ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64871
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Jan Hubicka changed:
What|Removed |Added
CC||nathan at codesourcery dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
101 - 131 of 131 matches
Mail list logo