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,
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*
testcase
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 ibuc...@gdcproject.org
* d-demangle.c
On Thu, May 14, 2015 at 01:56:54PM +0800, Hale Wang wrote:
gcc/ChangeLog:
2015-04-22 Hale Wang hale.w...@arm.com
Terry Guo terry@arm.com
PR rtl-optimization/64818
* combine.c (can_combine_p): Don't combine user-specified register
if
On Wed, May 13, 2015 at 1:29 PM, Segher Boessenkool
seg...@kernel.crashing.org 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
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 ibuc...@gdcproject.org
* d-demangle.c (dlang_call_convention): Return NULL
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 ibuc...@gdcproject.org
* d-demangle.c (dlang_identifier): Check
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 jwak...@redhat.com
Date: Thu May 14 14:36:20 2015 +0100
2015-05-14 Nathan
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 Buclawibuc...@gdcproject.org
On 14 May 2015 at 15:24, Jeff Law l...@redhat.com 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.
---
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
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com 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
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
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 ibuc...@gdcproject.org
* d-demangle.c
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]
Sent: 03 March 2015 16:19
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)
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
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
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
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
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
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
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
is a
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
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:
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
On 05/14/2015 04:40 AM, Uros Bizjak wrote:
On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson r...@redhat.com wrote:
On 05/13/2015 11:11 AM, Uros Bizjak wrote:
We can use general_operand instead of some_operand.
2015-05-13
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
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
On May 14, 2015, at 8:30 AM, Iain Buclaw ibuc...@gdcproject.org 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
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
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 aliasing
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.)
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.
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
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
On 05/14/2015 08:32 AM, Uros Bizjak wrote:
2015-05-14 Uros Bizjak ubiz...@gmail.com
* 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) case CONST_WIDE_INT: Check high and
low
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:
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
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
if so
On Wed, May 13, 2015 at 9:05 PM, Richard Henderson r...@redhat.com 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
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
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com 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
On 14 May 2015 at 15:24, Jeff Law l...@redhat.com 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.
---
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 =
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, everyone
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
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?
(Why does
On 04/24/2015 10:18 AM, Jiong Wang wrote:
2015-04-21 Jiong Wang jiong.w...@arm.com
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.
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.
On 14 May 2015 at 16:51, Jeff Law l...@redhat.com wrote:
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com 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
Ping!
Could someone who can approve please review the patch?
Thanks,
-Andi
Nuno Diegues n...@ist.utl.pt 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
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
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 changed in
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
If
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 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 =
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,
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.
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
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
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
On Wed, May 13, 2015 at 7:38 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, May 8, 2015 at 12:47 PM, Bin Cheng bin.ch...@arm.com 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:
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson r...@redhat.com 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 ubiz...@gmail.com
* config/alpha/alpha.md (extendqidi2): Use general_operand
instead of
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 ubiz...@gmail.com wrote:
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson r...@redhat.com 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 ubiz...@gmail.com
*
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 May 14, 2015 12:46:06 AM GMT+02:00, Joseph Myers jos...@codesourcery.com
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
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
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 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(oldval),
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
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
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 attribute.
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson r...@redhat.com 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 ubiz...@gmail.com
* config/alpha/alpha.md (extendqidi2): Use general_operand
instead of
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
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.
libgomp/
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 operands
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 Patches
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 pola...@redhat.com
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?
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 pola...@redhat.com
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?
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 pola...@redhat.com 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
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
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
90 matches
Mail list logo
