On 03/22/2016 11:23 AM, Thomas Schwinge wrote:
diff --git libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
index 01d1dc8..5806cb3 100644
--- libgomp/testsuite/libgomp.oacc-c-c++-common/routine-w-1.c
+++ libgomp/testsuite/libgomp.
On 03/21/2016 02:43 AM, Alan Modra wrote:
+enum valid_equiv { valid_none, valid_combine, valid_reload };
+
Might be worth documenting that each step represents a superset of the
previous one.
+ ret = valid_combine;
+ if (! MEM_READONLY_P (memref)
+ && ! RTL_CONS
On 03/23/2016 01:41 PM, Richard Biener wrote:
Btw, the issue in the PR is also fixed with a simple
Index: libcpp/line-map.c
===
--- libcpp/line-map.c (revision 234415)
+++ libcpp/line-map.c (working copy)
@@ -543,7 +543,7 @@ lin
On 03/23/2016 07:47 AM, Thomas Schwinge wrote:
Want me to re-word that? :-| I thought it would be obvious from looking
at the test case code; will not be a problem in practice. It's because
of constructs used in the test cases, like the following, for example:
if (__builtin_acc_on
On 03/24/2016 11:32 AM, Aldy Hernandez wrote:
On x86, PIC_OFFSET_TABLE_REGNUM calls a function
(ix86_use_pseudo_pic_reg) so its value can theoretically change between
its first and second use in the following conditional:
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM
&&
On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
It looks like this block of code is written by a helper function that is
really intended for other purposes than for maximal_insn_latency. Might
be worth changing to
int insn_code = dfa_insn_code
On 03/23/2016 03:21 PM, Richard Biener wrote:
On Wed, Mar 23, 2016 at 2:15 PM, Bernd Schmidt wrote:
On 03/23/2016 01:41 PM, Richard Biener wrote:
Btw, the issue in the PR is also fixed with a simple
Index: libcpp/line-map.c
In principle we probably should have an example, but once again I have
some problems with the style of the added documentation. I prefer
concise writing without unnecessary repetition. Any other reviewers can
of course override me, but the following is my opinion on these changes.
More problem
On 03/25/2016 11:00 PM, Alan Modra wrote:
I'll also prepare a patch to delete REG_LIVE_LENGTH everywhere.
Like this. Bootstrapped and regression tested x86_64-linux.
OK for stage1?
Oh wow that's a lot of stuff removed. Ok for this and the
FREQ_CALLS_CROSSED patch.
Bernd
On 03/28/2016 12:03 AM, David Wohlferd wrote:
On 3/24/2016 8:00 AM, Bernd Schmidt wrote:
> More problematic than a lack of documentation is that I haven't been
able to find an executable testcase. If you could adapt your example for
use in gcc.target/i386, that would be even more import
On 03/03/2016 03:55 PM, Marcel Böhme wrote:
@@ -4254,7 +4255,9 @@
Please use "diff -p" so that we get information about which function is
being patched. Are all the places being patched really problematic ones
where an input file could realistically cause an overflow, or just the
string func
On 03/29/2016 07:28 PM, Jeff Law wrote:
On 03/29/2016 11:23 AM, Jakub Jelinek wrote:
Hi!
The recent change to num_imm_uses (to add support for NULL USE_STMT)
broke it totally, fortunately we have just one user of this function
right now. I've filed a PR for GCC 7 so that we get a warning on th
On 03/25/2016 04:43 AM, Aldy Hernandez wrote:
If Bernd is fine with this, I'm happy to retract my patch and any
possible followups. I'm just interested in having no path causing a
possible out of bounds access. If your patch will do that, I'm cool.
I'll need to see that patch first to comment
On 03/30/2016 11:27 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, we are miscompiling glibc on i686-linux, because
the new indirect_jump_optimize mini-pass thinks that a insn
which has REG_LABEL_OPERAND note necessarily has to set the target register
to that label, while in the glibc case
On 03/31/2016 07:22 PM, Jeff Law wrote:
@@ -1237,11 +1237,13 @@ squangle_mop_up (struct work_stuff *work)
Thanks. I've just installed this patch, along with suitable tests from
70481 and 67394.
What are the rules for modifying libiberty again? Do we have to patch
binutils/gdb at the same ti
On 03/31/2016 10:53 PM, Patrick Palka wrote:
This patch fixes the new -Wparentheses warnings (implemented by the
subsequent patch) that are encountered during bootstrap:
/home/patrick/code/gcc/gcc/omp-low.c: In function ‘void
scan_sharing_clauses(tree, omp_context*, bool)’:
/home/patrick/code/g
On 04/01/2016 12:21 PM, Marcel Böhme wrote:
This fixes the write access violation detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498 (and a few other
unreported cases).
Sometimes length-variables for strings and arrays are of type long
other times of type int. Since cp-demangle.h exp
Cc'ing Matt Thomas who is listed as the vax maintainer; most of the
patch should be reviewed by him IMO. If he is no longer active I'd
frankly rather deprecate the port rather than invest effort in keeping
it running.
Index: gcc/except.c
===
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x {&,|,^}= {0,-1}, but while
x &= 0 or x {|,^}= -1 are optimized into constants and CSE can handle those
fine, we keep
On 03/31/2016 06:56 AM, Marcel Böhme wrote:
Hi Bernd,
Are all the places being patched really problematic ones where an input file
could realistically cause an overflow, or just the string functions?
The loop in demangle_args allows to call the patched register*- and
remember*-methods arbitr
On 04/01/2016 03:39 PM, Marcel Böhme wrote:
Hi Bernd,
Thanks for the feedback!
Patches need to be bootstrapped and regression tested, and patch
submissions should include which target this was done on.
Ideally you'd also want to include testcases along with your
patches, although I'm not enti
On 04/01/2016 04:51 PM, Jakub Jelinek wrote:
On Fri, Apr 01, 2016 at 03:35:19PM +0200, Bernd Schmidt wrote:
On 04/01/2016 03:14 PM, Jakub Jelinek wrote:
As the testcase below shows, we can end up with lots of useless
instructions from multi-word arithmetics.
simplify-rtx.c can optimize x
On 04/01/2016 05:05 PM, Jakub Jelinek wrote:
with my usual pair of rtl,yes checking bootstraps/regtests (x86_64-linux
and i686-linux, former one with ada, latter without), both without your
patch and with the patch.
Without the patch got 66555 successful replace_reads, with your patch
only 65971,
On 04/01/2016 11:08 AM, Richard Biener wrote:
{
! if (canon_true_dependence (s_info->mem,
!GET_MODE (s_info->mem),
!s_info->mem_addr,
!mem, mem_addr))
{
On 04/01/2016 07:41 PM, Pedro Alves wrote:
On 04/01/2016 11:21 AM, Marcel Böhme wrote:
static inline void
-d_append_num (struct d_print_info *dpi, long l)
+d_append_num (struct d_print_info *dpi, int l)
{
char buf[25];
sprintf (buf,"%ld", l);
Doesn't this warn about %ld format vs i
On 04/02/2016 11:49 AM, Marcel Böhme wrote:
Bootstrapped and regression tested on x86_64-pc-linux-gnu. Test cases
added + checked PR70498 is resolved.
Richard - any objections from an RM perspective to check in such
potentially security-related fixes now even if not regressions?
The patch no
On 04/04/2016 09:39 AM, Eric Botcazou wrote:
The audit trail of the PR is quite confused: __LIBGCC_EH_FRAME_SECTION_NAME__
needs to be (and is correctly) defined during the libgcc build because DWARF2
exceptions are used. The problem is that libgcc2.c expects the usual non-ELF
setup, with __EH_F
On 03/22/2016 03:15 PM, Marcos Díaz wrote:
the attached patch adds a new attribute 'security_sensitive' for functions.
The idea was discussed in PR middle-end/69976.
The first question would be: I see several submissions from folks
@tallertechnologies.com. Do you and your employer have cop
On 04/07/2016 01:52 PM, Senthil Kumar Selvaraj wrote:
The below patch fixes PR 60040 by not halting with a hard error on
a spill failure, if reload knows that it has to run again anyway.
Some additional information as to how this situation creates a spill
failure would be useful. It's ha
On 04/07/2016 11:56 PM, Jakub Jelinek wrote:
Not sure if this patch catches everything though, perhaps there could be
e.g.
(set (reg:SI ...) (plus:SI ((subreg:SI (reg:QI ...) 0) (const_int ...)))
and we'd still assign REG_EQUAL note. So maybe instead we should walk the
*loc expression and look f
On 04/01/2016 05:03 AM, Marcel Böhme wrote:
This fixes the invalid write of size 8 detailed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70492
Handle the special case when consume_count returns -1 due to an integer
overflow when parsing the length of the virtual table qualifier in
cplus-de
I've been looking through this patch. I had intended to commit it, but
after looking through it a little more carefully I think there are a few
things left to solve.
So, d_number/d_compact_number now return ints rather than longs, which
makes sense since the lengths in things like struct deman
On 04/08/2016 07:05 PM, Jakub Jelinek wrote:
After IRC discussions, I've bootstrapped/regtested following patch that
just punts if *loc contains any paradoxical subregs, together with
additional statistics gathering that proved that the new testcase is
the only spot in which this patch makes a di
As shown by Roger Orr in the comments of this PR, cpp_get_token can
cause a reallocation that invalidates some of the variables in
do_linemarker. It seems to occur in this call to linemap_add:
/* Allocate the new line_map. However, if the current map only has a
single line we ca
With some changes I was working on, I produced a situation where one of
the x86 peepholes made an incorrect transformation. In the prologue
expansion code, we have
/* When using red zone we may start register saving before allocating
the stack frame saving one cycle of the prologue. However
On 04/12/2016 12:49 AM, David Wohlferd wrote:
First draft is attached. It tests all 28 (14 conditions plus 14
inverted). I wasn't sure what to set for optimization (O2? O3? O0?),
so I left the default.
I've had it in a successful test run, and committed it with a minor
tweak (__builtin_abort
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure it never emits instructions or creates pseudos.
I think the approach looks sensible, but I don't know if you n
On 04/12/2016 10:06 PM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:02:18PM +0200, Bernd Schmidt wrote:
On 04/12/2016 05:10 PM, Jakub Jelinek wrote:
This patch arranges for a new argument to
convert_memory_address_addr_space_1 and calls it with that new argument set
to true, to make sure
On 04/12/2016 10:34 PM, Jakub Jelinek wrote:
+ return temp ? gen_rtx_fmt_ee (GET_CODE (x), to_mode,
+ temp, XEXP (x, 1))
+ : temp;
Wrap multi-line expressions in parens. No need for a full retest, just
make sure the file still b
On 04/13/2016 04:14 PM, Marek Polacek wrote:
I revamped the warning so that it follows what the C++ FE does (i.e. passing
IF_P bools here and there) and it seems to work quite well. I didn't mean to
tackle the OMP bits but I bet it would be just a matter of passing IF_P
somewhere.
Bootstrapped
On 04/13/2016 04:14 PM, Marek Polacek wrote:
This patch is meant to be applied on top of the "Wparentheses overhaul" patch.
I really think that warning about the dangling else problem isn't appropriate
as a part of the -Wparentheses warning, which I think should only deal with
stuff like precede
On 04/13/2016 06:11 PM, David Malcolm wrote:
Your approach encapsulates the logic for rejecting this situation
within should_warn_for_misleading_indentation, rather than at the
callers, which is arguably better for modularity (similar to how we
already call it for "do", which is then always rejec
On 04/13/2016 06:01 PM, Thomas Schwinge wrote:
The attached 0001-Split-up-gcc-omp-low.c.patch.xz is a Git "--color
--word-diff --ignore-space-change" patch, purely meant for manual review;
I'm intentionally ;-) not attaching a "patch-applyable" patch at this
point, to minimize the risk of other
On 04/13/2016 07:56 PM, Thomas Schwinge wrote:
Best way to present this might be to do
diff -du old-omp-low.c .
OK, I found Git "-C5%" produce something very similar to that;
0001-Split-up-gcc-omp-low.c-plain.patch.xz attached.
That looks much better. However, the //OMPWHATEVER comments are
On 04/14/2016 03:36 PM, Thomas Schwinge wrote:
I don't know how meaningful it is to create/discuss/review/commit the
following patch until the overall approach has been agreed upon?
Why not? We agree the file should be split, and this makes it easier. So
I'll approve it for stage1, or earlier
On 04/15/2016 02:35 AM, Segher Boessenkool wrote:
This now also shows up on GCC 5, see PR70672. It there happens in
the jump1 pass already.
Is this okay to backport to 5 and 4.9?
Ok.
Bernd
On 04/13/2016 03:04 PM, Marcel Böhme wrote:
Hi Bernd,
Shouldn't we check for overflows before performing the +1 addition
(i.e. 0 <= num < INT_MAX)? Ideally we'd also have a way to signal
from d_number if we had an overflow while parsing that number.
Without an overflow signal, d_number will alr
On 04/15/2016 10:32 AM, Uros Bizjak wrote:
This fixes possible wrong code with a tricky failure mode, so OK now.
Thanks.
[...]
While changing this part, it can be rewritten using dg-additional options, e.g.:
/* { dg-options "-Os -fomit-frame-pointer -fasynchronous-unwind-tables
-mno-red-zon
The PR is for a C++ form of the form
const double val() const { ... }
where the warning location is at the second const (by accident, in
reality it's just past the function's declarator), while the first const
is the one that we are warning about.
This patch adds some logic to the C and C++
We had this problem in the C frontend until very recently:
int array[some_count];
memset (array, 0, some_count);
which forgets to multiply by sizeof int. The following patch implements
a new warning option for this.
Bootstrapped and tested (a while ago, will retest) on x86_64-linux. Ok
f
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
Probably not without a fair amount of surgery, since the cdw_ and ds_
codes are private to each frontend.
Bernd
On 04/22/2016 05:31 PM, Jason Merrill wrote:
On Fri, Apr 22, 2016 at 11:24 AM, Bernd Schmidt wrote:
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
Probably not without a fair amount of surgery, since the cdw_
(Apologies if you get this twice, the mailing list didn't like the html
attachment in the first attempt).
We frequently get malformatted patches, and it's been brought to my
attention that some people don't even make the effort to read the GNU
coding standards before trying to contribute code.
On 04/19/2016 10:48 PM, Mikhail Maltsev wrote:
On 04/18/2016 12:14 PM, Richard Biener wrote:
Enlarging tree_function_decl is bad.
Probably using 3 bits for malloc_flag, operator_new_flag and free_flag is
redundant. I packed the state into 2 bits.
Passes should get at the info via flags_from_
On 04/22/2016 03:57 PM, Jason Merrill wrote:
This looks good, but can we move the code into c-common rather than
duplicate it?
That would be this patch. Also passes testing on x86_64-linux.
Bernd
* doc/invoke.texi (Warning Options): Add -Wmemset-elt-size.
(-Wmemset-elt-size): New item.
c-fa
On 03/02/2016 10:53 PM, Vladimir Makarov wrote:
The patch is ok for me. But I'd wait for GCC7. People are sensitive to
their code performance degradation. Even in most cases the patch
improves performance, in some case it can worsen code and people might
fill new PRs after such change.
I'v
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
- rtx_insn_list *merged_insns = 0;
+ auto_vec, 10> merged_insns;
I see Jeff has already acked this, but some of the expressions here are
getting unwieldy. can we maybe shorten some of this using typedefs?
Bernd
On 04/20/2016 04:57 PM, H.J. Lu wrote:
On Wed, Apr 20, 2016 at 7:54 AM, Jakub Jelinek wrote:
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01080.html
This is wrong, see my other comment on the libgomp patch.
See my reply to your reply on the libgomp patch.
Since Jakub has said it is wrong
On 04/16/2016 01:12 AM, David Wohlferd wrote:
There were basically 3 changes I was trying for in that doc patch. Are
any of them worth keeping? Or are we done?
1) "Do not clobber flags if they are being used as outputs."
2) Output flags sample (with #if removed).
3) "On the x86 platform, flags
On 04/18/2016 02:26 PM, Dhole wrote:
A few months ago I submited a patch to allow the embedded timestamps by
C/C++ macros to be set externally [2], which was already an improvement
over [1]. I was told to wait until the GCC 7 stage 1 started to send
this patch again.
+/* Read SOURCE_DATE_EPOC
On 04/21/2016 02:16 PM, Kirill Yukhin wrote:
Hello,
This looks like a typo to me.
GCC 6 Stage 4 (starts 2016-01-20)GCC 5.3 release (2015-12-04)
|
+-- GCC 5 branch created +
| \
v v
On 04/22/2016 09:45 PM, Sandra Loosemore wrote:
On 04/22/2016 10:42 AM, paul_kon...@dell.com wrote:
Would you expect people to conform to the abridged version or the
full standard? If the full standard, then publishing an abridged
version is not a good idea, it will just cause confusion. Let
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len - 1; i < len; i--)
This is a really icky way to write a loop, the i < len condition makes
it look like a forw
On 04/21/2016 01:24 AM, Trevor Saunders wrote:
On Wed, Apr 20, 2016 at 06:03:01AM -0700, Andi Kleen wrote:
A vector can have very different performance than a list, depending how
it is used. Do your patches cause any measure performance difference for
the compiler?
I haven't measured, but I
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
- remove_node_from_insn_list (insn, &nonlocal_goto_handler_labels);
+
+ unsigned int len = vec_safe_length (nonlocal_goto_handler_labels);
+ for (unsigned int i = 0; i < len; i++)
+ if ((*nonlocal_goto_handler_labels)[i
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
-static rtx_expr_list *
+static vec
extract_mentioned_regs (rtx x)
{
- rtx_expr_list *mentioned_regs = NULL;
+ vec mentioned_regs = vNULL;
subrtx_var_iterator::array_type array;
FOR_EACH_SUBRTX_VAR (iter, array, x, NONCONST)
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
-/* Remove INSN from queue. */
+/* Remove INSN at idx from queue. */
+static void
+queue_remove (unsigned int q, unsigned int idx)
+{
+ QUEUE_INDEX (insn_queue[q][idx]) = QUEUE_NOWHERE;
+ insn_queue[q].ordered_remove (idx);
+ q_size--;
On 04/25/2016 03:30 PM, Trevor Saunders wrote:
On Mon, Apr 25, 2016 at 02:28:51PM +0200, Bernd Schmidt wrote:
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
+ unsigned int len = cond_list.length ();
+ for (unsigned int i = len
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
It used the gc vector type, but isn't marked as a gc route, and appears
to be manually managed, so it should be safe to use the normal heap
vector.
gcc/ChangeLog:
2016-04-19 Trevor Saunders
* ira-emit.c
On 04/25/2016 04:21 PM, Bernd Schmidt wrote:
On 04/25/2016 03:30 PM, Trevor Saunders wrote:
On Mon, Apr 25, 2016 at 02:28:51PM +0200, Bernd Schmidt wrote:
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders
+ unsigned int len = cond_list.length
On 04/15/2016 02:52 PM, Senthil Kumar Selvaraj wrote:
For both testcases in the PR, reload fails to take into account that
FP-SP elimination can no longer be performed, and tries to find reload
regs for an rtx generated when FP-SP elimination was valid.
1. reload initializes elim table with FP-
On 04/25/2016 08:44 PM, Jim Wilson wrote:
On 04/18/2016 01:12 PM, Jim Wilson wrote:
On 04/11/2016 01:41 PM, Jim Wilson wrote:
Here is a patch to correct the -fabi-version docs on the GCC 5 branch.
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00480.html
ping^2
Cc'ing Jason as the most li
On 01/01/2016 07:02 PM, Hans-Peter Nilsson wrote:
On Tue, 1 Dec 2015, Bernd Schmidt wrote:
The automatic Makefile approach might look something like this. The effect is
similar to what happens when you edit tm.texi.in, except the build would not
be interrupted every time, only when you modify
On 01/29/2016 01:19 PM, Uros Bizjak wrote:
* gcc.target/i386/avx512bw-vptestmb-1.c: Correct [xyz]mm register
number scans.
* gcc.target/i386/avx512bw-vptestmw-1.c: Likewise.
* gcc.target/i386/avx512bw-vptestnmb-1.c: Likewise.
* gcc.target/i386/avx512bw-vptestnmw-1.c: Likewise.
* gcc.target/i386/a
===
--- gcc/ChangeLog (revision 235441)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2016-04-26 Bernd Schmidt
+
+ PR rtl-optimization/57193
+ * opts.c (default_options_table): Add OPT_frename_registers at -O2
On 04/26/2016 02:39 PM, Jakub Jelinek wrote:
I support that change, and -Wparentheses will still enable this, it just
gives more fine-grained control and be in line with what clang does.
Bernd, how much are you against this change?
Don't really care that much, I just don't quite see the point.
On 04/25/2016 07:55 PM, Jason Merrill wrote:
On 04/25/2016 05:07 AM, Bernd Schmidt wrote:
+if (TREE_CODE (arg2) == CONST_DECL)
+ arg2 = DECL_INITIAL (arg2);
+int literal_mask = ((!!integer_zerop (arg1) << 1)
+| (!!integer_zerop (arg2) <<
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
It is not fatal, but still ugly. The problem is that the function has
int i;
...
for (i = 0; ...)
...
for (unsigned int i = ... )
...
for (i = 0; ...)
This patch just declares the var in the only affected loop, so that the warning
is not e
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
^
../../gcc/reorg.c:1413:25: warning: matches this ‘i’ under old rules
for (unsigned int i = len - 1; i < len; i--)
^
Oh, and also - I flagged this while reviewing other parts of Trevor's
changes, this pat
On 04/26/2016 05:41 PM, Jakub Jelinek wrote:
On Tue, Apr 26, 2016 at 03:13:32PM +0200, Bernd Schmidt wrote:
On 04/26/2016 03:08 PM, Jakub Jelinek wrote:
^
../../gcc/reorg.c:1413:25: warning: matches this ‘i’ under old rules
for (unsigned int i = len - 1; i < len
On 04/26/2016 08:21 PM, Richard Sandiford wrote:
"H.J. Lu" writes:
I am working a patch to enable SSE, AVX and AVX512 for memcpy/memset
optimization. x86 backend defines MAX_BITSIZE_MODE_ANY_INT to 128
to keep the OI and XI modes from confusing the compiler into thinking
that these modes could
On 04/26/2016 08:35 PM, H.J. Lu wrote:
This
/* { dg-final { scan-assembler-times "vmovdqa64\[
\\t\]+\[^\{\n\]*%ymm\[0-9\]+\[^\nxy\]*\\(.{5}(?:\n|\[ \\t\]+#)" 1 {
target nonpic } } } */
fails on x32 since x32 with 32-bit pointers has (%r10d) instead of
(%r10). .{5} doesn't match.
What is this
On 04/26/2016 09:39 PM, H.J. Lu wrote:
make check-gcc RUNTESTFLAGS="--target_board='unix{-mx32}'
i386.exp=avx512vl-vmovdqa64-1.c"
Unfortunately, that doesn't work:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such
file or directory
compilation terminated.
Trying to follo
On 04/26/2016 11:28 PM, Dhole wrote:
I've fixed all the spaces issues. I've also changed the "unsigned long long"
to "time_t" as you suggested. Also, to improve reliability I'm now
using strtoll rather than strtoull, so that negative values can be
detected in SOURCE_DATE_EPOCH, which are treate
On 04/27/2016 09:50 AM, Dominik Vogt wrote:
The attached patch cleans up some (mostly unnecessary) dg-do
directives in the gcc.dg and gcc.target test cases.
Ok except...
* gcc.dg/spec-options.c: Switch order of the two "dg-do run" so that
the test ist actually "run" on sh*-*-*
On 04/27/2016 02:10 AM, H.J. Lu wrote:
On Tue, Apr 26, 2016 at 3:11 PM, Bernd Schmidt wrote:
On 04/26/2016 09:39 PM, H.J. Lu wrote:
make check-gcc RUNTESTFLAGS="--target_board='unix{-mx32}'
i386.exp=avx512vl-vmovdqa64-1.c"
Unfortunately, that doesn't work:
/usr/
On 04/26/2016 11:23 PM, Martin Sebor wrote:
The documentation for the new option implies that it should warn
for calls to memset where the third argument contains the number
of elements not multiplied by the element size. But in my (quick)
testing it only warns when the argument is a constant eq
On 04/27/2016 09:11 AM, Eric Botcazou wrote:
@@ -8562,7 +8563,8 @@ debug information format adopted by the
make debugging impossible, since variables no longer stay in
a ``home register''.
-Enabled by default with @option{-funroll-loops} and @option{-fpeel-loops}.
+Enabled by default with
On 04/27/2016 06:02 AM, Jeff Law wrote:
AFAICT the sra-1.c expects to see the incremented value and I'm at a
loss to understand what's really going on here. Can you give more details?
Yeah, maybe my first impression wasn't very accurate.
When I try to run gdb manually, it just crashes:
(gdb)
On 09/07/2016 11:48 PM, Joseph Myers wrote:
libgcc complex multiply is meant to eliminate excess
precision from certain internal values by forcing them to memory in
exactly those cases where the type has excess precision. But in
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01894.html I
accident
On 09/07/2016 06:05 PM, James Greenhalgh wrote:
Hi,
This patch arranges for half-precision complex multiply and divide
routines to be built if __LIBGCC_HAS_HF_MODE__. This will be true
if the target supports the _Float16 type.
OK?
Ok, but please see Joseph's patch from today: I think you pr
On 09/08/2016 01:21 AM, Paul Eggert wrote:
Sure, attached. On Fedora 24 x86-64 (GCC 6.1.1 20160621, valgrind
3.11.0), when I compile with "gcc -O2 flexouch.c" and run with "valgrind
./a.out", valgrind complains "Invalid read of size 2". This is because
GCC compiles "p->d[0] == 2 && p->d[1] == 3"
On 09/08/2016 07:20 PM, Jeff Law wrote:
On 08/29/2016 03:31 AM, Bernd Schmidt wrote:
How do these actually know where to save/restore registers? The frame
pointer may have been eliminated, and SP isn't necessarily constant
during the function. Seems like you'd have to calculate CFA
On 09/09/2016 10:56 PM, Segher Boessenkool wrote:
On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote:
I think the lack of test coverage is something we'll want to address.
Building and running the compiler, the various target libraries, and the
testsuite is more than enough coverage for
On 09/10/2016 12:56 PM, Marek Polacek wrote:
2016-09-10 Marek Polacek
* doc/extend.texi: Use lowercase "boolean".
* doc/invoke.texi: Likewise.
* doc/md.texi: Likewise.
* target.def: Likewise.
* doc/tm.texi: Regenerated.
Ok.
Bernd
On 09/06/2016 10:36 PM, Jakub Jelinek wrote:
+/* Helper function for listing valid choices and hint for misspelled
+ value. CANDIDATES is a vector containing all valid strings,
+ STR is set to a heap allocated string that contains all those
+ strings concatenated, separated by spaces, and
In general, it's functionality that I would very much like to have
(although maybe it's less useful these days now that the rtl side is
fairly static). I think there's not much sense looking too deeply at the
individual patches yet; we need to first figure out what we would really
like this to
On 09/13/2016 12:22 AM, Segher Boessenkool wrote:
This patch adds a TARGET_LRA_P (defined to hook_bool_void_false) to
every target that didn't yet override the hook. No functional change.
This patch series makes very little sense to me. Adding 35 new instances
of a hook definition so you can
On 09/12/2016 08:58 PM, Jason Merrill wrote:
TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest
alignment possible for any type or variable, and defaults to
BIGGEST_ALIGNMENT. But MAX_OFILE_ALIGNMENT is typically much larger
than BIGGEST_ALIGNMENT, and is documented as the limit f
On 09/12/2016 08:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
Would it be a separate configuration i.e. something like:
../src/configure --target=rtl-selftest
or somesuch?
The way I imagine it working, the top-level Makefile would
1001 - 1100 of 2198 matches
Mail list logo
