At 2013-01-22 19:58:43,"Ramana Radhakrishnan" wrote:>
> On 01/22/13 09:21, Xinyu Qi wrote:
> > Ping,
> >
> > Fix ChangeLog
>
> The ChangeLog format includes .
>
>
>
> If you want a patch accepted in the future, please help by creating the
> Changelog entry in the correct format, i.e. fill
This is the last of the merge insn patches. It merges the power6x movdi with
the normal floating point movdi.
2013-01-30 Michael Meissner
* config/rs6000/rs6000.md (movdi_mfpgpr): Delete, combine with
movdi_internal64, using wg constraint for move direct operations.
Like the
I've merged trunk revision 195591 to the gccgo branch.
Ian
On Wed, Jan 30, 2013 at 9:44 AM, Kai Tietz wrote:
>
> 2013-01-30 Kai Tietz
>
> PR other/543413
> * md5.c (md5_process_block): Handle case that size_t is
> a wider-integer-scalar a 32-bit unsigned integer.
This is OK.
Thanks.
Ian
On Wed, Jan 30, 2013 at 9:45 AM, Kai Tietz wrote:
>
> 2013-01-30 Kai Tietz
>
> PR other/54620
> * sha1.c (sha1_process_block): Handle case that size_t is
> a wider-integer-scalar as a 32-bit unsigned integer.
This is OK.
Thanks.
Ian
This patch like the previous 2 pages combines the decimal and binary floating
point moves, this time for 128-bit floating point.
In doing this patch, I discovered that I left out the code in the previous
patch to enable the wg constraint to enable -mcpu=power6x to utilize the direct
move instructi
This patch to libgo fixes backtrace information when optimizing.
Previously the backtraces just collected PC values and then converted
them into file/line information. This of course works poorly when
functions are inlined. This version uses the facilities of libbacktrace
to get good backtraces i
This change seems to have broken bootstrap with -march=pentium{2,3,-m} on
the 4.6 branch.
http://gcc.gnu.org/PR53728
--
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org where low card is hunger and high card is taste
sig
On Wed, Jan 30, 2013 at 04:27:57PM -0500, David Edelsohn wrote:
> On Wed, Jan 30, 2013 at 1:17 PM, Richard Henderson wrote:
> > For gcc 4.9, I intend to ensure that optabs.c can make automatic use of
> > [us]mul_highpart. There are plenty of targets that only implement
> > _highpart but not the w
On Wed, Jan 30, 2013 at 1:17 PM, Richard Henderson wrote:
> For gcc 4.9, I intend to ensure that optabs.c can make automatic use of
> [us]mul_highpart. There are plenty of targets that only implement
> _highpart but not the widening pattern. But that's not something that would
> be appropriate a
This patch builds upon the patch in:
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01457.html
It merges the DFmode and DDmode moves into one pattern. In addition, it merges
the -mmfpgpr code with the normal floating point moves, using a new conditional
constraint (wg) that only returns FLOAT_REGS
On Tue, 29 Jan 2013, Richard Biener wrote:
On Sun, Jan 27, 2013 at 4:28 PM, Marc Glisse wrote:
Hello,
this message is to check that I am not doing something absurd and ask for a
bit of advice.
In the attached patch, I let SLP recognize vector loads/stores just like it
recognizes those in an
This is a series of patches taken from my power8 work meant for inclusion
against GCC 4.9 when 4.8 is branched, and stage1 of 4.9 opens up again. They
could be installed in 4.8 at the discretion of David.
This patch merges together the movsd/movsf patterns, so that when I make
changes to the basi
Hi,
this patch backports a fix from trunk
ChangeLog
2013-01-30 Kai Tietz
2012-07-31 Mike Frysinger
Merged from trunk.
PR other/53285
* md5.c (md5_finish_ctx): Declare swap_bytes. Assign SWAP() output
to swap_bytes, and then call memcpy to move it to
For gcc 4.9, I intend to ensure that optabs.c can make automatic use of
[us]mul_highpart. There are plenty of targets that only implement
_highpart but not the widening pattern. But that's not something that
would be appropriate at this stage in the 4.8 cycle.
Whether this patch is appropria
Hi,
this patch fixes wrong handling of cases that bitness of size_t is
wider as 32-bit.
ChangeLog
2013-01-30 Kai Tietz
PR other/54620
* sha1.c (sha1_process_block): Handle case that size_t is
a wider-integer-scalar as a 32-bit unsigned integer.
Tested for x86_64-unk
Hi,
this patch fixes wrong handling of cases that bitness of size_t is
wider as 32-bit.
ChangeLog
2013-01-30 Kai Tietz
PR other/543413
* md5.c (md5_process_block): Handle case that size_t is
a wider-integer-scalar a 32-bit unsigned integer.
Tested for x86_64-unknown
I'm also touching on the middle-end and library changes, but would
appreciate a more thorough review from others in those areas.
On 01/23/2013 05:25 PM, Caroline Tice wrote:
Index: gcc/cp/g++spec.c
Changes to g++spec.c only affect the g++ driver, not the gcc driver. Are
you sure this is what
On 01/29/2013 04:53 AM, Richard Biener wrote:
I'm curious about the affect of -fno-aggressive-loop-optimizations
on SPEC CPU 2006 numbers (not curious enough to try for myself
though). Both on extra PASSes for official latest sources
(I have no access to those) and on performance.
The patch/opti
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56144
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 195582.
2013-01-30 Vladimir Makarov
PR rtl-optimization/56144
* lra-constraints.c (get_reload_reg): Don't reuse re
Tobias,
> Might be in the PDF version (untested), but they do work in the HTML
> version at http://gcc.gnu.org/onlinedocs/gfortran/Standards.html
I think my mistake was to use the links as they appear at
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01446.html
I was biased because I have found tha
I just finished a clean bootstrap of r195576 with your patch.
I have used it to clean the XPASS of gfortran.dg/do_1.f90 for -O0
and -O1 with the following patch:
--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/do_1.f90 2012-10-18
20:35:25.0 +0200
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg
On Wed, Jan 30, 2013 at 11:03 AM, Michael Haubenwallner
wrote:
> Erm - the question is why the 64bit libstdc++ found via LD_LIBRARY_PATH (set
> during libatomic build) didn't break these 32bit executables in your case.
I do not have the build any more, but --boot-ld-flags affects the
build logic
Dominique,
Dominique Dhumieres:
AFAICT, the links in
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@uref{http://www.fortran.com/@/iso_varying_string.f95} and at
@uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}.
are all broken.
Might be in the PDF version
Tobias,
AFAICT, the links in
Additionally, the GNU Fortran compilers supports the OpenMP specification
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@@ -545,6 +546,10 @@ for them, which work with GNU Fortran. They can be found
at
@uref{http://www.fortran.com/@/iso_var
On 01/30/2013 04:56 PM, David Edelsohn wrote:
> On Wed, Jan 30, 2013 at 10:44 AM, Michael Haubenwallner
> wrote:
>>
>> On 01/30/2013 03:16 PM, David Edelsohn wrote:
>>> wrote:
4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using
32bit gcc/xgcc to build libatomic
As promised: A patch for the "regression" PR54339. I am sure there is
room for improvement :-)
Everyone: Please feel free to comment on the current documentation,
http://gcc.gnu.org/onlinedocs/gfortran/ , and on the attached patch.
OK for the trunk?
Tobias
2013-01-30 Tobias Burnus
PR fo
On Wed, Jan 30, 2013 at 10:44 AM, Michael Haubenwallner
wrote:
>
> On 01/30/2013 03:16 PM, David Edelsohn wrote:
>> wrote:
>>> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using
>>>32bit gcc/xgcc to build libatomic.a.
>>> => This is the one that /does/ break, as that 64b
Hi all,
This patch implements the atomic built-ins using the new ARMv8 load-acquire
and store-release instructions.
They allow us to generate barrier-free code for a variety of atomic
operations such as: atomic load, atomic store, atomic compare and swap,
atomic {or, and, add, sub, xor}.
Tests wi
On 01/30/2013 03:16 PM, David Edelsohn wrote:
> wrote:
>> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using
>>32bit gcc/xgcc to build libatomic.a.
>> => This is the one that /does/ break, as that 64bit libstdc++.a is there now.
> Originally, I was using --boot-ld-flags
On Wed, Jan 30, 2013 at 7:03 AM, Kai Tietz wrote:
> Hmm, I see ... so we need an new condition.
>
> Is it ok to apply?
This version is OK if it bootstraps.
Thanks.
Ian
On Wed, Jan 30, 2013 at 04:04:55PM +0100, Dodji Seketeli wrote:
> As an aside, I am curious why about ...
>
> > --- gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C.jj 2012-12-14
> > 16:24:38.0 +0100
> > +++ gcc/testsuite/g++.dg/asan/deep-stack-uaf-1.C2013-01-22
> > 16:43:03.337091101 +0
Jakub Jelinek writes:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2013-01-22 Jakub Jelinek
>
> PR sanitizer/55374
> * gcc.c (LIBASAN_SPEC): Define just to ADD_STATIC_LIBASAN_LIBS if
> LIBASAN_EARLY_SPEC is defined.
> (LIBASAN_EARLY_SPEC):
Hmm, I see ... so we need an new condition.
Is it ok to apply?
Thanks,
Kai
Index: md5.h
===
--- md5.h (Revision 195572)
+++ md5.h (Arbeitskopie)
@@ -40,6 +40,11 @@
# include
typedef u_int32_t md5_uint32;
typedef uin
Kai Tietz writes:
> Yes, this is a valid point. The (u)int??_t types aren't necessarily
> declared by including sys/types.h. So what's about the following
> patch. If stdint.h header is present, then we should include it and
> then we can assume that the (u)int??_t types are present.
This is
Looks good to me. OK if nobody else responds today.
Jason
2013/1/30 Ian Lance Taylor :
> On Wed, Jan 30, 2013 at 2:53 AM, Kai Tietz wrote:
>>
>> this patch fixes for targets with sys/types.h the issue that wrong
>> assumptions about pointer-sizes are used.
>> Instead it uses uintptr_t/intptr_t.
>>
>> ChangeLog /include
>>
>> 2013-01-30 Kai Tietz
>>
>>
On Wed, Jan 30, 2013 at 2:53 AM, Kai Tietz wrote:
>
> this patch fixes for targets with sys/types.h the issue that wrong
> assumptions about pointer-sizes are used.
> Instead it uses uintptr_t/intptr_t.
>
> ChangeLog /include
>
> 2013-01-30 Kai Tietz
>
> PR other/54620
> PR targ
On Wed, Jan 30, 2013 at 6:35 AM, Michael Haubenwallner
wrote:
> But why didn't the RPATH_ENVVAR=LD_LIBRARY_PATH break for you when libatomic
> is configured (in stage3) for ppc64 because of this workflow I can see there:
>
> 1: gcc/xgcc is linked by prev-gcc/xg++
> 1.1: against *dynamic* libstdc+
Hi,
On Wed, 30 Jan 2013, Richard Biener wrote:
> 483 {
> 484 redirect_immediate_dominators (CDI_DOMINATORS, bb, new_bb);
> 485 set_immediate_dominator (CDI_DOMINATORS, new_bb, bb);
> 486 }
>
> but that doesn't set dominance info to DOM_OK again. The
> iterate
While looking into speeding up incremental SSA update for PR56113
(it's IDF compute slowness) I played with optimizing IDF compute
itself. One obvious thing that speeds it up by 5% is to use
quick_push in the innermost loop. When experimenting with using
a sparseset for the worklist to avoid ite
OK. Sriraman, are you working on documentation and more tests?
Jason
This fixes PR56147 - we have to care for mismatched symbol kinds
during merging.
Committed as obvious. (lto.exp doesn't understand dg-error for
link-time issues, so no testcase)
Richard.
2013-01-30 Richard Biener
PR lto/56147
* lto-symtab.c (lto_symtab_merge_decls_1): Guard
On 01/28/13 16:07, David Edelsohn wrote:
> On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner
> wrote:
>
>> But still curious if you've been able to reproduce the problem,
>> and why you didn't encounter this problem beforehand.
>
> As I mentioned before, because of --boot-ld-flags, with ea
On Tue, 2013-01-29 at 20:19 +0100, Andi Kleen wrote:
> > next time please reply to the points raised in a review if you disagree
> > with them, and don't just ignore them. That speeds up the review.
>
> It was all in the previous email on the topic.
This v2 patch did not incorporate all the chan
On Wed, 30 Jan 2013, Steven Bosscher wrote:
> On Wed, Jan 30, 2013 at 12:01 AM, Steven Bosscher wrote:
> > To prevent that mistake in the future, I've add an assert in dominance.c.
>
> Hmm, that worked with my release-checking compiler of course, but
> fails in at least tree-ssa-dom.c (same as fo
On Tue, Jan 29, 2013 at 4:49 PM, Marek Polacek wrote:
> I don't see any reason why we'd want to mark BBs in this case,
> changed_bbs are thrown away right after fix_loop_structure
> marks them.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2013-01-29 Marek Po
Hi,
this patch fixes for targets with sys/types.h the issue that wrong
assumptions about pointer-sizes are used.
Instead it uses uintptr_t/intptr_t.
ChangeLog /include
2013-01-30 Kai Tietz
PR other/54620
PR target/39064
* md5.h: Include sys/types.h if HAVE_SYS_TYPES_H
On Tue, Jan 29, 2013 at 9:00 PM, Georg-Johann Lay wrote:
> Richard Biener wrote:
>> Georg-Johann Lay wrote:
>>> This is tentative patch as discussed in
>>>
>>> http://gcc.gnu.org/ml/gcc/2013-01/msg00187.html
>>>
>>> fold-const.c gets 2 new function native_encode_fixed and
>>> native_interpret_fixe
Hi!
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01056.html
PR55742 - P1 - fix multiversioning (i386 backend)
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01105.html
PR55374 - put -lasan early on the command line with -fsanitize=address
Jakub
On 11/01/2012 09:07 PM, Caroline Tice wrote:
We have been developing a new security hardening feature for GCC that
is designed to detect and handle (during program execution) when a
vtable pointer that is about to be used for a virtual function call is
not a valid vtable pointer for that call (i.
Hi all,
This patch uses the new ARMv8 AArch32 vsel instruction to implement
conditional moves of floating point numbers.
For example, an instruction of the form:
vsel.f32 s0, s1, s2
means
s0 := cond ? s1 : s2
This can be useful, among other places, in Thumb2 because it doesn't req
On Thu, Jan 24, 2013 at 10:16:21AM +0100, Andreas Schwab wrote:
> Eric Botcazou writes:
>
> > ERROR: gcc.dg/vect/vect-multitypes-12.c: error executing dg-final: bad
> > index
> > "18-1": must be integer or end?-integer?
>
> Does that help? Perhaps the M-N feature isn't supported by your versi
Hi!
I've noticed
ERROR: (DejaGnu) proc "lreverse {{ASAN_OPTIONS 0}}" does not exist.
errors when regtesting gcc 4.8 on RHEL 5, it seems lreverse has been added
to tcl only in version 8.5.
Fixed thusly, ok for trunk?
54 matches
Mail list logo
