So, I was hoping that someone would step forward and review this. I’d like for
a reviewer to consider, is this the type of error messages we want to vend to
the poor user? It strikes me as, well, icky. Should -fPIE imply -fPIC?
Exclusive of that issue, the patch is fine.
On Jan 11, 2015, at
On Jan 14, 2015, at 6:52 AM, Richard Earnshaw rearn...@arm.com wrote:
On 14/01/15 11:57, Thomas Preud'homme wrote:
Ping?
I'm OK with this, but I think you also need a generic testsuite
maintainer to go over the target independent parts.
Ok.
On Jan 15, 2015, at 11:54 AM, Ilya Verbin iver...@gmail.com wrote:
On 15 Jan 11:20, Mike Stump wrote:
On Jan 15, 2015, at 9:53 AM, Ilya Verbin iver...@gmail.com wrote:
If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
done
in libitm.exp, it will not work:
Ok
On Jan 15, 2015, at 9:53 AM, Ilya Verbin iver...@gmail.com wrote:
If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
done
in libitm.exp, it will not work:
Ok, original patch is fine.
On Jan 11, 2015, at 2:33 PM, Prathamesh Kulkarni
prathamesh.kulka...@linaro.org wrote:
oops, sorry about this. We will build further flattening patches with
--enable-languages=all,go,jit,ada.
Shall that cover all the front-ends ?
No objc++ is non-default:
$ grep build_by_default
On Jan 8, 2015, at 9:35 PM, Jeff Law l...@redhat.com wrote:
Do you want to be a reviewer for libobjc?
I think things are fine as is. If things were pinged and there were no
response, or if someone wanted to do major updated on the library to bring it
up a decade, then we might want to change
On Jan 8, 2015, at 9:38 PM, Andrew Pinski pins...@gmail.com wrote:
2014-12-24 Dimitris Papavasiliou dpapa...@gmail.com
PR libobjc/51891
* libobjc/ivars.c: Add a check for classes without instance
variables, which have a NULL ivar list pointer.
*
On Jan 7, 2015, at 6:32 PM, Hans-Peter Nilsson hans-peter.nils...@axis.com
wrote:
PR62250 (r219171) was about some fortran tests that used atomic
operations but failing on systems where -latomic is required.
The fix was to always add -latomic. That caused test-suite
regressions for targets
On Jan 8, 2015, at 1:27 PM, Jakub Jelinek ja...@redhat.com wrote:
Any objections to approving it now?
LGTM.
Patch is Ok. If you could send the clang folks a heads up, I’ve love to see
them adopt the style.
On Jan 7, 2015, at 12:23 AM, Jakub Jelinek ja...@redhat.com wrote:
I'm fine with adding the no_sanitize_thread attribute, the patch LGTM
Thanks, I checked it in, the doc seemed trivial enough.
* tsan.c (pass_tsan::gate): Add no_sanitize_thread support.
(pass_tsan_O0::gate):
On Jan 8, 2015, at 11:29 AM, Jakub Jelinek ja...@redhat.com wrote:
I disagree. Busy waiting of this kind is not appropriate for the test suite,
What busy waiting, there is none in the last version of the patch?
tsan can't intercept the calls that you do through dlsym, because you
explicitly
On Jan 8, 2015, at 9:04 AM, Jakub Jelinek ja...@redhat.com wrote:
I don't know how portable scalbnl actually is in reality, so it would be
nice to hear from port maintainers whether say newlib, android, darwin,
cygwin, aix etc. have it.
darwin has it.
On Jan 7, 2015, at 2:44 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
Here is a new patch, that uses this method on all tsan tests,
which seem to depend on sleep(1), and which have unstable results
because of that.
OK for trunk?
No. So, I think this is wrong. The problem is that any
On Jan 7, 2015, at 12:23 AM, Jakub Jelinek ja...@redhat.com wrote:
But I really don't like the busy waiting.
We’ve already determined that sched_sleep isn’t intercepted and can be used to
non-busy wait. Any reason not to use it?
As tsan is only supported on x86_64-linux
So, I hate hardening
On Jan 6, 2015, at 11:17 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
On Tue, 6 Jan 2015 16:32:35, Mike Stump wrote:
On Jan 6, 2015, at 3:22 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
Yes, I think too that it can't fail under these conditions.
If you mean your version
On Jan 6, 2015, at 9:45 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
I tried your suggestion now, and it seems to work. (on a 4-way core AMD64
laptop)
Would you prefer this over adding a sleep in Thread1, which I posted
previously?
The problem with the patch is there is nothing in
On Jan 6, 2015, at 3:22 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
Yes, I think too that it can't fail under these conditions.
If you mean your version… A lot has been written on how to to make racy code
non-racy… I’d refer you to the literature on all the various solutions people
On Jan 5, 2015, at 5:06 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
I tried to elaborate your idea a bit, and used proper atomics.
It is necessary that the logic of the step function is completely invisible
to tsan.
Therefore it should not call sleep,
Again, sleep can’t fix race
On Jan 5, 2015, at 12:58 PM, Mike Stump mikest...@comcast.net wrote:
So, to help you out, I tried my hand at wiring up the extra library code:
So, my tsan build finally finished, and I could try this with a real test case.
I ran it 20 times, and got 11 fails with:
$ i=20; while let i--; do
On Jan 5, 2015, at 12:49 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote:
But tsan still gets at least 90% chance to spot that. As a matter of fact,
the tsan runtime is just _incredibly_ fast,
and catches errors, with a very high reliability
On Dec 24, 2014, at 9:28 AM, Dimitris Papavasiliou dpapa...@gmail.com wrote:
The attached patch fixes an issue reported a couple of years ago in Bug 51891
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891). The problem is caused
because classes without instance variables have no ivar list
On Jan 3, 2015, at 3:20 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
Yes, but all other tsan test cases call sleep(1) too.
Ick. The problem is pushing bugs to obscure them without fixing them, makes
the system inherently less good.
If there is already one bug that documents the problem
On Jan 4, 2015, at 9:00 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
It is due to a race condition in tsan itself, it cannot decide which access
was the
previous one and which was the second one, but our tsan tests are not meant as
a functional test of the tsan runtime library, they
On Jan 4, 2015, at 1:48 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
I would need a way to link the test case two helper functions, that are not
compiled with -fsanitize=thread
/* { dg-additional-sources “tsan-helper.c } */
might be one step forward to do that. I don’t know off hand
On Jan 4, 2015, at 11:44 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
On Jan 4, 2015, at 9:00 AM, Bernd Edlinger bernd.edlin...@hotmail.de
wrote:
It is due to a race
On Jan 3, 2015, at 1:01 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote:
the test case g++.dg/tsan/aligned_vs_unaligned_race.C
still fails sporadically (around 1 out of 100 times).
That is apparently a race condition in the tsan runtime itself.
To make the test reproducible pass, I need to
On Jan 2, 2015, at 3:28 AM, Tobias Burnus bur...@net-b.de wrote:
As found by Alessandro: Statically allocated coarrays in declared in the
specification part of a module didn't work (link-time failure). The reason
was that the associated coarray token was wrongly mangled and not a public
On Dec 31, 2014, at 8:46 AM, James Bowman james.bow...@ftdichip.com wrote:
Test pr20621 requires a target with more than 64K of available stack.
This patch adds a path to pass the test when the target has declared
a STACK_SIZE of 64K or less
2014-12-30 James Bowman
On Dec 31, 2014, at 8:44 AM, David Edelsohn dje@gmail.com wrote:
On AIX, GCC needs to build a multilib for AIX. When testing in tree,
the Dejagnu infrastructure adds linking options for the default,
non-pthread multilib. This causes failures for the G++ TLS tests.
The following patch
On Dec 27, 2014, at 3:07 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
h2 id=languagesNew Languages and Language specific
improvements/h2 + ul + lia
href=http://www.openmp.org/mp-documents/OpenMP4.0.0.pdf; OpenMP 4.0
+ specification/a offloading features are now supported in C/C++ and
+
On Dec 24, 2014, at 3:21 PM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
I normally build with --disable-libsanitizer, because the sanitizers
testresults are very unreproducable, so just annoying noise. This however
makes most (all?) ubsan testcases fail, since they want to load a
On Dec 26, 2014, at 7:57 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Dec 25, 2014 at 9:07 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
On Thursday 2014-12-18 11:35, H.J. Lu wrote:
Updated.
the RAX register (i.e., add the), and I suggest to make
this a sentence, similar to my previous
On Dec 27, 2014, at 8:33 AM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
On Sat, Dec 27, 2014 at 10:11:59AM -0600, Segher Boessenkool wrote:
Please consider pulling the check out and putting it in at the top of the
ubsan.exp type of files.
I suspect there is little need to check
On Dec 27, 2014, at 9:56 AM, Segher Boessenkool seg...@kernel.crashing.org
wrote:
From gcc.dg/ubsan/ubsan.exp:
# Main loop.
if [check_effective_target_fsanitize_undefined] {
That only runs once, doesn't it?
Yes, it does. Perfect.
On Dec 22, 2014, at 4:08 AM, Iain Sandoe i...@codesourcery.com wrote:
After the usual fun with tracking down a GTY(()) issue, it turned out to be
triggered by 216263 (changes in the gtfiles for cp that were not reflected in
objcp). However, it appears that the list was a bit out of sync in
On Dec 22, 2014, at 4:50 AM, Iain Sandoe iain_san...@mentor.com wrote:
When we find [ and we're in objcp mode, and the [ introduces a lambda, we
try to parse a message expression and if that fails we punt (thus we are
unable to recognise lambdas).
Even though Jason reviewed it, I also took a
On Dec 20, 2014, at 8:58 AM, FX fxcoud...@gmail.com wrote:
This patch below allows ubsan to run when libstdc++ is built but not
installed (something which happens on darwin, in particular). This fixes all
658 ubsan failures when run in this particular configuration.
OK to commit?
Ok.
So, I have a rough cut of a new feature to add pragma GCC unroll support to
gcc. It is safe wrt the test suite and code-gen, but there are some corners
that I need help or suggestions on how to round off nicely.
Things to think about, can we put this in even if we have TODO support for C++
On Dec 18, 2014, at 9:43 AM, H.J. Lu hjl.to...@gmail.com wrote:
+ arguments passed in vector registers. This can be used to
+ optimize Linux kernel./li
English, to optimize _the_ Linux kernel?
On Dec 18, 2014, at 10:42 AM, Vladimir Makarov vmaka...@redhat.com wrote:
Thank you very much for your work on porting LRA to SH!
I’ve ported my target to LRA, and I have not found any LRA bits I needed to
change.
On Dec 17, 2014, at 2:21 AM, FX fxcoud...@gmail.com wrote:
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
Would it be possible to apply the patch at
https://gcc.gnu.org/bugzilla/attachment.cgi?id=33932
before 4.8.4 is released? Results with the patch are posted
On Dec 17, 2014, at 3:44 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Dec 17, 2014 at 11:16:18AM +0100, Dominique Dhumieres wrote:
Currently gcc 4.8.4 does not bootstrap on darwin14 (Yosemite) due to pr61407.
Why has it not been pushed in earlier?
No good reason. No one checked it into
On Dec 17, 2014, at 1:34 AM, Richard Biener richard.guent...@gmail.com wrote:
Do we even link GCC with libm …?
Yes. :-) If you grew up on C++, you would realize, -lm as you call it, is
just there in C++, always. If you compile with g++ -v, you will even see it.
Also we don't require a C99
On Dec 16, 2014, at 4:49 PM, Sergio Durigan Junior sergi...@redhat.com wrote:
Ok.
Can you commit this one for me, please?
Committed revision 218843.
If anyone discovers any nasties, pre-approved to pull the patch out or resolve
the issue in the obvious way. I’d hate to impact the folks
On Dec 16, 2014, at 12:46 PM, Iain Sandoe i...@codesourcery.com wrote:
On 16 Dec 2014, at 20:40, Dominique d'Humières wrote:
Another testsuite issue on darwin is that testsuite doesn’t clean up the
.dSYM directories it generates. This gets really annoying on my autotester
:(
I have a
On Dec 16, 2014, at 1:24 PM, Dominique d'Humières domi...@lps.ens.fr wrote:
My patch is different and I am attaching it (it is quite old, so it may not
apply cleanly). The problem for more evolved form is that *.dSYM are
directories and ASAICT there is no command in derange to remove them.
On Dec 15, 2014, at 2:37 PM, Sergio Durigan Junior sergi...@redhat.com wrote:
This weekend I was running GDB's testsuite with many options enabled,
and I noticed that, for some specific configurations (specifically
when testing gdbserver), I was getting the following error:
Binary file
On Dec 16, 2014, at 1:43 PM, Sergio Durigan Junior sergi...@redhat.com wrote:
On Tuesday, December 16 2014, Mike Stump wrote:
So, either, the tool should not generate 0 in the output, which, is rather
anti-social, or one should strip the funny characters in a more portable
fashion.
tr
On Dec 11, 2014, at 4:05 PM, Eric Botcazou ebotca...@adacore.com wrote:
on behalf of Controls and Data Services, AdaCore would like to contribute a
port of the GCC to the Visium.
OK for the mainline?
The test suite bits are usual and customary. I’ll Ok them explicitly anyway.
I’m fine with
On Dec 12, 2014, at 3:36 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Marcus: Uros pointed out to me that these kinds of changes are considered
obvious
(with precedent athttps://gcc.gnu.org/ml/gcc-patches/2014-12/msg00309.html)
but did you have some concerns about backporting to other
On Dec 12, 2014, at 11:38 AM, Ryan Mansfield rmansfi...@qnx.com wrote:
Here are a few test tweaks. In 921202-1.c, if STACK_SIZE is used then VLEN
will blow the stack with 64bit longs. e.g. if STACK_SIZE == 512K then 3
arrays of 32767 longs means at a minimum 767K of stack will be used at
On Dec 11, 2014, at 5:07 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote:
David Malcolm dmalc...@redhat.com writes:
* I don't consider this a critical issue that cannot work without
current releases. We're already working around several upstream
DejaGnu issues in our codebase, and I
On Dec 11, 2014, at 1:32 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
the patch that adds the libstdc++.exp changes at
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00952.html using the new
target-utils.exp file is ok too then?
Ok.
On Dec 10, 2014, at 10:05 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Thanks for the guidance. I've moved the definitions into a separate file and
included that in the places that use it (more than 2 places in my count).
This is the patch attached.
The second patch (will send shortly
On Dec 8, 2014, at 7:06 PM, Wang Deqiang wang.deqi...@linaro.org wrote:
This is a ping for
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01049.html
Seems reasonable enough. I was hoping the arm folks would chime in, we should
have enough of them to review. Let’s given them two more days,
On Dec 9, 2014, at 3:17 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
In the gcc and g++ testsuite we already catch such cases and mark them as
UNSUPPORTED. In libstdc++.exp there is no such functionality.
I'm not very happy that it had to be copied, but I couldn't find a way to
include
On Dec 9, 2014, at 10:39 AM, Jeff Law l...@redhat.com wrote:
Also, a test for the GCC testsuite would be good. I have no idea what
license covers the LLVM testsuite. But given a good analysis of the problem
we may be able to write a suitable test independent of the LLVM test.
So, the usual
On Dec 8, 2014, at 12:44 PM, David Malcolm dmalc...@redhat.com wrote:
On Tue, 2014-11-25 at 20:34 -0500, David Malcolm wrote:
Add command-line option-parsing to the testcases, so that we can
manipulate them without needing a recompile (e.g. varying
optimization levels etc).
This uses
On Dec 8, 2014, at 5:29 PM, David Malcolm dmalc...@redhat.com wrote:
The only stuff I'm using getopt_long for is to make the binaries built
by jit.exp be more flexible e.g. so that I can turn down the number of
iterations they run when running under valgrind (and potentially other
tweaks, so
On Dec 5, 2014, at 9:25 AM, Dr. Philipp Tomsich
philipp.toms...@theobroma-systems.com wrote:
Should I revise, or do will you just drop tje line when applying when
applying this?
We like for the gcc-patches archive to have what exactly went in. It would be
best to re-post the patch with the
On Dec 3, 2014, at 1:18 PM, Jeff Law l...@redhat.com wrote:
The problem is that waiting for the final spec means effectively GCC doesn't
support the feature until gcc-6 in 2016 just due to the expected timing of
the dwarf5 standard and the gcc release schedule. They pretty much couldn't
On Dec 4, 2014, at 7:22 AM, Ilya Enkovich enkovich@gmail.com wrote:
--
2014-12-04 Ilya Enkovich ilya.enkov...@intel.com
PR target/64056
* lib/target-supports.exp (check_effective_target_stpcpy): New.
Thanks for the notice! I see there is also no description for mempcpy
On Dec 3, 2014, at 6:13 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
The check for the tiny memory model is something that is called frequently on
aarch64 testing
since we use it to prune relocation truncation errors in the testsuite.
Therefore it makes sense to cached the result.
I've
On Nov 30, 2014, at 11:21 PM, Oleg Endo oleg.e...@t-online.de wrote:
When running the testsuite on a sh-elf configuration, some test cases
fail due to multiple definitions of the function '_init'. This is
because on sh-elf every function is automatically prefixed with a '_'
char. When
On Dec 1, 2014, at 2:23 AM, Richard Biener rguent...@suse.de wrote:
The following patch unbreaks PCH
Any comments?
Seems better to me.
On Nov 28, 2014, at 4:03 AM, Richard Biener richard.guent...@gmail.com wrote:
On Fri, Nov 28, 2014 at 11:37 AM, Kaz Kojima kkoj...@rr.iij4u.or.jp wrote:
Hi,
I've got odd ICEs with some bitmap operations when working on
sh-lra branch.
bitmap_ior and bitmap_ior_and_compl are the bitmap
On Nov 26, 2014, at 1:35 AM, Ilya Enkovich enkovich@gmail.com wrote:
This patch fixes LTO streamers which were not adjusted when function_code
field was extended up to 12 bits.
OK for trunk after bootstrap and check?
Please could you burry this in a #define someplace. I think I have a
On Nov 26, 2014, at 4:24 AM, Andrew Stubbs andrew_stu...@mentor.com wrote:
On 14/11/14 11:12, Andrew Stubbs wrote:
On 07/11/14 10:35, Andrew Stubbs wrote:
if armv6 never co-exist with NEON, personally I think your original
patch is better
because TARGET_NEON generally will be used when
On Nov 27, 2014, at 9:28 AM, Andrew Stubbs a...@codesourcery.com wrote:
On 27/11/14 17:05, Mike Stump wrote:
Could you include a link or the patch. If the test suite, I'll review it if
no one else steps up.
The original patch is here:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01119
On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote:
One question to build maintainers, and one patch submitted to top-level
configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
This patch fixes that by ensuring that we print that unsupported message
only once.
The resulting test result comparison diff is:
2014-11-25 Tom de Vries
On Nov 23, 2014, at 4:06 PM, FX fxcoud...@gmail.com wrote:
One question to build maintainers, and one patch submitted to top-level
configure.ac
So, not sure who wants to review this. From the darwin perspective, Ok.
On Nov 25, 2014, at 5:34 PM, David Malcolm dmalc...@redhat.com wrote:
This makes it easier to compare jit.sum files from different runs
gcc/testsuite/ChangeLog:
* jit.dg/jit.exp (jit-dg-test): Use $name rathen than $prog
when calling jit_check_compile to avoid embedding the full path
On Nov 25, 2014, at 12:15 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 25, 2014 at 03:27:40PM +0100, Tom de Vries wrote:
This patch fixes that by ensuring that we print that unsupported message
only once.
The resulting test result comparison diff is:
2014-11-25 Tom de Vries
On Nov 19, 2014, at 4:24 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 19 Nov 2014, Jakub Jelinek wrote:
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
is it still bound to wide_int (i.e.
On Nov 19, 2014, at 4:07 AM, Jakub Jelinek ja...@redhat.com wrote:
For TARGET_SUPPORTS_WIDE_INT == 0 should be hopefully ok. Not sure
about TARGET_SUPPORTS_WIDE_INT != 0, can it express any generic_wide_int, or
is it still bound to wide_int (i.e. MAX_BITSIZE_MODE_ANY_INT rounded up)
On Nov 19, 2014, at 5:51 AM, FX fxcoud...@gmail.com wrote:
The attached patch fixes 23 asan testsuite failures on x86_64-apple-darwin14,
where the backtrace features e.g. wrap_malloc instead of interceptor_malloc.
So I adjusted the dg-output patterns to match.
OK to commit to trunk?
Ok.
On Nov 19, 2014, at 1:57 PM, Jakub Jelinek ja...@redhat.com wrote:
Though, following patch is just fine for me too, I don't think it will
make a significant difference:
This version is fine by me.
--- gcc/simplify-rtx.c2014-11-19 15:39:24.073113107 +0100
+++ gcc/simplify-rtx.c
On Nov 14, 2014, at 2:26 AM, Richard Biener richard.guent...@gmail.com wrote:
On Fri, Nov 14, 2014 at 2:10 AM, Jeff Law l...@redhat.com wrote:
On 11/13/14 12:37, Mike Stump wrote:
I was doing a merge, and it failed to even compile the runtime
libraries due to checking in bitmap. bitmap goes
On Nov 19, 2014, at 10:23 PM, David Malcolm dmalc...@redhat.com wrote:
It's not clear to me if I can approve my own patches to the jit
So, to answer that, we look at MAINTAINERS, and look up your name:
Various Maintainers
jit David Malcolm
On Nov 18, 2014, at 1:52 PM, Jakub Jelinek ja...@redhat.com wrote:
OImode/XImode on i?86/x86_64 are not = MAX_BITSIZE_MODE_ANY_INT, because
they are never used for integer arithmetics (and there is no way
to represent all their values in RTL if not using CONST_WIDE_INT).
As the following
On Nov 18, 2014, at 3:42 PM, Jakub Jelinek ja...@redhat.com wrote:
No, I'm not touching tmp array at all in that case, only look at vp
individual bytes. Either they are all 0, or all 0xff, or I return NULL.
Oh, sorry, I misread where the break; in your code was going. I might have
been
On Nov 14, 2014, at 1:00 PM, Maciej W. Rozycki ma...@codesourcery.com wrote:
http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00242.html
is still waiting, please review.
Wait no more.
Ok.
On Nov 17, 2014, at 2:23 AM, Richard Biener richard.guent...@gmail.com wrote:
On Sun, Nov 16, 2014 at 2:01 AM, Patrick Palka patr...@parcs.ath.cx wrote:
Currently the top-level driver handles SIGINT by immediately killing
itself even when the driver has subprocesses (e.g. cc1, as) running. I
On Nov 17, 2014, at 10:55 AM, David Edelsohn dje@gmail.com wrote:
It's unfortunately AIX continues to use stabs rather than an embedded dwarf
format. Sigh.
The other complexity is IBM backported the feature to earlier versions
of AIX, but there is no major or minor AIX version number
On Nov 14, 2014, at 9:30 AM, Jeff Law l...@redhat.com wrote:
On 11/13/14 15:59, Mike Stump wrote:
The problem, since this is a hook now, one can’t just test ifdef
FUNCTION_PROLOGUE.
Right, but we can test the existence of the expander via the HAVE_xxx
interface.
Which ones, HAVE_prologue?
On Nov 14, 2014, at 9:51 AM, Mike Stump mikest...@comcast.net wrote:
On Nov 14, 2014, at 9:30 AM, Jeff Law l...@redhat.com wrote:
On 11/13/14 15:59, Mike Stump wrote:
The problem, since this is a hook now, one can’t just test ifdef
FUNCTION_PROLOGUE.
Right, but we can test the existence
I was doing a merge, and it failed to even compile the runtime libraries due to
checking in bitmap. bitmap goes to remove set bits from the bitmap (the second
hunk in a two hunk set), and it fails to update the current pointer. That
memory is freed and then reallocated and a new index is put
On Nov 13, 2014, at 9:21 AM, Jeff Law l...@redhat.com wrote:
Presumably we can get the same kinds of problems with ports that don't emit
prologues/epilogues as RTL?
I use prologue/epilogue to emit rtl in my port. I’d like this optimization to
kick on in my port, as we do explain everything
On Nov 13, 2014, at 2:33 PM, Jeff Law l...@redhat.com wrote:
We don’t support fprintf prologues anymore, they were removed years ago.
Did we ever get all the ports converted?
Ah… sorry, I was wrong. We merely hookized it and the tm.h interface is gone.
TARGET_ASM_FUNCTION_PROLOGUE and
On Nov 12, 2014, at 6:09 AM, Marek Polacek pola...@redhat.com wrote:
The following patch moves the path prunning code into a separate
procedure and fixes the failures.
Ok for trunk?
Ok.
On Nov 12, 2014, at 2:55 AM, Thomas Schwinge tho...@codesourcery.com wrote:
There is no mechanism in DejaGnu to pass environment variables to remote
boards (which we're using in internal testing), and we currently use that
to circle through available accelerators/libgomp plugins
So, two
On Nov 12, 2014, at 7:04 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
And I think GCC is wrong to wan here. The point of the Wempty-body
warning is to catch things like:
if(a);
return 2;
return 3;
However,
if(a)
;
return 2;
In the olden days, we didn’t have enough
On Nov 12, 2014, at 8:53 AM, Ramana Radhakrishnan
ramana.radhakrish...@arm.com wrote:
One of the problems we appear to face with multilib testing especially
with conflicting ABIs in the ARM world is the occasional case where a
testglue file is built for one ABI but gets linked against
On Nov 12, 2014, at 3:52 PM, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 12 November 2014 22:41, Jakub Jelinek ja...@redhat.com wrote:
I think we had discussions on this topic, the important thing is that we
don't want to generate different warnings based on whether -save-temps has
On Nov 11, 2014, at 6:22 AM, Martin Liška mli...@suse.cz wrote:
Following patch adds checking for aliasing support. Patch can bootstrap on
x86_64-apple-darwin1
I’m impressed, must have been a lot of work to port darwin1 to x86_64. :-)
On Nov 11, 2014, at 7:37 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote:
Both EGG and clang currently accept it.
EDG… I think you mean.
On Nov 11, 2014, at 8:02 AM, Ilya Enkovich enkovich@gmail.com wrote:
This patch adds simple runtime MPX tests.
Make check shows no fails for mpx.exp suite for
x86_64-unknown-linux-gnu{-m32,-mx32,}. OK for trunk?
Ok with any changes necessary for:
I’m assuming that this won’t break
On Nov 11, 2014, at 8:51 AM, Jiong Wang jiong.w...@arm.com wrote:
currently, if a testcase use dg-output, then absolute file path will occur
in the test summary reported by dejagnu which is bad.
ok for trunk?
Ok.
On Nov 11, 2014, at 11:06 AM, FX fxcoud...@gmail.com wrote:
Here’s v2 of the patch
OK to commit?
Ok with comments:
libvtv:
libvtv/
2014-11-11 Francois-Xavier Coudert fxcoud...@gcc.gnu.org
PR target/63610
* configure:
Missing Regenerate.
OK to commit?
Ok.
This
801 - 900 of 3045 matches
Mail list logo
