On Wed, Aug 17, 2011 at 7:54 PM, Sriraman Tallam wrote:
> On Wed, Aug 17, 2011 at 12:37 AM, Richard Guenther
> wrote:
>> On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam
>> wrote:
>>> Support for getting CPU type and feature information at run-time.
>>>
>>> The following patch provides support
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00428.html
- adjust gthr-posix.h so that g++ -C -E works with STL headers
Jakub
On Wed, 17 Aug 2011, Eric Botcazou wrote:
> > I don't expect any issues, the patch is a noop right now (because
> > of that sign-extension of unsigned sizetype), but I'll leave it
> > until tomorrow for comments anyway.
> >
> > Thanks,
> > Richard.
> >
> > 2011-08-17 Richard Guenther
> >
> >
On Wed, 17 Aug 2011, Paolo Carlini wrote:
> Hi,
>
> I prepared the below basing on an hint provided by Joseph on the audit trail:
> essentially, I'm replacing all (but two) uses of abs_hwi outside hwint.c by
> absu_hwi, a variant which returns an unsigned HOST_WIDE_INT. All the
> replacements mak
On Mon, 8 Aug 2011, Sergey Kutserey wrote:
> Hopefully you can add this mirror into public mirror list for GCC project.
Thanks, Sergey. This is how I added your mirror to our list.
Gerald
Index: mirrors.html
===
RCS file: /cvs/gcc/
On Wed, Aug 17, 2011 at 8:51 PM, Artem Shinkarov
wrote:
> On Wed, Aug 17, 2011 at 4:28 PM, Artem Shinkarov
> wrote:
>> On Wed, Aug 17, 2011 at 3:58 PM, Richard Guenther
>> wrote:
>>> On Wed, Aug 17, 2011 at 3:30 PM, Artem Shinkarov
>>> wrote:
Hi
Several comments before the new ve
On Fri, 5 Aug 2011, Arnaud Charlet wrote:
> 2011-08-05 Ed Schonberg
>
> * exp_ch4.adb (Expand_N_Type_Conversion): When expanding a predicate
> check, indicate that the copy of the original node does not come from
> source, to prevent an infinite recursion of the expansion.
Fo
> > 2011-08-05 Ed Schonberg
> >
> > * exp_ch4.adb (Expand_N_Type_Conversion): When expanding a
> > predicate
> > check, indicate that the copy of the original node does not come from
> > source, to prevent an infinite recursion of the expansion.
>
> For ChangeLog entries we usu
On 8/18/2011 5:33 AM, Arnaud Charlet wrote:
2011-08-05 Ed Schonberg
* exp_ch4.adb (Expand_N_Type_Conversion): When expanding a
predicate
check, indicate that the copy of the original node does not come from
source, to prevent an infinite recursion of the expansio
The patch should be rather simple and self explaining.
Build and regtested on x86-64-linux.
OK for the trunk?
I wonder how far we should backport; the program is said to work in
4.1.2 and 4.2.5, but to fail in 4.3.6 up to the trunk. Oldest maintained
GCC is 4.4.6. The patch is relatively simpl
> Yes. I think the backends need to handle optimizing this case,
> esp. considering targets that do not have instructions to produce
> a {-1,...}/{0,...} bitmask from a comparison but produce a vector
> of condition codes. With using vec0 > vec1 ? {-1...} : {0,...} for
> mask = vec0 > vec1; we av
On Wed, Aug 17, 2011 at 10:52 PM, Joseph S. Myers
wrote:
> On Wed, 17 Aug 2011, Artem Shinkarov wrote:
>
>> +For the convenience condition in the vector conditional can be just a
>> +vector of signed integer type. In that case this vector is implicitly
>> +compared with vectors of zeroes. Consider
On 08/18/2011 11:59 AM, Tobias Burnus wrote:
The patch should be rather simple and self explaining.
I just realized that I forgot to add more context to the diff. Thus,
below the patch itself with some more lines (copied from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50109#c4).
Without, i
On Tue, 9 Aug 2011, Rainer Orth wrote:
This patch is the last but one in the series to finally fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
Only piece left before the switch :-)
* include/c_global/cmath (double abs(double)): Wrap in
!__CORRECT_ISO_
On 08/18/2011 10:30 AM, Richard Guenther wrote:
Ok.
Great. Thus I'm going ahead and committing the patch to fix the regression.
It looks like we might want to elimiate abs_hwi alltogether in favor
of absu_hwi?
Indeed, you are totally right. But I'd rather work on that as a followup
patch (may
Hi,
On Tue, 9 Aug 2011, Rainer Orth wrote:
This patch is the last but one in the series to finally fix
PR libstdc++-v3/1773__cplusplus defined to 1, should be 199711L
Only piece left before the switch :-)
* include/c_global/cmath (double abs(double)): Wrap in
!__CORRECT_ISO_CPP
On Thu, 18 Aug 2011, Paolo Carlini wrote:
> On 08/18/2011 10:30 AM, Richard Guenther wrote:
> > Ok.
> Great. Thus I'm going ahead and committing the patch to fix the regression.
> > It looks like we might want to elimiate abs_hwi alltogether in favor of
> > absu_hwi?
> Indeed, you are totally rig
This removes the fortunately unused tree_int_cst_msb with its
strange semantics
/* Note that using TYPE_PRECISION here is wrong. We care about the
actual bits, not the (arbitrary) range of the type. */
and "replaces" it by the existing tree_int_cst_sign_bit which has
the expected semant
On Thu, 18 Aug 2011, Paolo Carlini wrote:
Indeed. I would say let's not re-order for now, I'll have a further look
later on.
Is that a "ok" for Rainer or just part of the discussion?
* include/tr1/cmath (float fabs(float), long double fabs(long
double)): Wrap in !__CORRECT_ISO_CPP_MA
The following fixes a few places that think that using
host_integerp (t, 1) with t being a sizetype constant to
verify the value is "positive" is a good idea. sizetype
is an unsigned type (yes, still sign-extended), so
testing for a positive value is at least weird.
The patch below adds tree_int
The following fixes a typo I made.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-08-18 Richard Guenther
* expr.c (get_inner_reference): Fix typo in last change.
Index: expr.c
===
--- expr.
On 08/18/2011 01:37 PM, Marc Glisse wrote:
On Thu, 18 Aug 2011, Paolo Carlini wrote:
Indeed. I would say let's not re-order for now, I'll have a further
look later on.
Is that a "ok" for Rainer or just part of the discussion?
Sure. Actually the libstdc++ proper bits always were, I consider th
On Thu, 18 Aug 2011, Paolo Carlini wrote:
On 08/18/2011 01:37 PM, Marc Glisse wrote:
namespace std {
void f();
}
using std::f;
namespace std {
struct Complex{};
void f(Complex){}
}
//using std::f;
namespace std {
using ::f;
namespace tr1 {
On 08/18/2011 02:31 PM, Marc Glisse wrote:
I think the current patch is good enough for now (cool, I am reviewing
my own patch (improved by Rainer) ;-).
Eh, eh. Actually you should do it more often ;)
In the longer term, there is the usual idea that we could rename the
current cmath (just takin
Richard Guenther writes:
> On Mon, Aug 15, 2011 at 4:56 PM, Richard Sandiford
> wrote:
>> I'm about to post a patch that adds an extra parameter to rtx_cost.
>> Since most callers to rtx_cost are for SET_SRCs, it seemed a shame to
>> have to add an extra boiler-plate parameter to each of them. T
Following on from:
http://gcc.gnu.org/ml/gcc/2011-08/msg00306.html
this patch stops the ARM and Thumb-2 rtx costs from giving SETs a base
cost of COSTS_N_INSNS (4). In current trunk, the main effect is to stop
ivopts from being excessively conservative in the number of ivopts that
it creates
Hi,
On Thu, 18 Aug 2011, Richard Guenther wrote:
> > CPUID to get target features and set global vars corresponding to the
> > features. So, the builtin should be folded by into the appropriate
> > variable in libgcc.
>
> Hm, but then the variable should reside in libgcc and you'd only need an
Hello,
Two nits below...
On Thursday 18 August 2011 00:50:29 Tobias Burnus wrote:
> diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
> index 2910ab5..dc619c3 100644
> --- a/gcc/fortran/parse.c
> +++ b/gcc/fortran/parse.c
> @@ -2148,15 +2157,76 @@ endType:
[...]
> +
> +/* Check for F2008
On 18/08/11 14:03, Richard Sandiford wrote:
> Following on from:
>
> http://gcc.gnu.org/ml/gcc/2011-08/msg00306.html
>
> this patch stops the ARM and Thumb-2 rtx costs from giving SETs a base
> cost of COSTS_N_INSNS (4). In current trunk, the main effect is to stop
> ivopts from being excess
On Thursday 18 August 2011 11:59:36 Tobias Burnus wrote:
> The patch should be rather simple and self explaining.
It is indeed with the extra context.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
Yes.
>
> I wonder how far we should backport; the program is said to work in
> 4.1.
Ramana Radhakrishnan writes:
> On 17 August 2011 15:07, Joseph S. Myers wrote:
>> On Wed, 17 Aug 2011, Richard Sandiford wrote:
>>
>>> libgcc/
>>> PR target/50090
>>> * config/arm/bpabi-lib.h (RENAME_LIBRARY): Use a C-level alias
>>> instead of an assembly one.
>>
>> Is RENAME_L
Hi!
If gsi_stmt (*gsi) is a debug stmt, vect_finish_stmt_generation happily
copies over location from the debug stmt, instead of the following non-debug
stmt, which causes -fcompare-debug failures.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2011-08-18 Jak
On Thu, 18 Aug 2011, Artem Shinkarov wrote:
> >> + /* Avoid C_MAYBE_CONST in VEC_COND_EXPR. */
> >> + sc = c_fully_fold (ifexp, false, &maybe_const);
> >> + sc = save_expr (sc);
> >> + if (!maybe_const)
> >> + ifexp = c_wrap_maybe_const (sc, true);
> >> + else
> >> +
Hi!
If stack frame size is larger than 2GB, the MEMs returned by
assign_386_stack_local aren't necessarily valid MEMs. While we could do
validize_mem in all the assign_386_stack_local callers, it seems far easier
to do it just in one (well, two actually) spots.
Bootstrapped/regtested on x86_64-l
Hi!
For targetm.ms_bitfield_layout_p we ICE on DECL_PACKED flexible array
members, as they have NULL DECL_SIZE. We shouldn't adjust anything in that
case like we don't adjust anything for non-zero sized fields.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-08-18 Jak
On 11-08-18 10:00 , Jakub Jelinek wrote:
Hi!
If gsi_stmt (*gsi) is a debug stmt, vect_finish_stmt_generation happily
copies over location from the debug stmt, instead of the following non-debug
stmt, which causes -fcompare-debug failures.
Fixed thusly, bootstrapped/regtested on x86_64-linux and
Hi!
I'm getting
UNRESOLVED: decl_plugin.c compilation, -I. -I/usr/src/gcc/gcc/testsuite
-I/usr/src/gcc/gcc/testsuite/../../gcc
-I/usr/src/gcc/obj773/gcc/testsuite/g++/../../../gcc
-I/usr/src/gcc/gcc/testsuite/../../include
-I/usr/src/gcc/gcc/testsuite/../../libcpp/include
-I/usr/src/gcc/obj7
Richard, I am trying to make sure that when vcond has {-1} and {0} it
does not trigger masking. Currently I am doing this:
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 177665)
+++ config/i386/i386.c (working copy)
...well, for core instructions at least. NEON is a separate patch.
I haven't measured any benefit or regression from this change on its own.
It makes a difference with the new auto-inc-dec pass though.
I diffed the "before" and "after" assembly code for libav to get a sense
for whether the patch
On 08/18/2011 07:03 AM, Jakub Jelinek wrote:
> PR target/50092
> * config/i386/i386.c (assign_386_stack_local): Call validize_mem
> on the result before returning it.
>
> * gcc.dg/torture/pr50092.c: New test.
Ok.
r~
On Thu, Aug 18, 2011 at 4:06 PM, Jakub Jelinek wrote:
> Hi!
>
> For targetm.ms_bitfield_layout_p we ICE on DECL_PACKED flexible array
> members, as they have NULL DECL_SIZE. We shouldn't adjust anything in that
> case like we don't adjust anything for non-zero sized fields.
>
> Bootstrapped/regte
On 08/18/2011 02:23 AM, Richard Guenther wrote:
>>> >> The first one (inefficient) is vec0 > vec1 ? {-1,...} : {0,...}
>>> >> The second is vec0 > vec1. expand_vec_cond_expr is stupid, which is
>>> >> fine, but it means that we need to construct it carefully.
>> >
>> > This is still important.
> Ye
This is the NEON part of the patch to handle address register writeback
in the Cortex A8 and A9 schedulers. Although I can find no documentation
to say exactly how this is handled by the pipelines, a latency of 1
does seem to work well in practice, and is much easier to implement.
Tested in the s
The following patch fixes PR50107 which is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50107.
The problem was in typo in ira-color.c::ira_assign. This resulted in
wrong cost evaluations of multi-registers pseudos whose hard registers
only partially laid in caller-saved hard regis
16.08.2011, в 23:07, Vladimir Makarov написал(а):
> 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.
>
did you consider change of compile time becau
Jason,
> On 08/09/2011 09:14 AM, Marc Glisse wrote:
>> I don't think we should define the C++ 2011 value yet. In my opinion, we
>> should wait until:
>> 1) the standard is official
>> 2) gcc implements most of it: people will want to use __cplusplus as a
>> test to know if they can use C++0X featu
C1X has Unicode strings (u"", U"", u8"") but not raw strings. I've
applied this patch to enable the appropriate features in C1X mode.
C1X also has predefined macros __STDC_UTF_16__ and __STDC_UTF_32__ to
indicate that char16_t and char32_t really are UTF-16 and UTF-32
(which they always are with
On 08/18/2011 11:04 AM, Sergey Ostanevich wrote:
16.08.2011, в 23:07, Vladimir Makarov написал(а):
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.
di
On 08/18/2011 03:16 PM, Mikael Morin wrote:
OK with the two nits above fixed.
Thanks for the review and the making the wording less incomprehensible.
Committed as Rev. 177867.
The single-image coarray is slowly becoming feature complete; I only
have polymorphic coarrays and some fixes for d
Hi,
On Thu, 18 Aug 2011, Joseph S. Myers wrote:
> @@ -315,6 +315,10 @@ struct cpp_options
>/* Nonzero means process u/U prefix literals (UTF-16/32). */
>unsigned char uliterals;
>
> + /* Nonzero means process r/R rax strings. If this is set, uliterals
> + must be set as well. */
Here's a set of 8 tests which test the atomicity of all the >1 byte
__sync_mem routines. I didn't see the point of testing char for
atomicity. Maybe there isn't much point to short either, but maybe
there is some weird byte-load/store target out there now or later :-P
It doesn't hurt to hav
On Thu, 18 Aug 2011, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Aug 2011, Joseph S. Myers wrote:
>
> > @@ -315,6 +315,10 @@ struct cpp_options
> >/* Nonzero means process u/U prefix literals (UTF-16/32). */
> >unsigned char uliterals;
> >
> > + /* Nonzero means process r/R rax strings.
On Thu, Aug 18, 2011 at 03:37:44PM +0200, Mikael Morin wrote:
> On Thursday 18 August 2011 11:59:36 Tobias Burnus wrote:
> >
> > I wonder how far we should backport; the program is said to work in
> > 4.1.2 and 4.2.5, but to fail in 4.3.6 up to the trunk. Oldest maintained
> > GCC is 4.4.6. The pa
Hi Richard, Uros,
We are adding new ISAs, BM2 and AVX2, to x86 backend. We need to
extend ix86_isa_flags to 64bit. This is the last patch needed for
this. OK for trunk?
Thanks.
H.J.
2011-08-18 H.J. Lu
Igor Zamyatin
* config/i386/i386-c.c (ix86_target_macros_inte
On Thu, 18 Aug 2011, Marc Glisse wrote:
I think the current patch is good enough for now
Actually, could someone please append to this comment in tr1/cmath:
// Note: we deal with fabs in a special way, because an using std::fabs
// would bring in also the overloads for complex types, whic
On 08/18/2011 08:28 AM, H.J. Lu wrote:
> 2011-08-18 H.J. Lu
> Igor Zamyatin
>
> * config/i386/i386-c.c (ix86_target_macros_internal): Replace int
> with HOST_WIDE_INT for isa_flag.
> (ix86_pragma_target_parse): Replace int with HOST_WIDE_INT for
> isa variable
On Thu, Aug 18, 2011 at 6:10 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Aug 2011, Richard Guenther wrote:
>
>> > CPUID to get target features and set global vars corresponding to the
>> > features. So, the builtin should be folded by into the appropriate
>> > variable in libgcc.
>>
>> Hm, but th
Hi,
note that the same issue affects the legacy __gnu_cxx::copy_n by HP/SGI
but certainly I'm not going to change it now after so many years of
people relying on that "broken" behavior.
Tested x86_64-linux, committed.
Paolo.
///
2011-08-18 Paolo Carlini
Tom: ok for trunk?
fortran@: The fortran change just reflects the fix from libcpp,
fortran bootstrap and tests passed.
Thanks,
Gabriel
On Wed, Aug 17, 2011 at 1:04 PM, Dodji Seketeli wrote:
> Hello Gabriel,
>
> gch...@google.com (Gabriel Charette) a écrit:
>
>> Here is the updated patch.
>>
>>
Hi,
Actually, could someone please append to this comment in tr1/cmath:
// Note: we deal with fabs in a special way, because an using std::fabs
// would bring in also the overloads for complex types, which in C++0x
// mode have a different return type.
Something like:
// With __CORRECT
Mike Stump writes:
> On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote:
>> * git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is
>> required.
>
> Yes, it is.
Fine, thanks. I was just confused by the fact that it isn't currently
used to build the shared libgcc.
Rainer
--
The following patch fixes PR 49890. The details of the PR is described
on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49890.
The patch was successfully bootstrapped on x86-64 and ppc64.
Committed as rev 177874.
2011-08-18 Vladimir Makarov
PR rtl-optimization/49890
* ira-cos
On 08/18/2011 06:47 PM, Gabriel Charette wrote:
> Tom: ok for trunk?
>
> fortran@: The fortran change just reflects the fix from libcpp,
> fortran bootstrap and tests passed.
The Fortran change is OK.
Thanks for the patch!
Tobias
On 08/16/2011 02:37 AM, Gabriel Charette wrote:
Here is the upd
Paolo,
> 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 oka
Found while building our internal code base with -ftime-report. This
patch is against google/gcc-4_6, but the bug also exists in 4.7 and
gcc-4_6-branch.
OK for gcc-4_6-branch and trunk?
Tested on x86_64. Applied to google/gcc-4_6.
Diego.
* name-lookup.c (lookup_arg_dependent): Use c
> "Rainer" == Rainer Orth writes:
Jason> I'm of two minds about this, but I see that clang and edg still
Jason> use 199711L in C++0x mode, so let's stick with that for now.
Rainer> with the prerequisite patches now installed, here's the reworked version
Rainer> of the final patch.
Rainer> T
On Thu, Aug 18, 2011 at 1:03 AM, Richard Guenther
wrote:
> On Wed, Aug 17, 2011 at 7:54 PM, Sriraman Tallam wrote:
>> On Wed, Aug 17, 2011 at 12:37 AM, Richard Guenther
>> wrote:
>>> On Tue, Aug 16, 2011 at 10:50 PM, Sriraman Tallam
>>> wrote:
Support for getting CPU type and feature info
> "Tom" == Tom Tromey writes:
Tom> I'm finally getting back to this.
Tom> This patch adds test suite support for the libstdc++ pretty-printers.
Any comments on this?
I'd like to get it in; Phil found a bug in the std::tuple printer, and
it would be nice to put in a test case along with the
On Sun, Aug 7, 2011 at 10:47 AM, Richard Sandiford
wrote:
> This patch caused several regressions on big-endian 64-bit MIPS targets,
> which now try to shift single-precision floating-point arguments to
> the top of an FPR. The calls.c part...
I reported this as bug #50113 as it is breaking boot
OK.
Jason
Rainer, I know you're in the middle of libgcc2_extras, so I
don't want to commit something that conflicts and may well
be out-of-date any minute. But these c6x bits got missed
after the soft-fp move.
Please decide among you whether this patch should be applied
in the meantime, or whether it shoul
On 08/18/2011 04:18 PM, Jason Merrill wrote:
OK.
For trunk. The 4.6 branch looks very different.
Jason
On 11-08-18 16:18 , Jason Merrill wrote:
On 08/18/2011 04:18 PM, Jason Merrill wrote:
OK.
For trunk. The 4.6 branch looks very different.
Yes, I later realized that we had originally backported this timer patch
from trunk to google's 4.6 branch.
Thanks. Diego.
On 08/18/2011 10:25 AM, Sriraman Tallam wrote:
> Ok, so two things. I create the constructor as a comdat. So, it is
> created by gcc in every module but at link time only one copy will be
> kept. So, it is going to be called only once and that is not a
> problem.
Err, no. You'll wind up with one
Attached is a change to the harness to test with {-O[0123s] -g} as well
as corresponding changes to the tests themselves.
Tested by running "make check-gcc RUNTESTFLAGS=memmodel.exp" and
inspecting the logs manually.
Committed to branch.
* gcc.dg/memmodel/memmodel.exp: Torture with mo
C1X provides a standard way of declaring non-returning functions, with
the _Noreturn keyword and a header stdnoreturn.h defining a macro
"noreturn" to expand to _Noreturn. This patch implements this syntax
and header. Bootstrapped with no regressions on
x86_64-unknown-linux-gnu. Applied to mainl
On Thu, Aug 18, 2011 at 4:37 PM, Joseph S. Myers
wrote:
> The new keyword is C-only (C++0x has a different way of declaring
> non-returning functions) and I did not try to make the header do
> anything useful if included in C++ code.
I would suggest you don't define it all as macro when __cplusp
On 08/17/2011 02:17 PM, Anatoly Sokolov wrote:
> * doc/tm.texi.in (PREFERRED_OUTPUT_RELOAD_CLASS): Remove.
> * doc/tm.texi: Regenerate.
> * targhooks.c (default_preferred_output_reload_class): Don't use
> PREFERRED_OUTPUT_RELOAD_CLASS macro.
> * system.h (PRE
On 08/18/2011 11:15 AM, Joseph S. Myers wrote:
predefined by the compiler. (I'm presuming that difference from C1X
is still there in the approved version of C++0X, although it's
doubtful that C++ *should* differ from C1X in this way.)
Thanks, I've raised the issue.
Jason
On Thu, Aug 18, 2011 at 2:15 PM, Richard Henderson wrote:
> On 08/18/2011 10:25 AM, Sriraman Tallam wrote:
>> Ok, so two things. I create the constructor as a comdat. So, it is
>> created by gcc in every module but at link time only one copy will be
>> kept. So, it is going to be called only once
Committing version 1.
Added comment for pph_read_images and moved as requested.
See final patch attached.
Gab
2011-08-18 Gabriel Charette
gcc/cp/ChangeLog.pph
* pph-streamer-in.c (pph_reading_includes): New.
(pph_in_includes): Add logic to control pph_reading_include
On Aug 18, 2011, at 10:03 AM, Rainer Orth wrote:
> Mike Stump writes:
>
>> On Aug 15, 2011, at 10:53 AM, Rainer Orth wrote:
>>> * git libtool.m4 uses -fno-common on *-*-darwin. No idea if this is
>>> required.
>>
>> Yes, it is.
>
> Fine, thanks. I was just confused by the fact that it isn't c
On 08/17/2011 12:21 AM, Richard Guenther wrote:
> The patch itself looks sensible, though I am surprised ifcvt doesn't run in
> cfglayout mode (so you have to use reg notes to find probabilities ...)
It does run in cfglayout mode.
Jeff, I believe you're supposed to get the probabilities from some
C1X adds a constraint forbidding casts between pointers and floating-point
types (previously compile-time undefined). GCC already generates the
required diagnostics; I've applied this patch to add a testcase for them.
Index: gcc.dg/c1x-pointer-float-1.c
=
On 08/18/2011 02:51 PM, Sriraman Tallam wrote:
> Oh!, right, sorry. So, the only available option now is to mark it as
> a constructor in libgcc.
Or call it explicitly from the out-of-line tests.
The thing is, if you intend to use this from ifunc tests, I believe
that these can run *extremely* ea
On 08/17/2011 08:39 AM, Andrew MacLeod wrote:
> ! return __sync_mem_load (const_cast <__int_type *>(&_M_i), __m);
This suggests the builtin is incorrectly defined.
It ought to be const itself.
r~
As found by a c6x build failure, INSN_ANNULLED_BRANCH_P and RTL_CONST_CALL_P
both resolve to the same bit for CALL_INSNs. I want to fix this by
restricting INSN_ANNULLED_BRANCH_P to JUMP_INSNs, since annulling the slots
for a call or a plain insn doesn't really make sense.
The following has passe
On 08/16/2011 11:35 AM, Ulrich Weigand wrote:
> + /* Reload the displacement. */
> + push_reload (XEXP (ad, 1), NULL_RTX, &XEXP (ad, 1), NULL,
> +BASE_REG_CLASS, GET_MODE (ad), VOIDmode, 0, 0,
> +opnum, (enum reload_type) type);
Are you sure you want to
On Wednesday 17 August 2011 00:05:57 Tobias Burnus wrote:
> > I can propose the following ad-hoc fix for the two latter cases.
> >
> > The patch passes gfortran.dg/*goto* and gfortran.dg/*label*, and I'm
> > doing a full regression test. Is that OK?
>
> That's OK with test cases (original issue p
> Looking at the Ada case I believe this happens because
> Ada has negative DECL_FIELD_OFFSET values (but that's
> again in sizetype, not ssizetype)? Other host_integerp
> uses in Ada operate on sizes where I hope those are
> never negative ;)
Yes, the Ada compiler uses negative offsets for some
Before this patch the line_table was not identical to the non-pph line_table.
The child references patch just recently made this worst.
We had a design problem where we need to load the line_table entries for the
main file before the child's entries. However we need to load the bindings of
the
Hi, I had the problem with passing information about single variable
from expand_vec_cond_expr optab into ix86_expand_*_vcond.
I looked into it this problem for quite a while and found a solution.
Now the question if it could be done better.
First of all the problem:
If we represent any vector c
On 08/09/2011 10:31 AM, Dodji Seketeli wrote:
-#define in_system_header (in_system_header_at (input_location))
+#define in_system_header (in_system_header_at (input_location))
Unnecessary whitespace change.
struct GTY(()) cpp_macro {
+ /* Name of this macro. Used only for error reporting.
Hi,
Attached is a patch based on gcc-4.6.1 that wires-up missing ARM
iwmmxt intrinsics. Without it, gcc is completely useless when it comes
to using a large portion of the intrinsics documented on this page:
http://gcc.gnu.org/onlinedocs/gcc/ARM-iWMMXt-Built_002din-Functions.html
The patch is bas
On Fri, Aug 19, 2011 at 12:13 AM, Matt Turner wrote:
> Hi,
>
> Attached is a patch based on gcc-4.6.1 that wires-up missing ARM
> iwmmxt intrinsics. Without it, gcc is completely useless when it comes
> to using a large portion of the intrinsics documented on this page:
> http://gcc.gnu.org/online
At 2011-08-19 12:18:10,"Matt Turner" wrote:> Subject: Re:
>
> On Fri, Aug 19, 2011 at 12:13 AM, Matt Turner wrote:
> > Hi,
> >
> > Attached is a patch based on gcc-4.6.1 that wires-up missing ARM
> > iwmmxt intrinsics. Without it, gcc is completely useless when it comes
> > to using a large por
96 matches
Mail list logo
