> Alex are you still workin' for a patch?
Yes, I am. But as I write before I am not familiar with this particular
part of GCC at all, so I cannot give any estimates and even promize to
produce a working patch. If some other more knowledgeable person
is feeling like beating me to it, please feel f
D]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: gcc -O broken in CURRENT
>
>
> > Do you have a patch for this ?
> I do not fully understand the parts of GCC involved, so I need some
> time to verify my initial diagn
"Brian T.Schellenberger" wrote:
> Well, the linux-netscape 4 is the only browser I know that can handle Java
> pages on FreeBSD.
>
> Are there others?
>
> If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run
> *that*.
4.7 does this just fine, if you don't move the mouse
, 2002 10:41 PM
> To: Kenneth Culver; Matthew D. Fuller
> Cc: Terry Lambert; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: gcc -O broken in CURRENT
>
>
> On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
> | > (ttypa):{1078}% file
&g
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
| > demand paged dynamically linked executable
| >
| > Now, if you'd like to talk Netscape in
On Sat, 16 Mar 2002, Greg Black wrote:
> [Cc's trimmed]
>
> Kenneth Culver wrote:
>
> | > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
> | > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
> | > demand paged dynamically linked executable
> | >
>
> That's odd, I've never had any mozilla problems. All I know is that it
> doesn't crash on sites that Netscape crashes on (anything java) and for
> me it runs much faster than netscape. It loads slower, but renders pages
> much faster, and I tend to load my browser once per day, and just leave
>
> It's less slow and much more reliable than mozilla and remains the only
> available browser that can access most of the sites I need to access.
That's odd, I've never had any mozilla problems. All I know is that it
doesn't crash on sites that Netscape crashes on (anything java) and for me
it ru
> #include , see the thread we had on this a few weeks back on
> -chat.
>
OK, I'll look, but I disagree... Mozilla runs flawlessly for me, and
renders much faster than netscape, however it loads really slow. Opera
runs nicely too, although it's linux only.
Ken
To Unsubscribe: send mail to [EMAI
[Cc's trimmed]
Kenneth Culver wrote:
| > (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| > /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
| > demand paged dynamically linked executable
| >
| > Now, if you'd like to talk Netscape into building a ver
On Fri, Mar 15, 2002 at 08:53:16PM -0500 I heard the voice of
Kenneth Culver, and lo! it spake thus:
>
> I didn't realize anyone still used netscape 4.x. It's so disgustingly
> unstable and slow.
That it is. The problem, of course, is that all the alternatives are
more unstable and slowER.
#inc
> (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
> /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
> demand paged dynamically linked executable
>
> Now, if you'd like to talk Netscape into building a version intended for
> a version of FreeBSD newer th
[ Trim the CC's a bit ]
On Fri, Mar 15, 2002 at 04:00:08PM -0800 I heard the voice of
Terry Lambert, and lo! it spake thus:
> Kenneth Culver wrote:
> > > Other reasons I haven't even thought of yet 8-).
> >
> > Yeah, I was just wondering if there were issues making us keep a.out stuff
> > in
Kenneth Culver wrote:
> > Other reasons I haven't even thought of yet 8-).
>
> Yeah, I was just wondering if there were issues making us keep a.out stuff
> in FreeBSD aside from the "I wanna run 2.2.x programs" issue.
Linking with third party a.out libraries.
Other reasons I haven't even tho
> > At the risk of being yelled at, I have a question: Why do we still need to
> > support a.out? I know that a lot of people MIGHT still have some a.out
> > binaries lying around, but FreeBSD's default binary format has been ELF
> > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that
> We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is
> zero reason for subjecting users to this ABI change for what would be
> gained.
>
> If you want to do something productive, submit patches that Bmake GCC 3.1
> (which move us to Dwarf2 unwinding as a product).
>
Oh ok, that'
Kenneth Culver wrote:
> At the risk of being yelled at, I have a question: Why do we still need to
> support a.out? I know that a lot of people MIGHT still have some a.out
> binaries lying around, but FreeBSD's default binary format has been ELF
> for 3 or 4 years (Since 3.0-3.1 I believe). I'm no
On Fri, Mar 15, 2002 at 05:26:37PM -0500, Kenneth Culver wrote:
> > > At the risk of being yelled at, I have a question: Why do we still need to
> > > support a.out? I know that a lot of people MIGHT still have some a.out
...
> > Rather than offer $0.02, send the patch.
>
> Well, I was just asking
> > At the risk of being yelled at, I have a question: Why do we still need to
> > support a.out? I know that a lot of people MIGHT still have some a.out
> > binaries lying around, but FreeBSD's default binary format has been ELF
> > for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that
On Fri, Mar 15, 2002 at 04:54:59PM -0500, Kenneth Culver wrote:
>
> At the risk of being yelled at, I have a question: Why do we still need to
> support a.out? I know that a lot of people MIGHT still have some a.out
> binaries lying around, but FreeBSD's default binary format has been ELF
> for 3
> I guess it's possible to change over entirely. That would
> mean we would loase a.out support because the GNU tools are
> becoming incapable of supporting a.out ("all machines we
> run on are Linux machines" syndrome).
>
> If we really wanted to avoid problems like this in the future,
> we'd ju
On Fri, Mar 15, 2002 at 01:37:39PM +0100, Jan Stocker wrote:
> A little bit... most of you argumenting about binary incompatibility
> for -stable. OK... no chance to do it there, its my opinion too. But why not
> doing it for current and using that most common dwarf unwinding now (for a
There is
Jan Stocker wrote:
[ ... DWARF vs. setjmp/longjmp ... ]
> A little bit... most of you argumenting about binary incompatibility
> for -stable. OK... no chance to do it there, its my opinion too. But why not
> doing it for current and using that most common dwarf unwinding now (for a
> later ia64
h 14, 2002 7:16 PM
> To: Jan Stocker
> Cc: Alexander Kabaev; Martin Blapp; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: gcc -O broken in CURRENT
>
>
> On Thu, Mar 14, 20
On Thu, 14 Mar 2002, ozan s. yigit wrote:
> > Add the -ffloat-store flag to your compilation flags (or
> > add -msoft-float).
>
> that really means for this compiler on certain platforms, you
> can have slow and correct or fast and incorrect, but NOT fast
> and correct.
I think fast and correct
Jan Stocker wrote:
> So now i am a little bit confused... State of the art:
>
> 1) Bug is in -stable and -current
>--> This means possible patches only in -current arent responsible for
>this behaviour
Unless they were MFC'ed to -STABLE. THis is why you generally
should compare -REL
> If you really want to investigate FreeBSD FP/math capabilities
> search for UCBTEST or visit
> www.cs.berkeley.edu/~jhauser/arithmetic/TestFloat.html
cool! thanks for the pointer.
oz
---
gag reflex is an essential part of computing. -- anon
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
On Thu, Mar 14, 2002 at 07:50:38PM +0100, Raymond Wiker wrote:
> ozan s. yigit writes:
> > > Add the -ffloat-store flag to your compilation flags (or
> > > add -msoft-float).
> >
> > that really means for this compiler on certain platforms, you
> > can have slow and correct or fast and incor
On Wed, Mar 13, 2002 at 10:24:20PM +0100, Martin Blapp wrote:
> > We are using a set of patches that were part of gcc 2.95.3_test3.
> > Do you have a sample program in which exceptions are still broken on
> > FreeBSD 4.5?
>
> cd /usr/ports/devel/stlport
> make install
> cd work/STL*/test/eh
>
>
ozan s. yigit writes:
> > Add the -ffloat-store flag to your compilation flags (or
> > add -msoft-float).
>
> that really means for this compiler on certain platforms, you
> can have slow and correct or fast and incorrect, but NOT fast
> and correct.
Actually, if -ffloat-store is t
> Add the -ffloat-store flag to your compilation flags (or
> add -msoft-float).
that really means for this compiler on certain platforms, you
can have slow and correct or fast and incorrect, but NOT fast
and correct.
oz
---
freedom has a mental cost. -- peter roosen-runge
To Unsubscribe: send
On Thu, Mar 14, 2002 at 01:20:51PM -0500, Alexander Kabaev wrote:
> >b) other options were set at compile time
> > --> Why dont change to the same in the port?
> > Leads it to a broken world?
> > If the only difference is the lost of binary compatibility,
> >
On Thu, Mar 14, 2002 at 12:59:31PM -0500, ozan s. yigit wrote:
> in a related tangential note, i recently found (out of sheer irritation)
> in less than an hour that several (including the latest) versions of GCC
> -O and -O2 failed the paranoia test in different ways, to wit:
>
> gcc -o paranoi
> 2) Bug is in os delivered gcc but not in port gcc.
>a) port has more or less patches / os gcc has been modified
> --> Didn't someone told they are the same?
GCC from ports uses DWARF2 exception unwinding while GCC in src tree
uses sjlj exceptions. The exception handling code generated
On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote:
> 2) Bug is in os delivered gcc but not in port gcc.
>a) port has more or less patches / os gcc has been modified
> --> Didn't someone told they are the same?
Port has less patches. If you look at
/usr/src/contrib/gcc/contrib
in a related tangential note, i recently found (out of sheer irritation)
in less than an hour that several (including the latest) versions of GCC
-O and -O2 failed the paranoia test in different ways, to wit:
gcc -o paranoia paranoia.c
[paranoia output elided]
The number of DEFECTs discovere
Do you have a small, reproducible test case?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
[EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: gcc -O broken in CURRENT
>
>
> > Do you have a patch for this ?
> I do not fully understand the parts of GCC involved
> Do you have a patch for this ?
I do not fully understand the parts of GCC involved, so I need some
time to verify my initial diagnosis and to create a patch. In other
words - not yet :)
--
Alexander Kabaev
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > In message: <[EMAIL PROTECTED]>
: > Ed Hall <[EMAIL PROTECTED]> writes:
: > : Exception-handling is broken with -O in -stable, and has been for years.
: > : FreeBSD is on
Hi,
> This is a case of exception context register getting clobbered in
> shared library function call. GCC does not reload it when needed and
> this ultimately leads to semi-random word in program memory decremented
> by the __cp_pop_exception function. The bug is only triggered under very
> s
This is a case of exception context register getting clobbered in
shared library function call. GCC does not reload it when needed and
this ultimately leads to semi-random word in program memory decremented
by the __cp_pop_exception function. The bug is only triggered under very
specific circums
This is a case of exception context register getting clobbered in
shared library function call. GCC does not reload it when needed and
this ultimately leads to semi-random word in program memory decremented
by the __cp_pop_exception function. The bug is only triggered under very
specific circums
> Per thread exception stacks? THat's where I'd look...
Hmm, good point. The programms that crashed were all threaded ...
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Ed Hall <[EMAIL PROTECTED]> writes:
> : Exception-handling is broken with -O in -stable, and has been for years.
> : FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
> : to implement exceptions, so when
In message: <[EMAIL PROTECTED]>
Ed Hall <[EMAIL PROTECTED]> writes:
: Exception-handling is broken with -O in -stable, and has been for years.
: FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
: to implement exceptions, so when the GCC folks broke that path, it
I wrote:
: This problem should exist in -current since I think FreeBSD finally drops
^^
That should be "shouldn't". I shouldn't post in a hurry (like I'm doing
now).
-Ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in th
On Wed, Mar 13, 2002 at 11:49:52PM +0100, Martin Blapp wrote:
>
>
> Kris,
>
> > fixes things, or at least identify a list of possible changes which
> > others can test.
>
> How can I compile gcc without doing a "make world" ?
cd /usr/src/gnu/usr.bin/cc && make all
Kris
msg32812/pgp0.p
cd /usr/src/gnu/usr.bin/cc
make
make install
On Wed, 13 Mar 2002, Martin Blapp wrote:
>
>
> Kris,
>
> > fixes things, or at least identify a list of possible changes which
> > others can test.
>
> How can I compile gcc without doing a "make world" ?
>
> Martin
>
>
> To Unsubscribe: send mail
Kris,
> fixes things, or at least identify a list of possible changes which
> others can test.
How can I compile gcc without doing a "make world" ?
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Wed, Mar 13, 2002 at 11:42:46PM +0100, Martin Blapp wrote:
>
> Hi Kris,
>
> > Did you pursue my suggestion of comparing recent patches in the port
> > and in the source tree?
>
> Easy to say, hard to do. STABLE is broken as current is, and it seems that
> 4.4 and 4.3 are also broken for the
Hi Kris,
> Did you pursue my suggestion of comparing recent patches in the port
> and in the source tree?
Easy to say, hard to do. STABLE is broken as current is, and it seems that
4.4 and 4.3 are also broken for the STLport test.
This is a very difficult thing to do for someone that does not
On Wed, Mar 13, 2002 at 02:08:55PM +0100, Martin Blapp wrote:
>
> I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define
> DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded.
>
> All cpp* files are the same in the port and our system compilers.
>
> And ideas and pointers w
> We are using a set of patches that were part of gcc 2.95.3_test3.
> Do you have a sample program in which exceptions are still broken on
> FreeBSD 4.5?
cd /usr/ports/devel/stlport
make install
cd work/STL*/test/eh
add -O to gcc-freebsd.mk
gmake -f gcc-freebsd.mk clean
gmake -f gcc-freebsd.mk
On Wed, Mar 13, 2002 at 12:15:34PM -0800, Ed Hall wrote:
> Exception-handling is broken with -O in -stable, and has been for years.
> FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
> to implement exceptions, so when the GCC folks broke that path, it was
> never fixed. The
Exception-handling is broken with -O in -stable, and has been for years.
FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
to implement exceptions, so when the GCC folks broke that path, it was
never fixed. There are supposedly patches floating around that fix the
problem, b
I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define
DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded.
All cpp* files are the same in the port and our system compilers.
And ideas and pointers which subsystems I could test for this breakage ?
Martin
To Unsubscribe: s
STABLE is broken too, but in a different manner. I just added -O and
then this happened.
[algo] :testing inplace_merge #1() (weak) ... eh_test in free(): warning: junk
pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: jun
Hi,
> > Here are my test news. The -O bug doesn't happen with
> > gcc295 from ports !
>
I tried all these FLAGS, but noone of them was creating the
problems we see with -O :
Optimization Options
-fcaller-saves -fcse-follow-jumps -fcse-skip-blocks
-fdelayed-branch -felide-constructors
-fexpensi
On Tue, Mar 12, 2002 at 01:49:02AM +0100, Martin Blapp wrote:
>
> Hi all,
>
> Here are my test news. The -O bug doesn't happen with
> gcc295 from ports !
Since this problem was apparently introduced recently, can you check
the commits against the gcc code in -current with the patches to the
por
Hi all,
Here are my test news. The -O bug doesn't happen with
gcc295 from ports !
Previously I had stated before, the gcc295 from ports did
not work too. but it seems that that was a user error :-)
/usr/ports/devel/stlport (and the tests test/eh)
can be succesfully be made.
My staroffice bui
61 matches
Mail list logo
