On 3/03/2012, at 1:55 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 1:11 AM, Bernd Schmidt wrote:
> ...
>>
>> The following patch rewrites essentially all the cond_exec support in
>> ifcvt; reviewing is probably easier if it's thought of as new code.
>
> Kudos for improving if-conversion!
>
> I
Hi,
this patch allows that relocated const data is placed into .rdata. To provide
old behavior for older runtimes not supporting pseudo-relocation operating on
read-only sections, the option -fwritable-relocated-rdata can be used.
ChangeLog
2012-03-03 Kai Tietz
* doc/invoke.texi (fw
Hi all,
Attached patch was triggered by PR 52313
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve error
messages for module reading. It fixes one spelling of "GFORTRAN" --> "GNU
Fortran" and improves the error reporting of old *unversioned* format from:
> Parse error w
Dear Paul,
thanks for the review.
Paul Richard Thomas wrote:
I have a couple of remarks:
(i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
since! At the moment it does not cause any problems because of the
extremely limited use of the dtype 'type'. Whilst the array
descripto
> This patch adds Linux/x32 support to Ada. It sets LIBGNAT_TARGET_PAIRS
> similar to Linux/x86-64 and replaces system-linux-x86_64.ads with
> system-linux-x86.ads. It also adds "orl $0x0,(%esp)" check for SIGSEGV
> probe and sets __gnat_default_libgcc_subdir to libx32 for x32. Tested
> on Linux
On Fri, Mar 02, 2012 at 06:54:13PM +1300, Maxim Kuvyrkov wrote:
> > --- gcc/ipa-cp.c(revision 184662)
> > +++ gcc/ipa-cp.c(working copy)
> > @@ -508,7 +508,7 @@ ipcp_initialize_node_lattices (struct cg
> >
> > if (ipa_is_called_with_var_arguments (info))
> > type = IPA_BOTTOM;
> > -
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
http://translationproject.org/latest/gcc/de.po
(This file, 'gcc-4.7-b20120128.de.po', h
http://memoriadelcarrer.com/therefore.html Short way to long bed energy
This is a regression present on the 4.6 branch only. Applied on the branch.
2012-03-03 Eric Botcazou
PR target/52425
Backport from mainline
2011-05-22 Eric Botcazou
* config/sparc/sparc.c (sparc_delegitimize_address): Handle
UNSPEC_MOVE_PIC pattern
On Fri, Mar 2, 2012 at 6:59 PM, Mike Stump wrote:
> On Mar 2, 2012, at 1:33 AM, Richard Guenther wrote:
>>> Interestingly, the C++ frontend also has a pointer_diff function, but
>>> doesn't seem to attempt to optimize. Is there a reason for this?
>>
>> Frontends should not optimize when they are n
Tobias Burnus wrote:
thanks for the review.
Paul Richard Thomas wrote:
[...]
Something is odd. The test case didn't regtest, but I could swear that
it did so yesterday.
_1.f90: That was correctly failing because one cannot pass an
assumed-size array to an assumed-shape array.
_4.f90: Som
GNU Fortran warns by default for code like the following:
interface
subroutine sub (n) bind (C)
integer :: n
end subroutine sub
end interface
Namely, it prints:
Warning: Variable 'n' at (1) is a parameter to the BIND(C) procedure
'sub' but may not be C interoperable
That's on one h
The attached patch fixes PR 36160
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36160). It should correctly
account for wide characters when display error loci. I'm not sure if we can
check that in the testsuite harness, but you can manually see it at work on the
attached test.f90.
Bootstrapped
> Thus, this patch adds a warning flag for this purpose - and it also excludes
> those warnings from the default setting. That's a bit in line with Fortran
> 2008 and TS 29113, which remove more and more constraints and force the users
> to ensure themselves that the variables are interoperable.
On Sat, Mar 03, 2012 at 08:44:56AM +0100, FX wrote:
> PR 36044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36044) is an
> enhancement request for a way to display backtraces from user code. I'm
> against adding yet another nonstandard intrinsic for this purpose (which is
> how Intel Fortran doe
On Sat, Mar 03, 2012 at 10:53:24AM +0100, FX wrote:
> Hi all,
>
> Attached patch was triggered by PR 52313
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve
> error messages for module reading. It fixes one spelling of "GFORTRAN" -->
> "GNU Fortran" and improves the er
On Sat, Mar 3, 2012 at 11:53, FX wrote:
> Hi all,
>
> Attached patch was triggered by PR 52313
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52313), and tries to improve
> error messages for module reading. It fixes one spelling of "GFORTRAN" -->
> "GNU Fortran" and improves the error reportin
On Sat, Mar 03, 2012 at 03:23:01PM +0100, Tobias Burnus wrote:
> GNU Fortran warns by default for code like the following:
>
> interface
> subroutine sub (n) bind (C)
> integer :: n
> end subroutine sub
> end interface
>
> Namely, it prints:
>
> Warning: Variable 'n' at (1) is a paramet
On Sat, Mar 3, 2012 at 2:31 AM, Eric Botcazou wrote:
>> This patch adds Linux/x32 support to Ada. It sets LIBGNAT_TARGET_PAIRS
>> similar to Linux/x86-64 and replaces system-linux-x86_64.ads with
>> system-linux-x86.ads. It also adds "orl $0x0,(%esp)" check for SIGSEGV
>> probe and sets __gnat_d
Hi,
This patch backports x32 support to libtool:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5
OK to install?
Thanks.
H.J.
---
ommit 0d8c092cac25c3bce5dbfc1981b84df91b3f6086
Author: H.J. Lu
Date: Mon Dec 12 13:03:14 2011 -0800
Add x32
On 03/02/2012 10:11 AM, Richard Henderson wrote:
> I'm in the process of sanity testing this on x86_64 with trueval set to 0x80.
> Jakub, ok for 4.7 branch if it passes?
>
> * optabs.c (expand_atomic_test_and_set): Honor
> atomic_test_and_set_trueval even when atomic_test_and_set
>
Tobias Burnus wrote:
_3.f90: [...]
"fourteen" is really odd: Depending on the position of that subroutine
in file, I get an error or not. I think one should try to better
understand why that happens.
I found it with the help of Paul. The problem was that I set instead of
re-set the variable
On Sat, Mar 03, 2012 at 10:31:17AM -0800, Richard Henderson wrote:
> On 03/02/2012 10:11 AM, Richard Henderson wrote:
> > I'm in the process of sanity testing this on x86_64 with trueval set to
> > 0x80.
> > Jakub, ok for 4.7 branch if it passes?
> >
> > * optabs.c (expand_atomic_test_and_set
> What if the .mod file has been created by another compiler? Or do we have a
> separate error message for that?
For that, we get (only spelling was fixed by my patch, the message already
existed):
> Fatal Error: File 'foo.mod' opened at (1) is not a GNU Fortran module file
I committed the pat
> I think that this approach is a mistake. The patch
> starts us down a slippery slope. Why not export all
> the nonstandard intrinsics? In additions, the
> _gfortran_ prefix was used to separate the libgfortran
> namespace from userspace. Providing a means to
> circumvent this separation see
On Sat, Mar 3, 2012 at 23:02, FX wrote:
>> What if the .mod file has been created by another compiler? Or do we have a
>> separate error message for that?
>
> For that, we get (only spelling was fixed by my patch, the message already
> existed):
>
>> Fatal Error: File 'foo.mod' opened at (1) is
Hi,
This is the first one of the 3 tiny patches to fix the build failures
for sh64-elf.
stmt.c:lshift_cheap_p is testing the cost for (ashift (const1_rtx) (reg)).
SH doesn't such insns but returns COSTS_N_INSNS (1) as its cost for
SHmedia target. This results an unrecognized insn error for that
The attatched patch is to fix a thinko in sh_dwarf_register_span
which was found with a failure during sh64-elf build. Regtested
on sh4-unkonwn-linux-gnu.
Regards,
kaz
--
2012-03-03 Kaz Kojima
* config/sh/sh.c (sh_dwarf_register_span): Don't apply
DBX_REGISTER_NUMBER.
The attached patch is a one liner to fix another unrecognized
error when compiling libgcc on sh64-elf. We have no abssi2
insn for SHmedia ATM. Regtested on sh4-unkonwn-linux-gnu.
Regards,
kaz
--
2012-03-03 Kaz Kojima
* config/sh/sh.md (abssi2): Add TARGET_SH1 condition.
diff
On 01/23/2012 11:59 AM, Jason Merrill wrote:
The problem in this case was that a few places in the compiler were
assuming that when we have an OVERLOAD, all the functions within it come
from the same context. But that isn't the case when we have
using-declarations involved, so we need to take the
While thinking about core issue 1351, I noticed that we weren't dealing
very well with an NSDMI that depends on itself. This patch gives a
helpful error message.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 46131bcba27d82f43a26daa12a8c8e95f7208696
Author: Jason Merrill
Date: Mon Fe
The initializer-list paper did not allow brace elision for all
list-initialization, only for the traditional C aggregate
initialization. But extending it to all list-initialization has been
deemed desirable, so this patch implements that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit
Since we've decided not to mangle __is_empty and such, this patch
provides a more helpful error message.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit bdaa797823a9e45261cfe7a97e4f568decba790b
Author: Jason Merrill
Date: Thu Jan 12 12:42:07 2012 -0500
PR c++/36797
* mangle.c
And here's a hunk I held back from that patch to be conservative;
applying now that we're in stage 1. It should have no effect, but is
more consistent with other uses.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ed1e0f5a5dc43e87cfddbdca9adffd72e8c4719e
Author: Jason Merrill
Date:
34 matches
Mail list logo
