On 12/02/2015 04:09 PM, Nathan Sidwell wrote:
The PTX md file goes to a lot of effort handling SC and DC movs,
including for unspecs to mov low and high parts around. However, these
code paths are not exercised in any gcc test or the build of newlib.
The generic handling of these movs deals with
On 12/02/2015 05:10 PM, Dmitry Vyukov wrote:
ping
I do not see the original submission in my archives. This one comes too
late to make it into gcc-6. I can make some initial comments.
This patch adds support for coverage-guided fuzzing:
https://codereview.appspot.com/280140043
Please send
On 12/02/2015 05:55 PM, Dmitry Vyukov wrote:
Can you point to some concrete coding style violations (besides
function comments)?
(flag_sanitize & (SANITIZE_ADDRESS | SANITIZE_THREAD \
- | SANITIZE_UNDEFINED | SANITIZE_NONDEFAULT)))
+
On 12/02/2015 08:05 PM, Jeff Law wrote:
On 11/27/2015 07:09 AM, Dominik Vogt wrote:
New patch with the following changes:
* Fixed comment about dynamic var area placement.
* The area is now placed further away from the stack pointer than
the non-dynamic stack variables (tested only with
S
On 12/02/2015 07:21 PM, Segher Boessenkool wrote:
After shrink-wrapping has found the "tightest fit" for where to place
the prologue, it tries move it earlier (so that frame saves are run
earlier) -- but without copying any more basic blocks.
Unfortunately a candidate block we select can be insi
On 12/02/2015 07:21 PM, Segher Boessenkool wrote:
After shrink-wrapping has found the "tightest fit" for where to place
the prologue, it tries move it earlier (so that frame saves are run
earlier) -- but without copying any more basic blocks.
Another question would be - is there really a good r
On 12/02/2015 06:38 PM, Dmitry Vyukov wrote:
One thing to consider would
be whether you really need this split between O0/optimize versions, or
whether you can find a place in the queue where to insert it
unconditionally. Have you considered this at all or did you just follow
asan/tsan?
I inser
On 12/03/2015 10:33 AM, Kyrill Tkachov wrote:
PR rtl-optimization/68624
* ifcvt.c (noce_try_cmove_arith): Check clobbers of temp regs in both
blocks if they exist and simplify the logic choosing the order to emit
them in.
2015-12-03 Kyrylo Tkachov
PR rtl-optimization
On 12/03/2015 02:06 PM, Richard Sandiford wrote:
As Bernd requested, this patch adds "This pattern cannot FAIL" to the
documentation of optabs that came to be mapped to interal functions.
For consistency I did the same for optabs that were already being
used for internal functions.
Many of the o
On 11/23/2015 10:34 AM, Martin Liška wrote:
On 11/21/2015 05:26 AM, Hans-Peter Nilsson wrote:
IIRC you can replace the actual dg-runtest proc with your own
(implementing a wrapper). Grep aroung, I think we do that
already. That's certainly preferable instead of touching all
callers.
You are
On 12/03/2015 09:33 PM, David Malcolm wrote:
The attached patch updates the handling of %q+D, simplifying
the implementation, and ensuring that it retains the range
information of the decl, giving:
diagnostic-ranges-1.c:6:7: warning: unused variable ‘redundant’
[-Wunused-variable]
int redun
> The patch should bring C++ support for flexible array members closer
> to C (most of the same constructs should be accepted and rejected).
> The only C change in this patch is to include the size of excessively
> large types in diagnostics (I found knowing the size helpful when
> adding tests an
I think marking stuff with Warning as appropriate qualifies as obvious.
On 12/04/2015 05:37 PM, Jakub Jelinek wrote:
+ /* If the switch takes an integer, convert it. */
+ if (arg && cl_options[opt_index].cl_uinteger)
+ {
+ value = integral_argument (arg);
+
On 12/04/2015 05:45 PM, Jakub Jelinek wrote:
This patch fixes it to use explicit UNKNOWN_LOCATION, instead of
explicit or implicit input_location, which for most of process_options
is somewhere on line 1 of the main source file.
Ok.
Bernd
On 12/04/2015 04:18 PM, Andre Vieira wrote:
Reworked following Joern's suggestion.
Is this OK?
Yes.
Bernd
On 12/07/2015 10:35 AM, Eric Botcazou wrote:
As discussed with Alexandre in the audit trail, the attached minimal fix just
prevents the problematic BLKmode REG from being generated, which appears to be
sufficient to restore the nominal operating mode.
PR middle-end/68291
PR mi
On 12/04/2015 08:36 PM, Jakub Jelinek wrote:
On Fri, Dec 04, 2015 at 06:19:19PM +, Manuel López-Ibáñez wrote:
My guess is that the first error_at should use arg instead of
option->opt_text to be equivalent. Of course, ideally, this code would
not be duplicated, but rather merged "somehow".
On 12/04/2015 10:09 PM, David Malcolm wrote:
Updated patch to comment attached, which rewrites things to clarify the
meaning of SHOW_CARET_P.
I guess this is OK for now. I think I'll go play with the Fortran
frontend a bit to see what exactly is going on with its use of set_range
there, I sti
On 12/07/2015 02:44 PM, Jakub Jelinek wrote:
So like this?
+/* Perform diagnostics for read_cmdline_option and control_warning_option
+ functions. Returns true if an error has been diagnosed. */
Let's document arguments; for the ones identical to read_cmdline_option
an explicit pointer
On 12/07/2015 06:03 PM, Nathan Sidwell wrote:
On 12/07/15 11:18, Nathan Sidwell wrote:
calls to no return fns can cause problems with the PTX JIT. It doesn't
understand their no-return nature and can erroneously think there are
unexitable
loops (depending on the precise placement of bbs). It c
On 12/07/2015 06:34 PM, Nathan Sidwell wrote:
Aren't noreturn fns required to be void? It certainly doesn't make
sense for them to do otherwise.
The documentation says "it makes no sense" for them to have a type other
than void, but I don't think that translates into a requirement. I
suppos
On 12/07/2015 07:54 PM, Steve Ellcey wrote:
if (must_annul)
- used_annul = 1;
+ {
+ /* Frame related instructions cannot go into annulled delay
+slots, it messes up the dwarf info. */
+ if (RTX_FRAME_RELATED_P (trial))
+
On 12/07/2015 08:43 PM, Steve Ellcey wrote:
I am not sure about this. There is an earlier if statement in the loop
that does a 'return' instead of a break (or continue) and there is a
return in the 'else' part of the if that sets must_annul. Both of these
are inside the loop that looks at all t
On 12/08/2015 01:40 AM, Segher Boessenkool wrote:
- if (can_get_prologue (pro, prologue_clobbered))
- last_ok = pro;
}
Where did that test go?
Bernd
On 12/08/2015 12:32 PM, Martin Liška wrote:
Simple memory leak fix.
Patch can bootstrap and survives regression tests on x86_64-unknown-linux-gnu.
This one is OK. For the larger one I'm not sure whether we shouldn't be
saying no around this point and wait until stage 1 (unless we have
regress
On 12/07/2015 06:49 PM, Marek Polacek wrote:
diff --git gcc/testsuite/g++.dg/cpp0x/pr68116.C
gcc/testsuite/g++.dg/cpp0x/pr68116.C
index e69de29..04ed901 100644
--- gcc/testsuite/g++.dg/cpp0x/pr68116.C
+++ gcc/testsuite/g++.dg/cpp0x/pr68116.C
@@ -0,0 +1,12 @@
+// PR c++/68116
+// { dg-do compile
On 12/07/2015 11:41 PM, Jakub Jelinek wrote:
On Mon, Dec 07, 2015 at 04:11:48PM +0100, Bernd Schmidt wrote:
Let's document arguments; for the ones identical to read_cmdline_option an
explicit pointer there is sufficient, but errors is new.
This also needs an update to the function co
On 12/07/2015 04:05 PM, Martin Liška wrote:
As Jakub pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896#c15,
I forgot
to add a test-case to both GCC-5-branch and trunk.
May I please installed the suggested patch to both these branches?
Sure.
Bernd
On 12/08/2015 03:21 PM, Marek Polacek wrote:
+C::T C::b[]
+{
+ T (&C::foo)
+};
The problem I have with approving C++ testcases is that I have no idea
whether this is valid or not or what it expresses. You should Cc Jason
(which I've now done).
That's odd code--I don't approve of the cast in
On 12/08/2015 04:28 PM, Martin Liška wrote:
Majority of them (~2600 BTs) are in fortran FE (BT contains 'gfc_'): [2].
The rest contains some issues in CP FE, many GGC invalid read/write operations
([4]) and many
memory leaks in gcc.c (for instance option handling).
My question is if a bug shou
On 12/08/2015 04:43 PM, David Malcolm wrote:
This fixes various uninitialized src_range of c_expr, this time
in the various builtins that are parsed via c_parser_get_builtin_args.
Bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
I think both of these patches are OK. Some questions t
On 12/08/2015 11:50 AM, Eric Botcazou wrote:
I'm going to test it on x86-64, SPARC64 and Aarch64.
PR middle-end/68291
PR middle-end/68292
* cfgexpand.c (set_rtl): Always accept mode mismatch for SSA names
with BLKmode promoted mode based on RESULT_DECLs.
I thi
On 12/08/2015 05:02 PM, David Malcolm wrote:
I actually implemented something like this when implementing these two
patches.
Work-in-progress patch attached, which introduces an INVALID_LOCATION
value for source_location/location_t, and uses it to "poison" the
initial value of c_expr's src_rang
On 12/09/2015 03:18 AM, Bernd Edlinger wrote:
Furthermore there is a documented use for asm(""): The empty assembler string
is used to make a function
volatile, thus calls can not be optimized away. But I think it is not
necessary to make this clobber anything,
nor should it be an instruction
On 12/09/2015 12:50 PM, Martin Liška wrote:
I would like to backport forgotten patch to GCC-5 branch.
Bootstrap and regression tests have been running, ready after it finishes?
Ok.
Bernd
On 12/09/2015 12:22 PM, Ajit Kumar Agarwal wrote:
This is because the available_regs = 6 and the regs_needed = 1 and
new_regs = 0 and the regs_used = 10. As the reg_used that are based
on the Liveness given above is greater than the available_regs, then
> it's candidate of spill and the estima
On 12/09/2015 04:38 PM, David Malcolm wrote:
+/* The following function contains examples of bad indentation that's
+ arguably not misleading, due to a blank line between the guarded and the
+ non-guarded code. Some of the blank lines deliberately contain
+ redundant whitespace, to verify
On 12/09/2015 04:09 PM, Bernd Edlinger wrote:
So would you agree on the general direction of the patch,
if I drop the hunk in sched-deps.c ?
I'm not sure there was any consensus in that other thread, but I think
assuming that basic asms clobber memory and CC, can be justified. That
certainly
On 12/09/2015 05:24 PM, Thomas Schwinge wrote:
In addition to that, how about we split up gcc/omp-low.c into several
files? Would it make sense (I have not yet looked in detail) to do so
along the borders of the several passes defined therein? Or, can you
tell already that there would be too m
On 12/09/2015 05:49 PM, David Malcolm wrote:
+void
+fn_40_implicit_level_1 (int arg)
+{
+if (flagA)
+ foo (0);
+
+ foo (1);
+
The distinction I want to make here is between badly indented code vs
misleadingly indented code. Yes, the code is badly indented, but to my
eyes the code is suffici
On 12/09/2015 05:58 PM, David Malcolm wrote:
On Wed, 2015-11-04 at 14:56 +0100, Bernd Schmidt wrote:
This seems like fairly low impact but also low cost, so I'm fine with it
in principle. I wonder whether the length of the marker is the same
across all versions of patch (and VC tools)?
On 12/10/2015 09:08 AM, Jakub Jelinek wrote:
On Wed, Dec 09, 2015 at 06:23:22PM +0100, Bernd Schmidt wrote:
On 12/09/2015 05:24 PM, Thomas Schwinge wrote:
In addition to that, how about we split up gcc/omp-low.c into several
files? Would it make sense (I have not yet looked in detail) to do
On 12/09/2015 09:47 PM, Segher Boessenkool wrote:
After shrink-wrapping has found the "tightest fit" for where to place
the prologue, it tries move it earlier (so that frame saves are run
earlier) -- but without copying any more basic blocks.
Unfortunately a candidate block we select can be insi
On 12/10/2015 12:07 AM, Martin Sebor wrote:
* invoke.texi (Warning Options): Update -Wall options. Clarify
when some -Wextra options are enabled. Add -Wplacement-new example.
I tried to check this list against c.opt - I figure this should contain
essentially the ones that ar
On 12/09/2015 11:37 PM, Jakub Jelinek wrote:
Not sure what I've been thinking when writing the previous noce_try_abs fix.
I thought that the optimization can be applied for all the conditions,
and whether it can be applied depends on if it is cond ? ~x : x or
cond ? x : ~x. But that is not the c
On 12/10/2015 01:38 PM, Jan Beulich wrote:
* cfgexpand.c (expand_one_var): Exclude static and external
variables when adjusting stack alignment related state.
gcc/testsuite/
2015-12-10 Jan Beulich
* gcc.c-torture/execute/stkalign.c: New.
--- 2015-12-09/gcc/cfgexpand
On 12/10/2015 03:36 PM, Kyrill Tkachov wrote:
I'm okay with delaying this for next stage 1 if people prefer, though I
think it's
pretty low risk.
I think this is something we should fix now.
+ x = XEXP (x, 0);
+ if (start > 0)
+ x = gen_rtx_LSHIFTRT (mode, x, GEN_INT
On 12/10/2015 05:52 PM, Martin Sebor wrote:
The updated patch is attached.
Ok.
Bernd
On 12/10/2015 03:56 PM, David Malcolm wrote:
The following patch updates multiline.exp to use the global
$testname_with_flags
as a prefix in such results.
I also dropped the printing of the index in favor of printing the line
numbers enclosed within dg-{begin|end}-multiline-output.
After the
On 12/10/2015 04:04 PM, Michael Matz wrote:
This isn't stage 3 material really, OTOH fairly low risk. Anyway, okay
for trunk now or once stage 1 opens?
This is cool and we want it, but not now. Ok for stage 1, with the
formatting problems quoted below fixed.
Bernd
+#define TYPE_ALIGN(NOD
On 12/10/2015 05:07 PM, Jan Beulich wrote:
If not reaching
if (TREE_CODE (origvar) == SSA_NAME)
{
gcc_assert (TREE_CODE (var) != VAR_DECL
|| (!DECL_EXTERNAL (var)
&& !DECL_HAS_VALUE_EXPR_P (var)
&& !TREE_STATIC (var)
On 11/13/19 9:03 PM, Jeff Law wrote:
> OK. I'd actually recommend this go ahead and get installed. My tester
> will bootstrap it overnight.
Alright, let me know how that turns out. What kind of machine do you
have for that?
Bernd
On 11/15/19 2:48 PM, Andreas Schwab wrote:
> Here are the results of running the testsuite on m68k-linux:
>
> http://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00908.html
>
> This is a list of regressions:
Are these with the patch? I'm not seeing any of these in my testing with
qemu. Are you on r
On 11/15/19 5:34 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> Are these with the patch?
>
> Yes.
>
>> Are you on real hardware
>
> No, I'm using aranym.
Any chance you could show the command lines from the log files or some
other way of reproducing the issue?
Bernd
On 11/15/19 10:58 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> Any chance you could show the command lines from the log files or some
>> other way of reproducing the issue?
>
> Executing on aranym: OMP_NUM_THREADS=2
> LD_LIBRARY_PATH=.:/da
On 11/15/19 11:50 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> I meant the compiler command line of course... for any -mcpu flags that
>> might differ from my test run.
>
> There are none.
Well, there has to be some difference between what you
On 11/16/19 9:18 AM, Andreas Schwab wrote:
> On Nov 16 2019, Bernd Schmidt wrote:
>
>> Well, there has to be some difference between what you are doing and
>> what I am doing, because:
>>
>> Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ...
>
(Apologies to Jeff who's getting this twice because I didn't hit
reply-all the first time.)
On 11/17/19 6:56 PM, Jeff Law wrote:
> While scanning this patch I did notice the introduction of
> CC_STATUS_INIT in output_{and,ior,xor}si. You might want to check that.
That is intentional. CC_STATUS_
Hi Mikael,
> This fixed the problem, thanks.
Could you also run the testsuite to see if you can reproduce the
g++.old-deja failures Andreas reported?
Bernd
On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
> wrote:
>>
>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt wrote:
>>>
>>> Hi Mikael,
>>>
>>>> This fixed the problem, thanks.
>>>
On 11/20/19 8:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote:
>> Probably best to just run tests on stage1 and hope something shows up.
>
> Ok, how do I did that? I've always just done 'make -k check' after
> full b
On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
>> Also, it does not compute costs for jump
>> insns, so they are always set to zero. As a consequence, any possible
>> substitution is performed if a combination in
On 11/21/19 1:30 PM, Matthias Klose wrote:
>
> that would be apt build-dep gcc-9. The former would only install the build
> dependencies of the gcc-defaults package.
That gets me
E: You must put some 'source' URIs in your sources.list
where /etc/apt/sources.list looks like
deb http://ftp.por
On 11/22/19 1:42 AM, Segher Boessenkool wrote:
> On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
>> Thanks. Just FYI, this is held up a little. I decided I'd also test on
>> x86, and there it shows a case where ix86_rtx_cost misses something: the
>> i386/p
A patch I posted recently fixes combine to take costs of JUMP_INSNs into
account. That causes the pr30315 test to fail with -m32, since the cost
of an add that sets the flags is estimated too high.
The following seems to fix it. Bootstrapped and tested on x86_64-linux, ok?
Bernd
* config/i386
On 11/22/19 3:04 PM, Uros Bizjak wrote:
> On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt wrote:
>>
>> A patch I posted recently fixes combine to take costs of JUMP_INSNs into
>> account. That causes the pr30315 test to fail with -m32, since the cost
>> of an add that
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
In the meantime I've made an aranym setup in addition to the qemu setup
I had, and I've not been able to reproduce fa
On 11/23/19 9:53 PM, Bernd Schmidt wrote:
> I'll spend a few more days trying to see if I can do something about the
> bootstrap failure Mikael saw (currently trying to do a two-stage cross
> build rather than a really slow bootstrap).
Whew, I think I have it. One tst instruction e
g copy)
@@ -1,3 +1,8 @@
+2019-11-24 Bernd Schmidt
+
+ * config/i386/i386.c (ix86_rtx_costs): Handle care of a PLUS in a
+ COMPARE, representing an overflow detection.
+
2019-11-23 Jan Hubicka
* cif-code.def (MAX_INLINE_INSNS_SINGLE_O2_LIMIT): Remove.
Index: gc
On 11/19/19 1:27 AM, Segher Boessenkool wrote:
> The combine parts are okay for trunk, if you keep an eye out :-)
Thanks, now committed. That leaves the auto-inc-dec part. Since we're
being adventurous, I've also bootstrapped and tested the following in
the meantime (on the gcc135 machine). This j
On 11/24/19 8:43 PM, Segher Boessenkool wrote:
> But. Allowing autoinc into jump insns means those jump insns may then
> eventually need an output reload; it may just have been because of that?
That's almost certainly the reasoning, but as I pointed out in my
original mail - reload is careful aro
On 11/25/19 12:26 PM, Andreas Schwab wrote:
> On Nov 24 2019, Bernd Schmidt wrote:
>
>> Whew, I think I have it. One tst instruction eliminated when it
>> shouldn't have been:
>>
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
After the last fix, I did some more testing and since I feel confident
that it really is in good shape now, I committ
On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
> Are all 4 + 2 patches in now? Thus, can we close the bug?
We're missing one piece for better autoinc generation, but that's a
small optimization issue. The cc0 conversion is complete.
Bernd
On 11/25/19 1:38 PM, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
Committed as obvious.
Bernd
commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19
Author: Bernd Schmidt
Date: Mon Nov 25 13:48:08 2019 +0100
Change backends
So I was curious what would happen if I turned on LRA for m68k. It turns
out my autoinc patches from the cc0 patch set expose a bug in how LRA
handles autoincrement. While it copies the logic from reload's
inc_for_reload, it appears to be missing the find_reloads_address code
to ensure an autoinc a
On 11/26/19 1:36 AM, Joseph Myers wrote:
> I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> building _mulsc3.o; I get assembler errors:
I overlooked a difference in the 68881 vs coldfire patte
On 11/26/19 3:21 AM, Joseph Myers wrote:
>
> The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> --disable-multilib) successfully built libgcc and glibc, but ran into an
> ICE building the glibc tests. Again, I've not bisected but this commit
> seems likely to be responsible. Com
On 11/28/19 8:53 PM, Gunther Nikl wrote:> Bernd Schmidt
:
>> On 11/23/19 9:53 PM, Bernd Schmidt wrote:
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's a movqi using move.w.
>
On 06/11/2017 08:03 PM, Gerald Pfeifer wrote:
> On Tue, 30 May 2017, Bernd Schmidt wrote:
>> On 05/30/2017 09:05 AM, Richard Biener wrote:
>>> This leaves the nvptx and c6x ports without a maintainer. Do
>>> you have any recommendations for a successor here?
>> N
On 08/06/2014 07:23 PM, David Malcolm wrote:
diff --git a/gcc/function.h b/gcc/function.h
index 28a20f3..ba7597c 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -135,7 +135,7 @@ struct GTY(()) expr_status {
rtx x_apply_args_value;
/* List of labels that must never be deleted. */
-
This is a followup fix for the patches from PR41857, which contained a
bug that is exposed by the ptx backend. The problem is finding the right
pointer type for a mem_ref during ivopts.
The original problem was that on spu-elf, __ea pointers are 64 bit while
sizetype is 32 bit. During ivopts,
On 08/07/2014 09:50 PM, Bernd Schmidt wrote:
The following patch reworks this area - instead of trying to find a
proper pointer type, it just recognizes the case where an integer is
promoted to be the base, and performs all calculations in that type
rather than sizetype. That also seems to be an
On 08/12/2014 09:35 PM, Jakub Jelinek wrote:
As detailed in the PR, find_inc ignored any possible clobbers on
inc_insn (typically %cc/flags/etc. register) and thus we could ignore
all register dependencies between mem_insn and inc_insn even when
we could only safely ignore the mem_reg0 register d
On 08/14/2014 05:50 PM, Jakub Jelinek wrote:
I hope the scheduler doesn't attempt to swap sp += 24 with flags setter
because of the sp += 16 vs. flags setter dependency and sp += 24 vs. sp +=
16 dependency, but I feel kind of uneasy with find_inc assuming the recorded
dependency is the one for th
On 08/18/2014 06:07 PM, Ilya Verbin wrote:
I discovered an issue in the LTO streaming out for target - currently any file
(even without any pragma) compiled with -fopenmp/-fopenacc contains
.gnu.target_lto_* sections. This increases the size of an object file and
makes lto-wrapper to run mkof
On 08/19/2014 12:41 PM, Ilya Verbin wrote:
On 18 Aug 18:24, Bernd Schmidt wrote:
I think I'd be happier if the function was called init_offload_table
and also collected functions, rather than leaving that to
expand_omp_target. I think the patch would be ok with that change.
For the func
On 07/29/2014 12:36 AM, Joseph S. Myers wrote:
On Thu, 24 Jul 2014, Jakub Jelinek wrote:
Yeah. I believe gcc.c-torture/compile/ has been converted already,
so it is just about gcc.c-torture/execute/. Each of these tests has
it's own default idioms, e.g. -w in by default in gcc.c-torture/.
Us
On 08/22/2014 10:39 PM, Mike Stump wrote:
Before you check it in, consider:
930529-1.x has some alpha bits but I didn’t notice a discussion nor
do I have state on the bug to know if the resolution is correct.
Those are commented out, and I assume superseded by the use of -fwrapv.
Thanks!
Be
)
x = init_tmp_var (root, x, &gsi);
right after x is assigned to?
Ok with that change.
That also works, I've committed the following.
Bernd
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f22f09f..c5ef281 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-08-
On 08/22/2014 10:39 PM, Mike Stump wrote:
On Aug 22, 2014, at 5:18 AM, Bernd Schmidt wrote:
Here's another attempt.
Ok?
Ok. Thanks a ton for doing the work.
The next question would be what to do with gcc.c-torture/unsorted. As
far as I can tell, these are all just plain co
On 09/01/2014 11:03 AM, Jakub Jelinek wrote:
On Thu, Aug 14, 2014 at 05:59:56PM +0200, Bernd Schmidt wrote:
On 08/14/2014 05:50 PM, Jakub Jelinek wrote:
I hope the scheduler doesn't attempt to swap sp += 24 with flags setter
because of the sp += 16 vs. flags setter dependency and sp +=
geLog.gomp
===
--- ChangeLog.gomp (revision 214959)
+++ ChangeLog.gomp (working copy)
@@ -1,3 +1,11 @@
+2014-09-05 Bernd Schmidt
+
+ * Makefile.def (host_modules, flags_to_pass): Remove accel-gcc remnants.
+ * configure.ac: Don't call ACX_CANONICAL_ACCEL_TARGET. Remove
+ target-gcc-conf
On 11/06/2013 10:31 AM, Richard Biener wrote:
> We decided to move to C++. As part of a later discussion we decided
> to go with a single general dynamic-casting style, mimicing the "real"
> C++ variant which is dynamic_cast < ... >. Which resulted in
> is-a.h.
>
> So yes, we've decided to go C+
On 11/06/2013 12:31 PM, Richard Biener wrote:
> That I agree to. Instead of fixing the less than optimal separation /
> boundary
> between frontends and the middle-end, or fixing several other long-standing
> issues with GCC we spend a lot of time refactoring things to be C++.
> But that was kind
I'm looking into using LTO to pass information between compilers for
different targets, for the OpenACC implementation. This area of the
compiler seems somewhat obfuscated by overengineering, and I'd like to
simplify it first to make it easier to work with.
lto_gimple_out and lto_finish_out aren't
On 11/04/2013 04:31 AM, bin.cheng wrote:
> 2013-11-01 Bin Cheng
>
> * tree-ssa-loop-ivopts.c (enum ainc_type): New.
> (address_cost_data): New field.
> (get_address_cost): Compute auto-increment rtx cost in ainc_costs.
> Use ainc_costs for auto-increment rtx patterns.
>
On 11/18/2013 02:03 PM, Jan Hubicka wrote:
>> On Mon, Nov 18, 2013 at 11:10 AM, Bernd Schmidt
>> wrote:
>>> The following patch simplifies this by getting rid of
>>> all_lto_gen_passes. We could simplify a little further if we decided we
>>> really don'
This fixes some minor ugliness I noticed while looking at this code. It
renames a poorly named global variable (shadowed by some function args
in the same file), replaces a cast of an integer value to a pointer, and
removes an undocumented and unused return value.
Bootstrapped and tested on x86_64
On 11/22/2013 09:15 AM, Richard Sandiford wrote:
> I have a patch to upgrade most genrecog warnings into errors. This patch
> fixes one for bfin about {push,pop}_multiple_operation not being defined
> at the .md level.
>
> Tested by building bfin-elf with the warnings turned to errors, and by
> c
601 - 700 of 2198 matches
Mail list logo
