On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski wrote:
> I was improving tree aliasing for pointers by adding support a+1 and a
> not aliasing. But I ran into a bug in the aliasing where:
> /* If both references are through the same type, they do not alias
> if the accesses do not overlap. Thi
Jason Merrill wrote:
> On 08/03/2009 09:36 PM, Adam Butcher wrote:
>> Thanks. I haven't any copyright assignments on file -- this is my first
>> dabbling with gcc and I've been doing it
>> mostly to experiment with C++ lambda support and non-standard extensions
>> such as polymorphic lambda supp
Ãpeäcòà âëÿåì Ãaì çeìåëüÃûå ó÷añtêè ñ ïîñòðîéêîé èëè áeç Ãà Ãèìôèðîïîëüñêîì
øîñcÃ¥ , óäà ëåÃÃîñtü oò ÃÃÃà 39-64 kì . à êîòòeäæÃoì ïîñåëkÃ¥ - èÃôpà còpóêòyðà ,
ïpîâåäeÃû ýëåkòpè÷ecòâî,
Jack Howarth wrote on 03/08/2009 17:26:18:
> Ira and Dorit,
>Is there any chance that PR33113 will be addressed for
> gcc 4.5? If I recall correctly, it was one of the last
> major issues with vectorization in gfortran that wasn't
> addressed yet. Dorit made the following comment back in
> Au
Tom Tromey wrote:
>> "Dave" == Dave Korn writes:
>
> Dave> Were you using a --prefix? The PPL checks (by design I think) only
> Dave> look for PPL in your prefix.
>
> Dave> I do not know it; I have merely observed the behaviour. It may
> Dave> even not be by design for all I know, though
On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
>
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this b
Hi Jason,
Pending response from assign at gnu dot org, I've attached diffs made against
your latest lambda head. They are
cleaned up a little to from the previous diffs against trunk. First is the
re-layout fix, second is experimental
polymorphic lambda support.
Cheers,
Adam
0001-Re-laid-ou
Adam Butcher wrote:
Hopefully. From my point of view the class generated by a lambda expression
should be equivalent to something you
could write yourself -- aside from the single stack-pointer reference
optimization which only a compiler could achieve
-- the class has a name, albeit invisibl
On 2009-08-03 15:52:37 +0200, Unruh, Erwin wrote:
> In current gcc the order of options -D and -U is significant. The
> Single Unix(r) Specification explicitly specifies that the order
> should not matter for the c89 command. It reads (cited from
> version 2, which is ten years old):
[...]
FYI, I
On 2009-08-04 08:23:52 +0200, Paolo Bonzini wrote:
> User-specified CFLAGS are always passed last in the Makefiles (at
> least for Automake, but it is a good practice in general) so that
> the user can override options like -D, -U, -O, -g, -f, -m.
>
> The specified behavior would make this impossi
On 08/04/2009 09:35 AM, John Freeman wrote:
In my opinion, lambdas are not intended as just a shortcut to writing a
function object class. This is why our proposal did not require that
lambdas be implemented as classes; it is simply one implementation.
(Awaiting word to see if this is still the
Jason Merrill wrote:
On 08/04/2009 09:35 AM, John Freeman wrote:
In my opinion, lambdas are not intended as just a shortcut to writing a
function object class. This is why our proposal did not require that
lambdas be implemented as classes; it is simply one implementation.
(Awaiting word to see
On 08/04/2009 04:52 AM, Adam Butcher wrote:
Yes sorry about that. I appreciate the issue. I had taken a branch of trunk
and applied the lambda changes to it to
keep only lambda changes on my working branch (allowing simpler future
rebaseing). There were a number of things I
had to change to
On 08/04/2009 10:17 AM, John Freeman wrote:
Reiterating, to allow more freedom in implementation, we can just say it
"behaves as" a template, rather than "is" a template.
I don't see the difference. As long as they work the same, the compiler
is free to do whatever it wants internally.
Jaso
Status
==
The 4.3.4 release has been created and the final bits of the release
process will be carried out soon.
The 4.3 branch is now open again for checkins under the usual release
branch rules (regression and documentation fixes only). A 4.3.5
release is expected shortly after the 4.4.2
> "Erwin" == Unruh, Erwin writes:
Erwin> In current gcc the order of options -D and -U is significant. The
Erwin> Single Unix(r) Specification explicitly specifies that the order
Erwin> should not matter for the c89 command. It reads (cited from
Erwin> version 2, which is ten years old):
Erw
On 08/03/2009 09:39 PM, John Freeman wrote:
* Instead of transforming:
*
* [&] { i = 1; j = 2; k = 3; };
*
* into
*
* [&i,&j,&k] { i = 1; j = 2; k = 3; };
*
* and thus storing three pointers to int, transform it into:
*
* [sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1;
* var-from-stack(j
Hi jim ,
forgot to mention , I am accessing variable a as extern in file2.c
I am going through the solutions pointed by you but not able to
figure out one .
Thanks ,
Sumanth G
Jim Wilson wrote:
On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote:
> mycompiler-gcc -g file1.c file2.c
I had a similar issue on my port. I fixed it by adding a check_move
before the generation of the move to look at the potential offset
used.
That allowed the compiler to not generate those wrong offsets
depending on the mode on my port. It looks something like this :
/* Check the operands of the m
On Tue, Aug 04, 2009 at 08:03:56AM -0700, Tom Tromey wrote:
> > "Erwin" == Unruh, Erwin writes:
>
> Erwin> In current gcc the order of options -D and -U is significant. The
> Erwin> Single Unix(r) Specification explicitly specifies that the order
> Erwin> should not matter for the c89 command
Jason Merrill wrote:
On 08/04/2009 10:17 AM, John Freeman wrote:
Reiterating, to allow more freedom in implementation, we can just say it
"behaves as" a template, rather than "is" a template.
I don't see the difference. As long as they work the same, the
compiler is free to do whatever it wa
Jason Merrill wrote:
Incidentally, how does it work to just move the existing call of
finish_struct to after we parse the body? I don't see why we need it
to be complete while we're in the body.
When I was working on it, there were some checks to make sure the class
was complete. I can't re
Hello,
I am trying to rebuild gcc, for my target (ia32/amd64 bootloader) I will
not use any library whatsoever, target is ia32.
If I do:
rm -f -r ../toolchain
mkdir ../toolchain ../toolchain/source ../toolchain/build
tar --directory ../toolchain -xjf ../binutils-2.19.1.tar.bz2
mv ../toolchain
On 2009-08-05, at 04:03, Joe Buck wrote:
Another alternative would be an extra flag that would turn on
conformance
to the spec.
Traditionally spelled -posixly-correct in other GNU software. This would
presumably also affect other options, such as making the default -
std=c99
instead of g
John Freeman wrote:
+/* relayout again -- to allow for implicit
+ * parameters to have been added to the capture if it was a
+ * 'default capture' -- note that this would not be necessary if
+ * the stack-pointer variant was implemented -- since the layout
+ * would be known
On Tue, Aug 04, 2009 at 11:42:51AM -0700, Ross Smith wrote:
>
> On 2009-08-05, at 04:03, Joe Buck wrote:
> >
> > Another alternative would be an extra flag that would turn on
> > conformance
> > to the spec.
>
> Traditionally spelled -posixly-correct in other GNU software. This would
> presumably
Snapshot gcc-4.4-20090804 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090804/
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/branches
On Tue, Aug 04, 2009 at 12:35:15PM +0300, Dorit Nuzman wrote:
>
> Hi Jack,
> AFAIK this topic has not been addressed (closest thing is Richard
> Guenther's work on versioning unknown strides
> http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01174.html) and I don't know
> about the prospects of this b
On 2009-08-04 15:44:05 -0700, Joe Buck wrote:
> But AFAIK neither Posix nor the C89 standard nor the C99 standard
> say anything about -D and -U flags. It's the Single UNIX specification
> that is the issue, and it refers to a command that is spelled "c89",
> or (in later versions) "c99", not "gcc
On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
> >> i am not able to implement the alignment for short.
> >> The following is are the macros that i used for this
> >> #define PARM_BOUNDARY 8
> >> #define STACK_BOUNDARY 64
> The target is 32bit . The first two parameters are passed in regis
30 matches
Mail list logo
