On 07/12/2011 04:56 PM, Jason Merrill wrote:
A few more notes:
+ if (DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ if (!check_literal_operator_args(decl,
+ &long_long_unsigned_p, &long_double_p))
+ {
+ error ("%qD has illegal argument list", decl);
+
Hi Tobias,
On Sat, Jul 16, 2011 at 20:02, Tobias Grosser wrote:
> Here I am a little lost. You write using the precise method you get an
> interval [0,99] for the example in vect-pr43423.c. This is the example:
>
> int a[100], b[100], c[100];
>
> void foo(int n, int mid)
> {
> int i;
> for(i=0;
On 15 July 2011 15:56, Ulrich Weigand wrote:
> Ira Rosen wrote:
>
>> * gcc.dg/vect/pr49038.c: New test.
>
>> Index: testsuite/gcc.dg/vect/pr49038.c
>> ===
>> --- testsuite/gcc.dg/vect/pr49038.c (revision 0)
>> +++ testsuite/gc
On Sun, Jul 17, 2011 at 12:57 AM, Ian Lance Taylor wrote:
> Diego Novillo writes:
>
>> On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor wrote:
>>
>>> 2011-07-15 Ian Lance Taylor
>>>
>>> * configure.ac: Add --enable-build-poststage1-with-cxx. If set,
>>> make C++ a boot_language.
> I have measured it at some point and IIRC it was about 10% slower
> (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap,
> not sure if that included bootstrapping libstdc++ for the former).
IMO acceptable now that the build time of libjava has been halved.
--
Eric Botcazou
On Friday 15 July 2011 23:27:26 Tobias Burnus wrote:
> ptr(10,1:) => target was accepted as for the check "(10,1:)" was seen as
> equivalent to the valid "(10:, 1:)" - although the first dimension is
> not a range but an element. (Side note: (10:, 1:) would be wrong as well
> as one then needs to h
Modeless const_ints have been a recurring source of problems. The idea
behind keeping them modeless was presumably that we wanted to allow
const_ints to be shared between modes. However, in practice, every
"real" const_int does have a conceptual mode, and the sign-extension
rules mean that someth
This patch adds an array, mode_mem_attrs, that gives the default attributes
for a given mode. The defaults depend on STRICT_ALIGNMENT, which on rs6000
and v850 depends on command-line flags, and which could therefore in
principle be changed by __attribute__((optimize)). Although we might not
cope
Internally, emit-rtl.c uses the idiom:
MEM_ATTRS (mem) = get_mem_attrs (MEM_ALIAS_SET (mem), MEM_EXPR (mem),
MEM_OFFSET (mem), size, MEM_ALIGN (mem),
MEM_ADDR_SPACE (mem), GET_MODE (mem));
where we're reiterating most of the
This patch does the mechanical MEM_SIZE interface change. It also
makes set_mem_size take a HOST_WIDE_INT, and adds clear_mem_size
for resetting the size to "unknown".
The i386.c part includes an obvious pasto fix for:
if (dst_size)
set_mem_size (dst, GEN_INT (INTVAL (dst_size) - align_byt
This patch makes the mechanical MEM_OFFSET interface change,
along the same lines as the MEM_SIZE one.
Richard
gcc/
* doc/rtl.texi (MEM_OFFSET_KNOWN_P): Document.
(MEM_OFFSET): Change from returning an rtx to returning a
HOST_WIDE_INT.
* rtl.h (MEM_OFFSET_KNOWN_P)
This patch replaces the rtxes in mem_attrs with (bool, HOST_WIDE_INT) pairs.
There's already room for the bools in the padding after "addrspace".
(There's room for one more bool after this patch; we could move to
bitfields if more are needed.)
The new structure is 8 bytes bigger when using a combi
On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou wrote:
>> I have measured it at some point and IIRC it was about 10% slower
>> (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap,
>> not sure if that included bootstrapping libstdc++ for the former).
>
> IMO acceptable now that the
On Fri, Jul 15, 2011 at 5:51 PM, Rainer Orth
wrote:
> As discussed, here's the patch that obsoletes NetWare x86 on the 4.6
> branch.
>
> Tested by configuring/building on i386-pc-solaris2.11 with --target
> i386-pc-netware. As expected, without --enable-obsolete, the build
> fails in gcc, with --
On Fri, Jul 15, 2011 at 5:53 PM, Rainer Orth
wrote:
> Corresponding the the NetWare obsoletion and removal (upcoming,
> currently being tested) patches, here's the wwwdocs change.
>
> Ok?
Ok.
Thanks,
Richard.
> Rainer
>
>
> 2011-07-15 Rainer Orth
>
> * htdocs/gcc-4.6/changes.ht
On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou wrote:
> >> I have measured it at some point and IIRC it was about 10% slower
> >> (comparing C bootstrap with C++ in stag1 languages with C++ bootstrap,
> >> not sure if that included bootstrapp
On 2011.07.17 at 18:54 +0200, Markus Trippelsdorf wrote:
> On 2011.07.17 at 18:30 +0200, Richard Guenther wrote:
> > On Sun, Jul 17, 2011 at 1:30 PM, Eric Botcazou
> > wrote:
> > >> I have measured it at some point and IIRC it was about 10% slower
> > >> (comparing C bootstrap with C++ in stag1 l
First, I have another pending patch, cf:
http://gcc.gnu.org/ml/fortran/2011-07/msg00142.html
The attached patch adds diagnostic in the case that a use-associated
symbol is the same as the current procedure/module name. Besides typos,
that either indicates the use of the wrong procedure (which i
Updated version.
On 06/08/2011 11:45 AM, Tom de Vries wrote:
> On 06/08/2011 11:42 AM, Tom de Vries wrote:
>
>> I'll send the patch with the testcases in a separate email.
>
OK for trunk?
Thanks,
- Tom
2011-07-17 Tom de Vries
PR middle-end/43864
* gcc.dg/fold-compare-2.c (
Am 17.07.2011 20:30, schrieb Tobias Burnus:
Build and regtested on x86-64-linux?
If you say so :-)
OK for the trunk?
Actually, I am not 100% sure whether I need approval as Thomas already
gave kind of an approval in the PR.
Well, to remove any doubt: Yes.
Thanks for the patch!
Th
Thomas Koenig:
Am 17.07.2011 20:30, schrieb Tobias Burnus:
Build and regtested on x86-64-linux?
If you say so :-)
Well, I thought you had tested the patch :-)
(I had also regtested it successfully. By the way the "?" and the
incomplete subject shows that one shouldn't click on "sent" while
On Wed, Jul 6, 2011 at 11:25 AM, H.J. Lu wrote:
> On Wed, Jul 6, 2011 at 6:26 AM, Richard Guenther wrote:
>>
>> This fixes PR49645 - with MEM_REF the value-numbering machinery
>> to look through aggregate copies wasn't working reliably as
>> we have two representations for X, X and MEM[&X]. The
On 07/17/2011 07:55 AM, Sebastian Pop wrote:
Hi Tobias,
On Sat, Jul 16, 2011 at 20:02, Tobias Grosser wrote:
Here I am a little lost. You write using the precise method you get an
interval [0,99] for the example in vect-pr43423.c. This is the example:
int a[100], b[100], c[100];
void foo(int
Hi
This patch back ports a patch from gcc-4_6-branch to google/gcc-4_6 branch.
It skips a thumb1 only test on thumb2 devices.
thanks
Carrot
2011-07-18 Guozhi Wei
Backport r175894 from gcc-4_6-branch
2011-07-05 Janis Johnson
* gcc.target/arm/thumb-bitfld
On 07/17/2011 01:01 AM, Ed Smith-Rowland wrote:
On 07/12/2011 04:56 PM, Jason Merrill wrote:
Doesn't the shadowing apply everywhere, not just at file scope?
Yes, the shadowing should apply everywhere. What test do I use to get that?
I seem to remember trying something like global_p without succ
On 2011/6/15 09:12 PM, Richard Earnshaw wrote:
> On 22/04/11 16:21, Chung-Lin Tang wrote:
>> Hi Richard, this part's for you.
>>
>> The ARM backend changes needed are very little after the prior patches,
>> basically just a case in arm_canonicalize_comparison() to detect
>> (zero_extend:SI (subreg:
Before it was not obvious why the compiler rejected derived types with
allocatable or pointer components; cf. recent discussion in
comp.lang.fortran (and at j3). This patch mentions defined input/output
to make clear how to solve it. (Or not, given that defined I/O is not
yet implement in gfort
27 matches
Mail list logo
