http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08
19:40:01 UTC ---
Author: jakub
Date: Mon Oct 8 19:39:56 2012
New Revision: 192220
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192220
Log:
PR c++/54858
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54858
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-10-08
19:42:12 UTC ---
Author: jakub
Date: Mon Oct 8 19:42:06 2012
New Revision: 192221
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192221
Log:
PR c++/54858
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08
19:50:21 UTC ---
(In reply to comment #40)
I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems
that don't have it, the tests will simply fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #42 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
2012-10-08 20:10:26 UTC ---
(In reply to comment #41)
(In reply to comment #40)
I still don't see why the _POSIX_TIMERS 0 check exists at all. On systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08
20:31:01 UTC ---
Both OpenBSD and FreeBSD seem to have nanosleep calls documented as...
The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX'')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #44 from Jonathan Wakely redi at gcc dot gnu.org 2012-10-08
20:42:22 UTC ---
(In reply to comment #42)
You want to find an test such that:
(your test) = (nanosleep is the one you want)
That's why I was asking about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2012-10-08 20:46:04
UTC ---
Author: glisse
Date: Mon Oct 8 20:45:56 2012
New Revision: 192223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=192223
Log:
2012-10-08 Marc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
Bug #: 54860
Summary: [4.8 Regression]: build fails on cris-elf configuring
libgfortran due to recent attribute changes in core
gcc
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54400
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Summary|recognize haddpd|recognize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
Bug #: 54861
Summary: std::atomic_signal_fence(std::memory_order_seq_cst)
issues unnecessary mfence
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54861
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
Dodji Seketeli dodji at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
--- Comment #3 from Zoltan Glozik zoltan at epochcapital dot com.au
2012-10-08 22:11:26 UTC ---
Thanks Jon, how weird to communicate with you on the gcc mailing lists...
I hope you are doing well.
Cheers,
Zoltan
-Original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #142 from Jan Hubicka hubicka at gcc dot gnu.org 2012-10-08
22:19:55 UTC ---
After updating Mozilla this weekend, I definitely bloat up 8GB machine. The pak
in TOP is around 9-10GB. I checked malloc usage and there are not many
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
--- Comment #2 from dodji at seketeli dot org dodji at seketeli dot org
2012-10-08 22:23:25 UTC ---
hp at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org a écrit:
Just configure for --target=cris-elf and make all-gcc to produce
f951.
So I did this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #45 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-08
22:27:08 UTC ---
I can confirm the existence of sched_yield() back to Libc-166 in 1997 on
darwin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #143 from Steven Bosscher steven at gcc dot gnu.org 2012-10-08
22:30:20 UTC ---
Created attachment 28395
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28395
Use size_t for tree code book-keeping
...because overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
--- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-08
22:46:52 UTC ---
(In reply to comment #2)
$ ./f951 -quiet ../../prtests/test.f -ffixed-form
$
I am not seeing the crash.
Does running valgrind on that show
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54862
Bug #: 54862
Summary: [4.8 Regression] error: comparison between signed and
unsigned integer expressions in simplify-rtx.c
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #46 from Jack Howarth howarth at nitro dot med.uc.edu 2012-10-09
00:46:08 UTC ---
Revised patch posted to libstdc++ mailing list...
http://gcc.gnu.org/ml/libstdc++/2012-10/msg00047.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
--- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-09
01:48:48 UTC ---
(In reply to comment #3)
I'll try a few other hosts here.
Build also fails for x86_64 Fedora 8 (gcc-4.1.2-33) and Debian squeeze 6.0.4
gcc version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54860
--- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-10-09
03:25:53 UTC ---
(In reply to comment #4)
(In reply to comment #3)
I'll try a few other hosts here.
Build also fails for x86_64 Fedora 8 (gcc-4.1.2-33) and
Ping.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
Behalf Of Bin Cheng
Sent: Tuesday, September 25, 2012 4:00 PM
To: 'Richard Sandiford'
Cc: Ramana Radhakrishnan; Richard Earnshaw; gcc-patches@gcc.gnu.org
Subject: RE: [Updated]:
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the merging
are
really dead. And it turns out we have some zombies around.
On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
On 7 October 2012 22:13, Jonathan Wakely jwakely@gmail.com wrote:
On Oct 7, 2012 12:00 AM, NightStrike nightstr...@gmail.com wrote:
On Sat, Oct 6, 2012 at 7:30
On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher stevenb@gmail.com wrote:
On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
The following patch speeds LRA up more on PR54146. Below times for
compilation of the test on gcc17.fsffrance.org (an AMD machine):
Before:
real=1214.71
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we don't want VRP in early optimizations.
Richard.
Thanks,
Dehao
On Sat, Oct 6,
Hi,
When running libstdc++ regression test on Cortex-M0, the case 49445.cc fails
with error message:
/tmp/ccMqZdgc.o: In function `std::atomicfloat::load(std::memory_order)
const':^M
/home/build/work/GCC-4-7-build/build-native/gcc-final/arm-none-eabi/armv6-m/
libstdc++-v3/include/atomic:202:
On 8 October 2012 09:18, Richard Guenther richard.guent...@gmail.com wrote:
On Mon, Oct 8, 2012 at 3:16 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 7 October 2012 21:31, Manuel López-Ibáñez wrote:
On 7 October 2012 22:13, Jonathan Wakely jwakely@gmail.com wrote:
On Oct 7, 2012
Recent tests added to gcc.dg/tree-ssa don't clean up after themselves.
Tested on x86_64-suse-linux, applied on the mainline as obvious.
2012-10-08 Eric Botcazou ebotca...@adacore.com
* gcc.dg/tree-ssa/slsr-30.c: Use correct cleanup directive.
*
On Mon, Oct 08, 2012 at 09:20:47AM +0200, Richard Guenther wrote:
On Sun, Oct 7, 2012 at 11:27 PM, Steven Bosscher stevenb@gmail.com
wrote:
The next bottle-neck in my timings is in
lra-eliminate.c:lra_eliminate(), in this loop:
FOR_EACH_BB (bb)
FOR_BB_INSNS_SAFE (bb, insn,
On Fri, 5 Oct 2012, Steven Bosscher wrote:
On Fri, Sep 14, 2012 at 2:26 PM, Richard Guenther rguent...@suse.de wrote:
If you can figure out a better name for the function we should
probably move it to cfganal.c
It looks like my previous e-mail about this appears to have gone got
somehow,
On Fri, Oct 5, 2012 at 5:01 PM, Marc Glisse marc.gli...@inria.fr wrote:
[I am still a little confused, sorry for the long email...]
On Tue, 2 Oct 2012, Richard Guenther wrote:
+ if (TREE_CODE (op0) == VECTOR_CST TREE_CODE (op1) == VECTOR_CST)
+{
+ int count = VECTOR_CST_NELTS
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we don't want VRP in early optimizations.
I am not quite sure about that. VRP
On Sat, Oct 6, 2012 at 12:48 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
This patch adds machinery to genmodes.c so that largest possible sizes of
various data structures can be determined at gcc build time. These
functions create 3 symbols that are available in insn-modes.h:
On Sat, Oct 6, 2012 at 5:55 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new predicate
CONST_SCALAR_INT_P.
I did not include a few that were tightly
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the
merging are
really dead. And it turns out we have some zombies around.
On Sun, Oct 7, 2012 at 12:44 PM, Tom de Vries tom_devr...@mentor.com wrote:
Richard,
attached patch checks that unlinked uses do not contain ssa-names when
renaming.
This assert triggers when compiling (without the fix) the PR54735 example.
AFAIU, it was due to chance that we caught the
On Sun, Oct 7, 2012 at 4:58 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 10/07/2012 09:19 AM, Richard Guenther wrote:
In fact, you could argue that the tree level did it wrong (not that i am
suggesting to change this). But it makes me think what was going on
when
the decision to
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus 0, !=0 and the neon
thing are equivalent). Which would leave to decide what the expansion of
vec_cond_expr passes to the
On Mon, Oct 8, 2012 at 11:18 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 7:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Sun, Oct 7, 2012 at 5:15 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I added a santy check that after fixup all types that lost in the
merging are
On Mon, Oct 8, 2012 at 11:34 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 8 Oct 2012, Richard Guenther wrote:
VEC_COND_EXPR is more complicated. We could for instance require that it
takes as first argument a vector of -1 and 0 (thus 0, !=0 and the neon
thing are equivalent). Which
2) As we query the type_hash while we are rewritting the types,
we run into instability of the hashtable. This manifests itself
as an ICE when one adds sanity check that while merging function
types their arg types are equivalent, too.
This ICEs compiling i.e.
On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch would be unnecessary. Should we add a VRP
pass?
No, we
Hi Richard,
I have incorporated your comments.
Yes, call dump_mem_ref then, instead of repeating parts of its body.
Reference object is not yet created at the place we check for invariance. It
is still a tree expression. I created a common function and used at all places
to dump the step,
On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I benchmarked the patch moving loop header copying and it is quite noticeable
win.
Some testsuite updating is needed. In many cases it is just because the
optimizations are now happening earlier.
There are however few
Hi,
in this PR submitter points out that in the -Wparentheses warning, for, eg,
char in[4]={0}, out[6];
out[1] = in[1] 0x0F | ((in[3] 0x3C) 2);
warning: suggest parentheses around arithmetic in operand of ‘|’
[-Wparentheses]
the caret points to end of the expression, ie the final closing
Applied the following changes to 4.7/4.8 release notes caveats.
Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.127
retrieving revision 1.128
diff -u -p -r1.127
On Mon, Oct 8, 2012 at 12:01 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 11:04 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen de...@google.com wrote:
Attached is the updated patch. Yes, if we add a VRP pass before
profile pass, this patch
On Mon, Oct 8, 2012 at 12:01 PM, Kumar, Venkataramanan
venkataramanan.ku...@amd.com wrote:
Hi Richard,
I have incorporated your comments.
Yes, call dump_mem_ref then, instead of repeating parts of its body.
Reference object is not yet created at the place we check for invariance. It
is
On Mon, Oct 8, 2012 at 10:18 AM, Jakub Jelinek ja...@redhat.com wrote:
I'm playing with a patch to expand the insns_with_changed_offsets
bitmap to an sbitmap, and will send a patch if this works better.
Or make insns_with_changed_offsets a VEC of insns (or a pointer-set).
Or use
On Sun, Oct 7, 2012 at 5:59 PM, Vladimir Makarov wrote:
* lra-lives.c (lra_start_point_ranges, lra_finish_point_ranges):
Remove.
(process_bb_lives): Change start regno in
EXECUTE_IF_SET_IN_BITMAP. Iterate on DF_LR_IN (bb) instead of
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int foo (int v[])
{
int r;
for (i = 0; i SIZE; i++)
r = v[i];
return r;
}
which was a bit of a surprise. On second thoughts, this isn't entirely
On Sat, Oct 6, 2012 at 11:34 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
I benchmarked the patch moving loop header copying and it is quite
noticeable win.
Some testsuite updating is needed. In many cases it is just because the
optimizations are now happening earlier.
There are
On 08/13/2012 05:42 PM, Vladimir Makarov wrote:
On 08/13/2012 06:32 AM, Bernd Schmidt wrote:
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much
yes, my bad. here it is with the patches.
On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
This is the third patch in the series of patches to fix constant math.
this one changes some predicates at the rtl level to use the new
predicate CONST_SCALAR_INT_P.
I did not include a few that were
This replaces my_rev_post_order_compute in PRE by the already
existing inverted_post_order_compute, with the necessary adjustments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther rguent...@suse.de
* tree-ssa-pre.c (postorder_num):
This fixes PR54825, properly FRE/PRE vector BIT_FIELD_REFs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-10-08 Richard Guenther rguent...@suse.de
PR tree-optimization/54825
* tree-ssa-sccvn.c (vn_nary_length_from_stmt): Handle BIT_FIELD_REF.
On Mon, Oct 8, 2012 at 1:36 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
yes, my bad. here it is with the patches.
Just for the record, ok!
Thanks,
Richard.
On 10/06/2012 11:55 AM, Kenneth Zadeck wrote:
This is the third patch in the series of patches to fix constant math.
this one
Jason Merrill ja...@redhat.com writes:
OK.
Thanks. Committed to trunk at revision r192199.
--
Dodji
It appears that the patch should also special case the scan-assembler
.internal.*Foo.methodEv
tests in g++.dg/ext/visibility/pragma-override1.C and
g++.dg/ext/visibility/pragma-override2.C
on darwin as well...
Done, thanks.
Jason,
These tests are still failing on darwin. I
On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int foo (int v[])
{
int r;
for (i = 0; i SIZE; i++)
r = v[i];
return r;
On Mon, Oct 8, 2012 at 2:32 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 8, 2012 at 12:38 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
we recently noticed that, even at -O3, the compiler doesn't figure out that
the following loop is dumb:
#define SIZE 64
int
lto_obj_file_open allocates:
lo = XCNEW (struct lto_simple_object);
However, the data is never freed - neither explicitly nor in
lto_obj_file_close.
In the attached patch, I free the memory now after the call to
lto_obj_file_close.
Build and regtested on x86-64-gnu-linux.
OK for the
On Mon, Oct 8, 2012 at 2:39 PM, Tobias Burnus bur...@net-b.de wrote:
lto_obj_file_open allocates:
lo = XCNEW (struct lto_simple_object);
However, the data is never freed - neither explicitly nor in
lto_obj_file_close.
In the attached patch, I free the memory now after the call to
On Mon, Oct 8, 2012 at 1:00 AM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
This patch changes the worklist-like bitmap in lra_eliminate() to an
sbitmap. Effect on compile time:
I have another patch to also make lra_constraint_insn_stack_bitmap.
Without patch:
log.0: LRA
Il 07/10/2012 19:18, Steven Bosscher ha scritto:
Hello,
The attached patch adds a DF changeable flag to compute a subset of
reaching definitions that are also live at the program points they
reach. This is an idea I discussed with Paolo many years ago already,
but until today it hadn't
The following patch fixes PR52945 on Darwin. It as beem approved
by Jan Hubicka in PR52945#c5. Since I don't have write permission,
could someone commit it for me?
TIA
Dominique
2012-10-08 Dominique d'Humieres domi...@lps.ens.fr
PR gcc/52945
*
On Android NDK libstdc++ is configured, built and packaged separately.
The problem is not dependency on libgcc sources but rather dependency
on the symlink which is generated during libgcc build and cannot be
found if libstdc++ is configured and built separately.
It was working fine for 4.4 and
On Fri, Oct 5, 2012 at 7:19 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Oct 05, 2012 at 03:59:55PM +0200, Richard Guenther wrote:
I don't think we want to rely on that ... so just keep the push/pop_cfun.
Ok, so this is what I'm retesting (basically just comments added and the two
lines
On 10/08/2012 03:57 PM, Jason Merrill wrote:
This is definitely an improvement, though for warnings about issues
with the left or right argument, we could use the EXPR_LOCATION of the
problematic argument rather than the location of the new operand.
I agree. Let me see if I can figure out
On 10/08/2012 03:43 PM, Pavel Chupin wrote:
This issue has been introduced in 4.7.
Irrespective of what we are eventually going to do from a practical
point of view, I think it would be important to understand when/what
introduced the issue: did you analyze that in any detail?
Thanks,
Paolo.
On Mon, Oct 8, 2012 at 3:27 PM, Paolo Bonzini wrote:
I wonder if we actually need the non-pruned version anywhere...
I don't think so, but I'm not sure. Only ddg.c and loop-iv.c access
the DF_RD results directly (i.e. not via DU/UD chains). For loop-iv
the pruned version is fine. For ddg I
2) As we query the type_hash while we are rewritting the types,
we run into instability of the hashtable. This manifests itself
as an ICE when one adds sanity check that while merging function
types their arg types are equivalent, too.
This ICEs compiling i.e.
On Fri, 28 Sep 2012, Uros Bizjak wrote:
2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because
vec_duplicate doesn't match vec_concat. Do we really need to duplicate (no
pun intended) the pattern?
You can add this transformation to simplify-rtx.c. Probably vec_concat
with two equal
On 10/04/2012 11:40 AM, Jason Merrill wrote:
Recent versions of binutils seem to have started putting ' around the
version number in bfd/configure.in, which was confusing gcc configure.
When this change was made to binutils, the other directories changed to
using bfd/configure --version to
Ping. This patch
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01907.html (non-C parts) is
pending review.
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
Pavel Chupin pavel.v.chu...@gmail.com ha scritto:
It has been changed here:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=630d52ca0a88d173f89634a5d7dd8aee07d04d80
subj:Move gthr to toplevel libgcc
I see, thanks. Let's add Rainer in CC, see if he expected this to happen or not.
Paolo
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks ok to me (you can wrap that inside a
gcc.target/i386/pr54445-1.c FAILs to execute on Solaris 9 with native TLS:
ld.so.1: pr54445-1.exe: fatal: pr54445-1.exe: object requires TLS, but TLS faile
d to initialize
The following patch fixes this by both requiring TLS runtime support and
adding the necessary options.
Tested with the
On 10/8/2012 11:01 AM, Nathan Froyd wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding a 32 bit
field to rtx_def looks
On 10/06/12 01:50, Paolo Carlini wrote:
On 10/06/2012 02:33 AM, Joe Seymour wrote:
I'm seeing tr2/headers/all.cc fail in the libstdc++ testsuite:
In file included from
src/gcc-mainline/libstdc++-v3/testsuite/tr2/headers/all.cc:22:0:
Ping, again.
On 1 October 2012 16:56, Simon Baldwin sim...@google.com wrote:
Ping, again.
On 21 September 2012 12:45, Simon Baldwin sim...@google.com wrote:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00459.html
Full text of previous message and context at URL above. No
If the size of the inner array elements is 1 and we do not need a
cookie, we do not need to insert an overflow check. This applies to the
relatively frequent new char[n] case.
Built and regression-tested on x86_64-redhat-linux-gnu. Okay for trunk?
--
Florian Weimer / Red Hat Product
On Fri, 5 Oct 2012, Jason Merrill wrote:
+ error_at (loc, conversion of scalar to vector
+ involves truncation);
These errors should print the types involved. They also need to be
suppressed when !(complain tf_error).
Hello,
here is a new
As the testcase shows, we ICEd when generating the debug info for C++
and not splitting types into multiple registers.
The issue is in vt_add_function_parameter that we assumed that the
DECL_RTL expression was a pseudo register. But in that case it is
better to just give up than to ICE.
On Mon, Oct 8, 2012 at 4:40 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 28 Sep 2012, Uros Bizjak wrote:
2) {v[0]-v[1], v[0]-v[1]} is not recognized as a hsubpd because
vec_duplicate doesn't match vec_concat. Do we really need to duplicate
(no
pun intended) the pattern?
You can add
On Mon, Oct 08, 2012 at 05:58:15PM +0200, Marek Polacek wrote:
2012-10-08 Marek Polacek pola...@redhat.com
PR debug/54831
* var-tracking.c (vt_add_function_parameter): Use condition in place
of gcc_assert.
Perhaps s/in place/instead/ ?
--- gcc/var-tracking.c.mp
On Mon, Oct 8, 2012 at 6:08 PM, Uros Bizjak ubiz...@gmail.com wrote:
+(define_insn *sse3_haddv2df3
[(set (match_operand:V2DF 0 register_operand =x,x)
(vec_concat:V2DF
- (plusminus:DF
+ (plus:DF
+ (vec_select:DF
+ (match_operand:V2DF 1
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c' with a shift and a full store instead of an
insert because the store just overwrites unintialized data. I
On Mon, Oct 8, 2012 at 5:01 PM, Nathan Froyd froy...@mozilla.com wrote:
- Original Message -
Btw, as for Richards idea of conditionally placing the length field
in
rtx_def looks like overkill to me. These days we'd merely want to
optimize for 64bit hosts, thus unconditionally adding
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit instead
of a bbit[01]l. I would like to skip this test for -Os the way it already gets
skipped for -O0.
Tested on mips-mti-elf. Ok for checkin?
Hello,
This patch makes lra_constraint_insn_stack_bitmap an sbitmap. This
reduces compile time by another minute or so on gcc17 for the test
case of PR54146, and I think it's a general improvement also for less
extreme code. For cc1-i files the compile time change tends to be a
little less but
On Mon, Oct 08, 2012 at 06:09:41PM +0200, Jakub Jelinek wrote:
Ok with those changes.
Thanks, this is what I've checked in:
2012-10-08 Marek Polacek pola...@redhat.com
PR debug/54831
* var-tracking.c (vt_add_function_parameter): Use condition instead
of gcc_assert.
OK.
Jason
On 10/08/2012 08:28 AM, Dominique Dhumieres wrote:
These tests are still failing on darwin. I think that
target { ! *-*-solaris2* } { ! *-*-darwin* }
sould be replaced with
target { ! { *-*-solaris2* *-*-darwin* } }
Could someone with a darwin box handy make the appropriate change?
Thanks.
On Oct 8, 2012, at 9:21 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/octeon-bbit-2.c is failing with -Os because that optimization
level does not do whichever optimization it is that results in a bbit instead
of a bbit[01]l. I would like to skip this test for -Os the way it already
On Oct 8, 2012, at 8:53 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Fri, 5 Oct 2012, Jason Merrill wrote:
+ error_at (loc, conversion of scalar to vector
+ involves truncation);
These errors should print the types involved. They also need to be
On Oct 8, 2012, at 9:16 AM, Steve Ellcey sell...@mips.com wrote:
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS
because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c' with a shift and a full store instead of
101 - 200 of 240 matches
Mail list logo