* Matthias Klose wrote on Sat, Jul 09, 2011 at 05:37:46PM CEST:
On 07/07/2011 10:35 PM, Ralf Wildenhues wrote:
On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote:
On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote:
+AC_PROG_LIBTOOL
This tests the wrong compiler
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1. This means that the gcc installed and used by most people will
be built
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
Andrew Pinski pins...@gmail.com writes:
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2
On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor i...@google.com wrote:
Andrew Pinski pins...@gmail.com writes:
On Fri, Jul 15, 2011 at 11:52 PM, Ian Lance Taylor i...@google.com wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch
gch...@google.com (Gabriel Charette) writes:
+ set expectedSum [exec tr -d \} [exec cut -f 4 -d\
$xdiff_entry]]
+ set actualSum [exec cut -f 1 -d\ [exec sum $diff_result]]
You don't need cut and tr if you have tcl.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
On 07/15/2011 09:29 PM, Jason Merrill wrote:
On 07/13/2011 04:28 PM, Jason Merrill wrote:
I'm using --tool_opts to pass the extra -std=c++0x argument to the
compiler. Previously in my own testing I've used
--target_board=unix/-std=c++0x, but that is problematic because options
from
Sorry for pinging again, but the patch is large enough to block a bit my
progress ...
Other pending patches - which should be quickly reviewable::
- http://gcc.gnu.org/ml/fortran/2011-07/msg00170.html
- http://gcc.gnu.org/ml/fortran/2011-07/msg00142.html
Tobias
Tobias Burnus wrote:
*ping*
Right, here is the new version of the patch (with the correct files).
I added, a function register_pre_genericize_hook in
melt/warmelt-base.melt to be called when we want to register a MELT
function to handle the callback, so we don't manually set
sysdata_pre_genericize field.
Pierre Vittet
On Thu, Jul 14, 2011 at 11:43 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this is the ICE at -O2 on ACATS c34005a introduced on the 4.6 branch by
Martin's latest SRA patch. But it's actually the same PRE issue as:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02210.html
On Thu, Jul 14, 2011 at 11:44 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
this is a regression present on mainline and 4.6 branch. The compiler crashes
during gimplification because there is a COMPOUND_EXPR shared between the
TYPE_SIZE and TYPE_SIZE_UNIT expressions of an array type.
On Fri, 15 Jul 2011, Laurynas Biveinis wrote:
2011/7/6 Basile Starynkevitch bas...@starynkevitch.net:
* doc/plugins.texi (Building GCC plugins): gengtype needs its
gtype.state
Replace than in the patch with as.
I assume it passes make info?
OK with that change, thank you.
On Monday 11 July 2011 09:49:20 Tobias Burnus wrote:
On 07/10/2011 09:56 PM, Tobias Burnus wrote:
This patch implemented the trans*.c part of allocatable scalar
coarrays; contrary to noncoarray allocatable scalars, they have
cobounds and thus use an array descriptor.
I found a test case
Hello,
This is an update of the patch set that I initially posted to
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00858.html.
The main goals achieved by this set are the following:
- Decrease the overall memory consumption. On the tests I have done
on a reasonably big C++ program compiled
This patch adds -fdebug-cpp option. When used with -E this dumps the
relevant macro map before every single token. This clutters the output
a lot but has proved to be invaluable in tracking some bugs during the
development of the virtual location support.
Tested on x86_64-unknown-linux-gnu
In this third instalment the diagnostic machinery -- when faced with
the virtual location of a token resulting from macro expansion -- uses
the new linemap APIs to unwind the stack of macro expansions that led
to that token and emits a [hopefully] more useful message than what we
have today.
This patch basically arranges for the allocation size of line_map
buffers to be as close as possible to a power of two. This
*significantly* decreases peak memory consumption as (macro) maps are
numerous and stay live during all the compilation.
Ideally, I'd prefer some parts of this patch to be
This patch adds statistics about line maps' memory consumption and
macro expansion to the output of -fmem-report. It has been useful in
trying to reduce the memory consumption of the macro maps support.
Tested on x86_64-unknown-linux-gnu against trunk.
gcc/
* input.c (ONE_K, ONE_M,
This patch leverages the virtual location infrastructure to avoid
emitting pedantic warnings related to macros defined in system headers
but expanded in normal TUs.
The point is to make diagnostic routines use virtual locations of
tokens instead of their spelling locations. The diagnostic
Mikael Morin wrote:
let me understand one thing about coarray scalars: despite their name, they
are arrays, right?
Yes and no. In terms of the language, they are scalars - but they have a
codimension, e.g.
integer, save :: A[4:6, 7:*]
is a scalar variable on each image, but it has a
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote:
2011-07-15 Ian Lance Taylor i...@google.com
* configure.ac: Add --enable-build-poststage1-with-cxx. If set,
make C++ a boot_language. Set and substitute
POSTSTAGE1_CONFIGURE_FLAGS.
*
Dodji Seketeli wrote:
Support -fdebug-cpp option
Regarding Fortran: I think having a full support for the macro expansion
would be quite a lot of work, but I think -fdebug-cpp comes for free as
it is handled by libcpp.
Thus, how about adding support for that flag also to Fortran?
On Sat, Jul 16, 2011 at 05:25:36PM +0200, Tobias Burnus wrote:
PS: I should document somewhere how coarrays are implemented internally.
gcc/gcc4x/gcc/fortran/gfc-internals.texi
:-)
--
Steve
On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote:
Mikael Morin wrote:
let me understand one thing about coarray scalars: despite their name,
they are arrays, right?
Yes and no. In terms of the language, they are scalars - but they have a
codimension, e.g.
integer, save ::
On Fri, Jul 15, 2011 at 10:18 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu hjl.to...@gmail.com wrote:
If the first form of the address is not OK (it does not represent the
hardware
Tobias Burnus bur...@net-b.de a écrit:
Dodji Seketeli wrote:
Support -fdebug-cpp option
Regarding Fortran: I think having a full support for the macro
expansion would be quite a lot of work,
I know nothing about Fortran, but I would hope that adding support for
this feature to it should
On 07/16/2011 06:43 PM, Mikael Morin wrote:
Well, the current implementation supports effectively only a single
image - for -fcoarray=single on purpose and for -fcoarray=lib because it
has not yet been implemented.
Later, one has to add some function call for scalar[image_numer]
while scalar
Mikael Morin wrote:
On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote:
integer, save :: A[4:6, 7:*]
is a scalar variable on each image, but it has a coarank of 2 with
lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7.
ucobound(A, dim=1) == 6 ? Otherwise I'm even more confused.
On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu hjl.to...@gmail.com wrote:
Yes, this is an example from PR I am referring to. Did you try to
define LEGITIMIZE_RELOAD_ADDRESS? It is supposed to fix this.
They make things even more complex. ix86_simplify_base_index_disp
is called after reload is
On 07/16/2011 08:52 AM, Ian Lance Taylor wrote:
I would like to propose this patch as a step toward building gcc using a
C++ compiler. This patch builds stage1 with the C compiler as usual,
and defaults to building stages 2 and 3 with a C++ compiler built during
stage 1.
I just completed a
Diego Novillo dnovi...@google.com writes:
On Sat, Jul 16, 2011 at 02:52, Ian Lance Taylor i...@google.com wrote:
2011-07-15 Ian Lance Taylor i...@google.com
* configure.ac: Add --enable-build-poststage1-with-cxx. If set,
make C++ a boot_language. Set and substitute
On 07/07/2011 08:07 PM, Sebastian Pop wrote:
Hi,
Hi Sebastian,
sorry for taking so long. Here some comments from me:
First there are two cleanup patches independent of the fix:
Start counting nesting level from 0.
Do not compute twice type, lb, and ub.
Then the patch that fixes
On 07/16/2011 04:39 AM, Matthias Klose wrote:
The change to the toplevel Makefile.in was made in the generated file.
Oops, I was forgetting about the new Makefile system. This patch fixes
that, and also adds a check-target-libmudflap-c++ target to check-c++.
Jason
commit
33 matches
Mail list logo
