[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 --- Comment #2 from Mihai Preda --- Adding -lstdc++fs fixes the problem with g++ 8.3 g++-9 does not segfault even without -lstdc++fs g++-9 --version g++-9 (Ubuntu 9-20190402-1ubuntu1) 9.0.1 20190402 (experimental) [trunk revision 270074]
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 Frédéric Bron changed: What|Removed |Added CC||ufospoke at gmail dot com --- Comment #3 from Frédéric Bron --- I just tried with g++ (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) on Fedora and it works well. But to be able to link, I had to add -lstdc++fs.
[Bug fortran/90076] Polymorphic Allocate on Assignment Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90076 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-13 CC||pault at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90068, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90069, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90072 Blocks||86754 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for GCC7 up to trunk (9.0). Assignment to an allocatable polymorphic variable is not supported on earlier versions. As for pr90069, pr90072 one memory leak is fixed by revision r263916. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754 [Bug 86754] [meta-bug] Memory leaks at run time
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90079] New: SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079
Bug ID: 90079
Summary: SEGV in _aaKeys, _aaValues on 32-bit SPARC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-*-*
Created attachment 46161
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46161&action=edit
Trial patch
All aa tests currently SEGV on 32-bit Solaris/SPARC, e.g.
FAIL: libphobos.aa/test_aa.d execution test
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x0009c9b0 in rt.aaA.Impl.length() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:87
87 assert(used >= deleted);
(gdb) where
#0 0x0009c9b0 in rt.aaA.Impl.length() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:87
#1 0x0009c960 in rt.aaA.AA.empty() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:44
#2 0x0009e83c in _aaValues (aa=..., keysz=4, valsz=1,
tiValueArray=0x718fc ) at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:513
#3 0x00082688 in object.values!(test_aa.testKeysValues1().T[int],
test_aa.testKeysValues1().T, int).values(test_aa.testKeysValues1().T[int])
(aa=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:2171
#4 0x00077a9c in test_aa.testKeysValues1() ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/libphobos.aa/test_aa.d:56
#5 0x00077604 in D main ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/libphobos.aa/test_aa.d:3
1: x/i $pc
=> 0x9c9b0 <_D2rt3aaA4Impl6lengthMxFNaNbNdNiZk+32>: ld [ %g1 + 8 ], %g2
(gdb) p/x $g1
$1 = 0x8
(gdb) up
#1 0x0009c960 in rt.aaA.AA.empty() const (this=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:44
44 return impl is null || !impl.length;
(gdb) p impl
$2 = (rt.aaA.Impl *) 0x8
(gdb) up
#2 0x0009e864 in _aaValues (aa=..., keysz=4, valsz=1,
tiValueArray=0x718fc ) at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/aaA.d:513
513 if (aa.empty)
(gdb) p aa
$2 = {impl = 0x8}
(gdb) up
#3 0x000826b0 in object.values!(test_aa.testKeysValues1().T[int],
test_aa.testKeysValues1().T, int).values(test_aa.testKeysValues1().T[int])
(aa=...)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:2171
2171auto a = cast(void[])_aaValues(cast(inout(void)*)aa, Key.sizeof,
Value.sizeof, typeid(Value[]));
(gdb) p aa
$3 = {ptr = 0xfef11000}
Closer investigation reveals object.d calls _aaValues (and _aaKeys)
incorrectly:
While the implementation expects a struct AA
libdruntime/rt/aaA.d:extern (C) inout(void[]) _aaValues(inout AA aa, in size_t
keysz, in size_t valsz,
the call passes a void * instead:
libdruntime/object.d:inout(void)[] _aaValues(inout void* p, in size_t
keysize, in size_t valuesize, const TypeInfo tiValArray) pure nothrow;
libdruntime/object.d:auto a = cast(void[])_aaValues(cast(inout(void)*)aa,
Key.sizeof, Value.sizeof, typeid(Value[]));
The problem is that on 32-bit SPARC small structs are passed by reference, so
there's a mismatch between caller and callee.
On 64-bit SPARC instead, they are passed by value, so the mismatch doesn't
matter and the tests PASS.
So far, I've not yet managed to figure out the correct way to fix this, though:
while the attached patch allows libdruntime to compile, test_aa.d fails:
libdruntime/object.d:2172: error: cannot cast expression aa of type T[int] to
inout(AA)
testsuite/libphobos.aa/test_aa.d:56: error: template instance
object.values!(T[int], T, int) error instantiating
libdruntime/object.d:2150: error: cannot cast expression aa of type int[T] to
inout(AA)
testsuite/libphobos.aa/test_aa.d:66: error: template instance
object.keys!(int[T], int, T) error instantiating
libdruntime/object.d:2150: error: cannot cast expression aa of type int[string]
to inout(AA)
testsuite/libphobos.aa/test_aa.d:75: error: template instance
object.keys!(int[string], int, string) error instantiating
libdruntime/object.d:2172: error: cannot cast expression aa of type int[string]
to inout(AA)
[Bug fortran/90068] Array Constructor Containing Function Call Leaks Memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90068 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-13 Blocks||86754 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.7 up to trunk (9.0). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86754 [Bug 86754] [meta-bug] Memory leaks at run time
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 --- Comment #1 from Iain Buclaw --- Maybe we should be setting TRANSPARENT_AGGR_P afterall, then fixing the internal signatures in rt.aaA to accept a void*.
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 --- Comment #2 from Rainer Orth --- Created attachment 46162 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46162&action=edit Working patch This patch not only compiles, but gives way better results. I need to analyze them in detail, but it seems that most of the remaining failures are either generic Solaris issues that also exist on Solaris/x86 or big-endian problems also seen, e.g., on S/390.
[Bug fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90072 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-13 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89890, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90069 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0). Related to/duplicate of pr89890. As for pr90069, pr90076 one memory leak is fixed by revision r263916.
[Bug fortran/90069] Polymorphic Return Type Memory Leak Without Intermediate Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90069 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-13 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0). Why is it not a duplicate of pr90072?
[Bug c++/90080] New: SFINAE failure with static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080
Bug ID: 90080
Summary: SFINAE failure with static_cast
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alex at grundis dot de
Target Milestone: ---
Using `std::enable_if` with a trait checking for `static_castable` fails hard
instead of SFINAE and usage of the alternative signature.
Code (https://godbolt.org/z/2uJc3P):
template
struct is_static_castable : std::false_type
{};
template
struct is_static_castable(std::declval()))> :
std::true_type
{};
template::value, int> = 0>
auto safePtrCast(From* from)
{
return static_cast(from);
}
template::value, int> = 0>
To* safePtrCast(From* from)
{
return dynamic_cast(from);
}
struct BarBase{ virtual ~BarBase() = default;};
struct Bar : virtual BarBase{};
void foo(){
BarBase* b;
Bar* b2 = safePtrCast(b);
}
Error:
source>: In instantiation of 'struct is_static_castable':
:17:55: required by substitution of 'template::value), int>::type
> To* safePtrCast(From*) [with To = Bar; From = BarBase; typename
std::enable_if<(! is_static_castable::value), int>::type
= ]'
:28:33: required from here
:8:42: error: cannot convert from pointer to base class 'BarBase' to
pointer to derived class 'Bar' because the base is virtual
struct is_static_castable(std::declval()))> :
std::true_type
This looks like a regression as a similar error is described here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44267
[Bug tree-optimization/90020] [7/8 regression] -O2 -Os x86-64 wrong code generated for GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90020 --- Comment #14 from Dominique d'Humieres --- The test gcc.dg/torture/pr90020.c fails on darwin: Undefined symbols for architecture x86_64: "_x", referenced from: _main in ccemobuO.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 --- Comment #6 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Apr 13 11:32:49 2019 New Revision: 270338 URL: https://gcc.gnu.org/viewcvs?rev=270338&root=gcc&view=rev Log: 2019-04-13 Dominique d'Humieres PR fortran/79842 * module.c (gfc_use_module): use complete sentences. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres --- Closing. It would be nice if someone commits tests covering the errors.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 79842, which changed state. Bug 79842 Summary: i18n: subword translation in "Can't use the same %smodule" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/90037] [9 Regression] -Wnull-dereference false positive after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- Right. This is a good example of where extracting the predicate analysis bits from tree-ssa-uninit.c would be useful elsewhere. The isolate-erroneous-paths bits don't help either because the dereference isn't in the same block as the PHI with the NULL argument (educated guess here) I'm a little surprised DOM jump threading didn't bb11->bb41 to bb31 though.
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Rainer Orth --- > This patch not only compiles, but gives way better results. I need to analyze > them in detail, but it seems that most of the remaining failures are either > generic Solaris issues that also exist on Solaris/x86 or big-endian problems > also seen, e.g., on S/390. When looking at 32-bit vs. 64-bit sparc differences, I found a couple of tests that FAIL due to two other instances of the same problem: _aaClear and _aaRange. Will look for fixes later.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #14 from H.J. Lu --- Since all AVX512BW processors also have AVX512DQ and AVX512VL, we shouldn't optimize a function with just AVX512BW, but without AVX512DQ and AVX512VL. We should add -misa=AVX512-subset to enable a subset of AVX512XX: 1. PTA_AVX512 = PTA_AVX512F | PTA_AVX512CD 2. PTA_AVX512SKYLAKE = PTA_AVX512 | PTA_AVX512VL | PTA_AVX512BW | PTA_AVX512DQ
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #46 from Jakub Jelinek --- Author: jakub Date: Sat Apr 13 15:20:46 2019 New Revision: 270339 URL: https://gcc.gnu.org/viewcvs?rev=270339&root=gcc&view=rev Log: PR target/89093 * config/arm/arm.c (arm_valid_target_attribute_rec): Use strcmp instead of strncmp when checking for thumb and arm. Formatting fixes. * gcc.target/arm/pr89093.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr89093.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug c++/65799] Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
Eric Fiselier changed:
What|Removed |Added
CC||eric at efcs dot ca
--- Comment #4 from Eric Fiselier ---
Hi Jonathan,
Can you re-open this bug? GCC still accepts a number of conversions from void
that it shouldn't.
// g++ -std=c++2a
float dummy = {};
static_assert((int*)(void*)&dummy);
https://godbolt.org/z/_DtmUc
[Bug d/88039] gdc.test/compilable/ddoc12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039 Iain Buclaw changed: What|Removed |Added CC||ibuclaw at gdcproject dot org --- Comment #9 from Iain Buclaw --- This should have been resolved in r266933, however I don't have the ability to close.
生']-|/^'
gcc-bugs@gcc.gnu.org +++ 【 可 】 【禾兑】 【 开 】 【 粟 】 手 1:22机：158-2040-8807 1:221:22 Q 1:22 Q: 154-639-631 黎情料娄昆土肃跋gcc-bugs
[Bug d/89177] unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177 Serge Belyshev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||belyshev at depni dot sinp.msu.ru Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #8 from Serge Belyshev --- Fixed in trunk.
[Bug d/88039] gdc.test/compilable/ddoc12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ibuclaw at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from ibuclaw at gcc dot gnu.org --- Fixed in r266933.
[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 --- Comment #1 from ibuclaw at gcc dot gnu.org --- Comment on attachment 46150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46150 Use __makecontext_v2 on Solaris/SPARC >+version (makecontextv2) >+pragma(mangle, "__makecontext_v2") void makecontext(ucontext_t*, void >function(), int, ...); >+else >+void makecontext(ucontext_t*, void function(), int, ...); I would use alias here instead of pragma(mangle). void __makecontext_v2(ucontext_t*, void function(), int, ...); alias makecontext = __makecontext_v2; Both do the same thing however...
[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- After others have been committed, can you post a new stacktrace for this?
[Bug d/90065] Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- What about using a union instead of type-punning here?
[Bug c/90081] New: stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081
Bug ID: 90081
Summary: stdint constant macros evaluating to wrong type
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bafap5 at yahoo dot com
Target Milestone: ---
stdint.h defines macros for expressing integer constant expressions in such a
way that they evaluate to given types. In the stdint.h spec:
"The macro INTN_C( value) shall expand to an integer constant expression
corresponding to the type int_least N _t. The macro UINTN_C( value) shall
expand to an integer constant expression corresponding to the type uint_least N
_t."
However, within the current version of stdint.h, I find the following:
/* Signed. */
# define INT8_C(c)c
# define INT16_C(c) c
# define INT32_C(c) c
# if __WORDSIZE == 64
# define INT64_C(c) c ## L
# else
# define INT64_C(c) c ## LL
# endif
/* Unsigned. */
# define UINT8_C(c) c
# define UINT16_C(c) c
# define UINT32_C(c) c ## U
# if __WORDSIZE == 64
# define UINT64_C(c) c ## UL
# else
# define UINT64_C(c) c ## ULL
# endif
Many of these macros aren't actually transforming the input at all, which leads
to some erroneous results at compile-time. This was first brought to my
attention in a situation similar to the following:
int32_t x = -5;
if (x < INT32_C(0x))
Upon compiling with -Wall -Wextra, the following warning is generated:
warning: comparison of integer expressions of different signedness: ‘int32_t’
{aka ‘int’} and ‘unsigned int’ [-Wsign-compare]
if (x < INT32_C(0x))
^
In this way, stdint.h violates the spec, as it is supposed to explicitly yield
a signed expression. I was able to work around this issue by using a cast, but
the macro is really what I'd rather be using.
Inspection of the actual macro definitions reveals the potential for further
errors, such as the following:
int x = (uint8_t) -5; /* Correct, gives 251 */
int y = UINT8_C(-5); /* Incorrect, gives -5 */
The suggested resolution is to adjust the macros to always cast to the
appropriate "_leastN_t" types as the spec requires. Even in cases where the
default type for an expression would be large enough for the given value (such
as int8_t being stored in an int), the spec nonetheless requires the
"_leastN_t" type, which becomes meaningful in the context of dereferencing
operations.
I don't know exactly how gcc is currently deciding on which type to use for a
given integer literal, so I don't want to post a suggestion that could
potentially cause problems... But as far as I can tell, putting explicit casts
in all of the macros should fix the problem.
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #2 from Rich Felker --- musl does not support sharing an include dir between archs (or 32-/64-bit "versions of the same target" in gcc multilib framing), so aside from policy of not using lib names like lib64, the multilib framework is just not suitable. We do support full multiarch with separate include and lib paths for each separate arch/ABI in the same filesystem, similar but not exactly the same as what Debian does (Debian shares top-level include just not sys and bits; for musl this may unofficially work but it's not officially supported and there's no reason to believe it's compatible with 3rd-party libs that may install arch-dependent headers generated at build time into that dir).
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- 7.20.4#2 The argument in any instance of these macros shall be an unsuffixed integer constant (as defined in 6.4.4.1) with a value that does not exceed the limits for the corresponding type.
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 --- Comment #2 from Guy Perfect --- The issue is not resolved based on the merits of the out-of-range values used in the earlier examples. Type resolution still fails in the current implementation, as demonstrated below: int x = sizeof ((int8_t) 5); /* Correct, gives 1 */ int y = sizeof (INT8_C(5)); /* Incorrect, gives 4 */ In this case, INT8_C is required to evaluate to type int_least8_t, which cannot be larger than the smallest integer type able to represent the range of the type int8_t: "The typedef name int_least N _t designates a signed integer type with a width of at least N, such that no signed integer type with lesser size has at least the specified width." int8_t can be represented exactly using 1 byte, as shown by the cast. For the sizeof test to give 4 on the macro demonstrates that the macro is implemented incorrectly. A cast is still strongly encouraged (if not necessary) in order for these macros to be compliant with the stdint.h specification.
[Bug c/90081] stdint constant macros evaluating to wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90081 Martin Sebor changed: What|Removed |Added URL||http://www.open-std.org/jtc ||1/sc22/wg14/www/docs/summar ||y.htm#dr_456 CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- UINT8_C(-5) isn't valid but expanding the macros to their arguments isn't conforming either. C11 DR #456 suggests compiler magic is necessary to make the macros correct: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_456 (Also see C99 DR 209: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_209.htm).
