--- Comment #3 from vincent at vinc17 dot org 2006-04-11 15:16 ---
(In reply to comment #2)
> which is incorrect since the input domain is not symmetric wrt 0.
I disagree. Could you give an explicit example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
--- Comment #5 from vincent at vinc17 dot org 2006-04-11 15:46 ---
(In reply to comment #4)
> I mean the middle-end probably does some "interesting" foldings of
> -2147483647L
> - 1L as the result -08000 has the overflow flag set.
The bug also occurs with: (
--- Comment #6 from vincent at vinc17 dot org 2006-04-11 15:50 ---
BTW, concerning the overflow flag, I think it comes from the sign cancellation:
the long constant -2147483648 is replaced its opposite, but the opposite is not
representable in a long, hence the overflow.
--
http
--- Comment #5 from vincent at vinc17 dot org 2006-05-22 01:08 ---
IMHO, -frounding-math should be the default, unless -ffast-math is given.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
--- Comment #17 from vincent at vinc17 dot org 2006-06-08 07:18 ---
The patch looks strange to me too: is there any reason why the optimization
would be correct under wrapping? i.e. I don't understand why -fwrapv can "fix"
the problem (as said in comment #1).
--
htt
--- Comment #125 from vincent at vinc17 dot org 2008-11-11 10:13 ---
(In reply to comment #124)
> It seems like the C99 standard prohibits double rounding,
only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754,
it also contains specific bindings). IEEE
--- Comment #8 from vincent at vinc17 dot org 2009-05-18 14:56 ---
Are you sure that this comes from the extended precision? This would mean that
GCC does implicit extended -> double conversions in an asymmetric way, and
IIRC, I've never seen that.
I can't reproduce the p
nent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
--- Comment #2 from vincent at vinc17 dot org 2009-06-15 02:08 ---
This may be true for standard headers, but system directories don't contain
only standard headers: in practice, they generally also contain additional
libraries. And for instance, a -I/usr/include can be usef
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
> If you have modified the implementation (by putting headers/libraries in
> standard directories where those headers/libraries were not provided by
> the implementation in those ve
--- Comment #131 from vincent at vinc17 dot org 2009-07-22 17:33 ---
(In reply to comment #130)
> #define axiom_order(a,b) !(a < b && b < a)
> #define axiom_eq(a) a == a
> #define third ((double)atoi("1")/atoi("3"))
[...]
y: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960
--- Comment #2 from vincent at vinc17 dot org 2009-08-04 13:29 ---
There would the possibility to have a POSIX mode implied by c99, but I don't
think having different behaviors would be a good idea. IMHO, Makefiles should
be fixed to stick to POSIX.
Also, portable Makefiles, i.e.
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
--- Comment #3 from vincent at vinc17 dot org 2006-10-10 13:53 ---
(In reply to comment #2)
> What's worrying me a bit is the versioning of MPFR.
Note that GMP is similar.
> Vincent, would it be possible that some version number is increased every
> time a patch is poste
ority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
--- Comment #2 from vincent at vinc17 dot org 2007-03-15 16:51 ---
(In reply to comment #1)
> I don't think this is a bug, you need to read the other part of the document
> which says if you supply -I DEFAULT_DIR, it is ignored.
OK, but this isn't very clear, as the d
--- Comment #9 from vincent at vinc17 dot org 2008-08-18 22:58 ---
(In reply to comment #8)
> Please provide a preprocessed reduced testcase as similar to the original as
> possible.
Here's a similar testcase.
$ cat tst.c
void *foo (void);
void bar (void *);
void f (vo
--- Comment #11 from vincent at vinc17 dot org 2008-08-19 01:31 ---
(In reply to comment #10)
> If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
> really sounds strange. Are you sure about that?
Yes and here Debian's GCC 4.4 snapshot has the same
--- Comment #3 from vincent at vinc17 dot org 2008-08-23 20:00 ---
(In reply to comment #2)
> this warning was added on purpose, because probably someone requested it. I
> don't see that it is very different from the documented case of using the
> address of a function in
--- Comment #8 from vincent at vinc17 dot org 2008-09-06 18:42 ---
(In reply to comment #7)
> Does increasing bits cause floating point errors. How could 64 bit precison
> give correct result where as 80 bit give incorrect one.
You can have rounding errors whether you increa
--- Comment #11 from vincent at vinc17 dot org 2008-09-06 22:19 ---
(In reply to comment #10)
> The funny thing is that this only happens with -O2 or -O1 but not with -O0 ie
> no optimization it is all correct , when we optimize the results start
> varying.
Because with
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37838
--- Comment #9 from vincent at vinc17 dot org 2008-10-15 21:29 ---
What was said in bug 37838 but not here is that -frounding-math sometimes fixes
the problem. So, I was suggesting that -frounding-math should be enabled by
default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from vincent at vinc17 dot org 2008-10-15 22:33 ---
(In reply to comment #10)
> The default of -fno-rounding-math is chosen with the reason that this is what
> a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.
The C standard doesn't require
4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37846
--- Comment #3 from vincent at vinc17 dot org 2008-10-16 13:54 ---
(In reply to comment #1)
> Confirmed. The FP_CONTRACT macro is not implemented, but the default behavior
> of GCC is to behave like it was set to OFF.
The problem is that on PowerPC, x*y+z is fused (contract
--- Comment #14 from vincent at vinc17 dot org 2008-10-16 14:20 ---
(In reply to comment #12)
> Turning -frounding-math on by default would be a disservice to (most of) our
> users which is why the decision was made (long ago) to not enable this by
> default.
The compil
--- Comment #16 from vincent at vinc17 dot org 2008-10-16 17:39 ---
I was suggesting to improve the behavior by having -frounding-math by default
(at least when the user compiles with -std=c99 -- if he does this, then this
means that he shows some interest in a conforming implementation
: (unsigned int) exp
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39867
--- Comment #1 from vincent at vinc17 dot org 2009-04-23 13:44 ---
I forgot to say: the bug occurs whether one compiles with optimizations or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39867
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
--- Comment #12 from Vincent Lefèvre 2011-02-08
03:42:08 UTC ---
(In reply to comment #11)
> Any updates on this? re-confirmation? I would like to continue testing
> gcc-4.5.x on powerpc-darwin8, but can't b/c of this.
The --with-dwarf2 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #5 from Vincent Lefèvre 2011-03-01
15:05:19 UTC ---
Under Debian, I can no longer reproduce the problem with GCC 4.5.2:
$ gcc-4.5 -Wall warn-nulladdress.c
$ gcc-4.5 -Waddress warn-nulladdress.c
$ gcc-4.4 -Wall warn-nulladdress.c
warn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #7 from Vincent Lefèvre 2011-03-02
01:15:23 UTC ---
(In reply to comment #6)
> I think the intention is to warn, at least for a == (void *)0, since the
> address of a cannot be zero or null. So I would say that this is a regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #9 from Vincent Lefèvre 2011-03-02
15:17:33 UTC ---
(In reply to comment #8)
> Every warning warns about something valid in C, otherwise it would be an error
> not a warning.
No, for instance:
int main(void)
{
int i;
return i;
}
--- Comment #4 from vincent at vinc17 dot org 2007-05-22 22:50 ---
(In reply to comment #3)
> My recollection is that the special -I behavior is there because
> the system headers have special non-warning properties.
> This situation doesn't apply to -L.
But this
--- Comment #11 from vincent at vinc17 dot org 2010-02-19 13:08 ---
(In reply to comment #10)
> This issue was discussed on the WG14 reflector in October 2008, and the
> general
> view was that the standard should not make INT_MIN % -1 well defined (as this
> would impose a
-
0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http
--- Comment #1 from vincent at vinc17 dot org 2010-03-18 14:33 ---
If I understand correctly, the bug appears with:
r119248 | rguenth | 2006-11-27 12:38:42 +0100 (Mon, 27 Nov 2006) | 10 lines
2006-11-27 Richard Guenther
PR middle-end/25620
* builtins.c
--- Comment #18 from vincent at vinc17 dot org 2010-03-18 14:37 ---
The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is
incorrect. See PR 43419.
--
vincent at vinc17 dot org changed:
What|Removed |Added
--- Comment #7 from vincent at vinc17 dot org 2010-04-07 09:29 ---
This bug is still open, though it appears to be fixed. Is there any reason?
--
vincent at vinc17 dot org changed:
What|Removed |Added
--
Summary: Incorrect warning: use of 'D' length modifier with 'a'
type character
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo:
--- Comment #5 from vincent at vinc17 dot org 2010-04-07 10:58 ---
This bug should probably be resolved as fixed as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
--- Comment #7 from vincent at vinc17 dot org 2009-11-23 04:51 ---
(In reply to comment #6)
> Not a GCC bug, the POSIX list generally agreed the effects of reordering
> system directories should be unspecified or undefined.
What the POSIX list says does not matter if this does
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
--- Comment #4 from vincent at vinc17 dot org 2009-11-26 15:53 ---
(In reply to comment #1)
> Aliasing rules are indeed broken because you access a union of anonymous type
> through a pointer to a union of type ieee_double_extract.
OK, the real code in MPFR is a "doubl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent at vinc17 dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Summary: incorrect precision of sqrtf builtin for x87
arithmetic (-mfpmath=387)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #2 from Vincent Lefèvre 2010-10-20
01:51:56 UTC ---
Created attachment 22089
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22089
sh script to test sqrtf
Similar problems can also be found with:
printf ("%.60f\n%.60f\n%.60f\n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #7 from Vincent Lefèvre 2010-10-20
23:43:33 UTC ---
But there's something strange in the generated code: sometimes the fsqrt
instruction is used, sometimes "call sqrtf" is used (for the same sqrtf() call
in the C source). This is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180
Vincent Lefèvre changed:
What|Removed |Added
CC||vincent at vinc17 dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
--- Comment #19 from Vincent Lefèvre 2010-12-12
23:02:58 UTC ---
FYI, the problem has been handled in the MPFR trunk r7291 for MPFR 3.1.0.
MPFR's configure script now retrieves the location of the GMP source from GMP's
Makefile and adds the neces
ion: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
--- Comment #3 from vincent at vinc17 dot org 2008-04-24 15:04 ---
Is there any reason why this hasn't been fixed yet? (The trunk still has the
error. And I'm asking this because there's only one word to change.)
--
vincent at vinc17 dot org changed:
W
--- Comment #2 from vincent at vinc17 dot org 2008-05-22 08:34 ---
The severity should probably be changed to enhancement because gcc behaves as
documented (well, almost).
What can be done IMHO is:
1. Split the -Wuninitialized into two different warnings: one for which gcc
knows that
n a is an array
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #4 from vincent at vinc17 dot org 2008-05-22 11:01 ---
(In reply to comment #3)
> A way to tell gcc a variable is not uninitialized is to perform
> self-initialization like
>
> int i = i;
This doesn't seem to be valid C code.
> this will cause no
--- Comment #5 from vincent at vinc17 dot org 2008-05-22 11:23 ---
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback
--- Comment #7 from vincent at vinc17 dot org 2008-05-28 08:18 ---
(In reply to comment #6)
> (In reply to comment #5)
> > BTW, the i = i trick
>
> it only works in the initializer and not as a statement after the fact.
But in such a case, as i is not initialized y
/ x86_64
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
--- Comment #2 from vincent at vinc17 dot org 2008-06-10 09:09 ---
(In reply to comment #1)
> You should try out 4.3.1.
As I said, I could reproduce the problem with this version too (but there's a
bug in gmp.h, so I was not sure).
--
vincent at vinc17 dot org
--- Comment #4 from vincent at vinc17 dot org 2008-06-10 11:26 ---
cmpb$42, -481(%rbp)
je .L458
jmp .L456
.L463:
cmpb$85, -481(%rbp)
je .L461
cmpb$90, -481(%rbp)
je .L462
jmp .L456
.L458
--- Comment #6 from vincent at vinc17 dot org 2008-06-10 12:37 ---
OK, but shouldn't g++ generate a SIGABRT instead of a illegal instruction? I've
never had thought that a compiler should generate an illegal instruction on
purpose, so making me think that the problem come
--- Comment #8 from vincent at vinc17 dot org 2008-06-10 14:02 ---
I agree about SIGSEGV. But what about abort()? Wouldn't this be cleaner? This
builtin trap is quite similar to a failed assertion (often used to avoid
undefined behavior), isn't it?
--
http://gcc.gnu.or
--- Comment #10 from vincent at vinc17 dot org 2008-06-10 14:52 ---
(In reply to comment #9)
> Calling abort() doesn't work with free-standing environments.
OK, but how about using an illegal instruction with free-standing environments
and abort() with hosted ones? After all, t
--- Comment #11 from vincent at vinc17 dot org 2008-06-10 15:21 ---
Here's the testcase (I've never used va_list and so on myself, so I hope it is
correct; at least it shows the missing warning problem). With gcc -Wall
-std=c99 -Wc++-compat -pedantic -Wextra, I don't
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
--- Comment #1 from vincent at vinc17 dot org 2008-06-19 14:37 ---
To make things clear, perhaps I should have added:
#if __STDC__ == 1 && __STDC_VERSION__ >= 199901 && defined(__STDC_IEC_559__)
#pragma STDC FP_CONTRACT OFF
printf ("__STDC_IEC_559__ de
--- Comment #111 from vincent at vinc17 dot org 2008-06-20 16:09 ---
(In reply to comment #109)
> WHERE'S THE BUG
> This is really not a GCC bug. The bug is actually in the x87 FPU because it
> doesn't obey the IEEE standard.
Concerning the standards: The x87 FPU do
y -
over the binary * and /
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36588
--- Comment #113 from vincent at vinc17 dot org 2008-06-22 00:52 ---
(In reply to comment #112)
> It's true that double *precision* is available on x87. But not the *IEEE-754
> "double precision" type*.
It is available when storing a result to memory.
>
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 ---
(In reply to comment #114)
> Yes, but this requires quite a complicated workaround (solution (4) in my
> comment #109).
The problem is on the compiler side, which could store every result of a cast
or an assignm
--- Comment #118 from vincent at vinc17 dot org 2008-06-24 20:45 ---
(In reply to comment #117)
> By a lucky hit, I have found this in the GCC documentation:
> "
> -mpc32
> -mpc64
> -mpc80
OK, this is new in gcc 4.3. I haven't tried, but if gcc just chan
Version: 4.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36731
--- Comment #3 from vincent at vinc17 dot org 2008-07-04 19:34 ---
(In reply to comment #1)
> Works if you provide an (empty) input file:
[...]
There's mtune, but not march. Also, most users probably don't know that.
(In reply to comment #2)
> They do already via the c
--- Comment #120 from vincent at vinc17 dot org 2008-07-17 12:41 ---
(In reply to comment #119)
> REAL RESULT:
> 5.313991e+33
> 5.313991e+33
> 0.00e+00
> 0.00e+00
Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a h
--- Comment #5 from vincent at vinc17 dot org 2006-02-14 17:03 ---
(In reply to comment #4)
> Note however, that the true accurate value for d, calculated at infinite
> precision, is 1-(2^-16). So, the absolute error for gcj is 1+(2^-16) and the
> absolute error with correct
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 16:42
---
Even without , the function could be in a library called in a directed
rounding mode.
And one can change the rounding mode via a standard function in the glibc, no
need for a pragma.
--
http://gcc.gnu.org
--
What|Removed |Added
CC||vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 16:49
---
I think that this is just bug 323 (which is a real bug, not invalid). Version
3.4 added other regressions related to this bug (e.g. when one has function
calls), and this is not specific to the negate operation
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 17:08
---
Oops, forget my comment. There is a bug, but 5.1.2.3#13 / 6.3.1.5#2 / 6.3.1.8#2
is not related to it if gcc does reduce the precision (due to the "volatile",
that in fact prevents bug 323 from occu
--- Additional Comments From vincent at vinc17 dot org 2004-11-29 15:35
---
In Comment 5, I wrote:
> The real problem is that intermediate results in extended precision are not
converted back to double after a cast or an assignment; this is required by the
C standard, whet
--- Additional Comments From vincent at vinc17 dot org 2004-12-08 15:13
---
I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is
still needed for C compliance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
path
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
GCC host
--- Comment #2 from vincent at vinc17 dot org 2006-10-25 14:00 ---
(In reply to comment #1)
> So this sounds like a bug in your installation.
This cannot be with my installation in particular as the bug occurred on
various Linux machines (only one is mine). However it could be due
--- Comment #18 from vincent at vinc17 dot org 2006-10-28 09:07 ---
(In reply to comment #17)
> Yes, I can reproduce the NaN. In fact, any negative value
> gives a NaN.
Not any negative value, but in lngamma.c:
/* if x < 0 and -2k-1 <= x <= -2k, then lngamma(x) = N
--- Comment #20 from vincent at vinc17 dot org 2006-10-28 14:05 ---
(In reply to comment #19)
> The documenation in MPFR says:
> -- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
> Set ROP to the value of the Gamma function on OP, and its
>
--- Comment #22 from vincent at vinc17 dot org 2006-10-28 16:58 ---
(In reply to comment #21)
> Since you mentioned C functions missing in MPFR, what are your plans for the
> Bessel functions? I'd like to hook up builtins j0/j1/jn/y0/y1/yn. Thanks.
They're in the TOD
--- Comment #26 from vincent at vinc17 dot org 2006-10-31 09:54 ---
(In reply to comment #25)
> As I think about it more, I'm leaning toward having a new function
> mpfr_lgamma.
> This is because if we want this mpfr function to mimic the behavior of
> lgamm
--- Comment #28 from vincent at vinc17 dot org 2006-10-31 22:15 ---
(In reply to comment #27)
> It's likely that I'll end up doing it, so would you please tell me how?
According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
[iff] x < 0 &am
--- Comment #31 from vincent at vinc17 dot org 2006-11-02 15:57 ---
(In reply to comment #30)
So, I don't think a mpfr_signgam alone would really be useful. So, I think that
choice 2 would be better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
--- Comment #33 from vincent at vinc17 dot org 2006-11-05 23:27 ---
(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #30)
> > So, I don't think a mpfr_signgam alone would really be useful. So, I think
> > that
> > cho
--- Comment #1 from vincent at vinc17 dot org 2007-01-16 22:03 ---
Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get:
-2147483648 % -1 -> -2147483648
Ditto with:
#include
#include
int main (void)
{
volatile int i = INT_MIN, j = -1;
printf ("%d\n
--- Comment #2 from vincent at vinc17 dot org 2007-01-16 22:10 ---
-2147483648, this was on a G5, with gcc 4.0.1 under Mac OS X. On a G4 under
Linux, with gcc 4.1.2 prerelease (Debian), I get 2147483647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
95 matches
Mail list logo
