"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Richard Guenther wrote:
> > We didn't yet run into this issue and build openSUSE with 4.3 since
> > more than
> > three month.
> >
>
> Well, how often do you take a trap inside an overlapping memmove()?
That was the state with older gcc, but with ne
On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
> "H. Peter Anvin" <[EMAIL PROTECTED]> writes:
>
> > Richard Guenther wrote:
> > > We didn't yet run into this issue and build openSUSE with 4.3 since
> > > more than
> > > three month.
> > >
> >
> > Well, how often do you take a trap in
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed. The discussion is about
> what to do in the meantime.
While it is known that 32-bit glibc memmove and also inlines
for memmove and memrchr use std; some string op; cld;, 64-bit glibc d
Aurelien Jarno wrote:
> H. Peter Anvin a écrit :
>> Michael Matz wrote:
>>>
>>> On Wed, 5 Mar 2008, Aurelien Jarno wrote:
>>>
> So I think gcc at least needs an *option* to revert to the old
> behavior,
> and there's a good argument to make it the default for now, at least
> for
>>>
Aurelien Jarno writes:
> On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
> >
> > Aurelien Jarno wrote:
> > > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> > > >ABI and the direction flag, that is it now assumes that the direction
> > > >flag is cleared
Andrew Haley <[EMAIL PROTECTED]> writes:
>
> I suppose one could apply the precautionary principle, but those systems that
> don't update kernels won't update gcc either, so the solution won't work.
You seem to assume that running a gcc 4.3 compiled binary requires a
gcc update. That is not nece
Status
==
GCC 4.3.0 release has been tagged in SVN, tarballs uploaded
to gcc.gnu.org (though not to ftp.gnu.org yet).
The branch is still frozen though, until we agree on what if
anything to do about the implied cld instructions on i?86/x86_64.
Hopefully this will not take long.
The options a
On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > I suppose one could apply the precautionary principle, but those systems
> that
> > don't update kernels won't update gcc either, so the solution won't work.
>
> You seem to
When building GCC 4.3.0 for any newlib target I get:
...
supports shared libraries... yes
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed
after GCC_NO_EXECUTABLES.
Hi!
namespace A {
enum A {
x
};
}
void f()
{
A::A a;
using namespace A;
a = x;
}
works whereas
namespace A {
enum A {
x
};
}
void f()
{
using namespace A;
A::A a;
a = x;
}
gives th
It had been a while, so this merge was fairly long. It exposed a bug
in complex lowering (we were not splitting the basic block properly
when expanding complex divisions) and the ppc back end still hadn't
been updated for the new walk_gimple_stmt interface.
I also changed all the gimple_locus() a
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere else. And in gcc for blindl
Olivier Galibert wrote:
> On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
>> Olivier Galibert wrote:
>>> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
>>> I'm not convinced. It's been that way for 15 years, it's tha
Olivier Galibert wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere el
On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> >>It's a kernel bug, and it needs to be fixed.
> >
> >I'm not convinced. It's been that way for 15 years, it's that way in
> >the BSD kernel
On Wed, Mar 05, 2008 at 03:21:43PM -0800, David Daney wrote:
> Olivier Galibert wrote:
> >On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> >>FWIW I don't think it's a release blocker for 4.3.0. The error is arcane
> >>and happens seldomly if at all. And only on unfixed kernels. A
FX Coudert wrote:
[ Sorry, I'm way, way behind ]
C: integer overflow undefined, checking desirable at least for
debugging purposes.
I think latest Fortran is same as C, can someone confirm?
Yes, it is. Overflow undefined and no checking required; I think very
few Fortran users actually use
Olivier Galibert wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a feature. The bug is in the
documentation, nowhere el
Toon Moene wrote:
In Fortran, integers are used to index arrays. So if you want integer
overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
Jakub Jelinek wrote:
On Thu, Mar 06, 2008 at 09:44:05AM +0100, Andi Kleen wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
Richard Guenther wrote:
We didn't yet run into this issue and build openSUSE with 4.3 since
more than
three month.
Well, how often do you take a trap inside an overl
On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The b
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
H.J.
On Thu, Mar 6, 2008 at 7:37 AM, NightStrike <[EMAIL PROTECTED]> wrote:
>
> On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote
H.J. Lu wrote:
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
No, I believe the right way to approach this is by applying the good
old-fashioned principle from Ask Mr. Protocol
Hi,
I would like to modify GCC to inject a link-once word-sized data
declaration into the object file, i.e. to behave AS IF there were
extra declarations in the source code, e.g.:
void* __secret__Foo = &Foo;
(Where Foo is some piece of static data that was defined in source.)
Can someone gi
NightStrike wrote:
On 3/6/08, Olivier Galibert <[EMAIL PROTECTED]> wrote:
On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
It's a kernel bug, and it needs to be fixed.
I'm not convinced. It's been that way for 15 years, it's that way in
the BSD kernels, at that point it's a fea
Olivier Galibert wrote:
> On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
>> It's a kernel bug, and it needs to be fixed.
>
> I'm not convinced. It's been that way for 15 years, it's that way in
> the BSD kernels, at that point it's a feature. The bug is in the
> documentation, n
On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
> >what is the best way to handle this, assuming we are defining a new psABI.
BTW, just tested icc and icc doesn't genera
Hi,
On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to han
Another story, the sad story of the intel chip (I think it was
the 80188) where Intel made use of Int 5, which was documented
as reserved. Unfortunately, Microsoft/IBM had used this for
print screen or some such. Intel was absolutely right that
their documentation was clear and it was wrong to h
On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to handle t
H.J. Lu wrote:
On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> H.J. Lu wrote:
> >I agree with it. There is no right or wrong here Let's start from
> >scratch and figure out
> >what is the best way to
On Thu, Mar 6, 2008 at 9:06 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>
> H.J. Lu wrote:
> > On Thu, Mar 6, 2008 at 8:23 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> >> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> >> > H.J. Lu wrote:
> >> > >I agree with it. There i
> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes:
Richard> I am aware of the following merge candidates: the LTO branch, the
Richard> incremental compiler branch, the selective scheduling branch, the
Richard> YARA branch and of course the tuples branch.
FWIW I'm not sure if the incr
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You are taking
a purely engineering viewpoint,
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alluding to is that "real" Fortran programmer
Status update
=
The GCC 4.3 branch is now open for commits under normal release branch
rules.
GCC 4.3.1 should be released earlier than after two months. If we have
the workaround soon, we might cut 4.3.1-rc1 e.g. in two weeks or so,
depending on how well tested it will be then and d
Robert Dewar wrote:
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much
easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You are taking
a purely e
H.J. Lu wrote:
Not a fix, an (optional) workaround for a system bug.
So that is the bug in the Linux kernel. Since fixing kernel is much easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
The problem is, you're going to have to be a
On Thu, Mar 6, 2008 at 9:17 AM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
> >>
> >> Not a fix, an (optional) workaround for a system bug.
> >
> > So that is the bug in the Linux kernel. Since fixing kernel is much easier
> > than providing a workaround in compilers, I think k
On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote:
> On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> > >
> > > I suppose one could apply the precautionary principle, but those systems
> > that
> > > don't update
Robert Dewar wrote:
Sounds good, but has almost nothing to do with the real world. I
remember back in Realia COBOL days, we had to carefully copy IBM
bugs in the IBM mainframe COBOL compiler. Doing things right and
fixing the bug would have been the right thing to do, but no one
would have use
On Thu, Mar 06, 2008 at 03:12:21PM +0100, Olivier Galibert wrote:
> On Thu, Mar 06, 2008 at 03:03:15PM +0100, Paolo Bonzini wrote:
> > Olivier Galibert wrote:
> > >On Wed, Mar 05, 2008 at 05:12:07PM -0800, H. Peter Anvin wrote:
> > >>It's a kernel bug, and it needs to be fixed.
> > >
> > >I'm not c
On Thu, Mar 06, 2008 at 10:56:07AM +0100, Jakub Jelinek wrote:
> Status
> ==
>
> GCC 4.3.0 release has been tagged in SVN, tarballs uploaded
> to gcc.gnu.org (though not to ftp.gnu.org yet).
> The branch is still frozen though, until we agree on what if
> anything to do about the implied cld i
Hi,
I'd like to check in the fix for PR target/35189 into gcc 4.3.1:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00729.html
It has been approved for 4.3. But I want to give it a little on trunk first.
Thanks.
H.J.
On Thu, Mar 6, 2008 at 9:27 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Sta
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote:
> If the kernel allows state to leak from one process to another,
> for example from a process running as root to a process running as an
> ordinary user, it's a bug, with possible security implications.
I don't think that it is relevant in
Olivier Galibert wrote:
On Thu, Mar 06, 2008 at 09:58:41AM -0800, Joe Buck wrote:
If the kernel allows state to leak from one process to another,
for example from a process running as root to a process running as an
ordinary user, it's a bug, with possible security implications.
I don't think
On Thu, 6 Mar 2008, Joe Buck wrote:
> I suggest just letting 4.3.0 out into the world (finish the release
> process), and mention the caveat about the cld issue in the announcement.
> We would then have time to decide whether to do a quick 4.3.0.1, or not.
It certainly does need finishing (e.g. t
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> A process can send a signal via kill. IOW, a malicious process can
> *control when the process would be interrupted* in order to get it into
> the signal handler with DF=1.
If the malicious process can send a signal to another pro
On 3/6/08, Jack Lloyd <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> > A process can send a signal via kill. IOW, a malicious process can
> > *control when the process would be interrupted* in order to get it into
> > the signal handler with DF=1.
Hello,
here are the number of known regressions in GCC 4.3.0
in 4.3 new in 4.3
P1 0 0
P2 9122
P3 27 9
P4 37 6
P5 9620
important 11831
together 25157
Andreas
--
GMX startet ShortView
On Thu, Mar 06, 2008 at 06:30:46PM +, Joseph S. Myers wrote:
> On Thu, 6 Mar 2008, Joe Buck wrote:
>
> > I suggest just letting 4.3.0 out into the world (finish the release
> > process), and mention the caveat about the cld issue in the announcement.
> > We would then have time to decide wheth
FX Coudert wrote:
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alluding to is that "real"
H. Peter Anvin wrote:
Robert Dewar wrote:
H.J. Lu wrote:
So that is the bug in the Linux kernel. Since fixing kernel is much
easier
than providing a workaround in compilers, I think kernel should be fixed
and no need for icc/gcc fix.
Fixing a bug in the Linux kernel is not "much easier". You
H.J. Lu wrote:
Icc has been following psABI for years on Linux and it doesn't stop people
using icc on Linux. On the other hand, it may be a good idea to provide a
workaround in gcc and enables it by default. OSVs can fix thekernel and
disable it by default.
How widely is icc used? I ask bec
Jack Lloyd wrote:
On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
A process can send a signal via kill. IOW, a malicious process can
*control when the process would be interrupted* in order to get it into
the signal handler with DF=1.
If the malicious process can send a signal
If the malicious process can send a signal to another process, it
could also ptrace() it. Which is more useful, if you wanted to be
malicious?
And more to the point, it can happen before GCC 4.3.0.
Yes, and that's why the kernel should just fix it, and the fix should be
backported and trea
On Thu, Mar 06, 2008 at 08:43:27PM +0100, Paolo Bonzini wrote:
> Jack Lloyd wrote:
> >On Thu, Mar 06, 2008 at 07:13:20PM +0100, Paolo Bonzini wrote:
> >>A process can send a signal via kill. IOW, a malicious process can
> >>*control when the process would be interrupted* in order to get it into
Robert Dewar wrote:
Not really, it's just a matter of time. Typical distro cycles are on
the order of 3 years.
-hpa
again, in the real world, there are MANY projects that are nothing
like this interactive when it comes to moving to new versions of
operating systems.
This is true, but
Robert Dewar wrote:
FX Coudert wrote:
In Fortran, integers are used to index arrays. So if you want
integer overflow checking, use -fbounds-check :-)
I know there is a smiley here, but it seems to me that range checking
is quite different from overflow checking.
I think what Toon was alludi
On Thu, Mar 6, 2008 at 6:34 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 01:06:17PM +0100, Richard Guenther wrote:
> > On 06 Mar 2008 12:45:57 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Andrew Haley <[EMAIL PROTECTED]> writes:
> > > >
> > > > I suppose one could
On Thu, Mar 6, 2008 at 8:09 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 06:30:46PM +, Joseph S. Myers wrote:
> > On Thu, 6 Mar 2008, Joe Buck wrote:
> >
> > > I suggest just letting 4.3.0 out into the world (finish the release
> > > process), and mention the caveat a
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet another option
won't help in corner cases. And corner cases is exactly what people seem
to care about. For this reason that we have this single release, 4.3.0, that
behaves "bad" is already a problem.
The op
On Thu, 6 Mar 2008, Richard Guenther wrote:
> > Sounds good to me; certainly as soon as 4.3.0 gets out and gets wider
> > testing, people will find things. In the past we only used the 4th digit
> > for paper-bag issues (like failure to bootstrap on a major platform or
> > broken release tarb
Jack Lloyd wrote:
> But still: so the threat here is of a malicious process with the
> ability to send arbitrary signals to any process using CAP_KILL (since
> in any other case when a process can send a signal, it can do much
> more damage in other ways), which could leverage that into
> (potentia
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
> Richard Guenther wrote:
> >
> >A patched GCC IMHO makes only sense if it is always-on, yet another option
> >won't help in corner cases. And corner cases is exactly what people seem
> >to care about. For this reason that we have th
On Thu, Mar 6, 2008 at 11:06 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
> > Richard Guenther wrote:
> > >
> > >A patched GCC IMHO makes only sense if it is always-on, yet another option
> > >won't help in corner cases. And corn
Snapshot gcc-4.3-20080306 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 3/5/08, Andrew Haley <[EMAIL PROTECTED]> wrote:
> The proposed memory model partly described at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.ht
Hi,
I have a question about the validity of CLASSTYPE_VBASECLASSES.
Due to templates, it is not possible to know if a class has virtual
bases or not until the class is fully instantiated. Is checking
processing_template_decl sufficient to guarantee that
CLASSTYPE_VBASECLASSES is valid?
Thank
On Mar 6, 2008, at 2:06 PM, Andi Kleen wrote:
On Thu, Mar 06, 2008 at 12:56:16PM -0800, H. Peter Anvin wrote:
Richard Guenther wrote:
A patched GCC IMHO makes only sense if it is always-on, yet
another option
won't help in corner cases. And corner cases is exactly what
people seem
to ca
I just compiled an app with GCC. It is segmentation faulting in call_gmon_start
(even before reaching main() of my program
What does call_gmon_start() do ? Which library defines this function?
gdb) where
#0 0x2a000750 in call_gmon_start ()
#1 0x in ?? ()
(gdb) info
(gdb) disassemble
Reuben Harris wrote:
I would like to modify GCC to inject a link-once word-sized data
declaration into the object file, i.e. to behave AS IF there were
extra declarations in the source code, e.g.:
Builtin functions are a good source for how to create decls, but they
create mostly type decls.
I'm cc-ing gcc@ & gcc-patches@ list. I feel this interesting discussion
belongs more to gcc@
Tim Josling wrote:
Treelang was based on Richard Kenner's toy language. I packaged it up to
include as a part of GCC because toy had fallen behind the GCC mainline
and no longer worked, and there were
73 matches
Mail list logo
