> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Tuesday, December 18, 2012 12:10
> To: Joseph Prostko
> Cc: Joey Ye; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, libgcc] Make possible to disable JCR in crtstuff.c
>
> On Mon, Dec 17, 2012 at 5:23 PM, Joseph Pro
On Wed, 19 Dec 2012, Maxim Kuvyrkov wrote:
> The attached patch adds a release note for performance improvements for
> Broadcom XLP processors (MIPS architecture) that went into GCC 4.8.
The line's a "little" bit long, and I believe it's built-in (not
builtin).
Fine with those changes.
Thanks,
Thanks Tobias and Dominique,
I'll make the corrections that you have requested. I believe that the
2*(GFC_MAX_SYMBOL_LEN+1) has a historic origin - I had not thought
about it until last night, when you pointed it out.
As for the segfault - that line should go. The automatic nulling of
the _vptr
Hi Sandra,
On Sat, 10 Nov 2012, Sandra Loosemore wrote:
> 2012-11-10 Sandra Loosemore
>
> gcc/
> * doc/extend.texi: Copy-edit to fix incorrect hyphenation phrases
> involving "bit", "byte", "word", "precision", and "floating"
> modifiers.
Index: gcc/doc/extend.texi
===
Update various config htab_t uses to hash_table.
Modify types and calls to match.
* config/arm/arm.c'arm_libcall_uses_aapcs_base::libcall_htab
Fold libcall_eq and libcall_hash into new struct libcall_hasher.
* config/ia64/ia64.c'bundle_state_table
Fold bundle_state_hash and bundle_state_eq_p i
The attached patch adds a release note for performance improvements for
Broadcom XLP processors (MIPS architecture) that went into GCC 4.8.
OK to apply?
Thanks,
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
xlp-performance.patch
Description: Binary data
On Tue, Dec 18, 2012 at 3:15 PM, Richard Henderson wrote:
> On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
>> Argh. But why? Wouldn't that only apply to cases where the lock was
>> sometimes locked by one library and sometimes locked by a different
>> one?
>
> Or did you really mean
>
> "...
On Tue, Dec 18, 2012 at 6:38 PM, Sriraman Tallam wrote:
> The function versions are now determined purely based on the string
> value and not on DECL_FUNCTION_SPECIFIC_TARGET fields. So, this check
> is not necessary.
Ah, OK. Thanks.
The patch is OK with that minor fix then.
Diego.
On Mon, Dec 17, 2012 at 2:32 PM, Lawrence Crowl wrote:
> Convert statistics.c'statistics_hashes from htab_t to hash_table.
>
> Fold hash_statistics_eq into new struct stats_counter_hasher.
>
> Update dependent calls and types.
>
> Tested on x86_64.
>
> Okay for branch?
OK.
Diego.
On Mon, Dec 17, 2012 at 2:34 PM, Lawrence Crowl wrote:
> Change tree-parloops.c reduction and name_to_copy hash tables from
> htab_t to hash_table.
>
> Fold reduction_info_hash and reduction_info_eq into new struct
> reduction_hasher. Fold name_to_copy_elt_eq and name_to_copy_elt_hash
> into new
Hi Diego,
Thanks for the review.
On Tue, Dec 18, 2012 at 8:04 AM, Diego Novillo wrote:
> On 2012-11-16 14:55 , Sriraman Tallam wrote:
>>
>> Hi,
>>
>> The previous patch was incomplete because the front-end strips off
>> invalid target attributes which I did not consider. The attached
>> u
On Tue, Dec 18, 2012 at 10:38:06PM +0100, Tobias Burnus wrote:
> Updated patch attached. Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
Looks ok to me, thanks.
> 2012-12-11 Tobias Burnus
> Jakub Jelinek
> Janus Weil
>
> PR fortran/55636
> PR f
Dear Paul,
With your patch applied on top of a clean revision 194590, the executable
for unlimited_polymorphic_1.f03 gives a Segmentation fault -
invalid memory reference at
Program received signal SIGSEGV, Segmentation fault.
0x00011d1c in MAIN__ () at
/opt/gcc/p_work/gcc/testsuite/gfo
On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
> Argh. But why? Wouldn't that only apply to cases where the lock was
> sometimes locked by one library and sometimes locked by a different
> one?
Or did you really mean
"... only apply to cases where the memory protected by the lock
was visi
On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
> Argh. But why? Wouldn't that only apply to cases where the lock was
> sometimes locked by one library and sometimes locked by a different
> one?
If two copies of the library aren't looking at the same lock object,
then the lock does no actual loc
On Tue, Dec 18, 2012 at 2:30 PM, Richard Henderson wrote:
> On 12/18/2012 02:09 PM, Ian Lance Taylor wrote:
>> I have now committed this follow-on patch, to make libgo use the new
>> libatomic_convenience library. This means that the changes to
>> explicitly link against -latomic are no longer ne
On Fri, 7 Dec 2012, Jakub Jelinek wrote:
> 2012-12-07 Jakub Jelinek
>
> PR c/39464
> * c-typeck.c (convert_for_assignment): For -Wpointer-sign
> warning require that both c_common_unsigned_type as well as
> c_common_signed_type is the same for both mvl and mvr types.
>
Paul Richard Thomas wrote:
Please find attached an updated version of the patch, which I believe
answers your comments/objections.
Thanks for the patch. They patch is OK from my side, if you address the
issues below.
+ /* Assign a hash value for an intrinsic type. The algorithm is that of S
On 12/18/2012 02:09 PM, Ian Lance Taylor wrote:
> I have now committed this follow-on patch, to make libgo use the new
> libatomic_convenience library. This means that the changes to
> explicitly link against -latomic are no longer necessary.
Hang on, what are we doing here. Are we linking libat
On Tue, Dec 18, 2012 at 1:32 PM, Richard Henderson wrote:
> On 12/18/2012 11:30 AM, Ian Lance Taylor wrote:
>> 2012-12-18 Ian Lance Taylor
>>
>> PR go/55201
>> * Makefile.am (noinst_LTLIBRARIES): Define new make variable.
>> (libatomic_convenience_la_SOURCES): Likewise.
>>
Jakub Jelinek wrote:
As written, TREE_STATIC is currently not set (which is a bug, cf.
PR55733);
That's now fixed. I also add to remove a spurious free() call.
If that is changed, surely the name must be mangled too.
Perhaps best to set a bool variable to the condition and use it in both
plac
Dear Jakub,
The fortran part looks fine to me. The sooner that you commit the
better - I will update the unlimited polymorphic patch accordingly.
Thanks
Paul
On 18 December 2012 15:11, Jakub Jelinek wrote:
> Hi!
>
> - PR c/39464 P2 -Wpointer-sign fix
> http://gcc.gnu.org/ml/gcc-patches/2012
On 12/18/2012 08:47 AM, Jakub Jelinek wrote:
> 2012-12-18 Jakub Jelinek
>
> PR target/55562
> * sbitmap.c (bitmap_and, bitmap_xor, bitmap_ior): Return whether
> dst sbitmap changed even if it doesn't have popcount.
Ok.
r~
On 12/18/2012 11:30 AM, Ian Lance Taylor wrote:
> 2012-12-18 Ian Lance Taylor
>
> PR go/55201
> * Makefile.am (noinst_LTLIBRARIES): Define new make variable.
> (libatomic_convenience_la_SOURCES): Likewise.
> (libatomic_convenience_la_LIBADD): Likewise.
> * Makefile
On Tue, Dec 18, 2012 at 08:45:49PM +0100, Tobias Burnus wrote:
> Or one of the examples from PR55733. The example above gives
> currently (w/o your patch):
>
> static character(kind=1)[1:.str] * str = 0B;
> integer(kind=4) .str;
Yeah, that is not a problem for ABI.
> >Where would be TREE_STA
Jakub Jelinek wrote:
On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:
Looks mostly okay, however, I fear that for
subroutine foo()
character(len=:), allocatable :: str
allocate(str, stat=istat)
end subroutine foo
compiled with "-fno-automatic", gfortran will still generate the
no
On Tue, Dec 18, 2012 at 9:57 AM, Ian Lance Taylor wrote:
>
> This doesn't happen for me, and it's bizarre that libtool would turn a
> link against ../libatomic/libatomic.la into a link against -latomic.
> But in any case the fix is presumably going to be to add a convenience
> library for libatomi
On 12/18/12, Jakub Jelinek wrote:
> The bitmap unification changes apparently broke at least modulo
> scheduling, which used sbitmap_a_and_b_cg functions, which
> were replaced by bitmap_and. But, sbitmap_a_and_b_cg asserted
> dst->popcount is NULL and returned whether dst sbitmap changed,
> but
Hi!
On Tue, Dec 18, 2012 at 09:25:14AM +0100, Paolo Bonzini wrote:
> Il 17/12/2012 22:33, Jakub Jelinek ha scritto:
> > If gen_lowpart_if_possible returns NULL, the default
> > rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not
> > of the desired mode. I bet in most passe
On Dec 18, 2012, at 5:33 AM, Kyrylo Tkachov wrote:
> This patch adds arm and v8 NEON to the effective target checks that are used
> in the rounding functions vectorisation tests.
For testsuite port follow ons that follow in the same exact footsteps of
previous port work, I'm fine with you just c
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, December 14, 2012 12:09 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][Cilkplus] Fix pragma simd info being lost
>
find -latomic
> collect2: error: ld returned 1 exit status
> libtool: install: error: relink `libgo.la' with the above command before
> installing it
> make[10]: *** [install-toolexeclibLTLIBRARIES] Error 1
> make[10]: Leaving directory
> `/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/bu
[install-toolexeclibLTLIBRARIES] Error 1
make[10]: Leaving directory
`/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo'
test -z "/usr/lib/../lib32" || /bin/mkdir -p
"/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32"
/usr
Hi!
The bitmap unification changes apparently broke at least modulo scheduling,
which used sbitmap_a_and_b_cg functions, which were replaced by bitmap_and.
But, sbitmap_a_and_b_cg asserted dst->popcount is NULL and returned whether
dst sbitmap changed, but bitmap_and returns always false if dst->p
On 18/12/12 13:38, Kyrylo Tkachov wrote:
Hi all,
This one-line patch adds support for Cortex A-7 to the -mcpu=native option.
Ok for trunk?
No regressions on arm-none-eabi.
Thanks,
Kyrill
gcc/ChangeLog
2012-12-18 Kyrylo Tkachov
* config/arm/driver-arm.c (arm_cpu_table):
A
On 18/12/12 14:07, James Greenhalgh wrote:
Hi,
This obvious patch fixes the following warnings I see when building for
AArch64.
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
I've tested on aarch64-none-elf
On 18/12/12 14:02, James Greenhalgh wrote:
Hi,
This straightforward patch fixes the following warnings I see when building
for AArch64.
gcc/config/aarch64/aarch64.c:6385:7: warning: unused variable ‘reg’
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:12: warning: unused variable ‘mem’
On Tue, Dec 18, 2012 at 05:28:09PM +0100, Jakub Jelinek wrote:
> On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:
> > Looks mostly okay, however, I fear that for
> >
> > subroutine foo()
> > character(len=:), allocatable :: str
> > allocate(str, stat=istat)
> > end subroutine foo
> >
On Tue, Dec 18, 2012 at 04:40:10PM +0100, Tobias Burnus wrote:
> Looks mostly okay, however, I fear that for
>
> subroutine foo()
> character(len=:), allocatable :: str
> allocate(str, stat=istat)
> end subroutine foo
>
> compiled with "-fno-automatic", gfortran will still generate the
> non-GFC_
On 2012-11-16 14:55 , Sriraman Tallam wrote:
Hi,
The previous patch was incomplete because the front-end strips off
invalid target attributes which I did not consider. The attached
updated patch handles this with updated test cases.
Thanks,
-Sri.
On Thu, Nov 15, 2012 at 2:08 PM, Sriraman T
On Tue, 18 Dec 2012, Aldy Hernandez wrote:
> On 12/12/12 03:33, Richard Biener wrote:
> > On Tue, 11 Dec 2012, Aldy Hernandez wrote:
> > > 4. Type checking as part of a `for' initializer segfaults on g++ 3.2:
> > >
> > > for (type = TYPE_MAIN_VARIANT (blah); )
> > >
> > > The only reas
On 12/12/12 03:33, Richard Biener wrote:
On Tue, 11 Dec 2012, Aldy Hernandez wrote:
4. Type checking as part of a `for' initializer segfaults on g++ 3.2:
for (type = TYPE_MAIN_VARIANT (blah); )
The only reasonable thing I could think of, was disabling the tree
checking code
Jakub Jelinek wrote:
So, what about this version instead?
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-12-11 Jakub Jelinek
Janus Weil
PR fortran/55636
* gfortran.h (GFC_PREFIX): Define.
* trans-decl.c (gfc_create_string_length): F
Ping. This patch seems fairly straightforward to the point of
being almost obvious, but so far, no review (beyond one email
expressing interest).
Thanks!
> The GDB sources contain some python files, and executing them
> causes these .pyc files to appear. We could ignore them in GDB
> only, but
As discussed earlier, removing the brings happiness to older g++'s.
Committed as obvious, per your previous comment.
commit 5d215dbbe1c37aaf98307cb71d250222fb802114
Author: Aldy Hernandez
Date: Tue Dec 18 09:21:28 2012 -0600
PR other/54324
* tree-ssa-coalesce.c (struct ssa_na
As discussed in the thread entitled "allow bootstrapping with older
compilers", this patch disallows __attribute__ for GCC < 3.4.
Applied as obvious, as you mentioned in the other thread.
Thanks.
commit 370a6a8ddc628924c1deedf752ea9fc9a058d5cc
Author: Aldy Hernandez
Date: Tue Dec 18 09:13:48
On 12/18/2012 03:47 PM, Jakub Jelinek wrote:
> On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
>> Canadian Cross Builds fail to build libgcc/unwind-dw2.c
>>
>> ...
>> ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
>> file or directory
>> ...
>>
>> when the
On Tue, Dec 18, 2012 at 03:41:58PM +0100, Christian Bruel wrote:
> Canadian Cross Builds fail to build libgcc/unwind-dw2.c
>
> ...
> ../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
> file or directory
> ...
>
> when the build machine has sys/sdt.h installed (systemtap-sdt-d
Hello,
Canadian Cross Builds fail to build libgcc/unwind-dw2.c
...
../../../../libgcc/unwind-dw2.c:42:21: fatal error: sys/sdt.h: No such
file or directory
...
when the build machine has sys/sdt.h installed (systemtap-sdt-devel),
but not the target's, because of this:
#ifdef HAVE_SYS_SDT_H
#inc
On Tue, Dec 18, 2012 at 5:23 AM, Richard Biener
wrote:
> But of course we agreed to not to translation to C++ just because it's
> possible
> but to make the code better (in my sense better is equal to easier to
> maintain and/or understand).
This is not what this set of changes is doing. These
This fixes PR54838 by teaching fix_loop_structure to discover
that all latch edges disappeared and thus a loop is gone.
Conveniently we re-discover latch edges already, so simply move
that earlier and extend it.
The patch also properly honors LOOPS_HAVE_FALLTHRU_PREHEADERS
in fix_loop_structure a
On Mon, Dec 17, 2012 at 2:26 PM, Andreas Schwab wrote:
> Since libgo uses 8-byte atomic operations it needs to link against
> libatomic. Tested on m68k-linux and powerpc-linux.
>
> Andreas.
>
> PR go/55201
> * Makefile.def (all-target-libgo): Depend on all-target-libatomic.
>
On Tue, Dec 11, 2012 at 09:16:53PM -0500, David Edelsohn wrote:
> > @@ -1090,7 +1090,15 @@ gfc_create_string_length (gfc_symbol * s
> >const char *name;
> >
> >/* Also prefix the mangled name. */
> > - if (sym->module)
> > + if (sym->attr.save || sym->ns->proc_name->attr.
Hi!
- PR c/39464 P2 -Wpointer-sign fix
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00523.html
- PR fortran/55636 P1 Fortran ABI (mangling) fix
http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00726.html
- PR c++/55619 C FE changes corresponding to C++ FE changes for inline asm "m"
constrained
Hi,
This obvious patch fixes the following warnings I see when building for
AArch64.
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
gcc/config/aarch64/aarch64.md:840: warning: source missing a mode?
I've tested on aarch64-none-elf with no regressions and the patch
clears the
Hi,
This straightforward patch fixes the following warnings I see when building
for AArch64.
gcc/config/aarch64/aarch64.c:6385:7: warning: unused variable ‘reg’
[-Wunused-variable]
gcc/config/aarch64/aarch64.c:6385:12: warning: unused variable ‘mem’
[-Wunused-variable]
gcc/config/aarch64/aarch6
Hi all,
This one-line patch adds support for Cortex A-7 to the -mcpu=native option.
Ok for trunk?
No regressions on arm-none-eabi.
Thanks,
Kyrill
gcc/ChangeLog
2012-12-18 Kyrylo Tkachov
* config/arm/driver-arm.c (arm_cpu_table):
Add Cortex-A7.diff --git a/gcc/config/arm/dri
Hi all,
This patch adds arm and v8 NEON to the effective target checks that are used
in the rounding functions vectorisation tests.
A new effective target check for NEON hardware is added This check is used
to determine
whether to do runtime tests or just compilation.
With these changes the follow
Hi all,
This patch adds support for the vectorisation of the rounding functions:
floorf, ceilf, truncf, roundf. These can be implemented using the ARMv8 NEON
instructions: vrintm, vrintp, vrintz, vrinta.
This is done by defining the TARGET_VECTORIZE_BUILTINS and
TARGET_VECTORIZE_BUILTIN_VECTORIZED
Hi all,
This patch does some refactoring by moving the definitions of the NEON
builtins to a separate file (arm_neon_builtins.def) and includes that when
initialising the neon_builtin_data array and also during
the definition of enum arm_builtins (with appropriate redefinitions of the
VAR* macros)
Hi all,
The three following patches add support for the vectorisation of the
rounding functions: floorf, ceilf, truncf, roundf.
The first patch does some refactoring of the NEON builtins, allowing us to
give them symbolic names and thus paving the way for the definition of
TARGET_VECTORIZE_BUILTIN
Revisiting PR40815, in particular the attached supposedly bad dump
shows:
D.2021_14 = (unsigned int) rite_2;
D.2022_9 = (unsigned int) element_5(D);
D.2023_15 = -D.2022_9;
D.2024_16 = D.2021_14 + D.2023_15;
rite_17 = (char *) D.2024_16;
while now we have
_7 = (sizetype) element_6(D)
On Tue, 18 Dec 2012, Steven Bosscher wrote:
> On Tue, Dec 18, 2012 at 1:42 PM, Richard Biener wrote:
> > Thus I'd welcome hints at what information you are currently
> > missing
>
> I think the documentation for the loops maintenance should document
> those things that are different from before.
On Mon, 17 Dec 2012, Richard Biener wrote:
> On Mon, 17 Dec 2012, Richard Biener wrote:
>
> >
> > The following patch fixes a miscompilation due to bogus loop iteration
> > bound derived from array accesses in an inner loop. idx_infer_loop_bounds
> > analyzes the evoultion of an SSA name with r
On Tue, Dec 18, 2012 at 1:42 PM, Richard Biener wrote:
> Thus I'd welcome hints at what information you are currently
> missing
I think the documentation for the loops maintenance should document
those things that are different from before. Before loops were
maintained, the world was easy: Everyth
This updates loop docs to reflect changes I did for 4.8, which is
mostly that loop structures are now preserved from the start of
GIMPLE loop optimizations until the end of RTL loop optimizations.
Apart from the stale 'Lambda' chapter (and the missing GRAPHITE
chapter ...) things are surprisingly
On Wed, Jul 18, 2012 at 7:46 PM, Steven Bosscher wrote:
> Hello,
>
> This is my proposed fix for PR53948. We don't want to put user
> variables in callee-clobbered registers, but obviously function
> arguments are OK there. REG_USERVAR_P is set on PARM_DECLs and on user
> variables, so it can't be
On 11 December 2012 02:14, Benjamin De Kosnik wrote:
>
> The recent change in Fedora's documentation stack, from texlive-2007 to
> texlive-2013 caused some havoc in the libstdc++ "make pdf" rules.
>
> This patch fixes the previously unknown issues so that the pdf docs for
> libstdc++ can be built o
On Mon, Dec 17, 2012 at 9:01 PM, Lawrence Crowl wrote:
> On 12/17/12, Richard Biener wrote:
>> On Mon, Dec 17, 2012 at 8:36 PM, Lawrence Crowl wrote:
>>> Change tree-ssa-coalesce.c'coalesce_list_d.list from htab_t to
>>> hash_table.
>>>
>>> Fold coalesce_pair_map_hash and coalesce_pair_map_eq in
Il 17/12/2012 22:33, Jakub Jelinek ha scritto:
> Hi!
>
> If gen_lowpart_if_possible returns NULL, the default
> rtl_hooks.gen_lowpart_no_emit hook returns the original value, which is not
> of the desired mode. I bet in most passes for real insns such rtx is then
> meant to fail recog and thrown
70 matches
Mail list logo
