https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
Dominik Vogt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #12 from Andreas Krebbel ---
(In reply to Dominik Vogt from comment #4)
> I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
Yes. The system you are using needs a Glibc upgrade. The patch mentioned in
comment 2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #11 from Jakub Jelinek ---
OT, the gcc/config/s390/linux.h SIZE_TYPE definition looks weird:
(TARGET_64BIT ? "long unsigned int" : "long unsigned int")
As both strings are the same, it would be much cleaner to just say
"long unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #10 from Jakub Jelinek ---
It is a pitty glibc headers didn't use __SIZE_MAX__ if available, because that
appears to be correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #8 from Dominik Vogt ---
Gdb says:
(gdb) ptype __typeof__(size_t)
type = unsigned long
(gdb) ptype __typeof__(SIZE_MAX)
type = unsigned int
Two different types for unsigned 32 bit integers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #7 from Dominik Vogt ---
Or even
--
#include
#include
#define FOO(TYPE, EXPR) __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a;
void foo (void)
{
FOO(__SIZE_TYPE__, (SIZE_MAX));
}
--
So __typeof__(SIZE_MAX) is differe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #6 from Dominik Vogt ---
(In reply to Andreas Krebbel from comment #2)
> The reduced testcase fails with -m31 and -m64 but the original probably only
> with -m31 - right?!
Sorry, you're right. I was doing too many things in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 3 Feb 2017, vogt at linux dot vnet.ibm.com wrote:
> void
> foo (void)
> {
> __typeof__((4294967295U)) a;
> __typeof__((long unsigned int)0 + 0) *b = &a;
> }
That's not a m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #4 from Dominik Vogt ---
I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #3 from Dominik Vogt ---
> The reduced testcase fails with -m31 and -m64 but the original probably only
> with -m31 - right?!
The unreduced testcase fails with -m31 and -m64. I've tried the reduced test
case only with -m64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #2 from Andreas Krebbel ---
The reduced testcase fails with -m31 and -m64 but the original probably only
with -m31 - right?!
Looks like the following Glibc problem which has been fixed a while ago:
commit 26011b5cfa6a1a8d8005d65f11d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358
--- Comment #1 from Dominik Vogt ---
(built with --enable-bootstrap, --enable-multilib and --with-arch=zEC12)
13 matches
Mail list logo
