> Wouldn't you use these targets with --disable-target-libada
> --disable-gnattools?
Yes (or rather --disable-libada. I believe also disable-libada implies
--disable-gnattols), that's the primary use (manual debugging
is a secondary use).
Arno
LGTM
http://codereview.appspot.com/4862042/
On Tue, Aug 16, 2011 at 3:35 PM, Joseph S. Myers
wrote:
> On Tue, 16 Aug 2011, Sriraman Tallam wrote:
>
>> Index: libgcc/config/i386/t-cpuinfo
>> ===
>> --- libgcc/config/i386/t-cpuinfo (revision 0)
>> +++ libgcc/config/i386/t-cp
The standard says that if a template-id designates a single function,
that is used when we don't have sufficient type information to guide
deduction. But we were getting this wrong when passing to a variadic
parameter due to a simple logic error.
Tested x86_64-pc-linux-gnu, applying to trunk
I recently got a request to make attribute((used)) cause the implicit
instantiation of a member function of a class template whenever the
class is instantiated. This seemed like an appropriate extension of the
current semantics of that attribute, so this patch implements it.
Tested x86_64-pc-
I noticed an issue while reading the code the child referencing code more in
depth and wrote the following tests which exposes that issue.
We are loading every single header in the translation unit (not only the direct
children) when doing pph_in_includes, but the children themselves correctly
It is possible to run into a situation where we don't know what to do
with an initializer-list.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.6.
commit 1a54ca9d63f7e6453b3327a5699a39696f856a79
Author: Jason Merrill
Date: Mon Aug 15 06:15:17 2011 -0400
PR c++/50054
* typeck2.c
On Tue, 16 Aug 2011, Sriraman Tallam wrote:
> Index: libgcc/config/i386/t-cpuinfo
> ===
> --- libgcc/config/i386/t-cpuinfo (revision 0)
> +++ libgcc/config/i386/t-cpuinfo (revision 0)
> @@ -0,0 +1,2 @@
> +# This is an endfil
Mikael Morin wrote:
On Sunday 14 August 2011 09:35:56 Tobias Burnus wrote:
[Four examples which were still mishandled]
Hem, OK; it is a can of Pandora.
Sorry for opening it a bit more.
I can propose the following ad-hoc fix for the two latter cases.
The patch passes gfortran.dg/*goto* and
Jeff Law wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/16/11 15:35, grabekm90 wrote:
>
>> How to resolve a problem with pointers (especially arrays)? For
>> example, we have a GIMPLE function:
>>
>> set_a (int * a) { int * D.2701; D.2701 = a + 40; *D.2701 = 7; }
>>
>>
tmsri...@google.com (Sriraman Tallam) writes:
> Support for getting CPU type and feature information at run-time.
>
> The following patch provides support for finding the platform type at
> run-time, like cpu type and features supported. The multi-versioning
> framework will use the builtins add
Janus Weil wrote:
In any case, the patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK. Thanks for the patch!
Tobias
2011-08-16 Janus Weil
PR fortran/50070
* resolve.c (resolve_fl_variable): Reject non-constant character lengths
in COMMON variables.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/16/11 15:35, grabekm90 wrote:
> How to resolve a problem with pointers (especially arrays)? For
> example, we have a GIMPLE function:
>
> set_a (int * a) { int * D.2701; D.2701 = a + 40; *D.2701 = 7; }
>
> This is equivalent code in C:
>
> vo
Hi,
I work with a lot of code in C and Fortran.
My main task is to select, which of the function parameters and global
variables are input (they are only read out), output (they are only written
down) or inout (both uses) in the function. I wish GCC internals helped me.
Maybe you have better sol
On 08/16/2011 10:16 AM, Rainer Orth wrote:
Agreed. I'd prefer to first complete the build side of the migration
from gcc (mostly target headers left now, which seems to be somewhat
involved on first check), then deal with the libgcc-only macros, and
only then look into cleaning up the end result
Thanks for the report, HJ. And thanks for finding the problem Dominique
before I could even look at the PR. (I have no idea how the typo ended
up in my local patch file - it was clearly not present when I regtested
the patch.)
I have committed the attached patch as obvious - after regtesting.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ifcvt.c is sometimes over-aggressive in speculating instructions from a
not-predicted path.
Given:
if (test) goto E; // x not live
x = big();
goto L;
E:
x = b;
goto M;
ifcvt wants to turn it into:
On Tue, Aug 16, 2011 at 2:06 PM, H.J. Lu wrote:
> On Tue, Aug 16, 2011 at 1:50 PM, Sriraman Tallam wrote:
>> Support for getting CPU type and feature information at run-time.
>>
>> The following patch provides support for finding the platform type at
>> run-time, like cpu type and features suppo
On 08/16/2011 01:08 PM, Arnaud Charlet wrote:
Please post them.
OK, here they are. FWIW, I have no idea how these changes will play with
libada (in particular the stamp-tools handling), so I suspect these changes
may require a bit of adjustment to be suitable.
Wouldn't you use these targets wi
On 08/16/2011 11:31 AM, Marc Glisse wrote:
It might be less invasive to have decl_mangling_context return
global_namespace without actually modifying the expr?
Please.
Jason
On Tue, Aug 16, 2011 at 1:50 PM, Sriraman Tallam wrote:
> Support for getting CPU type and feature information at run-time.
>
> The following patch provides support for finding the platform type at
> run-time, like cpu type and features supported. The multi-versioning
> framework will use the bu
Support for getting CPU type and feature information at run-time.
The following patch provides support for finding the platform type at run-time,
like cpu type and features supported. The multi-versioning framework will use
the builtins added to dispatch the right function version. Please refer
On 08/16/2011 04:38 PM, Gabriel Charette wrote:
2011-08-16 Gabriel Charette
gcc/cp/ChangeLog.pph
* pph-streamer-in.c (pph_read_file_1): Set location of replayed
tokens to column 0 of the line the pph file was included on.
libcpp/ChangeLog.pph
* include/
This patch follows issue4907044.
Replayed definitions were given new source locations in the lexer. This would
shift all of the locations assigned later and since this replay is absent in
the non-pph, we get different source_locations for the tokens following the
replay in pph.
This improves t
On 08/16/2011 04:27 PM, Gabriel Charette wrote:
2011-08-16 Gabriel Charette
gcc/c-family/ChangeLog.pph
* c-opts.c (c_finish_options): Force BUILTINS_LOCATION for tokens
defined in cpp_init_builtins and c_cpp_builtins.
libcpp/ChangeLog.pph
* init.c (cpp_
This patch has yet to be committed to trunk, but I need it in pph.
This doesn't change anything (except that we now removed the built-in entry in
the line_table, so there are now only 2 ignored line table entries).
Tested with bootstrap and pph regression testing (full testing done with trunk
p
> Please post them.
OK, here they are. FWIW, I have no idea how these changes will play with
libada (in particular the stamp-tools handling), so I suspect these changes
may require a bit of adjustment to be suitable.
Arno
--- gcc-interface/Make-lang.in 2011-08-05 17:48:26.0 +0200
+++ gcc
After a lot of thinking and some experiments, I did not find a better
solution to considerably (like on 0.2% - 0.3% on ARM SPEC2000) improve
code size than use of non-regional RA for -Os.
So the patch makes one region allocation is default for -Os. I don't
use function optimize_function_for_s
> Sure, I was rather asking how make gnatlib (or whatever) is supposed to
> be invoked? From gcc/ada, any special needs?
>From /gcc typically.
> It would be good to contribute them, perhaps for close scrutiny by a
well, it's not a matter of contributing: it's more a matter of undoing what
was r
On 08/16/2011 09:53 AM, Rainer Orth wrote:
> actually makes some sense---so the general approach in your patch is good.
Indeed, but IMO it makes sense in general, not only for SPARC, but for
all targets that distinguish between -fpic and -fPIC.
> The patch is okay.
You mean as is, with all
On 08/16/2011 02:04 PM, Gabriel Charette wrote:
Setting *cache_ix to (unsigned) -1 used to be a "hack" (with a comment
explaining it which was removed just below), to avoid a warning about
it being unset in a branch, but that branch was only PPH_RECORD_END,
in which case it didn't matter.
Yeah
On 08/16/2011 09:44 AM, Rainer Orth wrote:
> So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not
> just via libada/Makefile is indeed important.
This seems to be easy: unless I'm mistaken, it should suffice to just
call GCC_PICFLAG in gcc/configure.ac and substitute the resul
On 08/16/2011 09:52 AM, Arnaud Charlet wrote:
> I've often had serious trouble when I tried to run make
> gnatlib/gnatlib-shared in gcc/ada.
Apparently "someone" in the past removed too many things from the Makefile
which broke partly this support (probably thinking that with libada/Makefile
Hello,
this implements two minor enhancements to code generated by the
spu_emit_branch_or_set routine.
This reduces code size for the g++.dg/opt/longbranch1.C to the
extent that it once again fits into local store, and thus fixes
the failure.
Tested on spu-elf.
Committed to mainline.
Bye,
Ulric
Hello,
since switching the frame growth direction on SPU to downward, the
displacements on stack addresses using an eliminable base registers
(e.g. frame_pointer_rtx) grow into the opposite direction from the
displacements that will be used in the final addresses which use
the real stack pointer r
I really like the way this is implemented! In particular having our
own cache is so great!
A few comments inline below.
Cheers,
Gab
On Mon, Aug 15, 2011 at 8:05 PM, Diego Novillo wrote:
> This patch finishes the support for external references to symbols in
> other PPH files.
>
> This is used w
On Thu, 11 Aug 2011, Terry Guo wrote:
> Thanks for your review. Here I attached the updated one. Is it ok to
> commit?
Yes, this looks good, Terry. Sorry for making you wait, I've been
off for a bit of an extended weekend. (In the future, "good modulo"
can be seen as approval already. :-)
Gera
Hi all,
here is a small patch for an ICE-on-invalid problem with COMMON and
character length. I was kinda surprised that we don't catch this
already. The fix is rather simple, but after the amount of discussion
(that I had with myself) in the PR, I probably cannot claim that it
was 'obvious' to me
"Joseph S. Myers" writes:
> On Mon, 15 Aug 2011, Rainer Orth wrote:
>
>> On top of the crtstuff and libgcc1 patches (and requiring the PICFLAG
>> centralization still under discussion), here's the bulk of the remaining
>> moves: it moves all LIBGCC2*, LIB2* macros and referenced files.
>>
>> Des
Hans-Peter Nilsson writes:
>> * Again, I noticed an unused target file,
>> config/cris/cris_abi_symbol.c. I assume it's a leftover from the
>> cris-aout port and can go.
>
> As obvious from its contents, yes, put it to rest if you please.
Ok, will do.
>> * config/cris/arit.c, config/c
Arnaud Charlet writes:
>> Ok, I see. Perhaps gcc/ada could be disentangled and those files
>> exclusively or primarily used for libgnat/libgnarl moved over to libada,
>> and referenced from there for the host build?
>
> That would require some delicate work on AdaCore's side, so wouldn't be
> he
Paolo Bonzini writes:
> On 08/15/2011 10:53 AM, Rainer Orth wrote:
>> * The general approach between libtool and libiberty differs. Unless
>>otherwise specified (PIC is the default or doesn't work for some
>>reason), libtool defaults to -fPIC, while libiberty has a strange
>>mixture
> Ok, I see. Perhaps gcc/ada could be disentangled and those files
> exclusively or primarily used for libgnat/libgnarl moved over to libada,
> and referenced from there for the host build?
That would require some delicate work on AdaCore's side, so wouldn't be
helpful in the short term (rather h
Steve,
> On Mon, 2011-08-15 at 19:53 +0200, Rainer Orth wrote:
>
>> * For IA64 HP-UX, there's a claim that -fPIC is necessary despite PIC
>> code being the default. I could find no hint in trunk that this is
>> true any longer.
>
> Rainer, If I recall correctly the issue for -fPIC on IA64 HP
Arnaud Charlet writes:
>> Yes, that needs to be done of course. I'm not sure if we still support
>> gnatlib_and_tools to build libada/gnattools. If so, we would need the
>> PICFLAG to be available somehow in the gcc Makefile (perhaps by providing
>> GCC_TARGET_PICFLAG in addition to GCC_PICFLAG
Paolo Bonzini writes:
> On 08/16/2011 04:59 AM, Rainer Orth wrote:
>> None of them uses any of those macros, so I think we're safe.
>
> Yes, I checked the same now. Looks like we're good.
Fine we've reached the same conclusion :-)
> I'll review the other patches soon, but they are _huge_! :)
Hans-Peter Nilsson writes:
>> From: Rainer Orth
>> Date: Mon, 15 Aug 2011 19:01:39 +0200
>
>> * Unlike any other target, cris has crisv32-*-none and cris-*-none
>> targets which seem to be aliases for their *-elf counterparts. Do we
>> really need to keep those? While I can inherit e.g. ex
On Tue, Aug 16, 2011 at 4:28 PM, Richard Guenther
wrote:
> On Mon, Aug 15, 2011 at 6:58 PM, Artem Shinkarov
> wrote:
>> On Mon, Aug 15, 2011 at 3:24 PM, Richard Guenther
>> wrote:
>>> On Fri, Aug 12, 2011 at 4:03 AM, Artem Shinkarov
>>> wrote:
Hi
Here is a completed version of th
On 15/08/11 10:28, Joey Ye wrote:
> gcc.c/torture/execute/20101011-1.c always fails on ARM, because
> it needs the target architecture trap in division by zero. It is
> implementation defined on ARM to trap division by zero. So this
> case should be skipped on ARM.
>
> There are two ways to ski
Hello,
this patch fixes for options -fopenmp and/or -ftree-parallelize-loops=
the binding to pthread-library.
ChangeLog
2011-08-16 Kai Tietz
* config/i386/mingw32.h (GOMP_SELF_SPEC): Add -pthread option.
Bootstrapped for x86_64-w64-mingw32 and i686-pc-mingw32. Applied at
revision 7
Marc,
>> * config/sol2-cxx.c
>
> You are missing a closing parenthesis in there, on the line with
> DECL_NAMESPACE_STD_P. I hadn't dared modify DECL_CONTEXT(decl) because I
drats, I had fixed that in my tree, but forgot to refresh the patch.
> was afraid of side effects.
>
> For instance, i
On Tue, 16 Aug 2011, Rainer Orth wrote:
thanks for the hint. This resulted in a far cleaner patch indeed.
Cool, thanks.
* config/sol2-cxx.c
You are missing a closing parenthesis in there, on the line with
DECL_NAMESPACE_STD_P. I hadn't dared modify DECL_CONTEXT(decl) because I
w
On Mon, Aug 15, 2011 at 6:58 PM, Artem Shinkarov
wrote:
> On Mon, Aug 15, 2011 at 3:24 PM, Richard Guenther
> wrote:
>> On Fri, Aug 12, 2011 at 4:03 AM, Artem Shinkarov
>> wrote:
>>> Hi
>>>
>>> Here is a completed version of the vector comparison patch we
>>> discussed a long time ago here:
>>>
Richard Guenther writes:
> This fixes PR50082 by completely defering to fold what kind of
> overflow warning to emit from tree-ssa-forwprop.c. It also moves
> overflow handling to the single place that decides whether and
> what we optimize.
>
> Bootstrapped and tested on x86_64-unknown-linux-gn
2011/8/16 Andreas Schwab :
> * ggc.h (ggc_alloc_rtvec_sized): Use ggc_alloc_zone_rtvec_def
> instead of ggc_alloc_zone_vec_rtvec_def.
Thanks again,
--
Laurynas
On Sunday 14 August 2011 09:35:56 Tobias Burnus wrote:
> I think the following is valid and it is still rejected (it is accepted
> by NAG 5.1 and ifort):
>
> 1 type t
> integer :: i
>end type t
>
>goto 1
> 1 print *, 'Hello'
> end
>
> Related but separate issue: BLOCK also starts a
Hi,
While looking at a failure with regrename and
mvectorize-with-neon-quad I noticed that the early-clobber in this
vec_pack_trunc pattern is superfluous given that we can use
reg_overlap_mentioned_p to decide in which order we want to emit these
2 instructions. While it works around the problem
Laurynas Biveinis writes:
> The patch to adjust the definition is obvious/pre-approved if anyone's
> inclined, or I'll just note in my TODO to fix this the next time I
> commit something.
Since I had it already readily tested on x86_64-linux, I've checked this
in.
Andreas.
2011-08-16 Andreas
2011/8/16 Richard Guenther :
>> ggc_alloc_zone_vec_rtvec_def is for allocating an array of rtvec_def,
>> but you want a single (variable sized) rtvec_def, so
>> ggc_alloc_zone_rtvec_def is the correct function to call.
>
> I'm not so sure about that given the more strongly typing of our allocators.
On 08/16/2011 04:59 AM, Rainer Orth wrote:
None of them uses any of those macros, so I think we're safe.
Yes, I checked the same now. Looks like we're good.
I'll review the other patches soon, but they are _huge_! :)
Paolo
Jason,
> On 08/11/2011 10:49 AM, Rainer Orth wrote:
>> There might be an alternative implementation that is less invasive to
>> the C++ frontend, though: add
>>
>> && TARGET_DECL_NAMESPACE_STD_P (decl)
>>
>> in write_unscoped_name, defaulting to true, override it in sol2.h (which
>> gets inc
This introduces a ptrofftype_p function to replace sizetype compatibility
checks throughout the compiler (of there are not too many).
Bootstrapped and tested on x86_64-unknonw-linux-gnu some time ago,
currently re-testing.
Patch 3/n will (finally) introduce "real" ptrofftype and uptrofftype.
Ri
> That's the simplest alternative. It would need however a pass through the
> config/ directory for targets that are never used as hosts for GCC (and
> thus libiberty).
>
> Alternatively, the libtool code could be extracted to config/picflag.m4.
>
>>Alternatively, one could think about using
Paolo,
> On 08/15/2011 02:05 PM, Joseph S. Myers wrote:
>>> > This patch almost completes the build side of the libgcc moves. It
>>> > moves the libgcc_tm_file support to libgcc/config.host (tm_file), where
>>> > it belongs. It builds on a patch Paolo posted some time ago, with some
>>> > mi
On Tue, Aug 16, 2011 at 1:17 PM, Andreas Schwab wrote:
> Liang Wang writes:
>
>> #define ggc_alloc_rtvec_sized(NELT) \
>> - (ggc_alloc_zone_vec_rtvec_def (sizeof (rtx), \
>> - sizeof (struct rtvec_def
This fixes PR50082 by completely defering to fold what kind of
overflow warning to emit from tree-ssa-forwprop.c. It also moves
overflow handling to the single place that decides whether and
what we optimize.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Ian, does this look ok?
Thanks,
Liang Wang writes:
> #define ggc_alloc_rtvec_sized(NELT) \
> -(ggc_alloc_zone_vec_rtvec_def (sizeof (rtx),\
> - sizeof (struct rtvec_def) + ((NELT) - 1),
> \
> +(ggc_alloc_zone_vec_rtvec_def (1
Ping.
BR,
Terry
> -Original Message-
> From: Terry Guo [mailto:terry@arm.com]
> Sent: Monday, August 15, 2011 4:07 PM
> To: 'Gerald Pfeifer'
> Cc: 'gcc-patches@gcc.gnu.org'; Richard Earnshaw; Matthew Gretton-Dann
> Subject: RE: [wwwdocs] Announce new ARM/embedded-4_6-branch branch
>
On Tue, Aug 16, 2011 at 11:35 AM, Liang Wang wrote:
> Current implementation of ggc_alloc_rtvec_resized allocates more
> spaces for rtvec. This patch uses original formula to compute size
> for rtvec. Bootstrap on x86_64 successfully.
>
> OK for trunk?
>
> By the way, I don't have write access t
On Tue, 16 Aug 2011, Ira Rosen wrote:
> The first part was already reviewed several months ago, but I am
> resubmitting it along with -mvectorize-with-neon-double documentation.
>
> OK to commit?
Looks good, thank you.
Gerald
Current implementation of ggc_alloc_rtvec_resized allocates more
spaces for rtvec. This patch uses original formula to compute size
for rtvec. Bootstrap on x86_64 successfully.
OK for trunk?
By the way, I don't have write access to SVN repository yet. Could
you please help commit it after appr
Hi,
The first part was already reviewed several months ago, but I am
resubmitting it along with -mvectorize-with-neon-double documentation.
OK to commit?
Thanks,
Ira
* htdocs/gcc-4.7/changes.html (targets): Document ARM NEON default
vector size change and -mvectorize-with-neon-double
Hi,
This patch changes the default vector size for auto-vectorization on
ARM NEON to 128 bits. This new version is a result of a discussion
with Richard and Ramana.
wwwdocs changes will follow shortly.
Bootstrapped and tested on arm-linux-gnueabi. The testsuite changes
were also checked on power
More VRP TLC, this restructures extract_range_from_binary_expr_1 a bit,
avoiding to glob unrelated tree codes to avoid some code duplication.
Instead factor out the common code.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-08-16 Richard Guenther
74 matches
Mail list logo
