On Wed, 2 Jul 2014, David Edelsohn wrote:
* config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Use
BYTES_BIG_ENDIAN rather than WORDS_BIG_ENDIAN to check for byte
endianness.
This patch is okay. Thanks for noticing it.
Committed, thanks.
Maciej
Hi!
The following testcase is miscompiled on s390-linux (31-bit).
r202393 changed:
@@ -11946,11 +11949,11 @@
if (op1 == const0_rtx (code == LT || code == GE)
On July 3, 2014 1:06:30 AM CEST, Jason Merrill ja...@redhat.com wrote:
I think that makes sense; I'm not aware of anyone working on improving
LTO debugging.
I've done that in the past. So it would be nice to verify we don't regress
existing tests.
Richard.
Jason
On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
I think that makes sense; I'm not aware of anyone working on
improving LTO
debugging.
I think at this point all we care about is that with -flto we don't ICE
on
On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote:
On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
I think that makes sense; I'm not aware of anyone working on
improving LTO
debugging.
I
On 2 July 2014 09:02, Tom de Vries tom_devr...@mentor.com wrote:
On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup,
setting the
full register), it seems that it may have wanted = instead of +.
[ move discussion from gcc ml to
On 03-07-14 10:20, Marcus Shawcroft wrote:
On 2 July 2014 09:02, Tom de Vries tom_devr...@mentor.com wrote:
On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup,
setting the
full register), it seems that it may have wanted = instead of +.
On 4 June 2014 01:07, Jones, Joel joel.jo...@caviumnetworks.com wrote:
There is duplicate code for determining whether a load or store
instruction needs acquire or release semantics. This patch removes the
duplicated code and uses a modifying operator to output a/l instead. Since
the
Hi again,
this is IMHO more spot-on, because I figured out where exactly things go
wrong as part of the most_specialized_class call. In complete analogy
with the get_bindings case for functions, the problem happens in
get_class_bindings, thus I added a simple push_tinst_level check around
The following patch should fix 61618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8046c67..2cffcef 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -43211,12 +43211,10 @@ expand_vec_perm_pblendv (struct
Hi all,
The attached patch provides support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base).
Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase.
OK to commit?
FX
underflow.ChangeLog
Description: Binary data
On Thu, Jul 3, 2014 at 11:06 AM, FX fxcoud...@gmail.com wrote:
Hi all,
The attached patch provides support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base).
Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase.
+int
On Wed, Jul 02, 2014 at 07:27:07PM -0700, Jason Merrill wrote:
On 06/26/2014 03:22 PM, Marek Polacek wrote:
The following is a revamped patch for -Wsizeof-array-argument.
Its purpose is to detect suspicious usage of the sizeof operator on an array
function parameter.
Then the name should be
Hello
the following patch fixes some post-build-checks from our distro build
system, better to upstream it:
[ 4077s] E: rust 64bit-portability-issue
/home/abuild/rpmbuild/BUILD/rust-0.11.0+git.1403898616.aa1163b/src/libbacktrace/dwarf.c:2690,
2873, 3005
[ 4077s] E: rust 64bit-portability-issue
(I don't think -O0 is needed, but have to check with a testsuite run.)
On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is
optimized out anyway, and the division simplified at compile time.
FX
Hi,
I pulled out the guality.exp [p]type test extension from the actual
dwarf2out.c changes (which I will repost soon with some tweaks). I think
the test extension itself is useful on its own (and will use it to
add tests for my new patches).
All new tests PASS, except when using -flto, so
The expand_vec_perm_palignr is similar for SSSE3 and AVX2 cases,
but AVX2 requires more instructions to complete the scheme.
The patch below adds AVX2 support for six instructions, leaving SSSE3 for two.
Is it ok?
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index
On Thu, Jul 03, 2014 at 11:53:29AM +0200, Mark Wielaard wrote:
I pulled out the guality.exp [p]type test extension from the actual
dwarf2out.c changes (which I will repost soon with some tweaks). I think
the test extension itself is useful on its own (and will use it to
add tests for my new
On Mon, Jun 30, 2014 at 01:50:12PM -0600, Jeff Law wrote:
On 03/04/14 09:40, Marek Polacek wrote:
This should fix ICE on insane alignment. Normally, check_user_alignment
detects e.g. alignment 1 32, but not 1 28. However, record_align
is in bits, so it's actually 8 * (1 28) and that's
On Thu, Jul 3, 2014 at 11:25 AM, Uros Bizjak ubiz...@gmail.com wrote:
The attached patch provides support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets (our main user base).
Bootstrapped and regtested on x86_64-apple-darwin13. Comes with a testcase.
Index:
Hello Marc,
On 28 Jun 12:42, Marc Glisse wrote:
It would enable a number of optimizations, like constant
propagation, FMA contraction, etc. It would also allow us to remove
several builtins.
This should be main motivation for replacing built-ins.
But this approach IMHO should only be used for
On Mon, Jun 30, 2014 at 03:40:18PM -0700, Mike Stump wrote:
I glanced at it:
(gdb) p/x TYPE_ALIGN (type)
$1 = 2147483648
(gdb) p/x TYPE_ALIGN (type)
$2 = 0x8000
The callee is int, the caller uses unsigned int. The assert I see is because
the routines are not type correct:
=
Hi!
On Wed, 2 Jul 2014 21:14:11 +0200, Tobias Burnus bur...@net-b.de wrote:
Thomas Schwinge wrote:
Reopening this oldie:
index 5fa42f4..68440d18 100644
--- a/libgomp/testsuite/libgomp.fortran/fortran.exp
+++ b/libgomp/testsuite/libgomp.fortran/fortran.exp
@@ -14,6 +14,7 @@ set
On Thu, Jul 3, 2014 at 11:42 AM, FX fxcoud...@gmail.com wrote:
(I don't think -O0 is needed, but have to check with a testsuite run.)
On x86_64-apple-darwin, -O0 or -O1 are needed: at -O2 my “use_real” call is
optimized out anyway, and the division simplified at compile time.
You can mark
I'd suggest to name this fie ieee_underflow_1.f90 for consistency.
In fact, since the directory is called ieee/, I think I’ll rename the others so
they don’t all start with ieee_
BTW: underflow control also works on alpha, using following code:
Could you test the attached
On Thu, Jul 3, 2014 at 12:26 PM, FX fxcoud...@gmail.com wrote:
I'd suggest to name this fie ieee_underflow_1.f90 for consistency.
In fact, since the directory is called ieee/, I think I’ll rename the others
so they don’t all start with ieee_
BTW: underflow control also works on alpha,
On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
On Fri, 20 Jun 2014, Marek Polacek wrote:
+@item -fsanitize=bounds
+@opindex fsanitize=bounds
+
+This option enables instrumentation of array bounds. Various out of bounds
+accesses are detected. Flexible array members are not
2014-07-02 21:03 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
Hello!
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape
bytes in opcode). This situation happens when REX prefix is used in SSE4
instructions. This
patch tries to avoid such
On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote:
On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
On Fri, 20 Jun 2014, Marek Polacek wrote:
+@item -fsanitize=bounds
+@opindex fsanitize=bounds
+
+This option enables instrumentation of array bounds. Various
On 02/07/14 22:42 +0100, Goncalo Carvalho wrote:
Hi,
In parallel/unique_copy.h __counter is never deleted.
I'm also trying to follow from other posts how to submit a patch but
is well possible I missed some of the conventions. Many apologies if
that's the case.
Thanks for this, it looks
2014-07-02 20:21 GMT+04:00 Andi Kleen a...@firstfloor.org:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This situation happens
when REX prefix is used in SSE4 instructions.
2014-07-02 20:27 GMT+04:00 Jakub Jelinek ja...@redhat.com:
On Wed, Jul 02, 2014 at 09:21:25AM -0700, Andi Kleen wrote:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This
Hi!
On Tue, 13 Aug 2013 13:06:30 +0200, I wrote:
I noticed something strange in the libgomp testresults (but not
necessarily specific to libgomp): an arbitrary set of the Fortran
execution tests are run just for -O, and others for each of the full set
of torture options: -O0, -O1, -O2, and so
On Thu, Jul 03, 2014 at 12:46:35PM +0200, Jakub Jelinek wrote:
On Thu, Jul 03, 2014 at 12:41:46PM +0200, Marek Polacek wrote:
On Sat, Jun 28, 2014 at 06:52:00PM +0200, Gerald Pfeifer wrote:
On Fri, 20 Jun 2014, Marek Polacek wrote:
+@item -fsanitize=bounds
+@opindex fsanitize=bounds
On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote:
2014-07-02 20:21 GMT+04:00 Andi Kleen a...@firstfloor.org:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape bytes in opcode). This
On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote:
Thanks Janis and Mikael for your replies (nearly a year ago...), but
still my questions remain to be answered: in my understanding, the
libgomp testsuite is not the place for compiler torture testing
(different optimization flags
Hi!
On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote:
Thanks Janis and Mikael for your replies (nearly a year ago...), but
still my questions remain to be answered: in my understanding, the
libgomp
On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 3a0f99b..44c4990 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,11 @@
2014-06-30 Christophe Lyon
2014-07-03 14:56 GMT+04:00 Jakub Jelinek ja...@redhat.com:
On Thu, Jul 03, 2014 at 02:49:10PM +0400, Ilya Enkovich wrote:
2014-07-02 20:21 GMT+04:00 Andi Kleen a...@firstfloor.org:
Ilya Enkovich enkovich@gmail.com writes:
Silvermont processors have penalty for instructions having 4+
On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 44c4990..73709c6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,16 @@
2014-06-30 Christophe Lyon
On Thu, Jul 03, 2014 at 01:06:48PM +0200, Thomas Schwinge wrote:
On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote:
Thanks Janis and Mikael for your replies (nearly a year ago...), but
still my
On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich enkovich@gmail.com wrote:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape
bytes in opcode). This situation happens when REX prefix is used in SSE4
instructions. This
patch tries to avoid
On Thu, 2014-07-03 at 12:05 +0200, Jakub Jelinek wrote:
On Thu, Jul 03, 2014 at 11:53:29AM +0200, Mark Wielaard wrote:
I pulled out the guality.exp [p]type test extension from the actual
dwarf2out.c changes (which I will repost soon with some tweaks). I think
the test extension itself is
Hello!
There is already a higher priority for registers not requiring REX.
My patch affects cases when compiler has to use xmm8-15 and it just
tries to say LRA to assign them for non SSE4 instructions. I doubt it
would have some use for other targets than Silvermont.
When it is just a
On Thu, Jul 03, 2014 at 12:19:15PM +0200, Thomas Schwinge wrote:
I found the following to work (but so far only did libgomp testing), but
that is a little bit more intrusive, but may actually be the right thing
to do. (Possibly also in additional places where ${tool}_target_compile
is used?
2014-07-03 15:11 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
On Thu, Jul 3, 2014 at 12:45 PM, Ilya Enkovich enkovich@gmail.com wrote:
Silvermont processors have penalty for instructions having 4+ bytes of
prefixes (including escape
bytes in opcode). This situation happens when REX prefix
On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote:
I didn't find a nice way to fix peephole2 patterns to take register
constraints into account. Is there any way to do it?
Use REX_SSE_REGNO_P (REGNO (operands[...])) in the insn C constraint.
Also fully restrict
Hi!
On Thu, 3 Jul 2014 13:35:15 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 12:19:15PM +0200, Thomas Schwinge wrote:
I found the following to work (but so far only did libgomp testing), but
that is a little bit more intrusive, but may actually be the right thing
to
Hi!
On Thu, 3 Jul 2014 13:09:57 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 01:06:48PM +0200, Thomas Schwinge wrote:
On Thu, 3 Jul 2014 12:58:32 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 12:54:32PM +0200, Thomas Schwinge wrote:
Thanks
Ping!
2014-06-24 13:37 GMT+04:00 Yuri Rumyantsev ysrum...@gmail.com:
Hi All,
Here is a fix for PR 61576 - additional test was added that block
containing reduction statement is predecessor of block containing phi
to choose the correct condition.
Bootstrap and regression testing did not
Hi,
Many thanks! I'll try add a test to the suite (unsure how foolproof
will be in terms of detecting memory usage).
The 11000 is simply to go beyond the minimum unique_count needed to
specialise the parallel version. This was on
g++ (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6) but the issue still
On Thu, Jul 03, 2014 at 02:37:41PM +0200, Thomas Schwinge wrote:
OK to document as follows?
2014-07-03 Jakub Jelinek ja...@redhat.com
libgomp/
* testsuite/libgomp.fortran/fortran.exp: Explain
gfortran-dg-runtest usage.
You wrote the patch, so put your name on it. Ok
On 03/07/14 13:40 +0100, Goncalo Carvalho wrote:
Hi,
Many thanks! I'll try add a test to the suite (unsure how foolproof
will be in terms of detecting memory usage).
Yes, it might not be worth adding to the testsuite, but I want to be
able to verify the patch changes something :-)
The 11000
Hi!
I have a need to pass »flags« to a gfortran-dg-runtest call, but found
that not to be possible as the *-dg-runtest interfaces are narrowed
compared to dg-runtest. Here is a patch to fix that. So far only tested
in libgomp. OK in principle? I'll then test this thoroughly, and, of
course,
Here’s an updated patch, providing support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc.
Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha.
OK to commit?
underflow.ChangeLog
Description: Binary data
underflow.diff
On Thu, Jul 3, 2014 at 2:43 PM, FX fxcoud...@gmail.com wrote:
Here’s an updated patch, providing support for underflow control in the
IEEE_ARITHMETIC module, for x86/x86_64 targets and alpha-glibc.
Bootstrapped and regtested on x86_64-apple-darwin13, tested by Uros on alpha.
The testcase
2014-07-03 16:07 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
On Thu, Jul 3, 2014 at 1:50 PM, Ilya Enkovich enkovich@gmail.com wrote:
I didn't find a nice way to fix peephole2 patterns to take register
constraints into account. Is there any way to do it?
Use REX_SSE_REGNO_P (REGNO
*ping*
Thanks,
James
On Tue, Jun 24, 2014 at 09:45:28AM +0100, James Greenhalgh wrote:
Hi,
vec_concat ( { a, b }, { c, d }) should give a new vector { a, b, c, d }.
On big-endian aarch64 targets, we have to think carefully about what this
means as we map GCC's view of endian-ness on to
On Tue, Jul 1, 2014 at 10:32 AM, Bin.Cheng amker.ch...@gmail.com wrote:
Sorry for this late reply, I spent some time in understanding the problem.
On Tue, Jun 24, 2014 at 12:36 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Jun 23, 2014 at 11:49 AM, Bin Cheng bin.ch...@arm.com
+@opindex Wodr
+@opindex Wno-odr
+@opindex Wodr
+Warn about One Definition Rule violations during link time optimization.
+Require @option{-flto-odr-type-merging} to be enabled. Enabled by default
Duplicated @opindex Wodr. (@item is missing)
Requires. Period after default
But according to
On 02/07/14 13:05, Charles Baylis wrote:
On 30 June 2014 14:26, Richard Earnshaw rearn...@arm.com wrote:
On 30/06/14 13:53, Charles Baylis wrote:
I see two options to fix it - one is to teach the back-end to
successfully generate code for this insn, and the other is to teach
the back-end that
On Wed, Jul 2, 2014 at 5:06 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
Firstly, it adds back the split conditions that I accidentally removed.
Without it the dot insns are never generated, or rather, always split
back to a separate compare instruction.
Secondly, the shift amount
Jason Merrill ja...@redhat.com writes:
On 06/27/2014 03:27 AM, Dodji Seketeli wrote:
+ print.prev_was_system_token != !!in_system_header_at(loc))
+/* The system-ness of this token is different from the one
+ of the previous token. Let's emit a line change to
+
Hello,
From gcc/i386/config/mingw32.h, STARTFILE_SPEC and ENDFILE_SPEC include
crtbegin.o and crtend.o unconditionally.
libgcc/config.host includes crtbegin.o and crtend.o in extra_parts for
i[34567]86-*-mingw* but not for x86_64-*-mingw*.
Building a toolchain for x86_64-pc-mingw32 then rapidly
The VFP9 floating-point unit (as occasionally used with ARM9 devices)
has an erratum (760019) whereby it is possible for floating-point
division and square-root instructions to be executed twice. This is not
a problem if the destination register is not used as an input, but can
cause incorrect
Moving into own thread from
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01895.html
This fixes the compilation failures of gcc.target/arm/simd/vexts64_1.c and
gcc.target/arm/simd/vextu64_1.c that I introduced in r by unsharing the test
body on AArch64. (As [u]int64x1_t are vector types on
Yes. That's exactly the problem I'm trying to solve here. I'm making
partial int modes have real corresponding types, and they can be any
bit size, with target PS*modes to match. The MSP430, for example, has
20-bit modes, 20-bit operands, and __int20. Rounding up to byte sizes
forces
And the hardware really loads 20 bits and not 24 bits? If so, I
think you might want to consider changing the unit to 4 bits instead
of 8 bits. If no, the mode is padded and has 24-bit size so why is
setting TYPE_PRECISION to 20 not sufficient to achieve what you
want?
The hardware
On 07/03/2014 06:12 PM, DJ Delorie wrote:
The hardware transfers data in and out of byte-oriented memory in
TYPE_SIZE_UNITS chunks. Once in a hardware register, all operations
are either 8, 16, or 20 bits (TYPE_SIZE) in size. So yes, values are
padded in memory, but no, they are not padded in
On Thu, Jul 3, 2014 at 4:15 PM, Richard Earnshaw rearn...@arm.com wrote:
The VFP9 floating-point unit (as occasionally used with ARM9 devices)
has an erratum (760019) whereby it is possible for floating-point
division and square-root instructions to be executed twice. This is not
a problem if
Hi Cesar!
On Wed, 2 Jul 2014 17:27:48 -0700, Cesar Philippidis ce...@codesourcery.com
wrote:
Thomas, is this patch ok for gomp-4_0-branch?
Tobias has approved the patch (and I'm confirming it does fix the issue);
thanks to you and Tobias for looking into this!
If so, please check it in.
Support operator (...) per CWG 1473.
I'll be AFK over the holiday.
Bootstrapped and tested on x86_64-linux.
OK?
I'm less sure if this is appropriate for 4.9.
Index: cp/parser.c
===
--- cp/parser.c (revision 212248)
+++
On 07/02/2014 06:30 PM, Jan Hubicka wrote:
But this is one of things that was not quite clear to me. I know that
polymorphic type A
was created at a give memory location. THis means that accesses to that
location in one
alias class has been made.
Now I destroy A and turn it into B,
On July 3, 2014 9:55:36 AM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote:
On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek ja...@redhat.com
wrote:
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
I think that makes sense;
On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote:
Well, simply removing the regression testing for LTO is a maintainance
nightmare as well.
The guality testsuite is very noisy anyway with all the xfail and xpass.
Let's keep it as is then?
Jakub
Hi!
Several places in wi::mul_internal didn't handle high parameter
and would return the low bits instead of high bits.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2014-07-03 Jakub Jelinek ja...@redhat.com
PR tree-optimization/61682
*
Hi!
The rhs1 of CONVERT_EXPR_CODE_P doesn't have to be a SSA_NAME, can be e.g.
invariant like ADDR_EXPR of a var, but ifcombine didn't think about that
possibility.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.9/4.8?
2014-07-03 Jakub Jelinek
Hi!
update_ssa that expand_thunk calls, if it needs to change anything,
computes CDI_DOMINATORS, but we assert that dominators are not computed
when we release e.g. an unused thunk.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk/4.9?
2014-07-03 Jakub Jelinek
On Jul 3, 2014, at 5:49 AM, Thomas Schwinge tho...@codesourcery.com wrote:
I have a need to pass »flags« to a gfortran-dg-runtest call, but found
that not to be possible as the *-dg-runtest interfaces are narrowed
compared to dg-runtest. Here is a patch to fix that. So far only tested
in
On 07/03/2014 10:01 AM, Thomas Schwinge wrote:
I'm happy to, but why don't we just get you set up? You're covered by
the general Mentor Graphics/CodeSourcery copyright assignment. Please
request an account per http://gcc.gnu.org/svnwrite.html, and on
There were two cases, where we did not have links any more, but
textual references to gcc.gnu.org via http.
This addresses it.
Applied.
Gerald
Index: gcc-2.96.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.96.html,v
retrieving
Latest results for 4.7.x
-tgc
Testresults for 4.7.4:
i386-pc-solaris2.8
i386-pc-solaris2.9
sparc-sun-solaris2.8
sparc-sun-solaris2.9
sparc64-sun-solaris2.8
x86_64-apple-darwin13.2.0
x86_64-pc-linux-gnu
Index: buildstat.html
Latest results for 4.8.x
-tgc
Testresults for 4.8.3:
i686-pc-linux-gnu
sparc-sun-solaris2.9
sparc64-sun-solaris2.9
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.8
Is what gdb prints for ptype stable across different gdb versions (except
for whitespace that you canonicalize)? If yes, this looks good to me.
Mark Yes, I believe it is (I tested against gdb git master and gdb 7.6.50).
Mark It tries to print the expression as a canonical C type, so it should
On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote:
Well, simply removing the regression testing for LTO is a
maintainance nightmare as well.
The guality testsuite is very noisy anyway with all the xfail and
That's what'll need fixing then.
Can I change TYPE_SIZE to TYPE_SIZE_WITH_PADDING then? Because it's
not reflecting the type's size any more. Why do we have to round up a
type's size anyway? That's a pointless assumption *unless* you're
allocating memory space for it, and in that case, you
On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote:
On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote:
Well, simply removing the regression testing for LTO is a
maintainance nightmare as well.
The
On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote:
On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote:
On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 08:37:07PM +0200, Richard Biener wrote:
Well, simply removing the
On Thu, 2014-07-03 at 22:14 +0200, Jakub Jelinek wrote:
On Thu, Jul 03, 2014 at 10:04:35PM +0200, Mark Wielaard wrote:
On Thu, 2014-07-03 at 21:52 +0200, Richard Biener wrote:
On July 3, 2014 8:38:14 PM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jul 03, 2014 at 08:37:07PM +0200,
This patch implements the TARGET_ATOMIC_ASSIGN_EXPAND_FENV for
powerpc-fpu. I have to adjust current c11-atomic-exec-5 testcase
because for IBM long double 0 += LDBL_MAX might generate
overflow/underflow in internal __gcc_qadd calculations.
The c11-atomic-exec-5 now passes for linux/powerpc,
Hello Dodji,
I found time this morning to run your changes through our system. I patched our
gcc-4.8.1 with your
latest change, and ran it through our folly testsuite.
One thing that I immediately noticed was that this increased the preprocessed
size substantially.
When preprocessing my
On Thu, 3 Jul 2014, Tom G. Christensen wrote:
Latest results for 4.8.x
Thanks, applied!
Gerald
Jakub Jelinek ja...@redhat.com writes:
@@ -1302,12 +1310,28 @@ wi::mul_internal (HOST_WIDE_INT *val, co
/* Handle multiplications by 1. */
if (op1 == 1)
{
+ if (high)
+ {
+ if (sgn == SIGNED wi::neg_p (op2))
+ val[0] = -1;
+ else
+ val[0]
On Jul 3, 2014, at 2:53 PM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Jakub Jelinek ja...@redhat.com writes:
+ if (sgn == SIGNED wi::neg_p (op1))
I think the preferred way of writing this is wi::neg_p (op1, svn)
Yes.
The bswap pass deals with 3 possibly different byte size: host, target and the
size a byte marker occupied in the symbolic_number structure [1]. However, as
of now the code mixes the three size. This works in practice as the pass is
only enabled for target with BITS_PER_UNIT == 8 and nobody
Hi,
This crash is due to fail to consider the exception situation that
the insn variable may not be a insn at all.
arm.c (thumb1_reorg): if the
selected insn is not a insn, continue to next bb.
---
gcc/config/arm/arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Andi Kleen a...@linux.intel.com
In my tests the optimized glibc out of line strcmp is always faster than
using inline rep ; cmpsb, even for small strings. The Intel optimization manual
also recommends to not use it. So remove the cmpstrnsi instruction.
Tested on Sandy Bridge, Westmere
From: Andi Kleen a...@linux.intel.com
The peephole that removes the code to compute a tristate for cmpstrnsi
when only a boolean jump is needed never triggers in my tests. Just
remove it.
gcc/:
2014-07-02 Andi Kleen a...@linux.intel.com
* config/i386/i386.md: Remove peepholes for
98 matches
Mail list logo
