unreachable intrinsic
> after the asm statement)
> ”
>
> so it's the documented way to make it so, but apparently it does more
> than this and affects the fs-segmented store.
This is only about asm goto.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47
t allowed to change flow control.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
0 is just one instance of "undefined value".
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
On Aug 04 2021, Eli Zaretskii via Gcc-bugs wrote:
> I'd love to, but please tell me where. I couldn't find any
> information about reporting libiberty bugs, sorry if I missed
> something obvious.
The libiberty README says to report bugs to gcc-bugs@gcc.gnu.org.
Andreas.
"gil.hur at sf dot snu.ac.kr" writes:
> Since "hello" is not printed, I think the if-statement is the same as no-op.
> Thus, removing the if-statement should not change the behavior of the program
> according to ISO C11.
Unless you are invoking undefined behaviour.
"joel at gcc dot gnu.org" writes:
> Why cmp.w when it is tst.l?
Because it is smaller.
"M.F. Wu" writes:
> Source code:
>
> typedef unsigned long long float64;
>
> float64 syst_float64_div( float64 a, float64 b )
> {
> float64 z;
>
> *( (double *) &z ) = *( (double *) &a ) / *( (double *) &b );
Please read <http://
If INT_MAX > SIZE_MAX then (size_t)INT_MAX == SIZE_MAX, ie. this is the
minimum either way.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Tadahito Kobayashi writes:
> return 0xe+0x1 ;
0xe+0x1 forms a single preprocessing token (a pp-number), but cannot be
converted to a valid token. Add some whitespace around + to break up
the preprocessing token.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
Key fingerpr
the use of 'placement new' in weird syntax I didn't know
> before, or is this code wrong and accidentally accepted by gcc? In the
> former case, please correct me and sorry for the noise!
$ gcc -Wunused-value -c new.cc
new.cc: In function 'int main(int, char**)':
new.cc
"Mikoláš Janota" <[EMAIL PROTECTED]> writes:
> However, the following declarations
> void p(int p[30]);
> void p(int p[4]);
>
> do not yield a warning.
See 6.7.5.3#7.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldst
ess of A is used instead of the address of the newly
> allocated memory.
This is not a bug. The evaluation order of the operands is unspecified.
> When splitting the multiple assignment in two (see #ifdef WORK_AROUND),
> everything works fine.
It's not a workaround, it's the on
Anders Torger <[EMAIL PROTECTED]> writes:
> Perhaps GCC should not accept code that will result in undefined
> behaviour
This is impossible because there is nothing wrong when the code is never
executed.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Max
cc-3.4.3/gcc/Optimize-Options.html#index-fstrict_002daliasing-422
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Anders Torger <[EMAIL PROTECTED]> writes:
> unsigned long
> hash(void *key)
> {
> unsigned long long ull;
> ull = *(unsigned long long *)key;
> return ((unsigned long *)&ull)[0] ^ ((unsigned long *)&ull)[1];
Try -Wstrict-aliasing.
Andreas.
--
A
15 matches
Mail list logo
