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 reviewed
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 kti...@redhat.com
*
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 when
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
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/x32
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;
- else if
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',
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 ebotca...@adacore.com
PR target/52425
Backport from mainline
2011-05-22 Eric Botcazou ebotca...@adacore.com
* config/sparc/sparc.c
On Fri, Mar 2, 2012 at 6:59 PM, Mike Stump mikest...@comcast.net 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
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:
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
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.
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 does
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 error
On Sat, Mar 3, 2012 at 11:53, FX fxcoud...@gmail.com 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
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 parameter to the
On Sat, Mar 3, 2012 at 2:31 AM, Eric Botcazou ebotca...@adacore.com 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
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 hjl.to...@gmail.com
Date: Mon Dec 12 13:03:14
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): Honor
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 patch
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 seems to
On Sat, Mar 3, 2012 at 23:02, FX fxcoud...@gmail.com 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
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 kkoj...@gcc.gnu.org
* config/sh/sh.c (sh_dwarf_register_span): Don't apply
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 kkoj...@gcc.gnu.org
* config/sh/sh.md (abssi2): Add
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
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
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 ja...@redhat.com
Date: Thu Jan 12 12:42:07 2012 -0500
PR
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
34 matches
Mail list logo
