On Sun, May 18, 2014 at 11:10 AM, Uros Bizjak wrote:
> Attached patch fixes following errors in .pod document sources:
>
> gfdl.pod around line 53: Expected text after =item, not a number
> gfdl.pod around line 147: Expected text after =item, not a number
> gfdl.pod around line 165: Expected text
graph dump is broken in trunk (and gcc-49) -- the subgraph of the last
function gets dumped. The patch fixed the problem. Also fixed the
function header dump -- the cgraph uid is still used in many places
such as -fdisable|enable-xxx options.
Ok for trunk?
David
Index: ChangeLog
=
> > * gfortran.dg/assign_10.f90
> > * gfortran.dg/assumed_rank_12.f90: Likewise.
> Likewise what? ;)
* gfortran.dg/assign_10.f90: Adjust regexps.
* gfortran.dg/assumed_rank_12.f90: Likewise.
Mystery of copy&paste;-)
Dominique
On Thu, Feb 27, 2014 at 7:57 AM, Yufeng Zhang wrote:
> On 02/26/14 02:25, Andrew Pinski wrote:
>>
>> Hi,
>>This is the final patch which adds support for the dynamic linker and
>> multi-lib directories for ILP32. I did not change multi-arch support as
>> I did not know what it should be chang
Hi,
On 05/24/2014 01:14 AM, Dominique d'Humières wrote:
* gfortran.dg/assign_10.f90
* gfortran.dg/assumed_rank_12.f90: Likewise.
Likewise what? ;)
Paolo.
I’ll commit this afternoon the following patch to the fortran-dev branch unless
someone objects.
Dominique
2014-05-24 Dominique d'Humieres
* gfortran.dg/assign_10.f90
* gfortran.dg/assumed_rank_12.f90: Likewise.
* gfortran.dg/coarray_12.f90: Likewise.
* gfortra
> Well, allocate_struct_function has a abstract_p argument for that. But
> yes, a simple patch like
>
> Index: gcc/function.c
> ===
> --- gcc/function.c (revision 210845)
> +++ gcc/function.c (working copy)
> @@ -64,6 +64,7
ok
On Fri, May 23, 2014 at 3:14 PM, Teresa Johnson wrote:
>
> On May 23, 2014 2:56 PM, "Xinliang David Li" wrote:
>>
>> On Fri, May 23, 2014 at 2:50 PM, Teresa Johnson
>> wrote:
>> > On Fri, May 23, 2014 at 2:28 PM, Xinliang David Li
>> > wrote:
>> >> for (i = 0; i < num_strings; i++)
>>
Hello all,
The attached patch fixes this PR by not seeking if the next character is a
space.
Regression tested on x86-64. New test case provided.
OK for trunk and back ports?
Regards.
Jerry
2014-05-23 Jerry DeLisle
PR libgfortran/61173
* io/list_read.c (eat_spaces): If t
ok.
David
On Fri, May 23, 2014 at 3:03 PM, Dehao Chen wrote:
> This patch fixes LIPO ICE that an unresolved node escaped after lipo fixup.
>
> testing on going. OK for google-4_9?
>
> Thanks,
> Dehao
>
> Index: gcc/ipa.c
> ===
> ---
This patch fixes LIPO ICE that an unresolved node escaped after lipo fixup.
testing on going. OK for google-4_9?
Thanks,
Dehao
Index: gcc/ipa.c
===
--- gcc/ipa.c (revision 210864)
+++ gcc/ipa.c (working copy)
@@ -39,6 +39,7 @@ along
On Fri, May 23, 2014 at 2:50 PM, Teresa Johnson wrote:
> On Fri, May 23, 2014 at 2:28 PM, Xinliang David Li wrote:
>> for (i = 0; i < num_strings; i++)
>> +{
>> + if (strcmp (build_info_strings[i], gi_ptr->build_info[i]))
>>
>> Add also check of gi_ptr->build_info:
>>
>>
On 05/23/2014 01:30 PM, Jan Hubicka wrote:
Vtables are always accessed via the vtbl pointer otherwise (that is almost
always misaligned because of the offset to RTTI pointer), so for vtables static
to given compilation unit, there is no way other compiler can derive the
alignment based on ABI pro
On Fri, May 23, 2014 at 2:28 PM, Xinliang David Li wrote:
> for (i = 0; i < num_strings; i++)
> +{
> + if (strcmp (build_info_strings[i], gi_ptr->build_info[i]))
>
> Add also check of gi_ptr->build_info:
>
>if (!gi_ptr->build_info || strcmp ( )
Added the check earli
> gcc/
> PR rtl-optimization/61222
> * combine.c (simplify_shift_const_1): Fix modes used when handling
> PLUS.
>
> gcc/testsuite/
> PR rtl-optimization/61222
> * gcc.c-torture/compile/pr61222-1.c: New test.
> * gcc.c-torture/compile/pr61222-2.c: Likewise.
OK,
for (i = 0; i < num_strings; i++)
+{
+ if (strcmp (build_info_strings[i], gi_ptr->build_info[i]))
Add also check of gi_ptr->build_info:
if (!gi_ptr->build_info || strcmp ( )
+{
+ gcov_error ("profiling:%s:Mismatched build info string "
+
Done. Passes manual testing, rerunning regression testing. New patch attached.
Thanks,
Teresa
On Fri, May 23, 2014 at 11:35 AM, Xinliang David Li wrote:
> The change makes gcov_info a variable length array, which is not ideal.
>
> Better just add one more field (instead of two):
>
> struct gcov_
Hi,
On 05/23/2014 10:32 PM, François Dumont wrote:
On 12/05/2014 22:42, Paolo Carlini wrote:
Hi,
On 05/12/2014 10:14 PM, François Dumont wrote:
Regarding Makefile.in I miss last time. I moved to a new system
lately, a Ubuntu based one, and still need to find out what version
of automake/auto
On Thu, May 22, 2014 at 5:04 PM, Xinliang David Li wrote:
> Also missing documentation in invoke.texi? Other than that, ok.
I have made the changes and committed my patch.
Sri
>
> David
>
> On Thu, May 22, 2014 at 5:00 PM, Paul Pluzhnikov
> wrote:
>> On Thu, May 22, 2014 at 4:36 PM, Sriraman
On Fri, May 23, 2014 at 1:32 PM, François Dumont wrote:
> Looks like I will have to build automake 1.11.1 myself otherwise.
Yes I do.
--
Regards,
Tim Shen
Committed as Rev. 210877.
Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 210876)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2014-05-23 Tobias Burnus
+
+ * gfc-internals.texi: Change URLs
On 12/05/2014 22:42, Paolo Carlini wrote:
Hi,
On 05/12/2014 10:14 PM, François Dumont wrote:
Regarding Makefile.in I miss last time. I moved to a new system
lately, a Ubuntu based one, and still need to find out what version
of automake/autoreconf I need to install. For the moment I have
upda
On Fri, May 23, 2014 at 01:54:47PM -0500, Peter Bergner wrote:
> On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> > The following patch gets bootstrap working again, but there seems to
> > be a large number of testsuite failures I will look into before
> > submitting the patch to the LLVM
On Fri, May 23, 2014 at 11:22:10AM -0500, Pat Haugen wrote:
> On 05/23/2014 01:09 AM, Segher Boessenkool wrote:
> >@@ -27385,6 +27371,11 @@ insn_must_be_first_in_group (rtx insn)
> > case TYPE_MFJMPR:
> > case TYPE_MTJMPR:
> >return true;
> >+case TYPE_MUL:
> >
On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> The following patch gets bootstrap working again, but there seems to
> be a large number of testsuite failures I will look into before
> submitting the patch to the LLVM mailing list.
FYI, it looks like a huge number of the failures are fro
On 05/23/14 12:39, Martin Jambor wrote:
Hi,
since Jakub has fixed my code and replaced wrong
validate_change (uin, DF_REF_LOC (use), newreg, true);
with correct
validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
in split_live_ranges_for_shrink_wrap, we
Hi,
since Jakub has fixed my code and replaced wrong
validate_change (uin, DF_REF_LOC (use), newreg, true);
with correct
validate_change (uin, DF_REF_REAL_LOC (use), newreg, true);
in split_live_ranges_for_shrink_wrap, we can remove the punting
condition slightly a
The change makes gcov_info a variable length array, which is not ideal.
Better just add one more field (instead of two):
struct gcov_info {
...
char ** build_info;
};
For regular case, it is null, for case where the build info is
available, make it point to a string array (with an null end
On 05/21/14 21:59, Rich Felker wrote:
On Wed, May 21, 2014 at 11:17:53AM +0200, Richard Biener wrote:
On Wed, May 21, 2014 at 3:59 AM, Rich Felker wrote:
Bug # 61144 is a regression in 4.9.0 that breaks building of musl libc
due to aggressive and semantically-incorrect constant folding of weak
On 05/20/14 20:12, Zhenqiang Chen wrote:
In the code, there are 4 combinations of EDGE_COUNT: <1, 1>, <1, 2>,
<2, 1> and <2, 2>. <2, 1> is "illegal". <2, 2> is legal, but need
split_edge. <1, *> can bypass the second check. EDGE_CRITICAL_P can
only distinguish <2, 2> from others.
So I think two
On 05/20/14 15:36, Richard Sandiford wrote:
This is OK for the trunk (referring to the follow-up message which fixed
EWRONGPATCH.
Sorry, while working on the follow-up LRA patch, I realised I hadn't
accounted for target changes that happen directly via target_reinit
(rather than SWITCHABLE_TARG
On 05/22/14 15:33, Kai Tietz wrote:
Hello,
This patch avoids for sibling-tail-calls the use of pseudo-register.
Instead it uses for load of memory-address the accumulator-register.
By this we avoid that IRA/LRA need to choose a register. So we
reduce register-pressure.
The accumulator-register
Support for embedding arbitrary build information from the profile-generate
compile into the gcda file in a new BUILD_INFO record. Lines from a file
passed to the -fprofile-generate compile via a new
-fprofile-generate-buildinfo=filename option are embedded as strings
in the gcov_info struct and em
On 05/22/14 16:07, H.J. Lu wrote:
On Thu, May 22, 2014 at 2:33 PM, Kai Tietz wrote:
Hello,
This patch avoids for sibling-tail-calls the use of pseudo-register. Instead
it uses for load of memory-address the accumulator-register. By this we avoid
that IRA/LRA need to choose a register. So
On 05/23/14 02:58, Kai Tietz wrote:
Hello,
yes the underlying issue is the same as for PR/46219. Nevertheless
the patch doesn't solve this mentioned PR as I used for know a pretty
conservative checking of allowed memories. By extending
x86_sibcall_memory_p_1 function about allowing register-arg
On 05/23/14 01:35, Maxim Kuvyrkov wrote:
On May 23, 2014, at 7:23 PM, Andreas Schwab wrote:
../../gcc/config/ia64/ia64.c: In function 'int
ia64_first_cycle_multipass_dfa_lookahead_guard(rtx, int)':
../../gcc/config/ia64/ia64.c:7551:1: error: control reaches end of non-void
function [-Werror=
On 05/23/14 05:45, Richard Biener wrote:
The following changes the configury to insist on [u]int64_t being
available and removes the very old __int64 case. Autoconf doesn't
check for it, support came in via a big merge in Dec 2002, r60174,
and it was never used on the libcpp side until I fixed
On 05/23/14 07:49, Richard Biener wrote:
This patch does the exercise of a "grand" rename and drops
HOST_WIDEST_INT which is equal to HOST_WIDE_INT now. But
we use [u]int64_t and the C99 inttypes.h PRI[dux]64 printf
modifiers (which I provide in hwint.h if they are not available).
Certainly mo
> >
> > if (expected_loop_iterations_reliable_p (loop))
> > niters = expected_loop_iterations (loop);
>
> But why not simply never return bogus values from expected-loop-iterations?
Hmm, actually we do have:
/* If we have a measured profile, use it to estimate the number of
iterations.
On May 23, 2014 7:26:04 PM CEST, Jan Hubicka wrote:
>> On Thu, May 22, 2014 at 11:36 PM, Dehao Chen
>wrote:
>> > If a loop's header count is less than iteration count, the
>iteration
>> > estimation is apparently incorrect for this loop. Thus disable
>> > unrolling of such loops.
>> >
>> > Testin
Hi,
I would like to ping these two patches. If we conclude it is absolutely unsafe
to not align virtual tables to 16byte boundary (that is an x86_64 ABI
requirement for array datastructures but I would like to argue that vtables are
compiler controlled ones and do not need to follow ABI here), I ca
> On Thu, May 22, 2014 at 11:36 PM, Dehao Chen wrote:
> > If a loop's header count is less than iteration count, the iteration
> > estimation is apparently incorrect for this loop. Thus disable
> > unrolling of such loops.
> >
> > Testing on going. OK for trunk if test pass?
>
> No. Why don't yo
On Fri, 2014-05-23 at 09:25 -0500, Peter Bergner wrote:
> xagsmtp4.20140523142452.1...@vmsdvm6.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6)
>
> On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
> > On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
On Fri, May 23, 2014 at 04:11:48PM +0400, Konstantin Serebryany wrote:
> >> 2) it doesn't still deal with unaligned power of two accesses properly,
> >>but neither does llvm (at least not 3.4). Am not talking about
> >>undefined behavior cases where the compiler isn't told the access
> >>
On 05/23/2014 01:09 AM, Segher Boessenkool wrote:
@@ -27385,6 +27371,11 @@ insn_must_be_first_in_group (rtx insn)
case TYPE_MFJMPR:
case TYPE_MTJMPR:
return true;
+case TYPE_MUL:
+ if (get_attr_dot (insn) == DOT_YES)
+return true;
+
On Fri, May 23, 2014 at 11:40 AM, Jakub Jelinek wrote:
> No other shared library does anything close to that, for each such library
> you can interpose any of its public symbols, either you know what you are
> doing when interposing it, or it breaks.
I think I have finally recalled why we added t
On Fri, May 23, 2014 at 11:36:33AM -0400, Vladimir Makarov wrote:
> The following patch adds missed test for the PR.
>
> Committed to the trunk as rev. 210838.
>
> 2014-05-23 Vladimir Makarov
>
> PR rtl-optimization/61215
> * gcc.target/i386/pr61215.c: New.
>
> Index: testsui
The following patch adds missed test for the PR.
Committed to the trunk as rev. 210838.
2014-05-23 Vladimir Makarov
PR rtl-optimization/61215
* gcc.target/i386/pr61215.c: New.
Index: testsuite/gcc.target/i386/pr61215.c
Looks good except for :
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index ef370fe..7e1ec71 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3280,7 +3280,8 @@ proc check_effective_target_vect_bswap { }
OK, let's start again from scratch. This patch fixes PR61098, a
problem caused by trying to do arithmetic on the count register. The
fix is to provide a new pseudo in rs6000_emit_set_long_const so
arithmetic will be done in a gpr.
Additionally, the patch fixes a number of other bugs and cleanup
Hi Christophe,
is there anything special about your setup? We've seen it build on
arm/linux and arm/android correctly.
On Fri, May 23, 2014 at 6:06 PM, Christophe Lyon
wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is
On Fri, May 23, 2014 at 6:35 PM, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote:
>> On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote:
>>> This is the latest patch for -fsanitize=float-cast-overflow. Since last
>>> version it:
>>> - adds tons of t
Hi,
sorry, I should have added a better description of the overall
algorithm, I will try to do that now, I hope I will at least clarify
what stage does what.
At summary generation time, we process one function after another,
looking at their bodies. There are three new things in the generated
su
On Fri, May 23, 2014 at 6:28 PM, Jakub Jelinek wrote:
> On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote:
>> This is the latest patch for -fsanitize=float-cast-overflow. Since last
>> version it:
>> - adds tons of tests written by Jakub;
>> - patches libubsan so it can handle 96-bit
On Fri, May 23, 2014 at 04:19:00PM +0200, Marek Polacek wrote:
> This is the latest patch for -fsanitize=float-cast-overflow. Since last
> version it:
> - adds tons of tests written by Jakub;
> - patches libubsan so it can handle 96-bit floating-point types
> (that is, long double and __float80
On Fri, 2014-05-23 at 17:45 +0400, Konstantin Serebryany wrote:
> On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
> > On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
> >> 5 months' worth of changes may break any platform we are not testing
> >> ourselves
> >> (that in
On Fri, May 23, 2014 at 6:12 PM, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 6:11 PM, Kugan
> wrote:
>> On 24/05/14 00:06, Christophe Lyon wrote:
>>> Hi,
>>> Since merge from upstream r209283 (210743 in GCC), my build fails on
>>> ARM, because rpc/xdr.h is not found.
>>> Is this expect
On Fri, May 23, 2014 at 6:11 PM, Kugan
wrote:
> On 24/05/14 00:06, Christophe Lyon wrote:
>> Hi,
>> Since merge from upstream r209283 (210743 in GCC), my build fails on
>> ARM, because rpc/xdr.h is not found.
>> Is this expected?
> I also have the same issue. I had to build glibc with
> --enable-o
On 24/05/14 00:06, Christophe Lyon wrote:
> Hi,
> Since merge from upstream r209283 (210743 in GCC), my build fails on
> ARM, because rpc/xdr.h is not found.
> Is this expected?
I also have the same issue. I had to build glibc with
--enable-obsolete-rpc to bootstrap now.
Thanks,
Kugan
Hi,
Since merge from upstream r209283 (210743 in GCC), my build fails on
ARM, because rpc/xdr.h is not found.
Is this expected?
Thanks,
Christophe.
On 23 May 2014 15:45, Konstantin Serebryany
wrote:
> On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
>> On Mon, May 12, 2014 at 03:20:37PM
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> They are often labeled just "integer" currently. Fix that.
>
> Also handle shift properly in those scheduling descriptions that
> neglected it.
>
>
> 2014-05-22 Segher Boessenkool
>
> gcc/
> * config/rs6000/440.md (ppc440-int
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> This uses the attribute "size" to specify the differences:
>
> idiv -> div size=32
> ldiv -> div size=64
>
> It could use "dot" as well, but the current code doesn't handle that.
>
>
> 2014-05-22 Segher Boessenkool
>
>
On Fri, May 23, 2014 at 5:41 PM, Marek Polacek wrote:
> On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
>> 5 months' worth of changes may break any platform we are not testing
>> ourselves
>> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM),
>> p
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> They are currently just "integer", but the dot version is fast_compare.
> This makes them all "logical".
>
>
> 2014-05-22 Segher Boessenkool
>
> gcc/
> * config/rs6000/rs6000.md (type): Add "logical". Delete
> "fast_c
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> They are currently just "integer", but the dot version is fast_compare.
> This makes them all "add". Later we should introduce attributes to
> distinguish e.g. addc and adde (which aren't currently handled as
> separate instructions at
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> This uses the attribute "size" to specify the differences:
>
> insert_word -> insert size=32
> insert_dword -> insert size=64
>
> It could use "dot" as well, but the current code doesn't handle that.
>
>
> 2014-05-22 Se
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> This uses the attributes "var_shift" and "dot" to specify the differences:
>
> var_shift_rotate-> shift var_shift=yes
> delayed_compare -> shift var_shift=no dot=yes
> var_delayed_compare -> shift var_shi
On Mon, May 12, 2014 at 03:20:37PM +0400, Konstantin Serebryany wrote:
> 5 months' worth of changes may break any platform we are not testing ourselves
> (that includes Ubuntu 12.04, 13.10, 14.04, Mac 10.9, Windows 7, Android ARM),
> please help us test this patch on your favorite platform.
On pow
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> This uses the attributes "size" and "dot" to specify the differences:
>
> imul3 -> mul size=8
> imul2 -> mul size=16
> imul -> mul size=32
> lmul -> mul size=64
> imul_compare -> mul size=32 dot=ye
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> This is for the legacy integer multiply-accumulate instructions.
> Quite a mouthful, and "mulhw" is also a terrible name since we already
> have a machine instruction called exactly that. Hence "halfmul".
>
> Also fixes the titan automa
On Fri, May 23, 2014 at 2:09 AM, Segher Boessenkool
wrote:
> Get rid of the one huge line. Group and order things a bit. Further
> changes will follow so this doesn't try to make it perfect.
>
> The rest of this patch series reduces the number of different integer
> instruction types by folding
Hi!
On Fri, 23 May 2014 13:50:40 +0200, Richard Biener
wrote:
> I think it was supposed to note that it uses two bits in the mask.
That is, you'd like me to add a comment saying that? (Which I can
certainly do.)
> Did Jakub approve these patches you are committing now?
For the two in this th
>> 2) it doesn't still deal with unaligned power of two accesses properly,
>>but neither does llvm (at least not 3.4). Am not talking about
>>undefined behavior cases where the compiler isn't told the access
>>is misaligned, but e.g. when accessing struct S { int x; }
>>__attribute
From: tschwinge
gcc/
* gimplify.c (omp_notice_variable) :
Rewrite check for ORT_PARALLEL and ORT_COMBINED_PARALLEL.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210860
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 3 +++
gcc/gimplify.c | 3 +--
2 files ch
On Fri, May 23, 2014 at 12:33 PM, Zhenqiang Chen
wrote:
> On 23 May 2014 17:05, Richard Biener wrote:
>> On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> The patch fixes PR rtl-optimization/61278. Root cause for issue is
>>> that df_live does not exist at -O1.
>>>
>>> Bo
I think it was supposed to note that it uses two bits in the mask.
Did Jakub approve these patches you are committing now?
Thanks,
Richard.
On Fri, May 23, 2014 at 1:32 PM, Thomas Schwinge
wrote:
> From: tschwinge
>
> gcc/
> * gimple.h (enum gf_mask): Rewrite "<< 0" shift expre
On 23/05/14 12:49 +0200, Rainer Orth wrote:
Any reason to list dragonfly twice?
Oops, no - that's due to me reordering commits with rebase so the sed
command added it to some files I'd already added it to.
Fixed with the attached patch, thanks.
commit 12ad71abb1122314f38e98d382c86eacd3cbb022
A
The following changes the configury to insist on [u]int64_t being
available and removes the very old __int64 case. Autoconf doesn't
check for it, support came in via a big merge in Dec 2002, r60174,
and it was never used on the libcpp side until I fixed that with
the last patch of this series, so
From: tschwinge
gcc/
* omp-low.c (expand_omp_for_static_chunk): Rename variable si to
gsi, and variables v_* to v*.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210858
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 5 +++
gcc/omp-low.c | 118 +
> This looks OK to me.
I obviously didn't look carefully enough, there are a few thinkos in the
output_constructor_bitfield hunk:
- if (shift < HOST_BITS_PER_WIDE_INT
- && shift + this_time > HOST_BITS_PER_WIDE_INT)
- {
- this_time = shift + this_time -
On Fri, May 23, 2014 at 01:08:09PM +0200, Thomas Schwinge wrote:
> @@ -5683,7 +5683,14 @@ omp_notice_variable (struct gimplify_omp_ctx *ctx,
> tree decl, bool in_code)
>switch (default_kind)
> {
> case OMP_CLAUSE_DEFAULT_NONE:
> - if ((ctx->region_type & ORT_TASK) != 0)
>
From: tschwinge
gcc/
* gimple.h (enum gf_mask): Rewrite "<< 0" shift expressions used
for GF_OMP_FOR_KIND_MASK, GF_OMP_FOR_KIND_FOR,
GF_OMP_FOR_KIND_DISTRIBUTE, GF_OMP_FOR_KIND_SIMD,
GF_OMP_FOR_KIND_CILKSIMD, GF_OMP_TARGET_KIND_MASK,
GF_OMP_TARGET_K
From: tschwinge
gcc/
* gimple.h (enum gf_mask): Add and use GF_OMP_FOR_SIMD.
* omp-low.c: Update accordingly.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210855
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 3 +++
gcc/gimple.h | 6 --
gcc/omp-low.c
From: tschwinge
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Remove duplicated variable
initialization.
gcc/cp/
* semantics.c (finish_omp_clauses): Remove duplicated variable
initialization.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210853
13
From: tschwinge
gcc/
* gimplify.c (omp_notice_variable) :
Explicitly enumerate the expected region types.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210852
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog | 5 +
gcc/gimplify.c | 15 +--
2 fi
From: tschwinge
gcc/c/
* c-parser.c (c_parser_omp_target): Return bool values.
gcc/cp/
* parser.c (cp_parser_omp_target): Return bool values.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210851
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/c/ChangeLog | 4 ++
Jonathan Wakely writes:
> diff --git a/libstdc++-v3/testsuite/30_threads/call_once/60497.cc
> b/libstdc++-v3/testsuite/30_threads/call_once/60497.cc
> index b058204..a82b88f 100644
> --- a/libstdc++-v3/testsuite/30_threads/call_once/60497.cc
> +++ b/libstdc++-v3/testsuite/30_threads/call_once/60
Hi,
On 05/23/2014 12:26 PM, Yury Gribov wrote:
>> Could you add something like
>
> It's always linux-vdso.so.1, but wasn't that already known, given the
> ldd requested by Jakub?!?
Well, for me dlpi_name for vdso was empty string hence I kept asking.
I also thought that ldd and dl_iterate_phdr
One of the things that worries me about all the static tuning tables we
have in the compiler is that it is easy to get the order of elements
wrong, especially when adding a lot of new fields to existing
descriptions. This patch attempts to improve the static checking in
this area by making use of
This marks a test that is xfail for darwin as also xfail for
dragonfly. I'm surprised it fails on darwin and dragonfly but not
freebsd, but Gerald's testresults don't show it failing.
Also fix a couple of tests which were missing target selectors on the
{ dg-do compile } directive, so the tests r
A mechanical patch to run tests on DragonFlyBSD.
Tested x86_64--unknown-linux-gnu and x86_64-unknown-dragonfly3.6,
committed to trunk.
patch.txt.bz2
Description: BZip2 compressed data
On 23 May 2014 17:05, Richard Biener wrote:
> On Fri, May 23, 2014 at 9:23 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> The patch fixes PR rtl-optimization/61278. Root cause for issue is
>> that df_live does not exist at -O1.
>>
>> Bootstrap and no make check regression on X86-64.
>>
>> OK for trunk?
>> Could you add something like
>
> It's always linux-vdso.so.1, but wasn't that already known, given the
> ldd requested by Jakub?!?
Well, for me dlpi_name for vdso was empty string hence I kept asking. I
also thought that ldd and dl_iterate_phdr might have used slightly
different code paths w
On Fri, May 23, 2014 at 11:25:02AM +0200, Paolo Carlini wrote:
> >>How do I print dlpi_name?
> >
> >Could you add something like
> > Report("'%s'\n", info->dlpi_name);
> >after
> > if (!info->dlpi_name || info->dlpi_name[0] == 0)
> >check in FindFirstDSOCallback? This should give us the name of
>
On Thu, May 22, 2014 at 4:15 PM, Paul Eggert wrote:
> Richard Biener wrote:
>>
>> Can you try to clarify the wording (I'm not a native speaker).
>
>
> Sure. I've filed a clarified version on PR 56955 and am attaching it here
> for convenience.
Thanks, installed.
Richard.
On Thu, May 22, 2014 at 8:11 PM, Jan Hubicka wrote:
>> >It won't be so easy, because struct function is really built at
>> >relatively convoluted
>> >places within frontend before cgraph node is assigned to them (I tried
>> >that few years
>> >back).
>>
>> Well, just call cgraph create node from s
On Wed, 21 May 2014, Jason Merrill wrote:
On 04/25/2014 05:04 AM, Marc Glisse wrote:
Does this approach seem ok, or do we need to try harder to find a way to
get this typeinfo into libsupc++?
The latter, I think; these are base types, so they should go in the library.
Hmm, ok. Because of th
Hi,
On 05/23/2014 11:21 AM, Yury Gribov wrote:
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
There are three issues here:
1) whether warning should cause termination
2) wheth
> still should have come up on your machine in the first place.
should not have
I've checked all available systems and wasn't able to repro this.
Given your exchanges with Jakub I thought that at this point it was
clear that the issue is real.
There are three issues here:
1) whether warning should cause termination
2) whether warning should be displayed by default
3) why
1 - 100 of 120 matches
Mail list logo
