On Tue, May 21, 2013 at 07:57:10PM -0700, Richard Henderson wrote:
+ /* This will create the if statement label. */
+ if_stmt_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
+ void_type_node);
+ DECL_CONTEXT (if_stmt_label[ii]) =
Hi,
Is the following patch okay for trunk?
SK
- Original Message -
From: Shakthi Kannan skan...@redhat.com
To: Joseph S. Myers jos...@codesourcery.com
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, May 6, 2013 4:00:06 PM
Subject: Re: [PATCH, wwwdocs] Fix PR 50642
Hi,
I am re-submitting the
Steve Ellcey sell...@imgtec.com writes:
It might be worth having a new generic scheduler that's supposed to be
a good compromise for modern cores though. Or, more simply, we could just
change:
MIPS_CPU (mips32, PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU (mips32r2, PROCESSOR_M4K,
Hi,
Is the following patch okay for trunk?
SK
- Original Message -
From: Shakthi Kannan skan...@redhat.com
To: gcc-patches@gcc.gnu.org
Sent: Friday, May 10, 2013 12:25:07 PM
Subject: [PATCH, PR preprocessor/42014] Added LAST_SOURCE_COLUMN in while loop
Hi,
The attached patch adds
Paolo Carlini paolo.carl...@oracle.com writes:
* call.c (build_conditional_expr_1): Add location_t parameter.
(build_conditional_expr): Likewise.
../../gcc/objc/objc-next-runtime-abi-02.c: In function 'tree_node*
build_v2_build_objc_method_call(int, tree, tree, tree, tree, bool)':
Ok.
Thanks a lot!
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00698.html
Thanks, K
BTW, do we need to update GCC internals with this change?
Thanks, K
On Wed, May 22, 2013 at 11:49 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Ok.
Thanks a lot!
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00698.html
Thanks, K
On Tue, May 21, 2013 at 07:03:54PM +0200, Uros Bizjak wrote:
This patch avoids movdqu/movdqa when SSE2 is disabled. Although
-mno-sse2 is bordering on ABI violation for 64bit targets, the patch
is simple enough to fix movti_internal_rex64 pattern.
If the TImode attr variant isn't valid for
On Wed, May 22, 2013 at 9:55 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, May 21, 2013 at 07:03:54PM +0200, Uros Bizjak wrote:
This patch avoids movdqu/movdqa when SSE2 is disabled. Although
-mno-sse2 is bordering on ABI violation for 64bit targets, the patch
is simple enough to fix
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn dje@gmail.com wrote:
On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
san...@codesourcery.com wrote:
On 05/21/2013 04:04 PM, David Edelsohn wrote:
There are three issues here:
1) Someone in the LTC toolchain team needs to benchmark this
Il 18/05/2013 04:37, Chung-Ju Wu ha scritto:
Hi all,
Using current trunk repository, it is now able to build
compiler with in-tree isl and cloog.
This patch is to extend ./contrib/download_prerequisites
usage to download isl and cloog conditionally in case
people would like to build gcc
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default. With
Glibc 2.17 this enables a nanosecond resolution std::system_clock in
the default configuration,
That is only partially true. Currently the transition is already de
facto going on: Just look at how many back ends use
compute_bb_for_insn to re-initialize the BLOCK_FOR_INSN pointers right
after pass_free_cfg (it's usually the first thing they do in the
machine-reorg pass).
Yes, and we
On Tue, May 21, 2013 at 2:50 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
On Fri, May 17, 2013 at 03:18:01PM +0300, Janne Blomqvist wrote:
Hi,
the example we provide for the usage of the random_seed intrinsic
could be better. At least one user has already been tripped over by
the
Andreas Schwab sch...@suse.de ha scritto:
Paolo Carlini paolo.carl...@oracle.com writes:
* call.c (build_conditional_expr_1): Add location_t parameter.
(build_conditional_expr): Likewise.
Argh, I'll fix it momentarily sorry. I admit I forgot to enable objc and
obj-c++ when
Andreas Krebbel kreb...@linux.vnet.ibm.com writes:
On 21/05/13 11:26, Richard Sandiford wrote:
gcc/
* recog.c (offsettable_address_addr_space_p): Fix calculation of
address mode. Move pointer mode initialization to the same place.
Thanks! This fixed the failure (and others).
The problem was that we had some optimzations added to the
reload_cse_move2add pass that would attempt transformations with
multi-hard-register registers, without keeping track of the validity of the
values in all hard registers involved.
That's not clear to me: for example in
On 05/21/2013 10:25 AM, Matthias Klose wrote:
Am 19.05.2013 11:40, schrieb Paolo Carlini:
On 05/19/2013 11:35 AM, Andreas Schwab wrote:
Tests that now fail, but worked before:
Thanks Andreas. Matthias, please revert ASAP, thanks.
you already did that.
Looks like ext/random includes
OK to merge to google/4_7 and google/4_8?
On Wed, May 15, 2013 at 12:28 PM, Evgeniy Stepanov euge...@google.com wrote:
Thanks!
On Wed, May 15, 2013 at 3:05 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 14 May 2013 10:56, Jonathan Wakely wrote:
On 14 May 2013 10:45, Evgeniy Stepanov
Hi Jon,
On 05/22/2013 10:14 AM, Jonathan Wakely wrote:
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default. With
Glibc 2.17 this enables a nanosecond
The following fixes FDO on setjmp using functions. We may not
blindly split blocks before setjmp receivers as that disconnects
the PHIs and will end up creating a bogus CFG when IPA inlining
then creates new abnormal edges to the new setjmp block - we're
going to have a hard time coalescing SSA
We have a new define_subst which may help here. I *think* that
define_cond_exec is (or is nearly) a subset of define_subst. On my
medium term
to-do list is to support define_cond_exec within gensupport via the
define_subst infrastructure, removing everything except the actual
parsing
The following libffi patch
[libffi] Fix several libffi testsuite failures on 64-bit SPARC and
PowerPC (PR libffi/56033)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00840.html
has remained unreviewed for a week. It needs a libffi maintainer, which
I suppose Anthony still is,
On 22 May 2013 10:47, Paolo Carlini wrote:
Could you please double check abi_check? On this glibc 2.17 machine I'm
seeing:
1 incompatible symbols
0
_ZNSt6chrono12steady_clock3nowEv
std::chrono::steady_clock::now()
version status: incompatible
GLIBCXX_3.4.17
type: function
status: added
Hi,
On 05/22/2013 11:59 AM, Jonathan Wakely wrote:
On 22 May 2013 10:47, Paolo Carlini wrote:
Could you please double check abi_check? On this glibc 2.17 machine I'm
seeing:
1 incompatible symbols
0
_ZNSt6chrono12steady_clock3nowEv
std::chrono::steady_clock::now()
version status: incompatible
.. an idea I have got: we could arrange for defining the symbol
unconditionally, even when isn't really meaningful in that clock
configuration, and therefore exporting it uncondtionally, a dummy
implementation in many configuration. We also have at the same time to
regenerate the baselines to
On Fri, May 17, 2013 at 1:40 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 13/05/13 17:47, Richard Biener wrote:
On Mon, May 13, 2013 at 5:45 AM, Kugan
kugan.vivekanandara...@linaro.org wrote:
Hi,
This patch removes some of the redundant sign/zero
extensions using value ranges
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't, really.
Suboptimal solution because ideally we would like to fail at build time,
but this
Hello,
arm_dwarf_register_span converts regno to a dbx register number while
building the PARALLEL rtx. But since
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01131.html this information
is centralized in DBX_REGISTER_NUMBER that will be called when
processing the operands in reg_loc_descriptor,
This silences a maybe-uninitialized warning, removes an obsolete comment and
changes the CFA offset of individual registers to comprise the global CFA
offset, thus making it possible to remove the special-casing of signal frames
from sparc64_frob_update_context.
Tested on SPARC/Solaris,
On 22 May 2013 11:30, Paolo Carlini wrote:
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't, really.
Suboptimal solution because ideally we
On 22 May 2013 11:40, Jonathan Wakely wrote:
On 22 May 2013 11:30, Paolo Carlini wrote:
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't,
Quoting Eric Botcazou ebotca...@adacore.com:
The problem was that we had some optimzations added to the
reload_cse_move2add pass that would attempt transformations with
multi-hard-register registers, without keeping track of the validity of the
values in all hard registers involved.
That's
On 05/22/2013 12:40 PM, Jonathan Wakely wrote:
On 22 May 2013 11:30, Paolo Carlini wrote:
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which have the
clock available linked at run time to a .so which doesn't,
Le 21/05/2013 20:05, Tobias Burnus a écrit :
That's a follow-up the just committed patch - which came too late in
some cases.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK, thanks
Mikael
On Wed, May 22, 2013 at 11:42:45AM +0100, Jonathan Wakely wrote:
On 22 May 2013 11:40, Jonathan Wakely wrote:
On 22 May 2013 11:30, Paolo Carlini wrote:
.. put an abort or something in the dummy implementations, to make sure
people don't try to run an executable built with headers which
Hello,
This patch adds support to AdvSIMD CLZ instruction and adds tests for the same.
Regression test done for aarch64-none-elf with no issues.
OK?
Regards
VP
---
gcc/ChangeLog
2013-05-22 Vidya Praveen vidyaprav...@arm.com
* config/aarch64/aarch64-simd.md (clzv4si2): Support for
On 22 May 2013 12:15, Jakub Jelinek wrote:
If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols to
3.4.19) and have now()@GLIBCXX_3.4.17
Anthony Green gr...@moxielogic.com writes:
Rainer - sorry, I've been travelling and falling behind on email.
This patch is fine. Please commit it to GCC. I'll put it in the
libffi git tree.
No worries, I just saw your vacation note. I've commited to mainline
now.
Jakub, what should we do
On 05/22/13 11:31, Christian Bruel wrote:
Hello,
arm_dwarf_register_span converts regno to a dbx register number while
building the PARALLEL rtx. But since
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01131.html this information
is centralized in DBX_REGISTER_NUMBER that will be called when
On Wed, May 22, 2013 at 10:01 AM, Uros Bizjak ubiz...@gmail.com wrote:
This patch avoids movdqu/movdqa when SSE2 is disabled. Although
-mno-sse2 is bordering on ABI violation for 64bit targets, the patch
is simple enough to fix movti_internal_rex64 pattern.
If the TImode attr variant isn't
On 05/22/2013 01:49 PM, Jonathan Wakely wrote:
On 22 May 2013 12:15, Jakub Jelinek wrote:
If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols
On 22 May 2013 12:49, Jonathan Wakely wrote:
On 22 May 2013 12:15, Jakub Jelinek wrote:
If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and change all 3.4.18 symbols
On Wed, May 22, 2013 at 12:49:44PM +0100, Jonathan Wakely wrote:
On 22 May 2013 12:15, Jakub Jelinek wrote:
If now() can be perhaps with worse precision emulated in configurations not
built against glibc 2.17, perhaps best solution would be to
add now()@@GLIBCXX_3.4.18 into 4.8.1 (and
On Wed, May 22, 2013 at 01:49:47PM +0200, Rainer Orth wrote:
Jakub, what should we do about the 4.8 branch? Wait until 4.8.1 is
released or apply now? This is a regression from 4.7.
You can apply it now.
Jakub
A rather obvious patch.
Committed to the trunk as Rev. 199196 after build+regtesting on
x86-64-gnu-linux.
I will backport the patch to 4.9 in a while.
Tobias
2013-05-22 Tobias Burnus bur...@net-b.de
PR fortran/57364
* resolve.c (get_temp_from_expr): Commit created sym.
2013-05-22
Jakub Jelinek ja...@redhat.com writes:
On Wed, May 22, 2013 at 01:49:47PM +0200, Rainer Orth wrote:
Jakub, what should we do about the 4.8 branch? Wait until 4.8.1 is
released or apply now? This is a regression from 4.7.
You can apply it now.
Done, thanks.
Rainer
--
On 22 May 2013 12:47, Vidya Praveen vidyaprav...@arm.com wrote:
Hello,
This patch adds support to AdvSIMD CLZ instruction and adds tests for the
same.
Regression test done for aarch64-none-elf with no issues.
OK?
Regards
VP
---
gcc/ChangeLog
2013-05-22 Vidya Praveen
I don't believe those functions should be provided by libgcc, at least
not by shared libgcc.so, as explained by Alan.
- David
On 05/22/2013 02:01 AM, Richard Biener wrote:
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn dje@gmail.com wrote:
Increasing the alignment of arrays within structs and unions would be
nice, but that probably will change the ABI. I think that they best we
may be able to do is increase the
On Wed, May 22, 2013 at 09:40:22AM -0400, David Edelsohn wrote:
I don't believe those functions should be provided by libgcc, at least
not by shared libgcc.so, as explained by Alan.
David, I think t-savresfgpr satifies that requirement.
# These can't end up in shared libgcc
LIB2ADD_ST += \
...
On Wed, May 22, 2013 at 3:57 PM, Sandra Loosemore
san...@codesourcery.com wrote:
On 05/22/2013 02:01 AM, Richard Biener wrote:
On Wed, May 22, 2013 at 3:57 AM, David Edelsohn dje@gmail.com wrote:
Increasing the alignment of arrays within structs and unions would be
nice, but that
Why does cross need the functions in libgcc and not provided by the linker?
- David
On Wed, May 22, 2013 at 10:00 AM, Alan Modra amo...@gmail.com wrote:
On Wed, May 22, 2013 at 09:40:22AM -0400, David Edelsohn wrote:
I don't believe those functions should be provided by libgcc, at least
not
Jonathan Wakely jwakely@gmail.com writes:
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default. With
Glibc 2.17 this enables a nanosecond resolution
With one Fortran file, I get the following assembler errors:
/tmp/cc28epKK.s:2075: Error: junk `@1.2304+16' after expression
That's due to the way a temporary variable is generated. While that
variable is local to the procedure, the name somehow escapes into the
assembler file. The dump looks
On Wed, May 22, 2013 at 07:57:34AM -0600, Sandra Loosemore wrote:
On 05/22/2013 02:01 AM, Richard Biener wrote:
Maybe the idea was to increase the alignment of the struct (without
affecting it's layout) when that increases the alignment of a contained
array member. Like for
struct { int i;
On Wed, May 22, 2013 at 10:05:47AM -0400, David Edelsohn wrote:
Why does cross need the functions in libgcc and not provided by the linker?
Only the ppc64 linker provides save/restore functions magically.
--
Alan Modra
Australia Development Lab, IBM
On Wed, May 22, 2013 at 10:35 AM, Alan Modra amo...@gmail.com wrote:
On Wed, May 22, 2013 at 10:05:47AM -0400, David Edelsohn wrote:
Why does cross need the functions in libgcc and not provided by the linker?
Only the ppc64 linker provides save/restore functions magically.
Okay, then the
On 22 May 2013 15:05, Rainer Orth wrote:
Jonathan Wakely jwakely@gmail.com writes:
This alters the configure script to enable C++11 thread library
features based on targets that are known to support the features,
rather than based on link tests which are disabled by default. With
Glibc
Jonathan Wakely jwakely@gmail.com writes:
All of them have the same root cause:
Excess errors:
Undefined first referenced
symbol in file
nanosleep /var/tmp//ccQhmiwd.o (symbol belongs to implicit dependency
/lib/librt.so.1)
ld: fatal:
Sounds reasonable. The patch is updated, bootstrapped and passed all
regression test.
Dehao
On Tue, May 21, 2013 at 5:34 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, May 17, 2013 at 5:48 PM, Dehao Chen de...@google.com wrote:
On Fri, May 17, 2013 at 1:22 AM, Richard Biener
On 2013-05-22 05:32 , Evgeniy Stepanov wrote:
OK to merge to google/4_7 and google/4_8?
Yes. Patches coming from trunk or other release branches need no
further approval for backporting. You just need to make sure you don't
introduce any regressions, of course.
Diego.
Hi,
earlier this week I asked on IRC whether we could have non-top-level
BIT_FIELD_REFs and Richi said that we could. However, when I later
looked at SRA code, quite apparently it is not designed to handle
non-top-level BIT_FIELD_REFs, IMAGPART_EXPRs or REALPART_EXPRs. So in
order to test
Hello Richard,
Thank you for reviewing my code. Please see my responses below.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Tuesday, May 21, 2013 10:57 PM
To: Iyer, Balaji V
Cc: 'Joseph S. Myers'; 'Aldy Hernandez';
The test file scalar_intrinsics.c (in gcc.target/aarch64)
is currently compile-only.
If you attempt to make it run, as opposed to just generate
assembler, you can't because it won't assemble.
There are two issues causing trouble here:
1) Use of invalid instruction mov d0, d1.
It should be
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57372
A fix is forthcoming - this is a dup of PR57340.
Ramana
--
Roman
Shakthi == Shakthi Kannan skan...@redhat.com writes:
Shakthi Is the following patch okay for trunk?
I still think it needs a test case.
I also don't recall -- did you check to see if the column number that is
emitted is actually correct?
You may want to change the Subject line of your note, as
On 22 May 2013 16:18, Ian Bolton ian.bol...@arm.com wrote:
The test file scalar_intrinsics.c (in gcc.target/aarch64)
is currently compile-only.
If you attempt to make it run, as opposed to just generate
assembler, you can't because it won't assemble.
There are two issues causing trouble
On 2013-05-21 23:15, Jakub Jelinek wrote:
Furthermore, do you want to generate just normal loop out of it, or
shouldn't we generate a #pragma omp simd loop out of it instead?
Haven't read the spec if array notation guarantees lack of forward/backward
loop dependencies and what are the
Hi,
This fixes PR target/57340 a fallout from my PR target/19599 patch.
Unfortunately this didn't show up in the testing I did and I'm sorry
about the breakage.
The problem here is that we choose r3 as a padding register with
indirect tailcalls that could use r3 for this purpose. Ofcourse
Hi Jakub,
Please see my response below.
Thanks,
Balaji V. Iyer.
-Original Message-
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: Wednesday, May 22, 2013 2:15 AM
To: Richard Henderson
Cc: Iyer, Balaji V; 'Joseph S. Myers'; 'Aldy Hernandez'; 'gcc-patches'
Subject: Re:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Wednesday, May 22, 2013 11:30 AM
To: Jakub Jelinek
Cc: Iyer, Balaji V; 'Joseph S. Myers'; 'Aldy Hernandez'; 'gcc-patches'
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 2013-05-21
Looks ok to me in general.
1) the parameter name is not ideal -- it is not callonce.
2) it might be better to extend the callonce parameter into
-ftest-coverage option such as -ftest-coverage=exec_once?
3) need documentation in invoke.texi
4) watch out for long lines.
cc Teresa.
David
On Tue,
On 05/22/2013 09:37 AM, Iyer, Balaji V wrote:
Furthermore, do you want to generate just normal loop out of it, or
shouldn't we generate a #pragma omp simd loop out of it instead?
Haven't read the spec if array notation guarantees lack of
forward/backward loop dependencies and what are the
Hi,
I have not intended aggregate jump functions to work with bit-fields
but apparently forgot to include the test to ignore them. PR 57347
testcase gives a good example why they need to be avoided. If we ever
decide to optimize for them too (and not just in IPA land), they
should be lowered
On 17 May 2013 19:20, Ian Bolton ian.bol...@arm.com wrote:
The MOVK instruction is currently not used when operand 2 is
more than 16 bits, which leads to sub-optimal code.
This patch improves those situations by removing the check and
instead masking down to 16 bits within the new X format
@@ -105,7 +105,7 @@ struct locus_descrim_hasher : typed_free_remove l
inline hashval_t
locus_descrim_hasher::hash (const value_type *item)
{
- return item-locus;
+ return LOCATION_LINE (item-locus);
}
/* Equality function for the locus-to-discriminator map. A and B
@@ -114,7 +114,7 @@
Sure, will update the patch for that.
Dehao
On Wed, May 22, 2013 at 9:40 AM, Cary Coutant ccout...@google.com wrote:
@@ -105,7 +105,7 @@ struct locus_descrim_hasher : typed_free_remove l
inline hashval_t
locus_descrim_hasher::hash (const value_type *item)
{
- return item-locus;
+
If -fprofile-use is specified, but no .gcda file is found, reset all
the flags back to the values they would have had if -fprofile-use was
not specified. Since the code path where -fprofile-use is on and
.gcda files are not found is not a well tested pass, this will
increase the robustness
This patch adds support for the byte, half-word, and quad-word atomic memory
operations that were added in ISA 2.07 (i.e. power8). Like the other patches,
this passes bootstrap and had no regressions in make check. Is it ok to commit
this patch after the previous 6 patches have been applied?
I unfortunately have not had time to keep up with gccgo, so I'm adding a
note that GCC 4.8.1 does not yet implement Go 1.1. Committed to the web
site.
Ian
Index: changes.html
===
RCS file:
On 05/22/2013 02:54 AM, Kyrylo Tkachov wrote:
From what I understand, using define_subst would mean creating a
define_subst for every pattern that can be predicable? There are at least
600 predicable patterns in the arm backend, so that would be infeasible.
No, define_subst works across
On 2013-05-22 08:18, Iyer, Balaji V wrote:
The overall function names are same, but the components inside it function
differs greatly from C and C++. For example, in C++ I can't use
build_modify_expr, but build_x_modify_expr. Also, I need to handle
overloaded function types, and that requires
Jan Hubicka hubi...@ucw.cz wrote:
If -fprofile-use is specified, but no .gcda file is found, reset all
the flags back to the values they would have had if -fprofile-use was
not specified. Since the code path where -fprofile-use is on and
.gcda files are not found is not a well tested pass,
Pre-remark: This patch does *not* enable finalization or polymorphic
deallocation.
* * *
Dear all,
The attached patch is a bit boring and invasive, but it paves the way to
FINAL support.
Changes of technical kind:
* Changed ABI for CLASS's virtual table (due to _final) - and, hence, it
Fix typo in assignment email address, to make gcc match GNU site:
https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters
It would be awesome if now GCC assigments were magically less work.
-benjamin2013-05-22 Benjamin Kosnik b...@redhat.com
* htdocs/contribute.html: Use
Hi Tobias,
I have now changed the mangling, see attached patch. (The test file uses
finalization - hence, I do not include it into the patch. I will include
it in the FINAL patch.)
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
OK (obvious really).
Thanks for the patch!
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Jeff Law
Sent: Wednesday, May 22, 2013 12:20 PM
To: Iyer, Balaji V
Cc: Jakub Jelinek; Richard Henderson; 'Joseph S. Myers'; 'Aldy Hernandez';
'gcc-
patches'
Subject: Re:
On 05/22/2013 01:13 PM, Iyer, Balaji V wrote:
Hi Jeff, Yes, converting the array notation expansion to #pragma simd
(or #pragma omp simd) trees will be beneficial performance wise. But,
it will require semi-significant re-write and this can destabilize a
currently stable implementation. IMHO,
On 22 May 2013 16:36:52 David Edelsohn dje@gmail.com wrote:
On Wed, May 22, 2013 at 10:35 AM, Alan Modra amo...@gmail.com wrote:
On Wed, May 22, 2013 at 10:05:47AM -0400, David Edelsohn wrote:
Why does cross need the functions in libgcc and not provided by the linker?
Only the ppc64
I've been writing some automation around testing gcc patches, and kept
running into ChangeLog conflicts, so I wrote the following to make it
easier.
The attached one-liner wraps git show into a form that omits changes
to ChangeLog files, for use when generating patches from a git repo,
so that
Hi,
Again sorry for such a delay. Paolo subtly ping'ed me on DR39
(c++/13590), and I remember that this bug (c++/54537) was blocking the
patch I wrote last year for DR39.
2012/11/15 Jason Merrill ja...@redhat.com:
[...]
I was only thinking of the primary signature; putting
extern C double pow
Revised patch included below. The spacing of my pasted in patch text
looks funky again, let me know if you want the patch as an attachment
instead.
I addressed all of Steven's comments, except for the suggestion to use
gcc_assert
instead of error() in verify_hot_cold_block_grouping() to keep this
On Wed, May 22, 2013 at 10:21 AM, Eric Botcazou wrote:
That is only partially true. Currently the transition is already de
facto going on: Just look at how many back ends use
compute_bb_for_insn to re-initialize the BLOCK_FOR_INSN pointers right
after pass_free_cfg (it's usually the first
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Wednesday, May 22, 2013 1:34 PM
To: Iyer, Balaji V
Cc: 'Joseph S. Myers'; 'Aldy Hernandez'; 'gcc-patches'
Subject: Re: [PING]RE: [patch] cilkplus: Array notation for C patch
On 2013-05-22 08:18, Iyer,
On 05/22/2013 03:17 PM, Steven Bosscher wrote:
Ah, the crazy stuff one can do after machine reorg. It's the Wild West
of GCC :-)
I still look at that hook as the contribution I most wish I'd never
made. The abuses are, umm, amazing.
jeff
A rather simple patch found while testing the draft finalization patch.
For a class(...), allocatable, intent(out) dummy argument, the actual
argument has to be deallocated. That worked for scalar polymorphic vars,
but not for polymorphic arrays.
Build and regtested on x86-64-gnu-linux.
OK
Hi Ian,
Thanks for the review. Here's v2, which I think addresses both of your
comments.
Kind Regards,
Matt.
2013-05-22 Matt Burgess matt...@linuxfromscratch.org
other/PR56780
* libiberty/configure.ac: Move test for --enable-install-libiberty
outside of the
On Wed, 22 May 2013, Jeff Law wrote:
So if we can represent array notation as an OpenMP SIMD loop and re-use the
OpenMP code generation, that's a significant win. I realize the OpenMP SIMD
stuff is still in-progress, but from a design standpoint we'd like to separate
out the front-end issues
On Wed, May 22, 2013 at 7:17 AM, Teresa Johnson wrote:
On Mon, May 20, 2013 at 3:42 PM, Steven Bosscher wrote:
But to be honest, I still don't really understand why we emit a
barrier at all if we're in cfglayout mode. They're ignored, they're
going to be overlooked if someone looks for
1 - 100 of 126 matches
Mail list logo
