On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus wrote:
> In particular, currently, the following item does not make clear that it
> is about legacy support: "Variables with the AUTOMATIC
> attribute can be used in EQUIVALENCE statements."
>
> I think it can remain as is with the -fdec umbrella item.
On Wed, 27 Nov 2019, Kewen.Lin wrote:
> Hi,
>
> As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
> is different from first_stmt_info, it's possible that the first_stmt DR isn't
> initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
> shouldn't use f
Thanks,
On 2019/11/26 18:15, Jan Hubicka wrote:
>> Hi,
>>
>> On 2019/11/26 16:04, Jan Hubicka wrote:
Summary variables should be deleted at the end of write_summary.
It's first newed in generate_summary, and second newed in read_summary.
Therefore, delete the first in write_summary,
On 2019/11/27 2:42 PM, Kewen.Lin wrote:
Hi Lijia,
on 2019/11/27 下午2:31, Li Jia He wrote:
Hi,
In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In fact,
PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
part to gcc-9-branch. This patch back
Hi Lijia,
on 2019/11/27 下午2:31, Li Jia He wrote:
> Hi,
>
> In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In
> fact,
> PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
> part to gcc-9-branch. This patch backport vector_{ungt,unge,unlt,unle}
Hi,
In order to fix PR92098, we need to define vec_cmp_* and vcond_mask_*. In fact,
PR92132 already fixed the issue on the trunk. We need to backport PR92132 int
part to gcc-9-branch. This patch backport vector_{ungt,unge,unlt,unle}
for vec_{cmp,cmpu} interface and related expand to gcc-9-branc
Hi,
As PR91790 exposed, when we have one slp node whose first_stmt_info_for_drptr
is different from first_stmt_info, it's possible that the first_stmt DR isn't
initialized yet before stmt SLP_TREE_SCALAR_STMTS[0] of slp node. So we
shouldn't use first_stmt_info for vect_setup_realignment, instead
Hi,
As Segher pointed out in PR92566, we shouldn't offer some vector modes which
aren't supported under current setting. This patch is to make it check by
VECTOR_UNIT_NONE_P which is initialized as current architecture masks.
Bootstrapped and tested on powerpc64le-linux-gnu.
Is it ok for trunk?
On 11/26/19 10:52 PM, Jonathan Wakely wrote:
On 26/11/19 20:07 +0100, François Dumont wrote:
Sure, I am about to do so.
However I wasn't sure about this syntax before the commit so I had
run the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
The
On Tue, Nov 26, 2019 at 2:30 PM Richard Sandiford
wrote:
>
> Andrew Pinski writes:
> > On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote:
> >>
> >> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
> >> PowerPC, we should do something similar for aarch64. This pattern
> >> do
hi jakub:
VF is used for differentiating AVX512F/AVX/SSE, but there's
condition TARGET_AVX512F in avx512f_maskcmp3, it must be a TYPO
and should be VF_AVX512VL instead.
Bootstrap and regression test on i386/x86_64 backend is ok.
OK for trunk?
diff --git a/gcc/config/i386/sse.md b/gcc/config/i3
I noticed that tsubst of a TEMPLATE_ID_EXPR was losing the location
information from its EXPR_LOCATION. Then I noticed that
cxx_eval_constant_expression was also throwing away location information for
variable references.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (tsubst_copy
Recent versions of graphviz reject the .dot files emitted by the
analyzer, with messages such as:
Warning: flat edge between adjacent nodes one of which has a record shape -
replace records with HTML-like labels
Edge node_9 -> node_8
The above warning seems to have been added to graphviz o
On 11/26/19 6:42 PM, Jakub Jelinek wrote:
On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:
Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
any references to its address would end up all referring to the first
element of the range, which would be wrong. H
Hi, Richard,
This patch is a not bugfix, while it is small. Martin and Honza are fine with
it.
But now we are in stage 3, is it ok to commit?
Thanks,
Feng
From: Feng Xue OS
Sent: Monday, November 25, 2019 10:17 PM
To: Martin Jambor; Jan Hubicka
Cc: lu
As we discussed in the V6 patches #1 and #2, before submitting the patches
adding eI support for movdi and movsi, you prefered that I reformat the patches
to make them easier in the future to identify the changes.
This patch changes just the movdi_internal64 insn. All of the constraints are
in th
As we discussed in the V6 patches #1 and #2, before submitting the patches
adding eI support for movdi and movsi, you prefered that I reformat the patches
to make them easier in the future to identify the changes.
This patch changes just the movsi_internal insn. All of the constraints are in
the
Hi!
On Wed, Nov 27, 2019 at 12:51:35AM +0100, Jakub Jelinek wrote:
> As mentioned in the PR, on the following testcase we ICE during combine.
> We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and
A subreg of something that is not a reg (or mem, if your port still does
that) is invali
On 11/25/19 1:22 PM, Bernd Schmidt wrote:
> 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 th
On 11/26/19 4:45 PM, Jakub Jelinek wrote:
> Hi!
>
> Without this patch, we emit in .debug_macro with -g3 -xc -
> a .file N "" directive which makes e.g. readelf unhappy.
> Elsewhere, we handle "" filename as "", so this patch does that too
> for .debug_macro.
>
> Bootstrapped/regtested on x86_64-
In r278621 I accidentally removed a test that prevented
an optimization from taking place when it wasn't supposed to,
causing test failures in Jeff's mass rebuilds of downstream
packages (e.g., snapd). In r278742 I committed the attached
patch, restoring the test.
Martin
PR tree-optimization/926
Hi!
The following testcase started ICEing with my r241630 PR78026 fix.
Before we created a new namespace and the check gfc_simplify_spread did
happened to work during that, but it doesn't anymore.
I believe gfc_init_expr_flag is the right flag to use when checking if
something has to be folded at
Hi!
As mentioned in the PR, on the following testcase we ICE during combine.
We have (subreg:V1DI (ne:DI (reg:CC flags) (const_int 0)) 0) and
gen_lowpart_for_combine turns that into (ne:V1DI (reg:CC flags) (const_int 0))
which looks wrong to me, later on the if_then_else simplifications try to
sim
Hi!
Without this patch, we emit in .debug_macro with -g3 -xc -
a .file N "" directive which makes e.g. readelf unhappy.
Elsewhere, we handle "" filename as "", so this patch does that too
for .debug_macro.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-11-27 Jakub Jel
On Tue, Nov 26, 2019 at 04:58:01PM -0500, Jason Merrill wrote:
> Hmm, we shouldn't have any PLACEHOLDER_EXPR under a RANGE_EXPR; if we did,
> any references to its address would end up all referring to the first
> element of the range, which would be wrong. How about skipping RANGE_EXPR
> in repla
On Thu, Nov 14, 2019 at 06:14:47PM -0500, Michael Meissner wrote:
> * config/rs6000/linux64.h (TARGET_PREFIXED_ADDR_DEFAULT): Enable
> prefixed addressing by default.
> (TARGET_PCREL_DEFAULT): Enable pc-relative addressing by default.
> * config/rs6000/rs6000-cpus.def (ISA_F
On Tue, 26 Nov 2019, Bernd Schmidt wrote:
> 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 bu
On 26/11/19 22:22 +, Richard Sandiford wrote:
+ libstd...@gcc.gnu.org
writes:
From: Andrew Pinski
Hi if we have a aarch64 compiler that has a big-endian
multi-lib, it fails to compile libstdc++ because
simd_fast_mersenne_twister_engine is only defined for little-endian
in ext/random but
Andrew Pinski writes:
> On Fri, Aug 18, 2017 at 12:17 PM Andrew Pinski wrote:
>>
>> Like https://gcc.gnu.org/ml/gcc-patches/2010-09/msg00060.html for
>> PowerPC, we should do something similar for aarch64. This pattern
>> does show up in SPEC CPU 2006 in astar but I did not look into
>> performa
+ libstd...@gcc.gnu.org
writes:
> From: Andrew Pinski
>
> Hi if we have a aarch64 compiler that has a big-endian
> multi-lib, it fails to compile libstdc++ because
> simd_fast_mersenne_twister_engine is only defined for little-endian
> in ext/random but ext/opt_random.h thinks it is defined alwa
Joel Hutton writes:
> Hi all,
>
> This patch updates the vect_char_add target selector to use its own
> cache instead of the vect_int cache.
>
> This was causing a situation where bb-slp-40.c would fail on sparc when
> run after other tests that use the vect_int target selector, but pass
> when
On 11/22/19 9:19 AM, Jakub Jelinek wrote:
Hi!
On the following testcase, replace_placeholders is called on a CONSTRUCTOR
{ a, [1..63] = NON_LVALUE_EXPR<42> }
and call build_ctor_subob_ref in that case. The problem is that index is
RANGE_EXPR and as it is not INTEGER_CST, we call
build_class_mem
On 26/11/19 20:07 +0100, François Dumont wrote:
On 11/26/19 1:21 PM, Jonathan Wakely wrote:
On 26/11/19 12:33 +0100, Stephan Bergmann wrote:
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not
On 11/25/19 6:41 PM, Jakub Jelinek wrote:
Hi!
The standard says that argument-attribute-clause is:
attribute-argument-clause:
( balanced-token-seq[opt] )
balanced-token-seq:
balanced-token
balanced-token-seq balanced-token
balanced-token:
( balanced-token-seq[opt]
On 11/25/19 6:32 PM, Jakub Jelinek wrote:
Hi!
On Mon, Nov 25, 2019 at 03:46:23PM +0100, Jakub Jelinek wrote:
On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
I guess the question is, shall we store the minimum precision needed
somewhere by finish_enum_value_list (perhaps only bot
On 11/25/19 3:34 PM, Paolo Carlini wrote:
Hi,
a bunch of straightforward tweaks: let's use the available location in
some additional places. Tested x86_64-linux, as usual.
Thanks, Paolo.
///
OK.
On 11/18/19 10:18 AM, Andrew Sutton wrote:
I forgot to mention a somewhat odd test included in the patch:
concepts-recursive-sat3.C does not recurse. Code follows:
template
concept Fooable = requires(T t) { foo(t); };
template
void foo(T t) { }
void test()
{
foo(0); // { dg-error "unsatisfi
Recently, Janne bumped the minimal MPFR version from 2.4 to 3.1. As a
follow-up cleanup, the mp_ data types can now be changed to mpfr_ and
GMP_RNDx rounding to MPFR_RNDx (with an additional MPFR_RNDA).
This patch changes the types in the middle end and a left over from
previous patch round in
On 11/18/19 10:13 AM, Andrew Sutton wrote:
This applies on top of the patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html
Wrap satisfaction with push/pop_tinst_level to force termination on recursion.
+ if (tmpl)
+ push_tinst_level (tmpl);
Actually, why not pass
On 11/22/19 10:28 AM, Andrew Sutton wrote:
This does a much better job identifying when an expression in a
requires-clause needs parentheses.
Andrew Sutton
OK.
Jason
On 11/20/19 10:45 AM, Andrew Sutton wrote:
This patch builds on https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html.
Tie static assertion diagnostics into constraint diagnostic. For
example, this program:
template
concept iterator =
requires (I i)
{
++i;
*i;
};
static_a
On 11/18/19 10:13 AM, Andrew Sutton wrote:
This applies on top of the patch here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01034.html
Wrap satisfaction with push/pop_tinst_level to force termination on recursion.
Andrew Sutton
OK.
On 11/13/19 8:28 AM, Andrew Sutton wrote:
This changes the diagnostic of non-boolean constraints and rvalue
conversion failures in constraint satisfaction into hard errors. I
also cleaned up the satisfaction routines to reduce the number of
functions involved.
Jason, this is a squashed version o
On 11/26/19 9:49 PM, Stephan Bergmann wrote:
On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had
run the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
I also try -std=gnu++98 and made sure
On 26/11/2019 20:07, François Dumont wrote:
However I wasn't sure about this syntax before the commit so I had run
the new 2_neg.cc with:
make CXXFLAGS=-std=c++98 check-debug
and it worked fine and still is !
I also try -std=gnu++98 and made sure that pch had been updated by
re-building libs
On Tue, Nov 26, 2019 at 10:48 AM Tobias Burnus wrote:
>
> When I tried to bootstrap with --enable-languages=default, which
> includes objc, it failed to build libobj.
>
> As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file
> is at a different location. I wonder why no one had t
On Tue, Nov 26, 2019 at 07:47:44PM +0100, Tobias Burnus wrote:
> Build on x86-64-gnu-linux.
> OK for the trunk?
The patch is obvious.
> PS: Assuming the build was indeed broken for everyone since 2 years, maybe
> one should remove 'objc' from the 'default' languages? – Which languages is
> now no
The problem with false positives is correlated with the degree of
optimization; a lot of people have reported problems at only the
`-Og' optimization level (even when the code in question is
embarrassingly correct).
Therefore, the general solution is probably that the implem-
entation
Actually, can you both try with my patch applied? If it still builds for
you and then builds for me, the problem is also solved. And with proper
path it looks better in any case.
(Remark: The compilation w/o maintainer mode was the usual Linux path,
i.e. all under /usr/bin.)
Tobias
On 11/26
On 11/26/19 8:13 PM, Iain Sandoe wrote:
Right, It’s not been broken at all AFAICT - I build it daily on Darwin
(often several times) and
frequently on Linux - as does anyone building —enable-languages=all
Ideas are welcome. I first did:
.../configure --prefix=/home/tburnus/projects/gcc-trunk
Hi!
On Thu, Nov 14, 2019 at 06:09:09PM -0500, Michael Meissner wrote:
> In this case, the current code re-uses the temporary for calculating the
> offset
> of the element to load up the address of the vector, losing the offset.
Reusing the same pseudo is *always* a bad idea. You get better
opti
Hi
Rainer Orth wrote:
When I tried to bootstrap with --enable-languages=default, which includes
objc, it failed to build libobj.
care to describe exactly how the build fails?
PS: Assuming the build was indeed broken for everyone since 2 years, maybe
one should remove 'objc' from the 'defau
Hi Tobias,
> When I tried to bootstrap with --enable-languages=default, which includes
> objc, it failed to build libobj.
care to describe exactly how the build fails?
> PS: Assuming the build was indeed broken for everyone since 2 years, maybe
> one should remove 'objc' from the 'default' langu
On 11/26/19 1:21 PM, Jonathan Wakely wrote:
On 26/11/19 12:33 +0100, Stephan Bergmann wrote:
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not
singular in valid_range. Moreover __check_singu
When I tried to bootstrap with --enable-languages=default, which
includes objc, it failed to build libobj.
As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file
is at a different location. I wonder why no one had the problem before
in the last years – the libobjc/Makefile.in
Second attempt this time with attachment.
Apologies.
regards,
Mark
On 26/11/2019 15:56, Mark Eggleston wrote:
On 26/11/2019 11:12, Tobias Burnus wrote:
Hi Mark,
On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems
related to my change
Hi all,
This patch updates the vect_char_add target selector to use its own
cache instead of the vect_int cache.
This was causing a situation where bb-slp-40.c would fail on sparc when
run after other tests that use the vect_int target selector, but pass
when run on its own.
This fixes Bug 92
Hi Christophe,
> Some time ago, you proposed to enable code hoisting for -Os instead,
> and this is the approach that was chosen
> in arm-9-branch. Why are you proposing a different setting for trunk?
Like I said in my message, I've now done more detailed benchmarking which
shows it affects -O3 p
Hi all,
This patch is part of a series adding support for Armv8.6-A features.
It enables options including -march=armv8.6-a, +i8mm and +bf16.
The +i8mm and +bf16 features are mandatory for Armv8.6-a and optional
for Armv8.2-a and onward.
Documents are at https://developer.arm.com/docs/ddi0596/lat
On 26/11/2019 11:12, Tobias Burnus wrote:
Hi Mark,
On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems
related to my changes, however, it does object to the lack of
character encoding in the file.
Note that some script modifies the fi
On Mon, 11 Nov 2019, Maciej W. Rozycki wrote:
> This patch series addresses a problem with the testsuite compiler being
> set up across libatomic, libffi, libgo, libgomp with no correlation
> whatsoever to the target compiler being used in GCC compilation.
> Consequently there in no arrangeme
On November 26, 2019 4:39:09 PM GMT+01:00, Christophe Lyon
wrote:
>On Tue, 26 Nov 2019 at 16:18, Wilco Dijkstra
>wrote:
>>
>> Hi,
>>
>> While code hoisting generally improves codesize, it can affect
>performance
>> negatively. Benchmarking shows it doesn't help SPEC and negatively
>affects
>> em
On Tue, 26 Nov 2019 at 16:18, Wilco Dijkstra wrote:
>
> Hi,
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mainly
>
ping?
On Mon, 18 Nov 2019 at 10:00, Christophe Lyon
wrote:
>
> On Wed, 13 Nov 2019 at 15:46, Christophe Lyon
> wrote:
> >
> > On Tue, 12 Nov 2019 at 12:13, Richard Earnshaw (lists)
> > wrote:
> > >
> > > On 18/10/2019 14:18, Christophe Lyon wrote:
> > > > + bool not_supported = arm_arch_no
Hi,
While code hoisting generally improves codesize, it can affect performance
negatively. Benchmarking shows it doesn't help SPEC and negatively affects
embedded benchmarks. Since the impact is relatively small with -O2 and mainly
affects -O3, the simplest option is to disable code hoisting for -
This is the patch removing discrepancy between recog and LRA insn
recognition:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01842.html
Index: ChangeLog
===
--- ChangeLog (revision 278451)
+++ ChangeLog (working copy)
@@ -1,3 +1,9
Hi Thomas,
this is a reorg of the last non-contiguous arrays patch. You'll notice that:
(1) A large part of the code has been pulled into oacc-parallel.c, with most
of the data structure declarations in oacc-int.h.
(2) target.c only contains relatively little code from gomp_map_vars_internal
tha
On 2019/11/8 8:55 PM, Chung-Lin Tang wrote:
On 2019/10/8 10:05 PM, Thomas Schwinge wrote:
Hi Chung-Lin!
While we're all waiting for Tom to comment on this;-) -- here's another
item I realized:
On 2019-09-10T19:41:59+0800, Chung-Lin Tang wrote:
The libgomp nvptx plugin changes are also quite
The following delays all edge pruning until inlining into a function
is complete. This avoids crashes with stmt folding walking the
SSA use->def chain and arriving at PHIs without arguments.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-11-26 Richard Biener
The following enhances vector CTOR simplification to cover the
case where we select a vector part. I've included testcases
for highpart, lowpart and odd/even extracts (with conversion).
The only case we cannot handle right now is conversion with
constants (but there's a latent bug there which I
Hi Andrew,
Could you repost your patch please to make review easier/quicker? It's no
longer linked...
Cheers,
Wilco
Hi Andrew,
> Hi if we have a aarch64 compiler that has a big-endian
> multi-lib, it fails to compile libstdc++ because
> simd_fast_mersenne_twister_engine is only defined for little-endian
> in ext/random but ext/opt_random.h thinks it is defined always.
>
> OK? Built an aarch64-elf toolchain whi
Hi Thomas,
I now played also around common blocks with "!$acc declare
device_resident (/block/)". [See attached test-case diff.]
Observations:
* !$acc declare has to come after the declaration of the common block.
In terms of the spec, it just needs to be in the declaration section,
i.e. it
On Nov 25 2019, Rainer Orth wrote:
> AFAICS this caused
>
> +FAIL: libstdc++-abi/abi_check
>
> on Solaris. In libstdc++.log I find
That happens on all targets that don't support decimal float.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 25
On 26/11/19 12:33 +0100, Stephan Bergmann wrote:
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not
singular in valid_range. Moreover __check_singular signature for
pointers is not intercepti
On 26/11/19 00:57 +, Joseph Myers wrote:
On Mon, 25 Nov 2019, Rainer Orth wrote:
and a few more, all DFP related. They used to be emitted by g++ for
__fundamental_type_info in libsupc++/fundamental_type_info.cc and lived
in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP
Committed as obvious.
Richard.
2019-11-26 Richard Biener
PR middle-end/92669
* cfganal.c (pre_and_rev_post_order_compute_fn): Deal with
NULL pre_order.
Index: gcc/cfganal.c
===
--- gcc/cfganal.c (
On 22/11/2019 18:59, Jonathan Wakely wrote:
On 22/11/19 18:38 +0100, François Dumont wrote:
I noticed that we are not checking that iterators are not singular
in valid_range. Moreover __check_singular signature for pointers is
not intercepting all kind of pointers in terms of qualification.
Hi Mark,
On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems
related to my changes, however, it does object to the lack of
character encoding in the file.
Note that some script modifies the file a bit – the final file does have
a charac
Hi Wilco,
On 11/19/19 3:11 PM, Wilco Dijkstra wrote:
ping
Various CPUs have max_cond_insns set to 5 due to historical reasons.
Benchmarking shows that max_cond_insns=2 is fastest on modern Cortex-A
cores, so change it to 2 for all Cortex-A cores.
Hmm, I'm not too confident on that. I'd suppor
I've check the changes with W3 validator. There are no problems related
to my changes, however, it does object to the lack of character encoding
in the file. My knowledge of HTML is limited, so don't know how to fix that.
This is the first time in changing the wwwdoc, I haven't included a
chan
On 26/11/2019 09:01, Robin Dapp wrote:
> I committed this patch (obvious). It fixes the s390 bootstrap by
> undefining existing defines before redefining them.
thanks.
sorry for the trouble.
> Hi,
>
> On 2019/11/26 16:04, Jan Hubicka wrote:
> > > Summary variables should be deleted at the end of write_summary.
> > > It's first newed in generate_summary, and second newed in read_summary.
> > > Therefore, delete the first in write_summary, delete the second in
> > > execute.
> > >
> >
On 11/20/19 3:33 PM, Martin Liška wrote:
I can come up with an upstream patch as well.
Hello.
I've just made an upstream review request for that:
https://reviews.llvm.org/D70707
Martin
Hi,
On 2019/11/26 16:04, Jan Hubicka wrote:
Summary variables should be deleted at the end of write_summary.
It's first newed in generate_summary, and second newed in read_summary.
Therefore, delete the first in write_summary, delete the second in
execute.
gcc/ChangeLog:
2019-11-26 Lu
Hi!
On Tue, Nov 12, 2019 at 12:27:26PM +0100, Jakub Jelinek wrote:
> But I'm afraid I don't really have the cycles to test this on all targets,
> nor does it fix the arm be or s390 31-bit problem with shmctl.
I have committed the following change cherry-picked from upstream,
before submitting the
Hi,
I committed this patch (obvious). It fixes the s390 bootstrap by
undefining existing defines before redefining them.
Regards
Robin
--
gcc/ChangeLog:
2019-11-26 Robin Dapp
* config/s390/linux.h: Add undef for MUSL_DYNAMIC_LINKERxx.
commit aa2879c029af2ae70067df23bc68081f62abb13
On Tue, Nov 26, 2019 at 09:07:11AM +0100, Richard Biener wrote:
> OK.
>
> It just occured to me - what if we'd use the type of the non-constant
> argument for creating the adjusted constant? Wouldn't that avoid
> the issue as well?
No, the type type of the non-constant argument is NULLPTR_TYPE t
On Tue, 26 Nov 2019, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because we assert the only constants with
> NULLPTR_TYPE created are 0.
>
> The fix is to perform the value adjustment of boundary value and EQ/NE
> conversion to other comparisons only for scalar integral types, no
> Summary variables should be deleted at the end of write_summary.
> It's first newed in generate_summary, and second newed in read_summary.
> Therefore, delete the first in write_summary, delete the second in
> execute.
>
> gcc/ChangeLog:
>
> 2019-11-26 Luo Xiong Hu
>
> * ipa-pur
90 matches
Mail list logo
