On Thu, Jan 19, 2012 at 12:16:01AM +0100, Jakub Jelinek wrote:
As described in the PR, if two argument erase is removing the last
element of one bucket (i.e. the one referenced in _M_buckets array
for the next bucket) and then at least one element from the
following bucket, but not all
2012/1/18 Jason Merrill ja...@redhat.com:
I still think the problem is that we're applying the attributes more than
once, and we should only apply them once. If we fix that, we don't need to
merge them.
Jason
Well, I will try to search for it a bit more. Nevertheless is the
chaining at
On 01/19/2012 08:34 AM, Jakub Jelinek wrote:
Ok, thanks for working on this.
Installed, do you want this for 4.6/4.5?
If yes, please give it at least a couple of weeks on the trunk.
It's fine by me but yes, let's give it time to bake.
Paolo
On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
if test x${build} = x${target} test x${build} = x${host}; then
This test is no longer necessary, is it? ia64 does its own cross-compile
detection via AC_RUN_IFELSE, and other hosts are cross-compile safe.
The patch is okay if you remove it.
On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski
andrew.pin...@caviumnetworks.com wrote:
Hi,
This adds the folding of x ((~x) | y)) into x y on the tree
level via fold-const.c
There is already partly done on
On Thu, Jan 19, 2012 at 09:54:43AM +0100, Paolo Bonzini wrote:
On 01/19/2012 12:24 AM, Jakub Jelinek wrote:
if test x${build} = x${target} test x${build} = x${host}; then
This test is no longer necessary, is it? ia64 does its own
cross-compile detection via AC_RUN_IFELSE, and other
On Wed, 18 Jan 2012, Aldy Hernandez wrote:
On 01/18/12 03:09, Richard Guenther wrote:
On Tue, 17 Jan 2012, Aldy Hernandez wrote:
What I have in mind is to abstract out the initialization of TM
builtins
from
gtm-builtins.def (through its inclusion in builtins.def)
Hi!
For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
aliasing by accessing the same object through incompatible lvalues
(in an asm operand through float resp. double lvalue and on the next
line through UINT32 resp. UINT64 lvalue.
GCC apparently errors out on this while
... which is confused about a useful testcase not using uninitialized
variables.
Testcase committed.
Richard.
2012-01-19 Richard Guenther rguent...@suse.de
PR tree-optimization/37997
* gcc.dg/tree-ssa/ssa-pre-28.c: New testcase.
Index:
On Thu, 19 Jan 2012, Jakub Jelinek wrote:
Hi!
For FFI_TYPE_FLOAT and FFI_TYPE_DOUBLE, I think src/ia64/ffi.c violates
aliasing by accessing the same object through incompatible lvalues
(in an asm operand through float resp. double lvalue and on the next
line through UINT32 resp. UINT64
On 01/19/2012 12:16 AM, Jakub Jelinek wrote:
Fixed thusly, if __is_bucket_begin is true, then we know __n is the first
item in its bucket and thus __prev_n should be in the _M_buckets array.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok, the testcase too of course.
On 19 January 2012 08:36, Jakub Jelinek wrote:
If you want a testcase that fails on x86_64-linux without the patch and
succeeds with it, here it is:
Thanks, Jakub, the analysis and patch look right, OK to checkin with
the testcase.
On Thu, Jan 19, 2012 at 10:00 AM, Andrew Pinski
andrew.pin...@caviumnetworks.com wrote:
On Tue, Jan 17, 2012 at 1:38 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Jan 17, 2012 at 8:06 AM, Andrew Pinski
andrew.pin...@caviumnetworks.com wrote:
Hi,
This adds the folding of x
On Wed, 2012-01-18 at 22:25 +0100, Uros Bizjak wrote:
On Wed, Jan 18, 2012 at 10:16 PM, Patrick Marlier
patrick.marl...@gmail.com wrote:
IMO, whatever the future decision would be, we shouldn't leave one
part of the compiler out-of-sync from the other. Proposed patch fixes
_current_
On Thu, 2012-01-19 at 13:24 +0100, Torvald Riegel wrote:
Note that if we remove the regparm, we should also remove it on the
other functions associated with txn begin (GTM_beginTransaction etc.).
And update libitm.texi ...
On Thu, Jan 19, 2012 at 1:24 PM, Torvald Riegel trie...@redhat.com wrote:
The spec does say that all function should be regparm(2), but I agree
that the above is less confusing. The attribute is ignored, but
perhaps a comment would clear this confusion even more.
Uros, thanks for spotting
This patch fixes three issues with building libgfortran for MinGW/MinGW64:
a) mode_t is unsigned short while scanf's %o expects an unsigned int
variable.
b) umask is not available
c) Only read and write is available but not group/other
read/write/execute, SUID/SGID or the sticky bit.
Thanks
Hello,
As discussed with Jakub in the PR, the problem is that a jump asm goto insn
is removed without purging the dead edges. Bootstrapped and tested on
x86-64. I had to use dg-prune-output to remove the error message and to
make the test pass, as we only checking for an ICE.
OK for
On 19/01/12 06:46, Bin Cheng wrote:
Hi,
Currently gcc generates code violating ARM EABI when passing arguments to
some floating point
helper functions, which are __aeabi_d2iz/__aeabi_d2uiz. As reported in bug
PR51835.
This patch fixes the issue, with test cases.
It is for trunk and 4.6
When we have a class-scope using-declaration that nominates functions,
we want to insert those functions into the derived class'
CLASSTYPE_METHOD_VEC. In non-template code we do this in
handle_using_decl, which is called from check_bases_and_members. But we
don't call that function for a
On 01/17/2012 06:52 PM, Cary Coutant wrote:
Would you consider it OK with a comment?
Yes.
How about if I call copy_declaration_context directly from
remove_child_or_replace_with_skeleton, instead of calling them
sequentially in break_out_comdat_types?
OK.
Jason
This is basically documentation of AVR specific extensions and stuff like
* command line options like -maccumulate-args etc.
* AVR named address spaces
Section doc/extend.texi::Named Address Spaces is split into several subsections
now; each subsection taking care of one target in alphabetical
Richard Guenther wrote:
This should fix PR51782 - we need to look at the base address operand
of MEM_REF and TARGET_MEM_REF to get at the address-space information
as both can have an embedded VIEW_CONVERT_EXPR. This is then
consistent with the gimple type system which keeps address-space
Hi!
It isn't clear why mudflap doesn't instrument DECL_ARTIFICIAL functions,
if it couldn't avoid instrumenting just a subset of them.
But there is certainly no reason why it shouldn't instrument normal clones
of user functions (OpenMP, TM, ISRA, ...). Fixed thusly,
bootstrapped/regtested on
Hi,
the attached patch fixes a problem which has been introduced with:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01527.html
Bootstrapped and regtested on x86_64, s390, and s390x.
Ok for mainline?
Bye,
-Andreas-
2012-01-19 Andreas Krebbel andreas.kreb...@de.ibm.com
PR
Tobias Burnus wrote:
Bootstrapped on x86-64-linux, but not (yet) tested on MinGW/MinGW64
OK for the trunk?
MinGW64 was successful - thanks to Brad for testing it and for updating
the version, which is linked from the wiki.
Tobias
On Thu, Jan 19, 2012 at 06:10:06PM +0100, Jakub Jelinek wrote:
2012-01-19 Jakub Jelinek ja...@redhat.com
PR libmudflap/40778
* tree-mudflap.c (mf_artificial): New function.
(execute_mudflap_function_ops, execute_mudflap_function_decls,
mx_register_decls,
Seemingly, resolve and friends are confused if there is no symtree -
thus set it.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch? (It's a regression.)
Tobias
2012-01-19 Tobias Burnus bur...@net-b.de
PR fortran/51904
*expr.c (gfc_build_intrinsic_call): Also set
I have no problems running make pdf in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
On Thu, Jan 19, 2012 at 08:23:58PM +0100, Tobias Burnus wrote:
Seemingly, resolve and friends are confused if there is no symtree -
thus set it.
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch? (It's a regression.)
Yes. Almost looks obvious (except I've read the
DJ Delorie wrote:
I have no problems running make pdf in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
That's odd. I have exactly the same version and I get the following TeX
error.
Tobias
texi2pdf /home/tob/projects/gcc-git/gcc/libiberty/libiberty.texi
This is pdfTeX, Version
On 01/19/2012 03:36 AM, Kai Tietz wrote:
Well, I will try to search for it a bit more. Nevertheless is the
chaining at this place IMHO a pretty bad idea. The merging of
attributes looks more sane. Also is this merging patch pretty less
invasive and would be fine for older branches, too.
The following patch solves PR40761 which is described on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761.
The patch was bootstrapped on x86/x86-64 with -O2 and -O0 with checking
enabled.
Committed as rev. 183312.
2012-01-19 Vladimir Makarov vmaka...@redhat.com
PR
On 01/18/2012 02:30 PM, Zamyatin, Igor wrote:
Yes, we use Atom for EEMBC measurements.
We'll be glad to help you with your findings.
Thanks.
Unfortunately I tried several alternative patches but I did not find a
better solution (it is mostly code size degradation on CoreI7). Now I
am
When we read a tree from the cache of an external PPH file and the
tree is mutated in the current file, we need to re-sign the tree to
reflect the changes.
The problem was, that the signing code was assuming that the tree had
come from the *current* file, so it was trying to sign a cache entry
On Wed, Jan 18, 2012 at 3:17 PM, Ian Lance Taylor i...@google.com wrote:
This patch to the Go testsuite driver recognizes a few more test lines
in Go tests. I somehow failed to notice these the last time I updated
the Go testsuite. This patch includes a couple of changes to make the
newly
Uros Bizjak ubiz...@gmail.com writes:
Some of the go tests require explicit -mieee compile flag [1]. Is
there a way to conditionally pass this flag to the compiler?
What does Java do?
Nothing... while the library is compiled with -mieee (the same as
libgo), the user is still expected to
Hello!
Attached patch adds -mieee to tests that need full IEEE compliance to
pass. While working on patch, I have noticed that go-test.exp doesn't
pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
format (so, these simply get ignored). With this issue fixed, we can
add -mieee to
commit de9e01e3b50f75bcd47da9d32ab0691c65094df5
Author: Sterling Augustine saugust...@google.com
Date: Thu Jan 19 14:31:14 2012 -0800
Add DW_AT_GNU_pubtypes and Add DW_AT_GNU_pubnames to comdat type dies.
M gcc/dwarf2out.c
Tested:
Via make check-c and make check-c++. No new
Would you consider it OK with a comment?
Yes.
How about if I call copy_declaration_context directly from
remove_child_or_replace_with_skeleton, instead of calling them
sequentially in break_out_comdat_types?
OK.
Updated patch attached. I fixed the regex so the test is independent
of
Uros Bizjak ubiz...@gmail.com writes:
Attached patch adds -mieee to tests that need full IEEE compliance to
pass. While working on patch, I have noticed that go-test.exp doesn't
pass DEFAULT_GOCFLAGS to go_target_compile procedure in expected
format (so, these simply get ignored). With this
On 31 December 2011 17:33, Jonathan Wakely wrote:
I want to commit the attached patch:
PR libstdc++/49204
* include/std/future (__future_base::_State_base::wait()): Call
_M_complete_async instead of _M_run_deferred.
(__future_base::_State_base::wait_for()): Call
On Jan 19, 2012, at 3:39 PM, Ian Lance Taylor wrote:
And I just have to repeat that this patch is an ugly ugly hack, since
-mieee should be the default. Perhaps we should investigate having
gcc/go/gospec.c or gcc/go/lang-specs.h somehow add -mieee for those
targets which require it.
I agree.
2012/1/19 Georg-Johann Lay a...@gjlay.de:
Georg-Johann Lay wrote:
This is basically documentation of AVR specific extensions and stuff like
* command line options like -maccumulate-args etc.
* AVR named address spaces
Section doc/extend.texi::Named Address Spaces is split into several
-Wall was warning about explicitly imported but not used __vtab,
__def_init etc. variables.
Build and regtested on x86-64-linux
OK for the trunk?
Tobias
2012-01-20 Tobias Burnus bur...@net-b.de
Janus Weil ja...@gcc.gnu.org
PR fortran/51056
* module.c (load_needed, read_module):
Dear Tobias,
This patch is OK for trunk.
I have made a lot of progress on PR51870; class scalars work correctly
but I need to extend the fix to class arrays. It requires a complete
rewrite of the parts of gfc_trans_allocate that are associated with
class allocation and initialization. The
46 matches
Mail list logo
