Segher Boessenkool <[EMAIL PROTECTED]> writes on Tue, 04 Mar
2008 01:25:33 +0100
> The Linux kernel, and probably some user-space applications and
> libraries
> as well, depend on GCC guaranteeing (a variant of) the following:
>
> "any access to a naturally aligned sca
Dasarath Weeratunge wrote:
I added a field to struct basic_block_def in basic-block.h of type
struct pointer_set_t.
Now when I try to rebuild GCC build fails with error:
libbackend.a(gtype-desc.o): In function `gt_pch_nx_basic_block_def':
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:2472: undefin
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Not quite, but fixing it in the kernel is easy.
>
> Still breaks for running on all old kernels.
Many more things break on old kernels. I guess it's not worse than
a (local) root exploit, is it?
*-stable and distributions should take care of it, as
Chris Lattner wrote:
Upon return to userspace, the modified state kicks in. Thus the
signal handler is entered with DF from userspace at trap time, not DF=0.
So it's an asynchronous state leak from one piece of userspace to
another.
Fine, it can happen either way. In either case, the dis
On Mar 5, 2008, at 4:47 PM, H. Peter Anvin wrote:
Chris Lattner wrote:
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()?
How hard is it to change the ke
Chris Lattner wrote:
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()?
How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"? Pro
Chris Lattner a écrit :
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()?
>>>
>>> How hard is it to change the kernel signal en
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()?
How hard is it to change the kernel signal entry path from "pushf" to
"pushf;cld"? Problem solved, no?
Th
On Sat, Mar 1, 2008 at 12:31 AM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Please open a new bug report (enhancement request, probably)
> for things that GCC still needs libcalls for, and make your new bug
> report block PR34513. Of course, it'd help if you then go on and
> remove that depen
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 program
needs to do std explicitely, which most don't do _and_ get hit
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 program
> needs to do std explicitely, which most don't do _and_ get hit by a signal
> whil
On Wed, Mar 05, 2008 at 03:10:12PM -0800, David Miller wrote:
> From: Michael Matz <[EMAIL PROTECTED]>
> Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)
>
> > The fix lies in the kernel, the work-around in gcc.
>
> This depends upon how you interpret this ABI situation.
>
> There is at least some agr
On Thu, Mar 06, 2008 at 12:13:04AM +0200, Adrian Bunk wrote:
> Compiling older kernels with new gcc versions has never been supported.
You read the thread too fast. It's not at all about compiling the
kernel.
OG.
On Thu, Mar 06, 2008 at 12:07:39AM +0100, Michael Matz wrote:
> For security problems I prefer fixes over work-arounds. The fix lies in
> the kernel, the work-around in gcc.
Incorrect. The bugs are in the ABI documentation and in gcc, and the
fixes should be done there. Doing it in the kernel
From: Michael Matz <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:07:39 +0100 (CET)
> The fix lies in the kernel, the work-around in gcc.
This depends upon how you interpret this ABI situation.
There is at least some agreement that how things have
actually been implemented by these kernels for mor
Hi,
On Wed, 5 Mar 2008, H. Peter Anvin wrote:
> Michael Matz wrote:
> >
> > Many bugs are a big issue to people who actually hit them, and we had (and
> > probably still have) far nastier corner case miscompilations here and there
> > and nevertheless released. It never was the end of the world
Michael Matz wrote:
Many bugs are a big issue to people who actually hit them, and we had (and
probably still have) far nastier corner case miscompilations here and
there and nevertheless released. It never was the end of the world :)
This is the sort of stuff that security holes are made
Hi,
On Wed, 5 Mar 2008, David Miller wrote:
> I will be sure to hunt you down to help debug when someone reports that
> once every few weeks their multi-day simulation gives incorrect results
> :-)
Give them a LD_PRELOADable DSO that intercepts signal() and sig_action(),
installing a trampoli
On Feb 29, 2008, at 19:13, Richard Guenther wrote:
We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove
Snapshot gcc-4.2-20080305 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080305/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Mar 05, 2008 at 02:16:22PM -0800, David Miller wrote:
> From: "Richard Guenther" <[EMAIL PROTECTED]>
> Date: Wed, 5 Mar 2008 22:40:59 +0100
>
> > Right. So this problem is over-exaggerated. It's not like
> > "any binary you create on that system will be broken on any
> > other existing s
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Thu, 6 Mar 2008 00:13:04 +0200
> On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> > The problem is with old kernels, which by definition stay unfixed.
>
> Compiling older kernels with new gcc versions has never been supported.
Adrian we'
From: Michael Matz <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:43:33 +0100 (CET)
> The error is arcane and happens seldomly if at all. And only on
> unfixed kernels.
Which translates right now into "all kernels."
From: "Richard Guenther" <[EMAIL PROTECTED]>
Date: Wed, 5 Mar 2008 22:40:59 +0100
> Right. So this problem is over-exaggerated. It's not like
> "any binary you create on that system will be broken on any
> other existing system."
I will be sure to hunt you down to help debug when someone report
On Wed, Mar 05, 2008 at 10:59:21PM +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 5 Mar 2008, Chris Lattner wrote:
>
> >
> > On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
> >
> > >Richard Guenther wrote:
> > > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > > >th
On Wed, Mar 05, 2008 at 10:43:33PM +0100, Michael Matz wrote:
> Hi,
>
> On Wed, 5 Mar 2008, Joe Buck wrote:
>
> >
> >
> > On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > > ABI is not going to be adjusted for that.
> > >
Chris Lattner wrote:
On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
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()?
How hard is it to change the kerne
Hi,
On Wed, 5 Mar 2008, Chris Lattner wrote:
>
> On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
>
> >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 overlappi
On Mar 5, 2008, at 1:34 PM, H. Peter Anvin wrote:
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()?
How hard is it to change the kernel signal entry path f
Richard Guenther a écrit :
> On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, 5 Mar 2008, Jan Hubicka wrote:
>> > > Linux kernel is disabling red zone and use kernel code model, yet the
>> > > ABI is not going to be adjusted for that.
>> > >
>> > > This is res
On Wed, Mar 5, 2008 at 10:43 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
> > Richard Guenther wrote:
> > >
> > >We didn't yet run into this issue and build openSUSE with 4.3 since more
> > >than
> > >three month.
> > >
> >
> >
Hi,
On Wed, 5 Mar 2008, Joe Buck wrote:
>
>
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > ABI is not going to be adjusted for that.
> > >
> > > This is resonably easy to fix on kernel side in signal handling, or by
>
There are already gcc 4.3.0 packages on the FTP site.
Sent from my iPhone
On Mar 5, 2008, at 13:20, Joe Buck <[EMAIL PROTECTED]> wrote:
On Wed, 5 Mar 2008, Jan Hubicka wrote:
Linux kernel is disabling red zone and use kernel code model, yet
the
ABI is not going to be adjusted for that.
T
On Wed, Mar 05, 2008 at 01:34:14PM -0800, H. Peter Anvin wrote:
> 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()?
Also, would it be possible
On Wed, Mar 5, 2008 at 10:34 PM, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> 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()?
Right. So
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > alias_sets_conflict_p() is used to determine if an addressable variable
> > and a type conflict also from the tree-ssa alias machinery (in effect to
> > determine which virtual variables need to be clobbered). It just isn't
> > feed COMPONENT_
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()?
-hpa
On Wed, Mar 5, 2008 at 10:20 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > > Linux kernel is disabling red zone and use kernel code model, yet the
> > > ABI is not going to be adjusted for that.
> > >
> > > This is resonably easy to fix on kernel side
From: Aurelien Jarno <[EMAIL PROTECTED]>
Date: Wed, 05 Mar 2008 21:52:14 +0100
> H. Peter Anvin a écrit :
> > The best would be if this could be controlled by a flag, which we can
> > flip once kernel fixes has been around for long enough.
>
> I have to agree there. Whatever the decision that gcc
On Wed, 5 Mar 2008, Jan Hubicka wrote:
> > Linux kernel is disabling red zone and use kernel code model, yet the
> > ABI is not going to be adjusted for that.
> >
> > This is resonably easy to fix on kernel side in signal handling, or by
> > removing std usage completely
On Wed, Mar 05, 2008 a
> alias_sets_conflict_p() is used to determine if an addressable variable
> and a type conflict also from the tree-ssa alias machinery (in effect to
> determine which virtual variables need to be clobbered). It just isn't
> feed COMPONENT_REFs, that's what you found very wrong, and I explained
Jan Hubicka wrote:
Yes, if there are four kernels that get it "wrong", that effectively means
that the ABI document doesn't describe reality and gcc has to adjust.
Kernels almost never follow ABI used by applications to last detail.
Linux kernel is disabling red zone and use kernel code model,
Hi,
On Wed, 5 Mar 2008, Jan Hubicka wrote:
> Kernels almost never follow ABI used by applications to last detail.
But we aren't talking about the ABI the kernel uses internally, but about
what is exposed to user-space via signal handlers. _That_ part needs to
be followed, and if it isn't it'
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> > The problem lies in the way how we represent load and store dependencies
> > as virtual operands. Conflicts between a pair of mem accesses are not
> > evaluated by asking alias_set_conflicts_p() on both accesses, but instead
> > via a chain of
See my comments in PR33009.
Dominique d'Humieres
H. Peter Anvin a écrit :
> Michael Matz wrote:
>> Hi,
>>
>> 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
x86/x86-64 on Linux.
>>
> On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> > Hi,
> >
> > 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
> > > > x
Michael Matz wrote:
Hi,
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
x86/x86-64 on Linux.
And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, Net
* Segher Boessenkool:
> Good point. Suggestions for better wording? How does
>
> "any access to a naturally aligned scalar object in memory
> that is not a bit-field and fits in a general purpose integer
> machine register, will be performed by a single machine
> instruct
On Wed, Mar 05, 2008 at 09:38:13PM +0100, Michael Matz wrote:
> Hi,
>
> 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
> > > x86/x86-64 on Lin
> The problem lies in the way how we represent load and store dependencies
> as virtual operands. Conflicts between a pair of mem accesses are not
> evaluated by asking alias_set_conflicts_p() on both accesses, but instead
> via a chain of virtual def and use operands.
But I thought this who
Hi,
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
> > x86/x86-64 on Linux.
>
> And for other kernels. I tested OpenBSD 4.1, FreeBSD 6.3, NetBSD 4.
I added a field to struct basic_block_def in basic-block.h of type
struct pointer_set_t.
Now when I try to rebuild GCC build fails with error:
libbackend.a(gtype-desc.o): In function `gt_pch_nx_basic_block_def':
/scratch/dweeratu/gcc/build/gcc/gtype-desc.c:2472: undefined reference
to `gt_pch_nx_
Hi,
On Wed, 5 Mar 2008, Richard Kenner wrote:
> I moved this to the main list because I think it's of general interest.
>
> I fail to understand how the issue of which alias set is used has any
> appreciable effect on the amount of memory used at compile time.
>
> The issue here is with somethi
* Ross Ridge:
> At the risk of my curiousity getting me into more trouble, could any
> one explain to me how to access these "eip" and "trapno" members from
> a signal handler on Linux? I can't find any relevent documention with
> man nor Google.
I think you need sigaction with a SA_SIGINFO, and
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 at the entry of a function and it doesn'
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 at the entry of a function and it doesn't clear once
> >more if needed.
> >...
> >I guess this has to be fi
> > But if it can't handle very simple cases correctly, I'd say it has some
> > serious problems.
>
> I await your design for a completely accurate def-use chain
> representation for memory accesses that does not take infinite amounts
> of memory at compile time.
> Until then, i have to laugh at
Hi guys and gals,
Currently, gcc.gnu.org runs a custom version of bugzilla 2.18.
The main differences between our version and the regular 2.18 is that
we removed some fields (operating system and something else) and added
some fields (target triples).
We've also modified the email handling code a
On Wed, Mar 05, 2008 at 06:05:44PM +, Andrew Haley wrote:
> > Hm, just out of curiosity, does not Java require 32-bit stores to be
> > atomic?
>
> Yes.
Linux uses typedef int sig_atomic_t; for all architectures, so if ARM
stores an int as two 16-bit guantities, it breaks ISO C requirements
Martin Jambor wrote:
> On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
>>> AFAIK the only reason we don't break this rule is that doing so would
>>> be grossly inefficient; there's nothing to stop any gcc back-end with
>>> (say) seriously slow DImode writes from using two SImode writes
On Tue, Mar 04, 2008 at 10:50:17PM +, Paul Brook wrote:
> > AFAIK the only reason we don't break this rule is that doing so would
> > be grossly inefficient; there's nothing to stop any gcc back-end with
> > (say) seriously slow DImode writes from using two SImode writes instead.
>
> I'm fairl
Hi all,
regtesting on i686-apple-darwin9 I see :
FAIL: gcc.c-torture/compile/pr33009.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer (test
for excess errors
> "kai-gcc" == kai-gcc <[EMAIL PROTECTED]> writes:
kai-gcc> A. There's something similar in the C standard: see
kai-gcc> sig_atomic_t. It might be possible to steal some wording
kai-gcc> from there.
kai-gcc> B. This guarantee - at least as I describe it below - cannot
kai-gcc> work for
Hi,
According to i386 psABI,
---
The direction flag must be set "forward" direction before entry and
upon exit from
a function.
---
So, asm statement should make sure that the direction flag is cleared before
function returns and kernel should make sure that the direction flag is cleared
when ca
Aurelien Jarno wrote:
Hi all,
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 at the entry of a function and it doesn't clear once
more if needed.
This causes some problems with the
On Tue, Mar 04, 2008 at 04:41:16PM -0500, Paul Koning wrote:
> > "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes:
> Segher> I disagree. People are relying on this undocumented GCC
> Segher> behaviour already, and when things break, chaos ensues. If
> Segher> we change this to be
Hi all,
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 at the entry of a function and it doesn't clear once
more if needed.
This causes some problems with the Linux kernel which does n
> "mfctr" will be very rare. I'm not sure there is any easy C code that
> would produce it.
Way back when I first was working on this stuff, I have seen it, though I
agree that it would be hard to find a test case.
> Duncan Purll writes:
Duncan> I am in the process of verifying that the gnu assembler produces object
code which corresponds on an instruction-by-instruction basis with the
interleaved source / assembly language listing obtained via -Wa,-ahls. This is
for the purposes of software certifica
Hi
I am in the process of verifying that the gnu assembler produces object code
which corresponds on an instruction-by-instruction basis with the interleaved
source / assembly language listing obtained via -Wa,-ahls. This is for the
purposes of software certification. I need to create C source
On 03/05/08 09:14, Richard Guenther wrote:
I agree, still it is probably nice to be able to compare testcase behavior
with/without SFTs with the same state of trunk for a while. So I'd just
adjust the default of --para max-fields-for-field-sensitive for now
(after the oracle patches got in) and
On 03/05/08 09:19, Rafael Espindola wrote:
Strange. This was a problem with mainline bootstrap (see rev 132886)
but I don't understand why it failed on the test machine but not on my
workstation when both are using --disable-bootstrap?
Since the branch has bootstraps disabled, you are at the m
> > >+if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> > >+&& (TYPE_PRECISION (TREE_TYPE (t))
> > >+!= TREE_INT_CST_LOW (TREE_OPERAND (t, 1
> > >+ {
> > >+error ("integral result type precision does not match "
> > >+ "field size o
"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:
> Thank you Ian. I did the modification you mentioned...now I am running
> into more problems.
Again: gcc@gcc.gnu.org is the wrong mailing list. Please do not send
any more e-mail about this to [EMAIL PROTECTED] Please take any
followups to [EMAIL PR
2008/3/5 Diego Novillo <[EMAIL PROTECTED]>:
> cc1 had failed to build because of invalid C90 declarations. Fixed with
> this patch.
Strange. This was a problem with mainline bootstrap (see rev 132886)
but I don't understand why it failed on the test machine but not on my
workstation when both a
On Wed, 05 Mar 2008, 13:47:36 +0100, Diego Novillo wrote:
> On 03/05/08 07:18, Richard Guenther wrote:
>
> >Comments?
>
> Makes sense to me.
>
> >+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
> >+ && (TYPE_PRECISION (TREE_TYPE (t))
> >+ != TREE_INT_CST_LOW (TREE_OP
On Wed, 5 Mar 2008, Diego Novillo wrote:
> On 03/05/08 06:48, Richard Guenther wrote:
>
> > you can see that in both cases the runs without SFTs are significantly
> > better(!) Which hints at the fact that we do a poor job with parititoning
> > and/or that partitioning triggers earlier with SFTs
On 03/05/08 07:07, Diego Novillo wrote:
The overnight tester has found hundreds of new regressions. Please
refrain from checking in anything in the branch until I figure out which
patch broke them and revert it.
cc1 had failed to build because of invalid C90 declarations. Fixed with
this p
On 03/05/08 06:48, Richard Guenther wrote:
you can see that in both cases the runs without SFTs are significantly
better(!) Which hints at the fact that we do a poor job with parititoning
and/or that partitioning triggers earlier with SFTs enabled.
All these differences seem to be less than 1
Sa Liu wrote:
I noticed that in fortran/convert.c the convert() function calls
convert_to_vector() if the target type is VECTOR_TYPE. When is that
function triggered in Fortran frontend? Since Fortran language doesn't
support vector type, why does it convert something to a vector expression?
On 03/05/08 07:18, Richard Guenther wrote:
Comments?
Makes sense to me.
+ if (INTEGRAL_TYPE_P (TREE_TYPE (t))
+ && (TYPE_PRECISION (TREE_TYPE (t))
+ != TREE_INT_CST_LOW (TREE_OPERAND (t, 1
+ {
+ error ("integra
While adding constant-folding for integral argument BIT_FIELD_REF I
noticed we have no way of passing down BIT_FIELD_REF_UNSIGNED to
fold_ternary. Luckily references to BIT_FIELD_REF_UNSIGNED are
rare - only expansion cares for it, through the use of
get_inner_reference.
So I propose to tighthe
I noticed that in fortran/convert.c the convert() function calls
convert_to_vector() if the target type is VECTOR_TYPE. When is that
function triggered in Fortran frontend? Since Fortran language doesn't
support vector type, why does it convert something to a vector expression?
Thanks!
Sa
The overnight tester has found hundreds of new regressions. Please
refrain from checking in anything in the branch until I figure out which
patch broke them and revert it.
Thanks. Diego.
Here are SPEC CPU 2000 results with plain trunk and the two alias-oracle
patches. Base results are plain -O3 -ffast-math, peak results include
--param max-fields-for-field-sensitive=0 which effectively disables the
creation of SFTs.
Unpatched (three runs):
E
On Mon, Mar 3, 2008 at 3:08 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I am aware of the following merge candidates: the LTO branch, the
> incremental compiler branch, the selective scheduling branch, the
> YARA branch and of course the tuples branch. Please announce those
> I forgot so
Ross Ridge wrote:
> Segher Boessenkool writes:
>> ... People are relying on this undocumented GCC behaviour already,
>> and when things break, chaos ensues.
>
> GCC has introduced many changes over the years that have broken many
> programs that have relied on undocumented or unspecified behaviour
88 matches
Mail list logo
