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
Can someone test http://dept-info.labri.fr/~thibault/tmp/test.c ?
Samuel
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
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-
--- Danny Smith <[EMAIL PROTECTED]> wrote: > Jon Foster wrote:
>
> > Given this source code:
> > extern const int meaning_of_life __declspec(dllexport);
> > const int meaning_of_life __declspec(dllexport) = 42;
> >
> >
> > GCC complains:
> > $ c++ -g -O2 -c test.cxx -o test.o
> > test.cxx:2:
Jon Foster wrote:
> Given this source code:
> extern const int meaning_of_life __declspec(dllexport);
> const int meaning_of_life __declspec(dllexport) = 42;
>
>
> GCC complains:
> $ c++ -g -O2 -c test.cxx -o test.o
> test.cxx:2: error: external linkage required for symbol 'const int
>mean
of DLLs? If so, the error message
is a little confusing. If not, then this is a GCC bug.
Removing the explicit "extern" line has no effect in either
case.
My Cygwin installation was updated recently - I'm using the
standard Cygwin GCC 3.3.1-3 package:
$ c++ --version
c++ (GCC) 3.3.
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
Hi All,
It's been about eight months since I last posted to this list - hope
everyone is doing well...
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 nobod
On Sun, 2002-10-20 at 00:57, Rolf Campbell wrote:
> Doesn't this mean that gcc is not a true ANSI compiler? Shouldn't that
> variable be "__end" or something to conform with ANSI rules?
AFAIK that is actually a ld issue - note that it is only global scope
'end' that collides, and that the end add
To: [EMAIL PROTECTED]
> Subject: Re: 1.3.12: gcc bug: variable named "end"
>
>
>
> As it has been since time immemorial in compilers with a Unix
> lineage or
> patterned after compilers of that lineage. Clearly GCC is
> such a compiler.
>
> The li
CYGWIN_NT-5.1 X22CHIKAYAMA 1.3.12(0.54/3/2) 2002-07-06 02:16 i686
unknown
gcc 2.95.3-5
The following program causes a segmentation fault.
---
int end;
main() { end = 0; }
---
Seems that the problem is with the variable name "end".
In the object code tries to store in some invalid address.
Variable
As it has been since time immemorial in compilers with a Unix lineage or
patterned after compilers of that lineage. Clearly GCC is such a compiler.
The linker binds the symbol "end" to the first unused address in the linked
program. Some linkers also define "etext" and "edata" to indicate the e
ee it */
int end;
/* do what you please with end */
int end = 0;
}
Elfyn
- Original Message -
From: Takashi Chikayama <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: 'ICPC02' <[EMAIL PROTECTED]>
Sent: Saturday, October 19, 2002 6:16 AM
Subject: 1.3
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:
>>---
>>
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 cau
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;
return 0
39 matches
Mail list logo
