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 b1d35a4f5c4b4f0ae6f
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 PR476
Basile Starynkevitch writes:
> I think that we might also want to have some easy & documented way to build
> the stage1
> directly with g++, assuming (or when) it is already available.
We already do: configure with --enable-build-with-cxx.
Ian
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. Set and substitute
>> POSTSTAGE1_CONFIGURE_FLAGS.
>>
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 ru
On Sat, Jul 16, 2011 at 6:47 PM, H.J. Lu 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 done si
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.
Sorry
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[]"
while "scalar" itself is
Tobias Burnus 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 not be har
On Fri, Jul 15, 2011 at 10:18 AM, H.J. Lu wrote:
> On Fri, Jul 15, 2011 at 9:09 AM, Uros Bizjak wrote:
>> On Fri, Jul 15, 2011 at 6:07 PM, H.J. Lu wrote:
>>
>> If the first form of the address is not OK (it does not represent the
>> hardware operation), then it should not enter into the
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 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
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?
Tobias
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. Set and substitute
> POSTSTAGE1_CONFIGURE_FLAGS.
> * Makefile.tpl (POSTSTAGE1_CONFI
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 coara
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 routines
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, SCALE
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
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.
diagn
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 against
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 wit
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 te
On Fri, 15 Jul 2011, Laurynas Biveinis wrote:
> 2011/7/6 Basile Starynkevitch :
>> * 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.
And a full
On Thu, Jul 14, 2011 at 11:44 PM, Eric Botcazou 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. Now this isn't
>
On Thu, Jul 14, 2011 at 11:43 PM, Eric Botcazou 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
>
> Bootstrapped/regtested on i
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
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*
htt
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 --
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-m
On Sat, 16 Jul 2011 00:04:58 -0700
Ian Lance Taylor wrote:
> Andrew Pinski writes:
>
> > On Fri, Jul 15, 2011 at 11:52 PM, 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 u
Andrew Pinski writes:
> On Fri, Jul 15, 2011 at 11:52 PM, 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 bu
31 matches
Mail list logo
