On Aug 7, 2014, at 12:47 AM, Tom de Vries wrote:
> Done. Committed as attached.
Thanks.
On Aug 9, 2014, at 9:55 AM, Chen Gang wrote:
>>
>
> Excuse me, I can not find it with `find ./ | grep "\.sum$”`
Then you didn’t do a test suite run. make check will create .sum files. Try
cd gcc && make check. Then in testsuite/gcc/gcc.sum there will be a file.
> After comparing, should th
On Aug 11, 2014, at 2:06 AM, Richard Earnshaw wrote:
> Not quite, read the subject line again.
Doh. I did miss that entirely. The solutions I gave were for other cases than
the case at hand.
> I'm not sure what the correct change to the testsuite is here.
The below is close, let me refine it
On Aug 11, 2014, at 8:08 AM, Joel Sherrill wrote:
> +#if defined(__rtems__)
> +#include
> +/* Required, for read(), write(), and close() */
> +#endif
Strikes me as exceptionally odd. Should be done unconditionally, and any
system that doesn’t like that should be the odd ball.
On Aug 11, 2014, at 10:57 AM, Jakub Jelinek wrote:
>
>> + if (timeout != -1)
>> +{
>> + signal (SIGALRM, alarm_handler);
>> + alarm (timeout);
>> +}
>
> Not sure how much portable signal/alarm is. So probably should be guarded
> by the existence of signal.h, SIGALRM being def
On Aug 11, 2014, at 2:02 PM, Jason Merrill wrote:
>
> On considering the request, it occurred to me that we could handle variadic
> arguments of non-trivial types the same way we handle normal value arguments
> of such types: pass by invisible reference. So this patch implements that.
> Sinc
On Aug 11, 2014, at 2:27 PM, Chen Gang wrote:
> Welcome additional disccusions or completions, and if no any additional
> reply within 1 week, I shall send patch v2 for it (still use sprintf).
So, my take is it is easier for a maintainer to re-review if you do it without
additional delay. I’d r
On Aug 11, 2014, at 2:58 PM, Janis Johnson wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them. Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
>
> OK for mainline and 4.9 branch?
So, my take is you can se
On Aug 11, 2014, at 2:59 PM, Janis Johnson wrote:
> Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
> generate neon instructions, but it should also check that the test will
> be run using hardware that supports neon, which this patch adds.
> Tested with arm-none-linux-gnu for
On Aug 11, 2014, at 3:00 PM, Janis Johnson wrote:
> Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
> those options conflict with flags for a thumb1 multilib. Don't add
> the extra ARM flags for a thumb1 multilib. Tested with arm-none-linux-gnu
> for mainline and 4.9 with
[ dup, sorry ]
On Aug 11, 2014, at 2:58 PM, Janis Johnson wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them. Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
>
> OK for mainline and 4.9 branch?
So, my ta
On Aug 11, 2014, at 3:01 PM, Janis Johnson wrote:
> The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
> is not 8 or greater, but then some tests fail because intrinsic functions
> used in the test have not been declared. This patch requires that
> __ARM_ARCH be 8 or greater.
On Aug 13, 2014, at 5:12 AM, Felix Yang wrote:
>The qsort library function may have different behavior on
> different hosts (say Linux vs MinGW).
> OK for trunk?
I just have one question. Why if we want to use a stable sort, and we program
in C++, would we not want to just use C++:
http
[ dup sorry ]
On Aug 13, 2014, at 5:12 AM, Felix Yang wrote:
> The qsort library function may have different behavior on
> different hosts (say Linux vs MinGW).
> OK for trunk?
I just have one question. Why if we want to use a stable sort, and we program
in C++, would we not want to just us
On Aug 15, 2014, at 6:49 AM, Alexander Ivchenko wrote:
> * lib/target-supports.exp (error_h): New check.
> (libc_has_complex_functions): Ditto.
> (tgmath_h): Ditto.
> * gcc.dg/builtins-59.c: Add libc_has_complex_functions check.
> * gcc.dg/builtins-61.c: Likewise.
>
On Aug 15, 2014, at 10:32 AM, enh wrote:
> can you file bugs against bionic for stuff like this?
I suspect you meant to ask Alexander this question… but just in case you did
intend to ask me, no. I don’t have any visibility into android local patches
or procedures.
In the end, people with lo
On Aug 16, 2014, at 5:28 PM, Gerald Pfeifer wrote:
> The patch below shaves 404 warnings from stage 1 when bootstrapping
> with clang 3.4.1 (i386-unknown-freebsd10.0).
>
> Regardless of whether we agree with that warning in clang, keeping
> things consistent and not using struct once and class i
On Aug 19, 2014, at 6:12 AM, Kyrill Tkachov wrote:
> So how about this?
Ok. Thanks.
On Aug 18, 2014, at 4:48 PM, Janis Johnson wrote:
> Tested with gcc.target/neon tests for mainline arm-none-eabi with many
> sets of multilib options; OK for mainline and 4.9?
Ok.
On Aug 19, 2014, at 2:38 PM, Steve Ellcey wrote:
> I was pinged about the lack of documentation for the
> check_effective_target_non_strict_align procedure I added
> to target-supports.exp. This patch fixes that.
Ok.
On Aug 20, 2014, at 7:26 AM, Chen Gang wrote:
> - for each test, always contents "unexpected errors" for gcc, g++ ...
> but "make check" skip them and continue, at last still "echo $?" = 0.
I use make -k -j16. It is roughly 16x faster. I’d use -j where n is the
core count. I think -k is use
On Aug 20, 2014, at 11:29 AM, Chen Gang wrote:
>
> It sounds useful to me. At present, my PC is 4 core, so I guess, -j2
No, -j4…. should be around twice as fast as -j2 on your machine (assuming you
aren’t memory starved (4GB or more)).
> for 2 directories are enough. This time (without "--dis
On Aug 18, 2014, at 3:06 AM, Chen Gang wrote:
> - one for original latest gcc source code (master for 20140816).
>
> - one for my modification based on the original latest gcc source code.
>
> - they passed building, but for make check, they reported same issues:
So, I see no evidence that you
On Aug 20, 2014, at 6:03 PM, David Malcolm wrote:
>> OK.
> Thanks; committed to trunk as r214253.
So, unless there is a consumer of this information, in general, you don’t need
to let us know you checked things in. We assume that by default. Cases were
it is useful, you check in someone else’
On Aug 21, 2014, at 8:00 AM, Sandra Loosemore wrote:
> tests that assume some non-default branch costs in the back end
Thanks.
One comment, could you put in /* non default branch cost */ above the three
where that is true. Even better would be to refactor those into something for
target suppo
On Aug 21, 2014, at 10:59 AM, Sandra Loosemore wrote:
> On 08/21/2014 11:36 AM, Mike Stump wrote:
>> On Aug 21, 2014, at 8:00 AM, Sandra Loosemore
>> wrote:
>>> tests that assume some non-default branch costs in the back end
>>
>> Thanks.
>>
>&
On Aug 21, 2014, at 4:22 AM, Richard Biener wrote:
> I still say we need to solve the issue at language level - that is,
> try to figure out what the language standard says about
>
> volatile struct X x, y;
> x = y;
The definition of x = y doesn’t change wrt volatile above. See below for the
On Aug 20, 2014, at 3:31 AM, Tony Wang wrote:
> It's a very simple test case modification to fix the test case failure on ARM
> bare metal target.
> thread_local6.C is a test case to test the behavior of the deconstruct of a
> thread local variable, and it just
> use _exit(0) to override the ret
On Aug 21, 2014, at 5:06 PM, Sandra Loosemore wrote:
> I'd really like the maintainers of these tree-ssa tests to figure out what
> target they're supposed to work for or come up with a suitable test for
> feature support, rather than me trying to guess the failure mode for all
> these other ba
On Aug 22, 2014, at 8:42 AM, Joseph S. Myers wrote:
> On Thu, 21 Aug 2014, Mike Stump wrote:
>> 1 - I use n843 for C99, which is slightly different from the standard, but
>> in this case I suspect it is the same.
>
> Use N1256 (C99+TC1+TC2+TC3) instead.
Thanks. I had the
On Aug 22, 2014, at 5:18 AM, Bernd Schmidt wrote:
>
> Here's another attempt.
> Ok?
Ok. Thanks a ton for doing the work.
The resolutions look fine, the translation looks good.
Before you check it in, consider:
930529-1.x has some alpha bits but I didn’t notice a discussion nor do I have
On Nov 1, 2013, at 3:11 PM, tsaund...@mozilla.com wrote:
> From: tbsaunde
>
> diff --git a/ChangeLog b/ChangeLog
> index e925959..8c24d35 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-11-01 Trevor Saunders
> +
> +* MAINTAINERS (Write After Approval): Add myself.
> +
> 20
On Aug 21, 2014, at 6:33 PM, Tony Wang wrote:
> Thanks for your reply, and I also thought of your suggestion to wrap the
> _exit. The fact is that dejagnu does
> the wrapper to both exit() and _exit(), but it give a higher priority to the
> exit(), which means if you both
> call exit() and _exit
On Aug 22, 2014, at 3:48 PM, Hans-Peter Nilsson wrote:
>
>> +/* non default branch cost */
>> +/* { dg-do run { target { ! "m68k*-*-* mmix*-*-* mep*-*-* bfin*-*-*
>> v850*-*-* picochip*-*-* moxie*-*-* cris*-*-* m32c*-*-* fr30*-*-* mcore*-*-*
>> powerpc*-*-* xtensa*-*-* hppa*-*-* nios2*-*-*"} }
On Aug 23, 2014, at 9:37 AM, Sandra Loosemore wrote:
> If we're going to go through the trouble of adding a comment here, we might
> as well make it something less terse and more explicit, like:
>
> These tests fail unless the target backend overrides BRANCH_COST to return a
> value >= 2.
Soun
On Aug 25, 2014, at 7:08 AM, David Malcolm wrote:
>
> I'm testing and committing individual patches, but this
> could have gone into trunk in one go.
Yeah, it’s a hard choice between bit rot and incrementally going in.
> what I realize now is that I should have
> continued rebasing my patches i
On Aug 25, 2014, at 11:03 AM, James Clarke wrote:
> The __DARWIN_64_BIT_INO_T macro is used to indicate whether dirent.d_ino
> is 64-bit or not, and so should be sized appropriately. Additionally,
> dirent.d_seekoff should only be defined/checked when
> __DARWIN_64_BIT_INO_T is defined.
>
> libsa
On Aug 25, 2014, at 12:45 PM, Steven Bosscher wrote:
> On Mon, Aug 25, 2014 at 9:29 PM, Mike Stump wrote:
>> On Aug 25, 2014, at 7:08 AM, David Malcolm wrote:
>>> It's too late now to switch to this approach, so in the meantime I've
>>> been working on
On Aug 25, 2014, at 11:03 AM, James Clarke wrote:
> Previously, this macro had taken the form 10X0, where X is the minor
> version number, e.g. 1090 for OS X 10.9 Mavericks. However, as of OS X
> 10.10 Yosemite, it should take the form 10XX00, i.e. 101000 for 10.10.
So, if they continue using the
On Aug 25, 2014, at 11:04 PM, James Clarke wrote:
> So I should just take that particular check out then?
Oh, yeah, I guess the is the way to fix it.
On Aug 26, 2014, at 1:35 AM, Richard Biener wrote:
>
>> 8 The implicitly-defined copy constructor for class X performs a member-
>> wise copy of its subobjects. The order of copying is the same as the
>> order of initialization of bases and members in a user-defined con-
>> structor (see
On Aug 26, 2014, at 9:02 AM, James Clarke wrote:
> These patches combine to address PR target/61407, meaning that GCC is
> able to bootstrap on OS X 10.10 Yosemite.
> James Clarke (2):
> Fix __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
For the first patch, Ok.
So, after baking for a week, I t
On Aug 28, 2014, at 7:27 AM, Bernd Schmidt wrote:
> The next question would be what to do with gcc.c-torture/unsorted. As far as
> I can tell, these are all just plain compile tests, except for dump-noaddr.c.
> Ok to move all except for that test to c-torture/compile, adjusting SFset.c
> and
On Aug 28, 2014, at 11:03 PM, Honggyu Kim wrote:
> This fixes some typo errors in the gcc internal document.
These errors are on purpose.
> -There are many places in which this document is incomplet and incorrekt.
> +There are many places in which this document is incomplete or incorrect.
On Aug 29, 2014, at 5:04 PM, Maciej W. Rozycki wrote:
> Executing on host: powerpc-linux-gnu-gcc arm_cortex_m25641.c
> -fno-diagnostics-show-caret -fdiagnostics-color=never -mthumb -S -o
> arm_cortex_m25641.s(timeout = 300)
> OK to apply?
Ok.
On Sep 1, 2014, at 6:34 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> (I sort of wonder why this wasn't added to the actual preprocessor 20 years
> ago.)
:-)
So can you hack the system at template expansion time yet? :-)
std::shell<“/bin/sh -c …”> maybe?
On Sep 2, 2014, at 3:28 AM, Hans-Peter Nilsson
wrote:
> In a native x86_64-linux toolchain in which
> eh-table-registration is done explicitly (i.e. dl_iterate_phdr
> and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the
> issue), the memory overhead for exception-initialization goes
> bey
> When I ran Asan test on Asan-bootstrapped GCC, some of them fail with
> memory leaks into GCC, even if Lsan is disabled. This caused by slightly
> wrong logic in saving/restoring env variables functionality in
> gcc-dg.exp (some tests override ASAN_OPTIONS and this env variable isn't
> restored
On Sep 3, 2014, at 1:03 AM, Uros Bizjak wrote:
> These testcases were intended to be compiled on x86 targets only [1].
Not a bug deal, but would a git mv bla gcc.target/i386 be more appropriate?
> 2014-09-03 Uros Bizjak
>
>* gcc.dg/20111227-2.c: Compile only for x86 targets.
>* gcc.d
On Sep 4, 2014, at 4:14 AM, Ramana Radhakrishnan
wrote:
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -2293,8 +2293,8 @@ proc check_effective_target_arm_little_endian { } {
>> proc check_effective_target_arm_vect_no_misalign { } {
>> retur
On Sep 4, 2014, at 5:22 PM, Kaz Kojima wrote:
> BTW, Jeff's comment on pr39228.c makes me think that this test
> can be moved into execute/ieee. Thought?
I don’t see a down side, specially if we know that the test case is picky about
ieee.
On Sep 5, 2014, at 3:10 AM, Thomas Schwinge wrote:
> Should PR20567 now be updated?
Updated.
On Sep 5, 2014, at 3:59 PM, Dominique Dhumieres wrote:
> See pr63188 for darwin. The same patch should probably
> fix the problem for hppa64-hpux* too.
Thanks.
Committed revision 214983.
Index: ChangeLog
===
--- ChangeLog (revisi
On Sep 6, 2014, at 12:20 AM, Andreas Schwab wrote:
> Mike Stump writes:
>
>> Index: config/pa/pa64-hpux.h
>> ===
>> --- config/pa/pa64-hpux.h(revision 214981)
>> +++ config/pa/pa64-hpux.h(wor
On Nov 5, 2013, at 12:00 PM, Richard Sandiford
wrote:
> I've committed the patch below, which is a trivial wide-intification of:
>
>http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00335.html
>
> I won't commit the mainline patch for a couple of days
So, please feel free to do a svn merge ^/tr
On Nov 5, 2013, at 12:44 PM, Oleg Endo wrote:
> +/* { dg-do compile { target "sh*-*-*" } } */
Why do this, when sh-torture.exp does this:
if { ![istarget sh*-*-*] } then {
return
}
? I suspect you merely copied the style from the other test cases. If there
isn't a good reason to do this, p
On Nov 5, 2013, at 1:45 PM, Oleg Endo wrote:
> You're right, it's redundant. It should be just
> /* { dg-do compile } */
>
> shouldn't it?
Yup, that's my take.
> I can change that before committing, no problem.
Thanks.
On May 29, 2010, at 2:28 PM, Steven Bosscher wrote:
> This is the first patch of 3 planned, to move the C front end to its
> own directory.
> This first patch moves all the code common to the C-family of front
> ends to a new directory c-family/.
You forgot to clean up the built bits?!:
On Nov 6, 2013, at 2:33 PM, Oleg Endo wrote:
> I've committed the attached patch as rev 204487.
I doubled checked the patch, all looks good, thanks for the work.
On Nov 6, 2013, at 2:48 PM, Richard Sandiford
wrote:
> The main part of getting avr to work was changing the type used to
> handle the insert_bits mask, which went into mainline first. This just
> mops up a couple of other problems.
> Will say more about the comparison later.
Look forward to
On Nov 7, 2013, at 8:43 AM, Joseph S. Myers wrote:
> This patch cleans up various issues with the tests of atomics built-in
> functions and libatomic functions, in preparation for adapting those
> tests to add test coverage of stdatomic.h macros. The tests were
> missing a return type for main (C
On Nov 7, 2013, at 9:47 AM, Richard Sandiford
wrote:
> Get the new port building on wide-int. Seemed pretty obvious so I went
> ahead and installed it.
Looks good.
ut_destructor
Fixed:
2013-11-07 Mike Stump
* config/pdp11/pdp11.c: Include dbxout.h.
* config/picochip/picochip.c: Likewise.
Index: config/pdp11/pdp11.c
===
--- config/pdp11/pdp11.c(revision 204436)
+++
On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
> Well, it is my understanding that the warning should be emitted for a
> volatile variable only if it is not accessed. Initialization means
> accessing, even though it is not used anywhere.
Let me try. A warning is useful, if there is no way a co
On Nov 8, 2013, at 1:32 AM, Bin.Cheng wrote:
> On Fri, Nov 8, 2013 at 5:03 PM, Mike Stump wrote:
>> On Nov 7, 2013, at 5:13 PM, Mingjie Xing wrote:
>>> Well, it is my understanding that the warning should be emitted for a
>>> volatile variable only if it is not acce
On Nov 8, 2013, at 2:25 AM, Bin.Cheng wrote:
> Thanks for elaborating. The warning message is actually for no-use of
> variable, and it has few things to do with whether it's accessed or
> not.
I disagree. If you examine why the warning was put in, you realize it was put
in so that lazy progra
On Nov 8, 2013, at 2:30 AM, Richard Sandiford
wrote:
> From gcse.c:
>
> --- wide-int-base/gcc/gcc/gcse.c 2013-11-05 13:09:32.148376180 +
> +++ wide-int/gcc/gcc/gcse.c 2013-11-05 13:07:28.431495118 +
> @@ -1997,6 +1997,13 @@ prune_insertions_deletions (int n_elems)
> bitmap_c
On Nov 8, 2013, at 2:35 AM, Mingjie Xing wrote:
> Oops, if it is not a bug, please close the report
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258
Well, I've stated my position. I can be swayed by a good argument, if someone
has one. I'd give people a chance to weigh in if they can think
On Nov 8, 2013, at 4:09 AM, Bernhard Reutner-Fischer
wrote:
> On 6 November 2013 08:04, Jakub Jelinek wrote:
>> On Wed, Nov 06, 2013 at 02:24:01AM +, Iyer, Balaji V wrote:
>>>Fixed patch is attached. The responses to your question are given below.
>>> Is this patch OK?
> May i suggest
On Nov 9, 2013, at 2:00 AM, Richard Sandiford
wrote:
> Fix formatting and remove some spurious differences with trunk
> (some of which are ordering rather than formatting, but it didn't
> seem worth separating them out).
> Applied as obvious (I hope).
I reviewed it, looks good.
On Nov 9, 2013, at 2:03 AM, Richard Sandiford
wrote:
> These changes don't have much in common except being simplifications.
> Note that "len == 0" isn't possible now that we've eliminated the
> 0-precision case. "val = val" should be redundant.
>
> OK to install?
Ok.
On Nov 9, 2013, at 2:13 AM, Richard Sandiford
wrote:
> There are two instances of:
>
> if (TREE_CODE (x) != INTEGER_CST)
> GCC_BAD ("invalid constant in %<#pragma pack%> - ignored");
> /* Cannot use tree_to_uhwi here or it will ice if above message printed.
> */
> align =
On Nov 9, 2013, at 2:16 AM, Richard Sandiford
wrote:
> wide_int_type_size_in_bits returns an offset_int (previously an addr_int)
> rather than a wide_int, so this patch renames it accordingly.
> OK to install?
Ok.
On Nov 9, 2013, at 2:17 AM, Richard Sandiford
wrote:
> Some cases where we could use const references instead of passing by value.
> OK to install?
Ok.
On Nov 9, 2013, at 2:28 AM, Richard Sandiford
wrote:
> Avoid some unnecessary "wide_int (x)"s and make more use of wi::.
> OK to install?
Nice. Ok.
On Nov 9, 2013, at 2:57 AM, Richard Sandiford
wrote:
> "mode_for_size (MAX_BITSIZE_MODE_ANY_INT, MODE_INT, 0)" isn't safe
> because the widest mode might not have an integer counterpart.
> We can get the widest integer mode directly using MAX_MODE_INT.
> OK to install?
Ah, curious. Ok. Long t
On Nov 9, 2013, at 5:34 AM, Bernhard Reutner-Fischer
wrote:
> Ok for trunk?
> 2013-10-12 Bernhard Reutner-Fischer
>
>* lib/dg-pch.exp (pch-init): Remove pchtest check objects.
Ok.
The code that does set chk_lang "c++-header", but just not the code that puts
in the comment, is fine
On Nov 11, 2013, at 8:35 AM, David Edelsohn wrote:
> I continue to see extra Cilk Plus failures on AIX. Tests that require
> LTO should check that the target supports LTO.
Iyer, sprinkle /* { dg-require-effective-target lto } */ on those test cases
and see if they then work ok as expected.
On Nov 10, 2013, at 8:28 AM, H.J. Lu wrote:
> This patch documents __builtin_setjmp and __builtin_longjmp. OK to
> install?
I like it. I think these two should be documented.
Alignments are stored in a byte, large alignments don't actually work nicely.
This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT to
be smaller than this. The competing change would to be to make it a short,
but, I'd be happy to punt that until such time as someone act
On Nov 12, 2013, at 1:16 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote:
>> Alignments are stored in a byte, large alignments don't actually work
>> nicely. This caps the alignment to 128, as most ports would define
>> BIGGEST_AL
On Nov 12, 2013, at 4:39 PM, Joseph S. Myers wrote:
> with a single evaluation. To achieve this, this patch adds a new GNU
> C extension __auto_type,
Nice, I like it.
This fixes a memory stomper that Kenny found.
This also improves the code in the face of vector of partial ints...
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index acee2000..ab8852f 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3163,7 +3163,7 @@ static void add_AT_location_descriptio
On Nov 13, 2013, at 2:28 PM, Magnus Granberg wrote:
> This patchset will add a new configure options --enable-default-pie.
Ick. Would be nice to figure out on what systems one can do this and just do
it without the configure option. Is there some reason that we need an option
for it?
On Nov 13, 2013, at 5:14 PM, Ian Lance Taylor wrote:
> On Wed, Nov 13, 2013 at 3:23 PM, Mike Stump wrote:
>> On Nov 13, 2013, at 2:28 PM, Magnus Granberg wrote:
>>> This patchset will add a new configure options --enable-default-pie.
>>
>> Ick. Would be nice to
On Nov 15, 2013, at 4:32 AM, Eric Botcazou wrote:
>> Either you need to document all the semantics so as to make clear to users
>> exactly when they can use these functions safely, or you need to state
>> that there are undocumented restrictions that may change from GCC version
>> to GCC version a
Kenny reported that the library name is mixed into the test case name. This is
wrong. This fixes it. I also trimmed -O0, as redundant and added support for
C++ runtime tests, once you guys want to add one.
The CK tests should either be made to work in C++ land, or moved to
gcc.dg/cilk-plus.
On Nov 15, 2013, at 8:23 PM, "Iyer, Balaji V" wrote:
> This is already done in my patch for _Cilk-spawn and _Cilk_sync support for
> C++. The patch was submitted ~3-4 weeks ago.
Ping once a day until reviewed. :-) You should form a new patch and post it
and be sure to cc jason on that email.
On Nov 18, 2013, at 3:09 AM, Vidya Praveen wrote:
>> Ok, let it bake on trunk and then you can back port it if no one screams.
>
> I think it has baked long enough. Could this be approved for 4.7 and 4.8 now?
Oh, that was pre-approval to back port, conditional on no fallout and no
screams… If
On Nov 19, 2013, at 8:54 AM, Ulrich Weigand wrote:
> another test case fix: darwin-longlong.c implements a "msw" routine
> extracting the most significant word from a long long. This of course
> needs to be updated for little-endian ...
>
> Tested on powerpc64le-linux.
>
> OK for mainline?
My
Here is a little one that was useful in debugging during wide-int development,
but isn't dependent upon wide-int.
Committed.
* gdbinit.in: Add pmz to print out mpz values.
Index: gdbinit.in
===
--- gdbinit.in (revision 20
On Nov 19, 2013, at 2:05 PM, Ilya Enkovich wrote:
>> Anything added that's XFAILed should have a comment explaining the reason
>> for the XFAILing (a reference to a bug in GCC Bugzilla is a good idea,
>> with that bug then mentioning the particular test that indicates whether
>> the bug is still p
On Nov 19, 2013, at 2:52 PM, Joseph S. Myers wrote:
> If a bound violation should be detected, the test should PASS when it's
> detected and FAIL when it's not, rather than XFAILing and XPASSing.
> Hopefully dg-shouldfail will do the right thing (causing an error exit
> status from the test to
On Nov 20, 2013, at 5:38 AM, Richard Sandiford
wrote:
> One simple switch to wi::add and one simplification that became possible
> after Kenny's patch to remove the other real_from_integer.
>
> Tested on x86_64-linux-gnu and applied as obvious (I hope).
Look good.
On Nov 20, 2013, at 5:58 AM, Richard Sandiford
wrote:
> I've committed a patch upstream to convert TREE_INT_CST_LOW to tree_to_[su]hwi
> if there is an obvious tree_fits_[su]hwi_p guard.
So, in general, I like putting them on trunk, and then merging them into the
branch. When that is done, the
On Nov 20, 2013, at 7:31 AM, Richard Sandiford
wrote:
> cst_fits_shwi_p replaces cst_and_fits_in_hwi, but if cst_fits_uhwi_p
> goes away then I think we might as well stick with the original name.
So the entire patch seems fine, except for one hunk I'll punt to Kenny to weigh
in and those are t
le that option,
>> nor does the Ada compiler.
>
> Hum. That’s unfortunate, because I haven’t found any other suitable place :)
> I do not see how to specify compiler flags only for Fortran.
>
>> You could also ask Mike Stump to review the testsuite changes.
>
> Mik
On Nov 22, 2013, at 12:03 PM, Richard Biener wrote:
> For the merge you want to have trunk frozen
I can do the required work without needing the trunk frozen. I prefer to not
freeze.
Richi has asked the we break the wide-int patch so that the individual port and
front end maintainers can review their parts without have to go through the
entire patch.This patch covers the aarch64 port.
Ok?
* config/aarch64/aarch64.c
(aapcs_vfp_sub_candidate): Use wide-int
Richi has asked the we break the wide-int patch so that the individual port and
front end maintainers can review their parts without have to go through the
entire patch.This patch covers the alias analysis code.
Ok?
* alias.c
(ao_ref_from_mem): Use wide-int interfaces.
501 - 600 of 2403 matches
Mail list logo
