On 2012/7/20 12:27 PM, Maxim Kuvyrkov wrote:
> Attached is a stand-alone patch that adds handling of "syncloop" and "atomic"
> type attributes.
>
> Tested by building cross-toolchain mips64-linux-gnu including GLIBC. OK to
> apply?
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
And
On Jul 19, 2012, at 6:54 PM, Eric Botcazou wrote:
>> I did a manual build and testing for x86_64-pc-mingw32 and I will run a
>> full bootstrap and regression run on GNU/Linux.
>>
>> Tristan.
>>
>> libstdc++-v3/
>> * libsupc++/eh_personality.cc (__gxx_personality_seh0): New function.
>>
>
> Tobias Burnus wrote:
>> I will now regtest everything, read through the whole patch - your
>> part and mine, update the ChangeLog and commit it tomorrow.
>
> I have now committed the attached version as Rev. 189700!
>
> Thanks agai for the review!
>
> Tobias
>
This seems to cause following fai
On x86_64 the same happens. Also I modified list of failing tests -
now it is correct
On Fri, Jul 20, 2012 at 11:43 AM, Igor Zamyatin wrote:
>>
>> Tobias Burnus wrote:
>>> I will now regtest everything, read through the whole patch - your
>>> part and mine, update the ChangeLog and commit it tomo
Hi H-P,
*cough*
Sounds like a call for a note in changes.html, to warn people
that they have to turn on the alignment feature in their startup
code (for whatever OS) for their ARMv6-or-later targets, if they
have not already done so.
What a good idea :-)
Maybe something like:
Index: chan
Maxim Kuvyrkov writes:
> 2012-07-13 Maxim Kuvyrkov
>
> * config/mips/mips.md (define_attr sync_*): Move before "type".
> (define_attr "type"): New values "atomic" and "syncloop".
> * config/mips/sync.md (atomic_exchange, atomic_fetch_add):
> Set "type" attribute.
>
Chung-Lin Tang writes:
> 2012-07-20 Chung-Lin Tang
> Maxim Kuvyrkov
> NetLogic Microsystems Inc.
>
> * config/mips/mips.c (mips_issue_rate): Handle XLP.
> * config/mips/xlp.md: New file.
OK, thanks.
Richard
On Thu, 19 Jul 2012, Markus Trippelsdorf wrote:
> On 2012.07.17 at 15:10 +0200, Richard Guenther wrote:
> > Comments welcome, of course.
>
> This patch apparently miscompiles the Linux kernel, which just
> hangs during early boot:
>
> ...
> SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0,
On Thu, Jul 19, 2012 at 6:53 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we emit various (correct) -Wnonnull warnings
> more than once, sometimes many times. The problem on the reported memcpy
> testcase is that glibc uses __attribute__((nonnull (1, 2))) and gcc
> uses __attribut
On Thu, Jul 19, 2012 at 8:24 PM, Richard Henderson wrote:
> While adding multiple new optabs over the past week or three, it
> occurred to me that (1) there are lots of places to update all in
> sync and (2) the representation size of optabs is huge.
>
> The first issue is somewhat trivially accom
On Thu, Jul 19, 2012 at 11:09 AM, Richard Guenther
wrote:
> Hmm, pp_flush looks like a lot more expensive compared to pp_newline
> for example in
>
> @@ -74,7 +74,7 @@ maybe_init_pretty_print (FILE *file)
> static void
> newline_and_indent (pretty_printer *buffer, int spc)
> {
> - pp_newline (
On Fri, Jul 20, 2012 at 10:37:32AM +0200, Richard Guenther wrote:
> On Thu, Jul 19, 2012 at 6:53 PM, Jakub Jelinek wrote:
> Hum. How hard would it be to merge the attributes?
IMHO hard and ugly. The thing is that you probably can do some hacks
easily in handle_nonnull_attribute, so that multipl
On Fri, Jul 20, 2012 at 11:02 AM, Steven Bosscher wrote:
> On Thu, Jul 19, 2012 at 11:09 AM, Richard Guenther
> wrote:
>> Hmm, pp_flush looks like a lot more expensive compared to pp_newline
>> for example in
>>
>> @@ -74,7 +74,7 @@ maybe_init_pretty_print (FILE *file)
>> static void
>> newline
On Fri, Jul 20, 2012 at 11:04 AM, Jakub Jelinek wrote:
> On Fri, Jul 20, 2012 at 10:37:32AM +0200, Richard Guenther wrote:
>> On Thu, Jul 19, 2012 at 6:53 PM, Jakub Jelinek wrote:
>> Hum. How hard would it be to merge the attributes?
>
> IMHO hard and ugly. The thing is that you probably can do
Hi,
tested x86_64-linux, committed (see audit trail for details)
Thanks,
Paolo.
/
2012-07-20 Chip Salzenberg
Jonathan Wakely
PR libstdc++/54025
* include/std/chrono (duration<>::duration): Fix per C++11.
* testsuite/20_util/durat
On 15/07/2012 08:23, Tobias Burnus wrote:
> Dear all,
>
> that's a follow up cleanup to the patch, which has just been merged.
> Most parts should be really obvious and nice, however, the offset part
> isn't. As the offset is not part of the descriptor defined at DTS
> 29113:2012's "8.2 C descript
This removes one odd piece in add_local_variables:
FOR_EACH_LOCAL_DECL (callee, ix, var)
-if (TREE_STATIC (var) && !TREE_ASM_WRITTEN (var))
- {
- if (!check_var_ann
- || (var_ann (var) && add_referenced_var (var)))
- add_local_decl (caller, var);
- }
-
On 18/07/2012 17:17, Tobias Burnus wrote:
> This patch was written on top of the big assumed-shape patch.* However,
> it should also work by itself.
>
> Bootstrapped and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>
> * http://gcc.gnu.org/ml/fortran/2012-07/msg00052.html
> 2012-07
On 07/20/2012 11:55 AM, Mikael Morin wrote:
On 18/07/2012 17:17, Tobias Burnus wrote:
+either assumed size or explicit shape. Deferred shape is already
+covered by the pointer/allocatable attribute. */
Don't we need to fix the pointer/allocatable diagnostics as well the
Hi,
This (old!) patch avoids uselessly pulling in the unwinder for 64-bit
division routines. I last posted it here:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01618.html
Other people have noticed the same issue, e.g.:
http://gcc.gnu.org/ml/gcc-help/2011-03/msg00187.html
Note that we take spe
On 07/20/2012 11:52 AM, Mikael Morin wrote
OK.
Thanks for the review.
I guess the division will be dropped too (the middle-end does the
reverse multiplication implicitly in the pointer arithmetic).
I wonder which one is faster (the casts in the second version are
certainly not nice for the mi
Dear all,
this patch is a cleanup follow up to the assumed-rank patch. Changes:
* Fix pattern matching for the dump. for some reason, the DTYPE differes
between i686 and x86-64.
* There was a proper check missing that assumed-rank arrays may not have
a codimension. (There are now checks in arra
On Fri, Jul 20, 2012 at 12:17 PM, Tobias Burnus wrote:
> On 07/20/2012 11:52 AM, Mikael Morin wrote
>>
>> OK.
>
>
> Thanks for the review.
>
>
>> I guess the division will be dropped too (the middle-end does the
>> reverse multiplication implicitly in the pointer arithmetic).
>> I wonder which one
Hi,
On several architectures, the test gcc.c-torture/execute/20101011-1.c
tests the raising of a signal when a division by zero occurs, but at
present the test is simply skipped on ARM. We can make the test
slightly more useful by using the EABI-provided ability to define a
division-by-zero handli
This fixes PR54031. While technically the source is invalid
(a pointer is not aligned as it should) it wasn't my plan to
exploit this with the get_object_alignment change. In fact
it is CCPs wrongdoing that it uses get_object_alignment_1
instead of get_pointer_alignemnt_1 when looking at a point
On 12-07-19 05:33 PM, Hans-Peter Nilsson wrote:
Maybe something like:
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.113
diff -p -u -r1.113 changes.html
--- changes.html
On 12-07-19 06:06 PM, Gabriel Dos Reis wrote:
On Thu, Jul 19, 2012 at 4:13 PM, Ryan Mansfield wrote:
GCC_DRIVER_HOST_INITIALIZATION happens before diagnostic_initialize, this
can cause crashes if it call diagnostics such as warning, or fatal_error are
used in the macro. One example would be in
Hi all,
I've fixed test which was failing on Android NDK
testsuite/ChangeLog:
2012-07-20 Anna Tikhonova
* gcc.dg/20020201-1.c: Include .
Patch attached.
Ok for trunk & 4.7?
20020201-1.p
Description: Binary data
Hi,
This patch provides some mild performance tuning for Cortex-M series
processors -- originally measured on a Cortex-M4 device (circa March
2011, on a 4.5-based branch), but making the changes for all Cortex-M
devices -- using the possibly-unwarranted assumption that other
Cortex-M devices are l
referenced vars can contain things we won't expand and shouldn't be
used to drive codegen (well, my goal is still to drop referenced
vars and solely use local decls everywhere, eventually adding a way
to do the UID -> decl lookup there).
Bootstrapped and tested on x86_64-unknown-linux-gnu, instal
On 20/07/2012 12:09, Tobias Burnus wrote:
> But if you prefer, I can now also lump all Bind(C) changes of TS29113
> together into a big patch.
>
No thanks. Patch is OK.
Mikael
Hi!
As detailed in the PR, I believe we should only add c into m's variant chain
if m's element type is the main variant of c's element type.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?
2012-07-20 Jakub Jelinek
PR c++/54038
* tree.c (build_cplus_a
> From: nick clifton
> Date: Fri, 20 Jul 2012 09:18:52 +0200
> "approved - please apply".
Thanks! I see the last sentence could do with better
punctuation, so I added the obvious comma. Installed as
follows.
Index: changes.html
=
Add a new field to tune_params structure to indicate whether LDRD/STRD
instructions are preferred over POP/PUSH/STM/LDM. Set the new field to false
for all existing tunes. Subsequent patches will set it to true for
Cortex-A15 and use it to determine which instructions to emit, in particular
for pro
This patch creates a new tune_param structure for Cortex-A15. The new tune
is identical to the generic cortex tune used for Cortex-A15 before this
patch, except the field prefer_ldrd_strd is set to true. This field will be
used by subsequent patches, in particular for prologue/epilogue.
Ok for tru
On 20/07/12 15:59, Greta Yorsh wrote:
> Add a new field to tune_params structure to indicate whether LDRD/STRD
> instructions are preferred over POP/PUSH/STM/LDM. Set the new field to false
> for all existing tunes. Subsequent patches will set it to true for
> Cortex-A15 and use it to determine whi
On 20/07/12 16:05, Greta Yorsh wrote:
> This patch creates a new tune_param structure for Cortex-A15. The new tune
> is identical to the generic cortex tune used for Cortex-A15 before this
> patch, except the field prefer_ldrd_strd is set to true. This field will be
> used by subsequent patches, in
On 07/20/2012 09:26 AM, Jakub Jelinek wrote:
As detailed in the PR, I believe we should only add c into m's variant chain
if m's element type is the main variant of c's element type.
We want c to get onto the appropriate variant chain even if it isn't
m's, so I'm applying this patch instead.
On Jul 20, 2012, at 3:35 AM, Julian Brown wrote:
> On several architectures, the test gcc.c-torture/execute/20101011-1.c
> tests the raising of a signal when a division by zero occurs, but at
> present the test is simply skipped on ARM. We can make the test
> slightly more useful by using the EABI-
On 20/07/12 11:35, Julian Brown wrote:
> Hi,
>
> On several architectures, the test gcc.c-torture/execute/20101011-1.c
> tests the raising of a signal when a division by zero occurs, but at
> present the test is simply skipped on ARM. We can make the test
> slightly more useful by using the EABI-p
Hi Maintainers,
Below patch does the basic enablement for next generation AMD low power btver2
core.
It defines -march=btver2 and -mtune=btver2, and lets -march=native correctly
recognizes btver2. At the moment the tuning is mostly a copy of btver1.
The patch passed bootstrap and the x86 tests.
On Fri, 20 Jul 2012 17:24:36 +0100
Richard Earnshaw wrote:
> On 20/07/12 11:35, Julian Brown wrote:
> > Hi,
> >
> > On several architectures, the test
> > gcc.c-torture/execute/20101011-1.c tests the raising of a signal
> > when a division by zero occurs, but at present the test is simply
> > sk
On 20/07/12 17:52, Julian Brown wrote:
> On Fri, 20 Jul 2012 17:24:36 +0100
> Richard Earnshaw wrote:
>
>> On 20/07/12 11:35, Julian Brown wrote:
>>> Hi,
>>>
>>> On several architectures, the test
>>> gcc.c-torture/execute/20101011-1.c tests the raising of a signal
>>> when a division by zero occ
On Fri, Jul 20, 2012 at 11:39:32AM -0500, venkataramanan.ku...@amd.com wrote:
> Below patch does the basic enablement for next generation AMD low power
> btver2 core.
> It defines -march=btver2 and -mtune=btver2, and lets -march=native correctly
> recognizes btver2. At the moment the tuning is mos
On 2012/07/20 00:37:15, Cary wrote:
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c
File gcc/dwarf2out.c (right):
http://codereview.appspot.com/6305113/diff/3001/gcc/dwarf2out.c#newcode8517
gcc/dwarf2out.c:8517:
Should use SKELETON_COMP_DIE_ABBREV here instead of 1.
http://
Hi Jakub,
Thanks for reviewing the patch.
> Seems the only difference from btver1 are the cache sizes, right? That
> looks very expensive way of adding another cache size, we can only have
> 32 different schedulings as PROCESSOR_* is used as a bitmask.
> For -march=native, it is either no change
Hello,
these patches fix the handling of the following (invalid) code:
I=5
print *,(/(i,i=1,I)/)
end
The first patch adds a diagnostic as ifort and Nag do.
There was a concern in the PR whether we should accept it or not.
I followed Tobias' suggestion: warning by default, error
The final pass of gcc uses dwarf information to generate unwind tables and
directives (e.g., with command line option -fexceptions). Dwarf information
generated for epilogues should be ignored when generating unwind info,
because the ARM ABI only allows unwind at procedure boundaries. This patch
ad
The variable floats_from_frame in function arm_expand_epilogue became unused
after removal of FPA support. This patch cleans it up and simplifies the
initialization of num_regs variable.
Ok for trunk?
Thanks,
Greta
ChangeLog
gcc/
2012-07-20 Greta Yorsh
* config/arm/arm.c (arm_expan
Hi,
Currently doing a 32bit unaligned load on MIPS64, produces 4 byte loads, this
can be improved to using lwl/lwr instead. The problem is the code in
mips_expand_ext_as_unaligned_load that handles this case does handle the case
where the register is DImode but the width is 32.
This patch fi
On 20/07/2012 20:16, Mikael Morin wrote:
> I have started a regression test.
> OK for trunk if it passes?
>
Unfortunately, it fails with errors like:
/home/mik/gcc4x/src/gcc/testsuite/gfortran.dg/char_pack_1.f90:55.10:
do i = i + 1, nv
1
Warning: AC-IMPLIED-DO initial expression re
Igor Zamyatin wrote:
I have now committed the attached version as Rev. 189700!
This seems to cause following fails at least on i686:
I have now committed as obvious (Rev. 189725) a patch to solve the issue
for assumed_rank_12.f90; I have also a patch for the other issue
(assumed_rank_6.f90),
ping?
On Thu, Jul 19, 2012 at 2:43 PM, Pat Haugen wrote:
> Update form stores are cracked into a store and addi, and the store is dual
> issued to the LSU/FXU. So based on this info I would think it should look
> like the following (untested).
>
> @@ -141,12 +141,10 @@ (define_insn_reservation "power4-
I have now merged the trunk into the branch (Rev. 189727).
Tobias
Looks like these were left from Steven's ident-cleanup.
Steven, for future reference, you might want to use
contrib/warn_summary on the build-logs. ;)
Incidentally, the magic option to increase diff context for svn
is -x -U as in "-x -U5" below, just to show there's not much
else in that function.
On 07/20/2012 03:34 PM, David Edelsohn wrote:
Looks good. Check it in after testing.
Testing went fine, patch checked in.
-Pat
The #elif defined ... #define DO_TEST 0 exceptions are accumulating.
Maybe the DO_TEST = 1 case should be the exception...
Committed.
gcc/testsuite:
* gcc.c-torture/execute/20101011-1.c (DO_TEST): Define as 0 for CRIS.
Index: gcc.c-torture/execute/20101011-1.c
Tobias Burnus writes:
> + if (e->rank != class_ts.u.derived->components->as->rank)
> + class_array_data_assign (&parmse->pre, ctree, parmse->expr,
> + TREE_TYPE (parmse->expr));
../../gcc/gcc/fortran/trans-expr.c: In function ‘gfc_conv_derived_to_cl
Hi,
The Octeon pop instruction does not take into account the upper 32bits of the
64bit register, so its usage can be optimized when there is a truncation right
before the instruction.
This patch implements this small optimization.
OK? Bootstrapped and tested on MIPS64-linux-gnu (Octeon) wit
On Wed, 18 Jul 2012, Siddhesh Poyarekar wrote:
> Hi,
>
> Resending. I did not get any responses the last two times and I too
> forgot about it. Can someone please review this?
This is *not* an approver-review.
> An assembler directive with an operand is filtered through
> output_asm_insn (or asm
61 matches
Mail list logo
