On 2012/7/13 09:28 AM, Mike Stump wrote:
On Jul 11, 2012, at 11:52 PM, Chung-Lin Tang wrote:
Core parts adding the new hooks. BUILT_IN_THREAD_POINTER and
BUILT_IN_SET_THREAD_POINTER are different hooks, as some targets only
implement one of them (thread pointer read).
sorry seems a little
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
if (RTL_CONST_OR_PURE_CALL_P (insn))
/* Pure functions can read from memory. Const functions can
read from arguments that the ABI has forced
On 2012/7/13 02:37 AM, Richard Sandiford wrote:
+void
+default_expand_builtin_set_thread_pointer (rtx val ATTRIBUTE_UNUSED)
+{
+ sorry (__builtin_set_thread_pointer() not available for this target);
+}
Function names should be quoted by % %. But maybe we can save the
translators some
On 2012/7/13 02:45 AM, Richard Sandiford wrote:
/* Implement TARGET_EXPAND_BUILTIN_THREAD_POINTER. */
static rtx
mips_expand_builtin_thread_pointer (rtx tp)
{
rtx fn;
if (TARGET_MIPS16)
...
}
(i.e. always using the passed-in tp, which is safe with your 1/6 patch),
then
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote:
I'd suggest:
1. Remove this unittest for now.
And revert the patch for now.
2. Integrate locus with block, and store them as an index. (This will
incur big operation to GCC)
I'm not sure what you mean with integrate...?
A
On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
if (RTL_CONST_OR_PURE_CALL_P (insn))
/* Pure functions can read from
On 11 Jul 2012, at 00:01, Iain Sandoe wrote:
Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed
patch causes no regressions.
ppc-darwin 8 tests are still running, but it bootstrapped (500M G4, 24hrs
for c/c++ build test).
FAOD, from a testing perspective this is
On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote:
I'd suggest:
1. Remove this unittest for now.
And revert the patch for now.
2. Integrate locus with block, and store them as an index. (This
On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Sandiford rsand...@nildram.co.uk
Date: Thu, 12 Jul 2012 21:18:54 +0200
if (CALL_P (insn))
{
On Fri, Jul 13, 2012 at 9:36 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Btw, we discussed this briefly on the summit with Dodji and libcpp
virtual locations already provide a way to associate a location_t with
something else resulting in a new location_t. For inlining we simply
Hi Mikael, dear all,
On 07/05/2012 03:51 PM, Mikael Morin wrote:
I think the assumed-rank = rank == -1 convention should be
documented in gfortran.h, at least for the gfc_array_spec::rank field.
Okay. (Done in my version, which is not yet attached.)
@@ -2990,6 +3008,15 @@ gfc_procedure_use
Richard Sandiford rsand...@nildram.co.uk writes:
Function names should be quoted by % %. But maybe we can save the
translators some work and use:
sorry (%qs is not available for this target,
__builtin_thread_pointer());
...
sorry (%qs is not available for this target,
On 12/07/12 14:04, Kenneth Zadeck wrote:
you are on the right track with the example but combine will not get
this unless everything is in the same bb.
the whole point of having a separate pass for doing extension
elimination is that it needs to be done over the entire function.
There is
From: Richard Guenther richard.guent...@gmail.com
Date: Fri, 13 Jul 2012 09:37:13 +0200
On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com
wrote:
On Fri, Jul 13, 2012 at 8:47 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Sandiford
On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Guenther richard.guent...@gmail.com
Date: Fri, 13 Jul 2012 09:37:13 +0200
On Fri, Jul 13, 2012 at 9:21 AM, Steven Bosscher stevenb@gmail.com
wrote:
On Fri, Jul 13, 2012 at 8:47 AM,
A patch that's in my local tree for quite some time. This removes
redundant tests.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
* gimple.c (gimple_types_compatible_p_1): Remove redundant
type
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote:
This patch adds __int256 to the front-ends.
We have another patch underway to do N-bit constant ints, where N is defined
by the port. This patch is in the process
From: Richard Guenther richard.guent...@gmail.com
Date: Fri, 13 Jul 2012 10:08:05 +0200
On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
Ok for 4.7 too?
Of course.
Committed to trunk as follows, including the test-case which
doesn't fail on trunk but
On Fri, Jul 13, 2012 at 10:34 AM, Mike Stump mikest...@comcast.net wrote:
On Jul 13, 2012, at 12:33 AM, Richard Guenther wrote:
On Fri, Jul 13, 2012 at 3:59 AM, Mike Stump mikest...@comcast.net wrote:
This patch adds __int256 to the front-ends.
We have another patch underway to do N-bit
On Fri, Jul 13, 2012 at 9:50 AM, Steven Bosscher stevenb@gmail.com wrote:
On Fri, Jul 13, 2012 at 9:36 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Btw, we discussed this briefly on the summit with Dodji and libcpp
virtual locations already provide a way to associate a location_t
Hi,
thanks to Jason's work on DR 1402, fixing in mainline and branch this
library/ABI issue is now trivial. Tested x86_64-linux.
Thanks,
Paolo.
/
2012-07-13 Paolo Carlini paolo.carl...@oracle.com
PR libstdc++/53657
* include/bits/stl_pair.h
We fail to handle constant addresses in get_pointer_alignment_1
so we use too pessimistic alignment when accessing a packed
structure via such a pointer.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
PR
On Fri, Jul 13, 2012 at 3:36 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com
wrote:
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen de...@google.com wrote:
I'd suggest:
1. Remove this unittest for now.
And
On Fri, Jul 13, 2012 at 11:41 AM, Dehao Chen de...@google.com wrote:
On Fri, Jul 13, 2012 at 3:36 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jul 13, 2012 at 9:18 AM, Steven Bosscher stevenb@gmail.com
wrote:
On Fri, Jul 13, 2012 at 3:36 AM, Dehao Chen
Hi Richard,
This patch adds scheduling support for the NetLogic XLP, including a new
pipeline description, and associated changes.
Asides from the new xlp.md description file, there are also some sync
primitive attribute modifications, for better scheduling of sync loops
(Maxim should be able to
This fixes PR53922 - we failed to handle don't know return
from value_inside_range inside range_includes_zero_p. Fixed
and re-structured the code to not have the strage range/anti-range
issue.
Bootstrapped and tested on x86_64-unknown-linxu-gnu, applied.
Richard.
2012-07-13 Richard Guenther
it really is not.
the problem is that sign extension removal is just a more difficult
problem than what you are considering. You have attacked a small part
of the problem and have a good start but you really should consider the
whole problem.
kenny
On 07/13/2012 03:53 AM, Tom de Vries
I think the comment at the start of the file is wrong, since
it speaks about varpool_finalize_variable, but there's no such
function (not even mentioned in CLs). I'd say the author meant
varpool_finalize_decl.
2012-07-13 Marek Polacek pola...@redhat.com
* cgraphunit.c: Rename
2012/6/30 Georg-Johann Lay g...@gcc.gnu.org:
Is there a special reason to restrict it to SYMBOL_REF?
Doesn't the same issue occur with, e.g.
(const (plus (symbol_ref const_int))) or label_ref?
Hi!
We have added splits for symbol_ref plus const and label_ref. With
this patch, assembly code and
If one writes p - ((intptr_t)p % align) to align a pointer we neither
produce optimal code for the aligning nor can we track the alignment
for the resulting pointer from within CCP. The following makes
sure we transform the above to p ~align instead.
Bootstrapped and tested on
Recognized as memset, fixed.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
* libmudflap.c/fail11-frag.c: Adjust to not look like memset.
* libmudflap.c/fail12-frag.c: Likewise.
Index:
It appears that mudflap tries to run its test without optimization
as well by doing
set MUDFLAP_FLAGS [list {} {-static} {-O2} {-O3}]
but it does not consider options pre-pended on each commandline
which includes -O2. So we happen to run the {-O2} test twice
and the {} test is useless.
Fixed
On Fri, 13 Jul 2012, Mike Stump wrote:
As I said, in Kenny's next patch, we add support for all constants of
any size the port needs. I don't know if you've ever tried to use the
compiler with OImode, but, what I can say is the bugs are not terribly
latent at times and they are not hidden
Hi,
this is a rebase of RTH's patch posted a few years ago. It is almost
unchanged, except that there is no SEH specific unwind.h header (there are 3
#if/#endif part in unwind-generic.h) and a minor cleanup in unwind-seh.c
(indentation, unused variables).
This patch allows to propagate GCC
On Thu, Jul 12, 2012 at 9:21 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Jul 11, 2012 at 9:39 PM, Steven Bosscher stevenb@gmail.com
wrote:
Hello,
GCC calls free_after_parsing in rest_of_clean_state.
That's way too late, it can be done in free_lang_data_in_cgraph
On 07/10/2012 02:04 AM, Jason Merrill wrote:
Apparently we need to implement DR 1402 in 4.7 in order to fix the
std::pair ABI breakage properly. So here it is: if overload resolution
chooses a non-trivial copy constructor, instead of causing the move
constructor to be deleted, we just don't
Mike Stump wrote:
This patch adds __int256 to the front-ends. We follow the __int128 code
fairly closely...
So, an outstanding question would be, how do I get the mangle codes
allocated for the type? I just choose two unused codes, for now. All in
all, the patch was pretty straight
On Jul 13, 2012, at 1:57 AM, Richard Guenther wrote:
I have put the patch through the C test suite, and it doesn't show any
failures.
Do you have any examples of bugs that are _introduced_ by my patch? I'd be
happy to fix any that arise.
No. Just you expose the users to those bugs by
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE (OI, 32);
./spu/spu-modes.def:29:INT_MODE (OI, 32);
Hi. ping [for the libiberty part]
[The gdb part needs to be updated due to recent changes there, but I'm
going to wait until the libiberty part is approved.]
On Mon, Jul 9, 2012 at 11:10 AM, Doug Evans d...@google.com wrote:
Hi.
filename_seen in gdb does a linear search, this patch changes
I think it's confusing to have filename_cmp and filename_eq that do
basically the same thing. Perhaps filename_eq should be
filename_cmp_v or filename_cmp_hash or something, to indicate that
it's *supposed* to be the same functionality as filename_cmp but with
a different signature?
Hello,
Geoff had to make asm_out_file read-write for PCH [1], because at the
time it was necessary to read back anything written to asm_out_file
and store it in the PCH. This didn't work on mingw32 so Danny Smith
made the file binary [2] with the b modifier (but according to 'man
fopen', only for
I'm sorry recent weeks I've got busy
No problem. I am sorry to reply this late to your message as well.
Later is the response from previous mail.
Please do not take this bad, but it will really ease communication (and
the review) if, when you reply to this message, you write your answers
On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie d...@redhat.com wrote:
I think it's confusing to have filename_cmp and filename_eq that do
basically the same thing. Perhaps filename_eq should be
filename_cmp_v or filename_cmp_hash or something, to indicate that
it's *supposed* to be the same
If there's precedent, I'm not worried about it.
Ok to check in.
Date: Fri, 13 Jul 2012 12:36:44 -0700
From: Doug Evans d...@google.com
Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org
On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie d...@redhat.com wrote:
I think it's confusing to have filename_cmp and filename_eq that do
basically the same
On Fri, 13 Jul 2012, Georg-Johann Lay wrote:
The avr port defines __int24 and __uint24.
Is that compatible with a generic __int24?
In my view, given suitable generic support ports like that should move to
__intN keywords (usable with unsigned, so unsigned __intN would be the
unsigned version
On Fri, Jul 13, 2012 at 10:56 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
From: Richard Guenther richard.guent...@gmail.com
Date: Fri, 13 Jul 2012 10:08:05 +0200
On Fri, Jul 13, 2012 at 9:59 AM, Hans-Peter Nilsson
hans-peter.nils...@axis.com wrote:
Ok for 4.7 too?
Of course.
Configure with --disable-build-poststage1-with-cxx exposed functions
that should have been marked static. Bootstrapped on
powerpc-unknown-linux-gnu, committed as obvious.
Thanks,
Bill
2012-07-13 Bill Schmidt wschm...@linux.ibm.com
PR bootstrap/53955
* config/spu/spu.c
On Jul 13, 2012, at 6:39 AM, Joseph S. Myers wrote:
On Fri, 13 Jul 2012, Mike Stump wrote:
As I said, in Kenny's next patch, we add support for all constants of
any size the port needs. I don't know if you've ever tried to use the
compiler with OImode, but, what I can say is the bugs are
On Jul 13, 2012, at 9:20 AM, Georg-Johann Lay wrote:
We have another patch underway to do N-bit constant ints, where N is defined
by the port. This patch is in the process of being reviewed now, and Kenny
should be able to submit it shortly.
The avr port defines __int24 and __uint24.
Is
On Jul 13, 2012, at 11:21 AM, Nathan Froyd wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE (OI, 32);
./spu/spu-modes.def:29:INT_MODE (OI, 32);
On Fri, 13 Jul 2012, Mike Stump wrote:
I understand the beauty of putting in the const wide int stuff first...
I don't think it matters much to me... but I might ask why? I think we
have added support for all in-tree gcc ports for all possible testcases.
Do you know of a single
On Jul 13, 2012, at 12:28 AM, Iain Sandoe wrote:
On 11 Jul 2012, at 00:01, Iain Sandoe wrote:
Anyway, although i686-Darwin 8 is sadly in need of some TLC, the proposed
patch causes no regressions.
ppc-darwin 8 tests are still running, but it bootstrapped (500M G4, 24hrs
for c/c++ build
On Jul 12, 2012, at 11:47 PM, Chung-Lin Tang clt...@codesourcery.com wrote:
and then for the return value, maybe a const0_rtx for Pmode.
A little unsure what you mean. Are you referring to return const0_rtx
for default_expand_builtin_thread_pointer() instead of NULL?
Yes. NULL has the
On Fri, Jul 13, 2012 at 1:11 AM, Richard Guenther rguent...@suse.de wrote:
A patch that's in my local tree for quite some time. This removes
redundant tests.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-13 Richard Guenther rguent...@suse.de
On Jul 13, 2012, at 11:28 AM, Steven Bosscher wrote:
On Fri, Jul 13, 2012 at 8:21 PM, Nathan Froyd froy...@mozilla.com wrote:
On Fri, Jul 13, 2012 at 10:36:35AM -0700, Mike Stump wrote:
I just checked all in tree gcc targets, and none claim OImode support.
./s390/s390-modes.def:23:INT_MODE
On Jul 13, 2012, at 4:21 PM, Joseph S. Myers wrote:
On Fri, 13 Jul 2012, Mike Stump wrote:
I understand the beauty of putting in the const wide int stuff first...
I don't think it matters much to me... but I might ask why? I think we
have added support for all in-tree gcc ports for all
58 matches
Mail list logo
