On May 14, 2015 12:46:06 AM GMT+02:00, Joseph Myers
wrote:
>On Wed, 13 May 2015, Marek Polacek wrote:
>
>> > Rather, how about having an extra argument to c_fully_fold_internal
>(e.g.
>> > for_int_const) indicating that the folding is of an expression with
>
>> > integer constant operands (so th
On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote:
> No doubt, looking forward to the day, when this can be reverted.
>
> libgomp/
> * env.c (initialize_env): Remove static attribute.
> * libgomp.map (INTERNAL): Export initialize_env.
Ugh. While you
On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote:
> Do the patches allow us to remove the restrictions from the folding patterns?
With the c_fully_fold_internal patches there's no need to tweak any match.pd
patterns. So PR66127 + PR66066 are to be solved solely in the C FE. Is that
On Wed, May 13, 2015 at 10:19:31PM +0200, Thomas Schwinge wrote:
> +/* Kernel helper for compare-and-exchange. */
> +static int
> +nvidia_cas (int oldval, int newval, int *ptr)
> +{
> + int ret;
> +
> + asm volatile ("atom.cas.b32 %0, [%1], %2, %3;" : "=r"(ret) : "r"(ptr),
> + "r"(ol
On Wed, May 13, 2015 at 10:52:08PM +0200, Thomas Schwinge wrote:
> In a similar vein, I have now committed the following to gomp-4_0-branch
> in r223178. This is not meant to be integrated into trunk as-is: there
> are incompatible libgomp ABI changes, for example. We'd still appreciate
ABI inco
Hi DJ,
Ok but..
+case SECCAT_TBSS:
+ return default_select_section (decl, reloc, align);
+
+default:
+ gcc_unreachable ();
Would it be better to just "default:" everything to
default_select_section, instead of enumerating everything we know
about today?
Yes it would. :-}
Ping.
Joseph, do you have any further comments on the patch?
Jason, can you review the C++ parts?
Thanks,
On Thu, May 07, 2015 at 06:22:40PM +0200, Marek Polacek wrote:
> This (third) version of the patch entails the change in tsubst_enum Ed
> suggested + new testcase.
>
> Bootstrapped/regtested
On Thu, May 14, 2015 at 10:05:36AM +0200, Jakub Jelinek wrote:
> On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote:
> > No doubt, looking forward to the day, when this can be reverted.
> >
> > libgomp/
> > * env.c (initialize_env): Remove static attrib
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>> We can use general_operand instead of some_operand.
>>
>> 2015-05-13 Uros Bizjak
>>
>> * config/alpha/alpha.md (extendqidi2): Use general_operand
>> instead of some_operand for oper
On 27/04/15 00:07, Kugan wrote:
While I support your goals, I think your approach needs some refinement.
In particular, we DO NOT want another function that starts looking at
constant values and tries to decide, on a case by case basis, what to do
with that value. We need to keep the logic fo
On Thu, May 14, 2015 at 10:54:07AM +0200, Jakub Jelinek wrote:
> On Thu, May 14, 2015 at 10:05:36AM +0200, Jakub Jelinek wrote:
> > On Thu, May 14, 2015 at 12:10:50AM +0200, Thomas Schwinge wrote:
> > > No doubt, looking forward to the day, when this can be reverted.
> > >
> > >
On Mon, Apr 27, 2015 at 05:57:26PM +0100, Wilco Dijkstra wrote:
> > James Greenhalgh wrote:
> > On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
> > > > -Original Message-
> > > > From: Wilco Dijkstra [mailto:wdijk...@arm.com]
> > > > Sent: 03 March 2015 16:19
> > > > To: GCC
Hi Mikael, hi all,
please find attached the new version of this patch, where most of the source=
expression assignment to the object to allocate is handled by
gfc_trans_assignment (). To use trans_assignment with temporaries introduced
during the preparation of the source= expression, a gfc_expr
On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek wrote:
>On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote:
>> Do the patches allow us to remove the restrictions from the folding
>patterns?
>
>With the c_fully_fold_internal patches there's no need to tweak any
>match.pd
>patterns.
On Thu, May 14, 2015 at 11:48:55AM +0200, Richard Biener wrote:
> On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek
> wrote:
> >On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote:
> >> Do the patches allow us to remove the restrictions from the folding
> >patterns?
> >
> >With the
On Thu, May 14, 2015 at 11:48:55AM +0200, Richard Biener wrote:
> On May 14, 2015 10:10:35 AM GMT+02:00, Marek Polacek
> wrote:
> >On Thu, May 14, 2015 at 09:59:49AM +0200, Richard Biener wrote:
> >> Do the patches allow us to remove the restrictions from the folding
> >patterns?
> >
> >With the
On Wed, May 13, 2015 at 10:46:06PM +, Joseph Myers wrote:
> Yes. The two patches are OK together, though I think it would be better
Thanks.
> to add for_int_const checks also in the cases of unary operations, &&, ||
> and ?: (the last three being cases where it's only the evaluated operand
On Wed, May 13, 2015 at 7:38 PM, Richard Biener
wrote:
> On Fri, May 8, 2015 at 12:47 PM, Bin Cheng wrote:
>> Hi,
>> GCC's IVO currently handles every IV use independently, which is not right
>> by learning from cases reported in PR65447.
>>
>> The rationale is:
>> 1) Lots of address type IVs ref
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>> We can use general_operand instead of some_operand.
>>
>> 2015-05-13 Uros Bizjak
>>
>> * config/alpha/alpha.md (extendqidi2): Use general_operand
>> instead of some_operand for oper
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
> > Compile with -da to get dump files, look at the .reload one (which is
> > for LRA if that is enabled), stare long and hard. I recommend coffee.
>
> OK! Looking more at this, the LRA is not actually looping on the link, but on
> an
On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak wrote:
> On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
>> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
>>> We can use general_operand instead of some_operand.
>>>
>>> 2015-05-13 Uros Bizjak
>>>
>>> * config/alpha/alpha.md (extendqidi2)
On 20-04-15 14:25, Richard Biener wrote:
On Wed, 15 Apr 2015, Tom de Vries wrote:
On 03-04-15 14:39, Tom de Vries wrote:
On 27-03-15 15:10, Tom de Vries wrote:
Hi,
this patch fixes PR65443, a todo in the parloops pass for function
transform_to_exit_first_loop:
...
TODO: the common case
The AC_STRUCT_DIRENT_D_TYPE autoconf macro expands to include
AC_SEARCH_LIBS for opendir, which can't be used when cross-compiling.
We don't actually care about crufty old systems that put opendir()
somewhere weird, so this just replaces AC_STRUCT_DIRENT_D_TYPE with a
manual check for the part we
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
Hi,
Started these as separate patches, but as more came out of what I was
originally trying to achieve (see Patch 6/7), I thought it better to
have it as a running series.
These set out to update d-demangle.c for new ABI additions, general
bug fixes, a
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
> > On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote:
> > > It seems that with whenever a function's frame is bigger than 512 bytes,
> > > LRA loops.
I cannot reproduce this with your testcase. Please post the *exact*
testc
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_call_convention): Return NULL if have reached the
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
The next version of D adds support for cent and ucent for platforms
that are able to handle them natively. This adds support for
demangling them.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_type): Handle cent and ucen
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
Like C++ const and volatile, in D mangled symbols can exist modifiers
that represent the const, immutable, inout and shared-ness of the
'this' parameter.
This information should be written out in the demangled symbol to show
that each variant has a uniq
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
This addresses a subtle logic error, noticed when I was in the middle
of testing out some other tightening up of parsing checks.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_identifier): Check encoded length of identifie
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
The next version of D introduces two new mangle conventions.
- Nj to represent methods whose 'this' parameter is also the function
return value
- Nk to represent a 'ref' parameter that is also the function return value
This patch introduces support for
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
> I cannot reproduce this with your testcase. Please post the *exact*
> testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation helped. Kaboom.
It wants to reload pretty much e
On 05/13/2015 03:14 PM, Iain Buclaw wrote:
One last thing that was added in the next D version's ABI (and I
subsequently missed).
This is a trivial patch to just ignore the new mangle symbol.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw
* d-demangle.c (dlang_template_args): Skip ove
> James Greenhalgh wrote:
> On Mon, Apr 27, 2015 at 05:57:26PM +0100, Wilco Dijkstra wrote:
> > > James Greenhalgh wrote:
> > > On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
> > > > > -Original Message-
> > > > > From: Wilco Dijkstra [mailto:wdijk...@arm.com]
> > > > > Sen
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
In my tests, this gives the demangler near-complete support. Of a
sample of about 75k symbols pulled from the standard library
unittester, all but 20 were successfully parsed.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw
* d-demangle.c (dlang
The PR is due to missing the third argument to open(3) but there are
some other errors in the same function as well as some unimplemented
features, and some bad error handling elsewhere.
The autoconf check for sendfile is intentionally conservative because
some BSDs define a sendfile() function w
On 14 May 2015 at 14:58, Jeff Law wrote:
> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>
>> If a symbol that has so far been valid abruptly ends then we will want
>> to fail the process rather than silently succeed.
>>
>> ---
>> libiberty/ChangeLog
>>
>> 2015-05-13 Iain Buclaw
>>
>> * d-dem
On Thu, May 14, 2015 at 01:56:54PM +0800, Hale Wang wrote:
> > >> gcc/ChangeLog:
> > >> 2015-04-22 Hale Wang
> > >> Terry Guo
> > >>
> > >>PR rtl-optimization/64818
> > >>* combine.c (can_combine_p): Don't combine user-specified register
> > if
> > >>i
Reported by Nathan and fixed by his patch. I added the tests.
Tested powerpc64le-linux, committed to trunk. This should be
backported too.
commit f859cb0e4a369bdade09d5d77f9c8bb78d388294
Author: Jonathan Wakely
Date: Thu May 14 14:36:20 2015 +0100
2015-05-14 Nathan Myers
Jonat
On Wed, May 13, 2015 at 1:29 PM, Segher Boessenkool
wrote:
> On Wed, May 13, 2015 at 01:25:16PM -0400, David Edelsohn wrote:
>> > PR rtl-optimization/30967
>> > * config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
>> > destination mode for the cost of scc patterns.
>
On 14 May 2015 at 15:24, Jeff Law wrote:
> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>
>> In my tests, this gives the demangler near-complete support. Of a
>> sample of about 75k symbols pulled from the standard library
>> unittester, all but 20 were successfully parsed.
>>
>> ---
>> libiberty/
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested by
Richi. I also applied the new types_match to 2 other patterns in match.pd
where it seemed clearly appropriate.
I would like to propose this small tweak (regtested ok). If we had a
di
On 05/11/2015 04:10 PM, Eric Botcazou wrote:
This fixes an RTL checking failure I ran into while working on a change and it
is latent in the pristine compiler. emit_pattern_{after|before}_setloc have:
if (active_insn_p (after) && !INSN_LOCATION (after))
if (active_insn_p (first) && !INSN
On 05/14/2015 08:04 AM, Marc Glisse wrote:
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested
by Richi. I also applied the new types_match to 2 other patterns in
match.pd where it seemed clearly appropriate.
I would like to propose this
Hi,
This patch fixes an internal compiler error when micromips/nomicromips
attributes are used.
The problem here was that the cached boolean attributes for the current
target did not agree with the uncached attributes throwing an assertion error.
It appears that saving and restoring the state fo
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buc
On 05/13/2015 04:45 AM, Eric Botcazou wrote:
Hi,
the SJLJ EH schemes manipulate a buffer that contains a few pointers and, in
particular, the stack pointer. Therefore, when dynamic stack allocation is
also used, you need to update its value in the buffer, otherwise Bad Things
will happen if you
On 12-05-15 12:04, Richard Biener wrote:
The fact that we have to handle this specially in both build_va_arg and
>gimplify_va_arg makes me wonder whether we should be dealing with all this in
>build_va_arg already.
>
>That is, determine whether we take the address, and add the address operator
>i
> On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
> > I cannot reproduce this with your testcase. Please post the *exact*
> > testcase (nothing snipped) and the command line you used?
>
> Making the array volatile and using optimisation helped. Kaboom.
>
> It wants to reloa
On 05/04/2015 03:27 PM, David Malcolm wrote:
@@ -158,7 +158,7 @@ expand_location_1 (source_location loc,
location (toward the expansion point) that is not reserved;
that is, the first location that is in real source code. */
loc = linemap_unwind_to_first_non_r
On Wed, May 13, 2015 at 9:05 PM, Richard Henderson wrote:
> On 05/13/2015 10:53 AM, Uros Bizjak wrote:
>> The only part that actually processes CONST_WIDE_INT is
>> alpha_legitimate_constant and movti expander. The latter immediately
>> splits any TImode CONST_WIDE_INTs.
>>
>
> Indeed. Also proba
On 14 May 2015 at 15:24, Jeff Law wrote:
> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>
>> In my tests, this gives the demangler near-complete support. Of a
>> sample of about 75k symbols pulled from the standard library
>> unittester, all but 20 were successfully parsed.
>>
>> ---
>> libiberty/
On 05/14/2015 08:32 AM, Uros Bizjak wrote:
> 2015-05-14 Uros Bizjak
>
> * config/alpha/alpha.c (alpha_extract_integer): Do not handle
> CONST_WIDE_INT and CONST_DOUBLE. Assert CONST_INT_P (x).
> (alpha_legitimate_constant_p) : Check high and
> low part of the constant using alp
Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations
showed "rest of compilation" as taking a significant chunk of time:
rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall
1388 kB ( 6%) ggc
This turned out to be almost entirely spent inside initi
PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00772.html
The Fortran part was already approved, only the diagnostics part is pending.
Thanks,
Manuel.
Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks:
608 bytes in 4 blocks are definitely lost in loss record 184 of 229
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5BC88B0: xcalloc (xmalloc.c:162)
by 0x524F72D: alloc_mem(
Hello,
after this patch I think I'll close the PR. This was regtested on
ppc64le-redhat-linux.
Apparently I wrote this patch in a file that already had a trivial hunk:
-1-A -> ~A is rejected for complex while -A-1 isn't, there is no reason
for this difference (maybe there was before integer_
Marek,
This may be unrelated to your patches for PR 66127 and 66066 but I am
having a new failure when building the latest glibc with the latest GCC.
I haven't yet tracked down exactly which patch caused the problem. Included
is a cutdown test case from libio/memstream.c in glibc that results in
On Thu, 2015-05-14 at 09:42 -0700, Steve Ellcey wrote:
> Marek,
>
> This may be unrelated to your patches for PR 66127 and 66066 but I am
> having a new failure when building the latest glibc with the latest GCC.
>
> I haven't yet tracked down exactly which patch caused the problem. Included
> i
On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote:
> Sorry for the noise, it looks like this failure is not related to any
> recent changes in GCC. I still get the error in older GCC's so I think
> something must have changed in glibc. I will start digging there.
Yeah -- strict aliasi
On Wed, 13 May 2015, Jan Hubicka wrote:
> Thank you! This looks fine. Please add also the testcase that should break if
> the new test was wrong andosmeone fixed postreload to allow use of the same
> register
> this check will prevent wrong code?
I'm checking in a patch with the following addit
On Thu, May 14, 2015 at 03:20:46PM +, James Bowman wrote:
> > It wants to reload pretty much everything. Looking at your code,
> > it seems you use the ancient interfaces instead of
> > TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
>
> The FT32 target uses TARGET_ADDR_SPACE_
On 05/14/2015 10:38 AM, David Malcolm wrote:
Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks:
608 bytes in 4 blocks are definitely lost in loss record 184 of 229
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5BC88B0: xc
On 05/14/2015 10:33 AM, Marc Glisse wrote:
Hello,
after this patch I think I'll close the PR. This was regtested on
ppc64le-redhat-linux.
Apparently I wrote this patch in a file that already had a trivial hunk:
-1-A -> ~A is rejected for complex while -A-1 isn't, there is no reason
for this dif
On 05/14/2015 10:29 AM, David Malcolm wrote:
Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations
showed "rest of compilation" as taking a significant chunk of time:
rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall
1388 kB ( 6%) ggc
This turn
On Thu, 14 May 2015, Iain Buclaw wrote:
> On another note, I've found out why the remaining 20 symbols in my 75k
> sample failed. They don't fail at all! It's just that they were all
> greater than 33,000 characters in length, and my test used c++filt,
> which trims anything bigger than 32767 (w
On 05/14/2015 04:40 AM, Uros Bizjak wrote:
> On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak wrote:
>> On Wed, May 13, 2015 at 8:53 PM, Richard Henderson wrote:
>>> On 05/13/2015 11:11 AM, Uros Bizjak wrote:
We can use general_operand instead of some_operand.
2015-05-13 Uros Bizjak
On 05/14/2015 09:20 AM, James Bowman wrote:
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation help
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy.
"B" should match it seems?
(Why does IRA think r56 should be in memory? Yeah, good question.)
On May 14, 2015, at 8:30 AM, Iain Buclaw wrote:
>
> On another note, I've found out why the remaining 20 symbols in my 75k
> sample failed. They don't fail at all! It's just that they were all
> greater than 33,000 characters in length, and my test used c++filt,
> which trims anything bigger th
On 14 May 2015 at 16:51, Jeff Law wrote:
> On 05/14/2015 07:36 AM, Iain Buclaw wrote:
>>
>> On 14 May 2015 at 14:58, Jeff Law wrote:
>>>
>>> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process ra
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
> On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
> >The alternative that allows move to mem is alt 1, but it thinks the operand
> >doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy.
> >
> >"B" should match it seems?
On 04/24/2015 10:18 AM, Jiong Wang wrote:
2015-04-21 Jiong Wang
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
(init_inv_motion_data): Initialize new variables.>
(free_inv_motion_data):
On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is "B" or "W"), it picks alt 0, loop, every
On 05/14/2015 01:15 PM, Iain Buclaw wrote:
Iant commited in the changes first time around. I don't have write
after approval access in GCC just yet, probably should go about
getting that sorted out if this is to become a regular thing. I dealt
with copyright assignments back in September.
Yea,
The following patch is for solution of PR65862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
In some cases, calculations of reg class costs are not enough to choose
the right class. For example, in some cases you don't want to start fp
unit for energy saving considerations if you don'
On 05/14/2015 04:42 PM, Vladimir Makarov wrote:
The following patch is for solution of PR65862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
In some cases, calculations of reg class costs are not enough to
choose the right class. For example, in some cases you don't want to
start fp
On Thu, 14 May 2015, Marek Polacek wrote:
> Ping.
> Joseph, do you have any further comments on the patch?
The C front-end changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
Jeff Law writes:
> For all kinds of reassociation we have to concern ourselves with adding
> overflow where it didn't already occur. Assuming a 32 bit architecture
> we could get overflow if A is 0x7fff, b is -4 and and c = 3
>
> 0x7fff + -4 = 0x7ffb
> 0x7ffb + 3 = 0x7ffe
>
Ping!
Could someone who can approve please review the patch?
Thanks,
-Andi
Nuno Diegues writes:
> Hello,
>
> I have taken the chance to improve the patch by addressing the
> comments above in this thread.
> Namely:
> - to use a simple random generator managed inside the library only
> - rem
On 05/14/2015 03:13 PM, Jiong Wang wrote:
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
0x7fff + -4 = 0x7f
On Thu, 2015-05-14 at 19:22 +0200, Marek Polacek wrote:
> On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote:
> > Sorry for the noise, it looks like this failure is not related to any
> > recent changes in GCC. I still get the error in older GCC's so I think
> > something must have chang
This patch addresses the libgomp testsuite failure in
libgomp.oacc-fortran/data-2.f90 on nvidia targets. There are a couple of
things going on in here. The major underlying problem involved how
gomp_acc_remove_pointer was clearing target_mem_desc.to_free and
.tgt_end. That caused both a memory leak
> On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
> > On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
> >> On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
> >>> The alternative that allows move to mem is alt 1, but it thinks the
> >>> operand
> >>> doesn't match (it is "B" or "W"), i
Hi,
this patch adds checks of tree_base and type_common flags/fields. I also
refactored
code to use verify_type_variant_flag macro for better brevity and added a
comment
of what can differ between variants and why. Hope it will be useful :)
There seems to be 3 issues:
- C++ FE seems to build typ
Patch below prevents printing of duplicate statements in module files.
Without it module files grow exponentially in size with nested use of
modules that contain equivalence statements. Tested on x86-64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780
https://gcc.gnu.org/bugzilla/show
On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote:
> Patch below prevents printing of duplicate statements in module files.
> Without it module files grow exponentially in size with nested use of
> modules that contain equivalence statements. Tested on x86-64-linux.
>
> https://
On 05/14/2015 09:36 PM, Steve Kargl wrote:
On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote:
Patch below prevents printing of duplicate statements in module files.
Without it module files grow exponentially in size with nested use of
modules that contain equivalence statements
On Thu, May 14, 2015 at 09:39:03PM -0700, Russell Whitesides wrote:
>
> On 05/14/2015 09:36 PM, Steve Kargl wrote:
> > On Thu, May 14, 2015 at 08:53:11PM -0700, Russell Whitesides wrote:
> >> Patch below prevents printing of duplicate statements in module files.
> >> Without it module files grow e
On 05/05/2015 01:59 AM, rohitarul...@freescale.com wrote:
Jeff, the issue is still reproducible with GCC v4.8 branch but
not with GCC
v4.9 or trunk. Was it fixed by some other approach or has the bug
gone latent? Obviously if the former, then the patch is only
relevant to gcc-4.8 if the latter,
On 05/14/2015 06:43 PM, James Bowman wrote:
On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (i
Hi Richard,
r223090 seem to miss a parenthesis and seem to be causing:
from ../../widen/gcc/fold-const.c:46:
../../widen/gcc/fold-const.c: In function 'tree_node*
fold_range_test(location_t, tree_code, tree, tree, tree)':
../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral a
As described in PR target/63810, this addresses several problems with
the validation and encoding of deployment target version strings for the
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro. There are
currently four testcases exercising inputs to -mmacosx-version-min
(gcc/testsuite/gcc.dg/dar
Sorry, this is not the right fix. Looking at it.
Thanks,
Kugan
On 15/05/15 16:41, Kugan wrote:
> Hi Richard,
>
> r223090 seem to miss a parenthesis and seem to be causing:
>
> from ../../widen/gcc/fold-const.c:46:
> ../../widen/gcc/fold-const.c: In function 'tree_node*
> fold_r
93 matches
Mail list logo
