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
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
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 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, 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
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
> 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
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
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
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/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~
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
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/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
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
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 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
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 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 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
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
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
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
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 04:18 PM, Jason Merrill wrote:
OK.
For trunk. The 4.6 branch looks very different.
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
OK.
Jason
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
> "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 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
> "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
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
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
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
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
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
--
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
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,
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
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
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, 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
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, 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
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.
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
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. */
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
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
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
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
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
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
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
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
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 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~
...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
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)
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
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!
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
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
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 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
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
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.
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
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
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
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
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
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
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 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
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.
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
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
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:
> 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
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 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
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 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 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
> 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
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
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
> > 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 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
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 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, 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 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
> >
> >
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, 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
96 matches
Mail list logo
