https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71179
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat May 21 07:09:16 2016
New Revision: 236554
URL: https://gcc.gnu.org/viewcvs?rev=236554&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
2016-05-21 Kugan Vivekanandarajah
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973
--- Comment #21 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat May 21 08:35:25 2016
New Revision: 236556
URL: https://gcc.gnu.org/viewcvs?rev=236556&root=gcc&view=rev
Log:
@@ -1,3 +1,22 @@
2016-05-21 Iain Sandoe
Domi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #15 from Dominique d'Humieres ---
> Another odd thing I found is on or about scanner.c:1530 is this:
>
> if (c == '0' || c == ' ' || c == '\n')
>
> What is the significance of a zero digit in that position. ...
'0' is not a cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71000
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70999
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151
Georg-Johann Lay changed:
What|Removed |Added
CC||gigo121 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103
--- Comment #2 from denisc at gcc dot gnu.org ---
Author: denisc
Date: Sat May 21 10:47:27 2016
New Revision: 236558
URL: https://gcc.gnu.org/viewcvs?rev=236558&root=gcc&view=rev
Log:
PR target/71103
* config/avr/avr.md (define_ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677
Georg-Johann Lay changed:
What|Removed |Added
Keywords||missed-optimization
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676
Georg-Johann Lay changed:
What|Removed |Added
Keywords||missed-optimization
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69647
Georg-Johann Lay changed:
What|Removed |Added
Target||avr
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218
Bug ID: 71218
Summary: Add a warning about "new T[integer-literal]"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218
--- Comment #1 from Marc Glisse ---
Can you be more specific? Do you mean people should have written:
T tab[8];
instead? What if 8 or sizeof(T) is large? If your "..." includes possible
writes to p, or if p escapes and "..." may throw, I guess th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2014-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Bug ID: 71219
Summary: Warn about (struct S*)malloc(n) where n <
sizeof(struct S)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
--- Comment #12 from Jonathan Wakely ---
PR 71219 requests a new warning for:
struct S* p = (struct S*)malloc(sizeof(p));
which would solve some of the other bugs shown in comment 3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
--- Comment #13 from Jakub Jelinek ---
If we add such a warning, IMNSHO it shouldn't be in -Wall, because sizeof on
pointer is a perfectly valid thing, which is used in huge amounts of code,
there is really nothing wrong on it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71218
--- Comment #2 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #1)
> Can you be more specific? Do you mean people should have written:
> T tab[8];
Yes, exactly. I was fixing some code earlier today that used a dynamically
allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
--- Comment #14 from Jonathan Wakely ---
See PR 71219 and the TC it links to. The suggestion is to warn for
(T*)malloc(n) where n < sizeof(T) i.e. when there is enough context to infer
that what was intended was malloc(sizeof(T)). The occurrence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
--- Comment #15 from Jakub Jelinek ---
Even (T*)malloc(n) where n < sizeof(T) is quite common, e.g. in GCC itself
(well, we don't usually use malloc but some ggc_alloc*) - e.g. if T is a union
and the code wants to allocate memory just for one of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71205
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70735
Maurice changed:
What|Removed |Added
CC||m-ou...@m-ou.se
--- Comment #12 from Maurice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> This is a bandaid, but it works.
>
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2490f856..726973a6 100644
> --- a/gcc/fortran/mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71056
--- Comment #4 from Yichao Yu ---
(Sorry I'm not sure how to understand that cross link). Is the fix merged?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #17 from Jerry DeLisle ---
Steve, I like your patch much better. I will test and commit for you with a
Changelog
Dominique, Do you have a version of gfortran where this does not give an ICE???
I have just one other thing to check fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
--- Comment #18 from Dominique d'Humieres ---
> Dominique, Do you have a version of gfortran where this does not give an
> ICE???
4.3.1, 4.3.6, and 4.4.7 (see comment 13).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71220
Bug ID: 71220
Summary: ICE on instantiation using variadic template
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
Bug ID: 71221
Summary: [concepts] ICE in tsubst_pack_expansion when expanding
a sizeof... expression in a requires clause of a
member function template
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222
Bug ID: 71222
Summary: [concepts] ill-formed code taking the address of a
function concept not rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71221
--- Comment #1 from Tom Honermann ---
(In reply to Tom Honermann from comment #0)
> $ g++ --version
> g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010
Oops, I ran the above in the wrong terminal session. The correct gcc version
info is:
$ g++ --ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71223
Bug ID: 71223
Summary: [fold expression] Incorrect processing a fold
expression
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Prior
32 matches
Mail list logo
