https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84080
Bug ID: 84080
Summary: the compiler crashes when compiling the following
sample file
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
--- Comment #3 from Jerry DeLisle ---
I think this bug is invalid and gfortran is correct.
If you do this:
&n
ta(1:8)%c = 'bogus'
/
You get what you expect. The way you have it, you can not put 8 strings called
'bogus' into one strng element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82541
Paolo Carlini changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422
--- Comment #7 from cookevillain at yahoo dot com ---
(In reply to Andrew Pinski from comment #5)
> The first example is invalid C90 anyways:
> t4.c:10:3: error: ISO C90 forbids mixed declarations and code [-Wpedantic]
I forgot to mention it in m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83924
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83924
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Sun Jan 28 01:28:05 2018
New Revision: 257131
URL: https://gcc.gnu.org/viewcvs?rev=257131&root=gcc&view=rev
Log:
2018-01-27 Paolo Carlini
PR c++/83924
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84079
Bug ID: 84079
Summary: missing -Warray-bounds taking the address of a
multidimensional array element
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55422
cookevillain at yahoo dot com changed:
What|Removed |Added
Version|4.4.3 |5.4.0
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83152
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
Bug ID: 84078
Summary: false positive for -Wmaybe-uninitialized
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077
--- Comment #1 from Flössie ---
Created attachment 43264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43264&action=edit
Preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077
Bug ID: 84077
Summary: Likely wrong code with `__builtin_expect()` on
i686-linux-gnu
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073
--- Comment #5 from emsr at gcc dot gnu.org ---
In a way, I *am* treating this as a char array n the C side and it would
probably be most correct to have
character(kind=c_char) thing(42).
and get
char thing[42];
honestly.
Is there a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66505
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073
--- Comment #4 from Thomas Koenig ---
The real error is that lengths unequal to one are not
C interoperable, and should be rejected.
From the F2003 standard, 15.2.1:
"if the type is character, inter-
operability also requires that the length ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53129
Eric Gallager changed:
What|Removed |Added
Keywords||patch
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83828
--- Comment #3 from H.J. Lu ---
On AVX512 machine, r257121 gave:
FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512bitalgvl-vpopcntb-1.c (test for excess errors)
FAIL: gcc.target/i386/avx512bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83905
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84073
--- Comment #3 from emsr at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Withe the following change
>
> --- pr84073.f90 2018-01-26 22:48:32.0 +0100
> +++ pr84073_db.f902018-01-27 00:03:06.0 +0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074
--- Comment #3 from Vladimir Fuka ---
The bug has been around for so long that I already forgot I saw these problems
before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #21 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #2 from Wilc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77428
--- Comment #3 from Eric Gallager ---
(In reply to Tom de Vries from comment #1)
> Created attachment 39528 [details]
> tentative patch
Have you sent this patch to the gcc-patches mailing list yet?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51088
--- Comment #6 from Eric Gallager ---
(In reply to Marek Polacek from comment #5)
> Patch to give an error if taking an address of a label defined in ({}):
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00381.html
Does this patch still apply aga
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35511
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66504
Eric Gallager changed:
What|Removed |Added
Known to work||4.7.4, 4.8.5, 5.5.0, 6.4.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070
Eric Gallager changed:
What|Removed |Added
Keywords||needs-bisection
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83442
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #21 from Waldemar Brodkorb ---
I can confirm that this fixes the problem even for gcc 7.x.
Any chance to get it included into gcc 7 branch?
No regression found while running the uClibc-ng testsuite inside
qemu-system-m68k.
Thanks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38743
--- Comment #8 from Eric Gallager ---
(In reply to Eric Gallager from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > a patch like http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00474.html is
> > needed for libgcc.
>
> Confirming tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301
--- Comment #3 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> (In reply to Ryan Johnson from comment #0)
> > ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though
> > it correctly warns when $MY_TOOLS i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
Bug ID: 84076
Summary: [5/6/7/8 Regression] Warning about objects through POD
mistakenly claims the object is a pointer
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83905
--- Comment #3 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Sat Jan 27 13:10:24 2018
New Revision: 257123
URL: https://gcc.gnu.org/viewcvs?rev=257123&root=gcc&view=rev
Log:
i386: Use const reference of struct ix86_frame to avoid copy
We ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83442
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #13 from Heinz Kohl ---
O.k., but following your arguments I'd expect 0xb as result for my second
example 0xb.3590da0e2a06736p-3 (attachment 41578), but it's giving 0, also
stopping at 'x' and not at '.', just as in the first case.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--- Comment #5 from Bernd Edlinger ---
FYI the C++ FE behaves differently:
cat x.cc
typedef __SIZE_TYPE__ size_t;
extern "C" void *memset(void *s, int c, size_t n)
__attribute__ ((visibility ("hidden")));
void
foo1 (void *s, size_t n)
{
mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84065
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 27 10:28:20 2018
New Revision: 257121
URL: https://gcc.gnu.org/viewcvs?rev=257121&root=gcc&view=rev
Log:
PR fortran/84065
* decl.c (add_init_expr_to_sym): Ignore i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #20 from Domi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
--- Comment #6 from Jakub Jelinek ---
Zero sized object occupies zero bytes, if you have an array of them,
necessarily all the elements of the array need to have the same address. While
individual variables could be in theory padded, it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84046
--- Comment #5 from Martin Uecker ---
(In reply to Jakub Jelinek from comment #4)
> If you want aggregate with size 1 and isn't used to store information, use
> typedef struct { char : 1; } zero;
> instead.
Yes, thank you.
But for my understand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Bug ID: 84075
Summary: Template parameter not resolved: invalid application
of ‘sizeof’ to incomplete type
‘boost::serialization::U’
Product: gcc
Version: 7.3.0
47 matches
Mail list logo
