Dave Korn, le Wed 21 Nov 2007 15:57:15 -, a écrit :
> On 21 November 2007 15:43, Samuel Thibault wrote:
>
> > Ok, so cygwin has it too. It's fixed in HEAD, see
> >
> http://www.nabble.com/-Bug-c-34130---New%3A-the-builtin-abs%28%29-gives-wrong-
> result-when-used-in-some-expression-tf4824981.h
On 21 November 2007 15:43, Samuel Thibault wrote:
> Ok, so cygwin has it too. It's fixed in HEAD, see
>
http://www.nabble.com/-Bug-c-34130---New%3A-the-builtin-abs%28%29-gives-wrong-
result-when-used-in-some-expression-tf4824981.html#a13808833
Now why didn't you just say "PR34130" in the first
Dave Korn, le Wed 21 Nov 2007 15:38:55 -, a écrit :
> On 21 November 2007 15:30, Samuel Thibault wrote:
>
> > Dave Korn, le Wed 21 Nov 2007 15:22:15 -, a écrit :
> >> On 21 November 2007 15:02, Samuel Thibault wrote:
> >>
> >>> Can someone test http://dept-info.labri.fr/~thibault/tmp/test
On 21 November 2007 15:30, Samuel Thibault wrote:
> Dave Korn, le Wed 21 Nov 2007 15:22:15 -, a écrit :
>> On 21 November 2007 15:02, Samuel Thibault wrote:
>>
>>> Can someone test http://dept-info.labri.fr/~thibault/tmp/test.c ?
>> Yep, the URL works fine.
>> Perhaps you'd like to expand
Dave Korn, le Wed 21 Nov 2007 15:22:15 -, a écrit :
> On 21 November 2007 15:02, Samuel Thibault wrote:
>
> > Can someone test http://dept-info.labri.fr/~thibault/tmp/test.c ?
> Yep, the URL works fine.
> Perhaps you'd like to expand on that request?
Yes: please run make test and ./test
On 21 November 2007 15:02, Samuel Thibault wrote:
> Can someone test http://dept-info.labri.fr/~thibault/tmp/test.c ?
/win/t/artimi/chips $ wget 'http://dept-info.labri.fr/~thi
bault/tmp/test.c'
--15:20:18-- http://dept-info.labri.fr/~thibault/tmp/test.c
=> `test.c'
Resolving dept-in
Dave Korn schrieb:
2) Also, the function call is through a
pointer-to-function-taking-stdargs, but the function itself is not a
stdargs function. Given the wrong calling conventions, this is liable
to lead to both caller *and* callee cleaning the args off the stack.
Calling conventions sh
Original Message
>From: Reini Urban
>Sent: 30 June 2005 18:42
>> 1) The function call is through a pointer-to-function-returning float,
>> but the function itself returns a void *. This is likely to screw up
>> the x87 FP stack when the caller pops a return value that the callee
>> didn
Dave Korn schrieb:
Original Message
From: Gerrit P. Haase
Sent: 30 June 2005 12:10
static int hack30_pray(ax, items, func)
int ax;
int items;
void *func;
{
return 0;
}
int main () {
int ax, items;
void * symref;
float num;
num = ((*((float (*)()) hack30_pray))(ax,items,symref));
Dave Korn wrote:
> > In any case, this should not ICE so you should file a gcc PR.
>
> But 3.3.x branch is closed now, and the bug is fixed in 3.4.x, so there's
> really very little point.
I did in fact skim the whole thread before replying but in my skimming I
thought that it was ICEing under
Original Message
>From: Brian Dessent
>Sent: 30 June 2005 17:12
> Reini Urban wrote:
>
>>num = ((*((float (*)()) hack30_pray))(ax,items,symref));
>
> I'm no language lawyer but this seems invalid. I seem to recall
> discussion on one of the gcc lists about trying to cast a function
Reini Urban wrote:
>num = ((*((float (*)()) hack30_pray))(ax,items,symref));
I'm no language lawyer but this seems invalid. I seem to recall
discussion on one of the gcc lists about trying to cast a function
pointer from one function signature to another, and how it was not
defined/supported
Original Message
>From: Gerrit P. Haase
>Sent: 30 June 2005 12:10
> Reini Urban wrote:
>> oops.
>>> static int hack30_pray(ax, items, func)
>>> int ax;
>>> int items;
>>> void *func;
>>> {
>>> return 0;
>>> }
>>> int main () {
>>> int ax, items;
>>> void * symref;
>>> float num;
Reini Urban wrote:
oops.
Not yet tested for other gcc versions,
but I know that it worked for previous perl/gcc versions.
Maybe just that previous perls didn't use -O3
$ gcc -v
[...]
gcc version 3.3.3 (cygwin special)
Reini Urban schrieb:
easy reproducible testcase:
cat > gccO3bug.c
stati
oops.
Not yet tested for other gcc versions,
but I know that it worked for previous perl/gcc versions.
Maybe just that previous perls didn't use -O3
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-
4 Jan 2003, Corinna Vinschen wrote:
> Date: Tue, 14 Jan 2003 10:05:46 +0100
> From: Corinna Vinschen <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: Cygwin <[EMAIL PROTECTED]>
> Subject: Re: GCC bug with strftime
>
> On Mon, Jan 13, 2003 at 07:00:07PM -0800, R
On Mon, Jan 13, 2003 at 07:00:07PM -0800, Richard Troy wrote:
> > > The problem is that this call fails to return an hour:
> > >
> > > strftime(IT,key,"%m/%d/%y %l:%M %p", brokentime);
I'm sorry to say that but...
> The answer is yes, I have checked. The code works in my various RedHat
> environm
Richard Troy writes:
>
> I recently discovered a bug in strftime(). I downloaded a very recent copy
> of cygwin and tried again, but it's still there. So, I'd like to report
> it. I sent mail to the gcc-bugs list but nobody there seems to care, so I
> thought I'd mention it here.
>
> The problem
> > of cygwin and tried again, but it's still there. So, I'd like to report
> > it. I sent mail to the gcc-bugs list but nobody there seems to care, so I
> > thought I'd mention it here.
> >
> > The problem is that this call fails to return an hour:
> >
> > strftime(IT,key,"%m/%d/%y %l:%M %p", br
> >I recently discovered a bug in strftime(). I downloaded a very recent copy
> >of cygwin and tried again, but it's still there. So, I'd like to report
> >it. I sent mail to the gcc-bugs list but nobody there seems to care,
>
> Why *would* anyone in gcc care about a library problem? I believe th
On Mon, Jan 13, 2003 at 05:46:20PM -0800, Richard Troy wrote:
>I recently discovered a bug in strftime(). I downloaded a very recent copy
>of cygwin and tried again, but it's still there. So, I'd like to report
>it. I sent mail to the gcc-bugs list but nobody there seems to care,
Why *would* anyon
Original Message-
> From: Alex Song [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, March 13, 2002 08:14
> To: Michael A Chase; [EMAIL PROTECTED]
> Subject: RE: gcc bug, cygwin specific cygwin-1.3.10-1 gcc-2.95.3-5
>
> hi,
>
> is end being a global variable specific
> From: Alex Song [mailto:[EMAIL PROTECTED]]
> is end being a global variable specific to the C language (which i doubt)
? to
> gcc ? to cygwin ? to windows ? or is it ALWAYS the case ?
It's not always the case. I was able to compile/run the test program on
Solaris, with three different compiler
ENGINEER
EDMI Product Development Division
[EMAIL PROTECTED]
Ph : +61 7 3881 6443
FAX : +61 7 3881 6420
> -Original Message-
> From: Michael A Chase [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 13 March 2002 3:58 PM
> To: Alex Song; [EMAIL PROTECTED]
> Subject: Re: gcc bug,
o.org/~esr/faqs/smart-questions.html
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.
- Original Message -
From: "Alex Song" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 12, 2002 19:19
Subject: RE: gcc
> >The global 'end' is a reserved word. It refers to the end of the data
> >area. That means you can't use it as a global variable in your program.
is this reserved word cygwin specific ? or is it a reserved word for all gcc ?
thanks for your help.
cheers,
alex
-
>>hi,
>>
>>i think i have found a bug, either that or i am very stupid. the bug is a
>>gcc bug and it is cygwin specific (cygwin-1.3.10-1 gcc-2.95.3-5) and the
>>following code causes a seg fault:
>>---
>>int end;
>>
>>int main ()
>>{
>> end = 1;
>>
>> ret
On Fri, Mar 08, 2002 at 05:03:26PM +1000, Alex Song wrote:
>hi,
>
>i think i have found a bug, either that or i am very stupid. the bug is a
>gcc bug and it is cygwin specific (cygwin-1.3.10-1 gcc-2.95.3-5) and the
>following code causes a seg fault:
>---
>i
28 matches
Mail list logo
