Hi,
>> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
>
> Why a new option? The -fstrict-volatile-bitfields option is already
> GCC-specific, and I think it can do what you want anyway.
As I understand Richard's comment, he proposes to
have an option for true AAPCS compliance,
Hi,
On Fri, 18 Oct 2013 14:06:57, Richard Biener wrote:
>
> On Fri, Oct 18, 2013 at 1:56 PM, Bernd Edlinger
> wrote:
>> Hello Richard,
>>
>> I see it the same way.
>>
>> The existing code in optimize_bit_field_compare looks wrong. It is very
>> asymmetric,
>> and handles lvolatilep and rvolatil
Hi,
For little endian, the permute control vector for unpacking high and low
halves of a vector register must be reversed from the one used for big
endian. Fixing this corrects 27 failing tests for
powerpc64le-unknown-linux-gnu.
Bootstrapped and tested for powerpc64{,le}-unknown-linux-gnu with n
The test fails on the 32-bit hpux target because the long double type
is larger than the largest
integer type. Test passes on 64-bit hpux target. On linux, long
double is the same as double.
So, it's simplest to just skip long double test.
Tested on hppa2.0w-hp-hpux11.11.
Dave
--
John Davi
Skipped because alias definitions are not supported on 32-bit hpux
targets.
Tested on hppa2.0w-hp-hpux11.11.
Dave
--
John David Anglin dave.ang...@bell.net
2013-10-19 John David Anglin
PR testsuite/58645
* gnat.dg/specs/linker_alias.ads: Skip on hppa*-*-hpux*.
Inde
The attached change fixes an identifer conflict caused by renaming the
member _slot to m_slot.
This fixes PR target/58603.
Committed as obvious. Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-
hpux11.11 and hppa1.1-hp-hpux11.11.
Dave
--
John David Anglin dave.ang...@bell.net
2013-10-19
On Sat, Oct 19, 2013 at 3:12 PM, Paolo Carlini wrote:
> Yes, but giving it a name doesn't buy us much wrt the issue I pointed out.
> For comparison, in similar cases, the compiler driver has --params which the
> user can fine tune on the command line. The best approximation we have got
> in the li
The following patch (related to my 58800 patch) adds many more tests
for several important functions. While 58800 is my fault, the reason
it was not caught earlier is that many functions in libstdc++ have
almost no testing. This works toward fixing that.
These tests are kept to an acceptable amoun
A previous fix to a performance problem in std::sort unfortunately has
lead to a crashing bug in std::nth_element.
The following minimal patch fixes the problem (there are a couple of
different ways of fixing it, this is the shortest and safest).
2013-09-19 Chris Jefferson
PR libstdc++/58800
*
> Jan,
>
> Does this seem reasonable to you?
Oops, sorry, I missed your email. (I was travelling and I am finishing a paper
now).
>
> Thanks,
> Igor
>
> > -Original Message-
> > From: Zamyatin, Igor
> > Sent: Tuesday, October 15, 2013 3:48 PM
> > To: Jan Hubicka
> > Subject: RE: Honnor
On 10/19/2013 10:18 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like
On 10/19/2013 02:41 PM, Mike Stump wrote:
On Oct 19, 2013, at 7:22 AM, Richard Sandiford
wrote:
As discussed, this patch effectively goes back to your original idea of
having excess upper bits in a HWI being undefined on read (at least as
the default assumption). wide_int itself still ensures
On Wed, 16 Oct 2013, Marek Polacek wrote:
> @@ -2946,7 +2957,8 @@ c_parser_declarator (c_parser *parser, b
>struct c_declspecs *quals_attrs = build_null_declspecs ();
>struct c_declarator *inner;
>c_parser_consume_token (parser);
> - c_parser_declspecs (parser, quals_a
On Oct 16, 2013, at 1:11 AM, Richard Biener wrote:
> I suppose it's fine to move the testcase to the C++ lto testsuite
> if you verify it will use the C compiler for the C parts.
Thanks. Testing pointed out one additional feature lto testing need to make
thing whole thing go. Committed.
2013-
On 10/19/2013 07:51 PM, Tim Shen wrote:
On Sat, Oct 19, 2013 at 4:03 AM, Paolo Carlini wrote:
About the < 2, in general hardcoding a parameter value in the code isn't a
nice idea. Why don't we take it out to a macro, say
_GLIBCXX_REGEX_NFA_QUANTIFIERS_LIMIT? In stl_deque.h we have something
sim
On Oct 19, 2013, at 7:22 AM, Richard Sandiford
wrote:
> As discussed, this patch effectively goes back to your original idea of
> having excess upper bits in a HWI being undefined on read (at least as
> the default assumption). wide_int itself still ensures that the excess
> bits are stored as s
On Oct 19, 2013, at 7:18 AM, Richard Sandiford
wrote:
> So I think Mike's original patch was right and that this extra
> "y.len == 1" check is redundant.
So, gcc's optimizer agrees with your view, it is redundant. :-)
I checked this in:
Index: wide-int.h
==
Hello!
> I'm fighting with mode switching (to be more precise with
> create_pre_exit function) trying to make it work for MPX. I saw
> create_pre_exit had some stability issues before and now I'm facing
> similar issues trying to have it working when bound register is
> returned by function in ad
On Sat, Oct 19, 2013 at 4:03 AM, Paolo Carlini wrote:
> About the < 2, in general hardcoding a parameter value in the code isn't a
> nice idea. Why don't we take it out to a macro, say
> _GLIBCXX_REGEX_NFA_QUANTIFIERS_LIMIT? In stl_deque.h we have something
> similar and in the present case it wou
On Oct 19, 2013, at 5:20 AM, "Bernhard Reutner-Fischer"
wrote:
>> WIDE?
>
> s/positve/positive/g
Thanks. Here is what I put in:
Index: wide-int.h
===
--- wide-int.h (revision 203835)
+++ wide-int.h (working copy)
@@ -185,7 +185
Hi Kenny,
As discussed, this patch effectively goes back to your original idea of
having excess upper bits in a HWI being undefined on read (at least as
the default assumption). wide_int itself still ensures that the excess
bits are stored as signs though.
This patch is already quite big, so I'v
Kenneth Zadeck writes:
> On 10/19/2013 05:01 AM, Richard Sandiford wrote:
>> Mike Stump writes:
>>> + // We optimize x < y, where y is 64 or fewer bits.
>>> + // We have to be careful to not allow comparison to a large positive
>>> + // unsigned value like 0x8000, those would be en
Hello,
The test case pr54089-3.c started to fail a while ago, because of the
broken test for load of constant 31. Committed as obvious to trunk and
4.8 branch.
Cheers,
Oleg
testsuite/ChangeLog:
* gcc.target/sh/pr54089-3.c: Fix test for load of constant 31.
Index: gcc/testsuite/gcc.targ
On Sat, Oct 19, 2013 at 2:55 PM, Uros Bizjak wrote:
>
> The list of possible return registers in ix86_function_value_regno_p
> is incomplete. 32bit and 64bit targets use %[er]dx register for
> DImode and TImode values respectively and %st(1) and %xmm1 for
> imaginary part of complex values. Addit
Hello!
The list of possible return registers in ix86_function_value_regno_p
is incomplete. 32bit and 64bit targets use %[er]dx register for
DImode and TImode values respectively and %st(1) and %xmm1 for
imaginary part of complex values. Additionally, 64bit SYSV targets use
%rdi and %rsi registers
On 10/19/2013 05:01 AM, Richard Sandiford wrote:
Mike Stump writes:
+ // We optimize x < y, where y is 64 or fewer bits.
+ // We have to be careful to not allow comparison to a large positive
+ // unsigned value like 0x8000, those would be encoded
+ // with a y.len == 2.
+ if (
> -Original Message-
> From: Joey Ye [mailto:joey.ye...@gmail.com]
> Sent: Friday, October 18, 2013 6:37 AM
>
> I do encourage you to upstream this patch, though I'm not the maintainer of
> libiberty to approve it.
OK. Thank you.
Here it is.
Could you push it to appropriate people?
Atta
Paolo Carlini wrote:
> Patch is Ok with me. Before committing you may want to test -m32 too.
Obviously, you did not!-(see
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01471.html
FAIL: tr2/dynamic_bitset/pr58729.cc execution test
On x86_64-apple-darwin12, the failure is
Assertion failed: (pd
Hello!
The testcase in PR58792 [1], where a function returns its result in
multiple registers, triggered a very picky assert in mode-switching
code. The problem was, that x86_64 didn't mark correctly all of its
possible return registers, so code assumed that something went wrong
here.
The mode-sw
On 18 October 2013 22:55:39 Jakub Jelinek wrote:
On Fri, Oct 18, 2013 at 01:52:54PM -0700, Mike Stump wrote:
> On Oct 18, 2013, at 6:11 AM, Kenneth Zadeck wrote:
> >>> Does this look ok? Kenny, can you double check the cases, think I
have them right, but? a double check would be good.
> >>
This ensures the path names in the debug info of the library are consistent
with those of libgcc.
Tested on x86_64-suse-linux, applied on the mainline.
2013-10-19 Thomas Quinot
* gcc-interface/Makefile.in: Use canonical absolute path to refer to
the top source directory and
The compiler may emit an incorrect alignment in the XVE descriptive type
associated with a record type containing a dynamic-sized field.
Tested on x86_64-suse-linux, applied on the mainline and 4.8 branch.
2013-10-19 Eric Botcazou
* gcc-interface/utils.c (scale_by_factor_of): New fu
Tested on x86_64-suse-linux, applied on the mainline.
2013-10-19 Eric Botcazou
* gcc-interface/cuintp.c: Remove useless include directives.
(build_cst_from_int): Use standard predicate.
(UI_To_gnu): Simplify.
(UI_From_gnu): Fix formatting.
* gcc-interfa
This is a regression present on all active branches. The descriptive types
emitted in the debug info by the Ada compiler can have a different scope than
that of the type they are associated with, which goes against the spec.
Tested on x86_64-suse-linux, applied on all active branches.
2013-10
Paolo Carlini writes:
> Before committing you may want to test -m32 too.
Where it in fact fails, see PR58804.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Fri, 2013-10-18 at 09:59 +0200, Christian Bruel wrote:
> On 10/18/2013 01:05 AM, Oleg Endo wrote:
> > I was wondering, in file sh-mem.c, the new function
> > 'sh4_expand_cmpstr' ... why is it SH4-something? It's a bit confusing,
> > since cmp/str has been around since ever (i.e. since SH1). May
Mike Stump writes:
> + // We optimize x < y, where y is 64 or fewer bits.
> + // We have to be careful to not allow comparison to a large positive
> + // unsigned value like 0x8000, those would be encoded
> + // with a y.len == 2.
> + if (y.precision <= HOST_BITS_PER_WIDE_INT
> +
Hi,
On 10/19/2013 05:53 AM, Tim Shen wrote:
On Fri, Oct 18, 2013 at 9:13 PM, Tim Shen wrote:
As the comment in this patch said, DFS approach is faster in simple
regex, but exponentially slower in complex(many quantifier) cases.
Actually I suggest to use DFS where number of quantifiers < 2, to
On Fri, 2013-10-18 at 09:38 +0200, Christian Bruel wrote:
> On 10/18/2013 12:53 AM, Oleg Endo wrote:
> > Hi,
> >
> > On Thu, 2013-10-17 at 16:13 +0200, Christian Bruel wrote:
> >> Hello,
> >>
> >> This patch just reorganizes the SH code used for memory builtins into
> >> its own file, in preparatio
39 matches
Mail list logo
