Hi,
> I don't quite understand: does XFAILing the test mean that the test
> isn't attempted, or just that if it fails it doesn't show up on the
> report (except incrementing the number of expected failures)?
The latter. I think you want to skip it completely for the targets
affected by the malloc b
Hi, I wonder if there's any kind schedule available on the development
Concepts proposal into GCC. I know there's a related branch in svn, but
it seems stale as of 11/2008.
Please don't take this as a pressure to get things going. I just want to
know the time frame it will be ready, I'm sort of ex
On Thu, Nov 20, 2008 at 21:19, Weddington, Eric
<[EMAIL PROTECTED]> wrote:
> Are you also proposing to do the re-implementation as you describe above (as
> a gimple pass, in IPA mode)?
Not necessarily, but it's a possibility. Initially I'm more
interested in removing code that is not useful and
2008/11/20 Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Thu, Nov 20, 2008 at 05:28:16PM +0100, Joel Porquet wrote:
>> Gcc is using local-exec tls model instead of global-dynamic. The
>> option -fpie is supposed to act as -fpic though (dixit the manual).
>> Here is the first problem...
>
> Could you
With looking at PRs 37742 and 37955 I reminded myself of our broken
restrict implementation which tries to model restrict semantics
within our type-based alias set framework. The implementation
heavily relies on correct tracking of restrict bases
(DECL_BASED_ON_RESTRICT_P/DECL_GET_RESTRICT_BASE)
2008/11/21 Rodolfo Lima <[EMAIL PROTECTED]>:
> Please don't take this as a pressure to get things going. I just want to
> know the time frame it will be ready, I'm sort of excited because of the
> possibilities it unleashes. I'd really like to help on this task, but I
> never worked on GCC internal
On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I think the only reasonable thing to do is to rip out the broken
> restrict pointer handling completely.
>
> Any better ideas?
I will assume that this program is valid. I am not familiar enough
with the restrict definit
On Fri, 21 Nov 2008, Diego Novillo wrote:
> On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > I think the only reasonable thing to do is to rip out the broken
> > restrict pointer handling completely.
> >
> > Any better ideas?
>
> I will assume that this program is
On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
>
> > I think the only reasonable thing to do is to rip out the broken
> > restrict pointer handling completely.
> >
> > Any better ideas?
>
> I will assume
On Fri, 21 Nov 2008, Jakub Jelinek wrote:
> On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
> >
> > > I think the only reasonable thing to do is to rip out the broken
> > > restrict pointer handling comp
On Fri, Nov 21, 2008 at 11:19:32AM +0100, Joel Porquet wrote:
> I agree that wether the code is pic or not and the tls model are quite
> independent.
> According to the manual, the default policy for TLS is affected by the
> pic model though:
>
> -ftls-model=model
> ...
> The default wit
On Fri, 21 Nov 2008, Richard Guenther wrote:
> On Fri, 21 Nov 2008, Jakub Jelinek wrote:
>
> > On Fri, Nov 21, 2008 at 08:31:18AM -0500, Diego Novillo wrote:
> > > On Fri, Nov 21, 2008 at 06:21, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > >
> > > > I think the only reasonable thing to do is
Richard Guenther <[EMAIL PROTECTED]> writes:
> int foo (int *__restrict p)
> {
> int *__restrict q;
> int v;
> q = p + 1;
> q = q - 1;
> v = *q;
> *p = 1;
> return v + *q;
> }
> extern void abort (void);
> int main()
> {
> int i = 0;
> if (foo (&i) != 1)
> abort ();
> retur
hi,
a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
However, I'm finding a huge number of failures with g++ caused by the
fact that __Unwind_GetIPInfo is not defined.
When 'make checking', I conventionally move the built libgcc_s.
1.dylib and libgcc_s.10.4.dylib to
Geert Uytterhoeven wrote:
On Fri, 21 Nov 2008, Alan Cox wrote:
On Thu, 20 Nov 2008 17:26:36 -0800
David Daney <[EMAIL PROTECTED]> wrote:
MIPS: Make BUG() __noreturn.
Often we do things like put BUG() in the default clause of a case
statement. Since it was not declared __noreturn, this could
Hi,
> This program appears to me to be invalid according to C99 6.7.3.1,
> which is the only definition of restrict that we have.
>
> If P is assigned the value of a pointer expression E that is based
> on another restricted pointer object P2, associated with block B2,
> then either t
> This is one of the reasons that the generated code can only be used
> in executables.
Okay, I abdicate on this point.
Nevertheless, how could i have a coherent compilation concerning the
TLS management, if my executable needs dynamically libraries ? Aren't
the exec and dynamic models completely
On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
> hi,
>
> a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
> However, I'm finding a huge number of failures with g++ caused by the
> fact that __Unwind_GetIPInfo is not defined.
>
> When 'make checking', I conventiona
On Fri, 21 Nov 2008, David Daney wrote:
> Geert Uytterhoeven wrote:
> > On Fri, 21 Nov 2008, Alan Cox wrote:
> > > On Thu, 20 Nov 2008 17:26:36 -0800
> > > David Daney <[EMAIL PROTECTED]> wrote:
> > >
> > > > MIPS: Make BUG() __noreturn.
> > > >
> > > > Often we do things like put BUG() in the de
On Fri, Nov 21, 2008 at 06:51:26PM +0100, Joel Porquet wrote:
> Nevertheless, how could i have a coherent compilation concerning the
> TLS management, if my executable needs dynamically libraries ? Aren't
> the exec and dynamic models completely incompatible in the same
> "whole" (eg one executable
Michael Matz <[EMAIL PROTECTED]> writes:
>> This program appears to me to be invalid according to C99 6.7.3.1,
>> which is the only definition of restrict that we have.
>>
>> If P is assigned the value of a pointer expression E that is based
>> on another restricted pointer object P2, ass
On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
>>> This program appears to me to be invalid according to C99 6.7.3.1,
>>> which is the only definition of restrict that we have.
>>>
>>> If P is assigned the value of a poi
On Fri, Nov 21, 2008 at 07:46:43PM +0100, Geert Uytterhoeven wrote:
> > up with a couple of options:
> >
> > 1) Enhance the _builtin_trap() function so that we can specify the
> > break code that is emitted. This would allow us to do something
> > like:
> >
> > static inline void __attribut
Snapshot gcc-4.4-20081121 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20081121/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, Nov 21, 2008 at 10:14 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Michael Matz <[EMAIL PROTECTED]> writes:
>>
This program appears to me to be invalid according to C99 6.7.3.1,
which is the only def
Andrew Morton wrote:
Yup, this change will fix some compile warnings which will never be
fixed in any other way for mips.
+static inline void __noreturn BUG(void)
+{
+ __asm__ __volatile__("break %0" : : "i" (BRK_BUG));
+ /* Fool GCC into thinking the function doesn't return. */
+
26 matches
Mail list logo
