Bin.Cheng wrote:
>>> + gassign *get_res = gimple_build_assign (lhs, done);
>>> + gsi_replace (gsi, get_res, true);
>>> + *handled_ops_p = true;
>>> + }
>>> + break;
>>> + }
>>> +}
>>> + return NULL_TREE;
>>> +}
>>> +
>>> +/* Main entry poin
From: Andrew Pinski
Hi,
While working on bit-field lowering pass, I came across this bug.
The IR looks like:
VIEW_CONVERT_EXPR(var1) = _12;
_1 = BIT_FIELD_REF ;
Where the BIT_FIELD_REF has REF_REVERSE_STORAGE_ORDER set on it
and var1's type has TYPE_REVERSE_STORAGE_ORDER set on it.
PRE/FRE
On Wed, Jan 15, 2020 at 06:56:48PM -0500, David Malcolm wrote:
> gcc/analyzer/ChangeLog:
> PR analyzer/93281
> * region-model.cc
> (region_model::convert_byte_offset_to_array_index): Convert
> offset_cst to ssizetype before dividing by byte_size.
> ---
> gcc/analyzer/region
On January 16, 2020 9:13:46 AM GMT+01:00, apin...@marvell.com wrote:
>From: Andrew Pinski
>
>Hi,
> While working on bit-field lowering pass, I came across this bug.
>The IR looks like:
> VIEW_CONVERT_EXPR(var1) = _12;
> _1 = BIT_FIELD_REF ;
>
>Where the BIT_FIELD_REF has REF_REVERSE_STORAGE_ORD
On January 16, 2020 6:08:48 AM GMT+01:00, apin...@marvell.com wrote:
>From: Andrew Pinski
>
>Commit g:f96bf49a0 added the target field to expand_operand.
>But it leaves it uninitialized when doing a full initialization
>inside create_expand_operand. This fixes the problem and improves
>the code g
On January 16, 2020 6:08:49 AM GMT+01:00, apin...@marvell.com wrote:
>From: Andrew Pinski
>
>In struct _dep, there is an implicit padding of 4bits. This
>bit-field padding is uninitialized when init_dep_1 is being called.
>This means we access uninitialized memory but never use it for
>anything.
Hi,
As we discussed in the thread
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
I'm working to teach IVOPTs to consider D-form group access during unrolling.
The difference on D-form and other forms during unrolling is
gcc/ChangeLog
2020-01-16 Kewen Lin
* cfgloop.h (struct loop): New field estimated_uf.
* config/rs6000/rs6000.c (TARGET_LOOP_UNROLL_ADJUST_TREE): New macro.
(rs6000_loop_unroll_adjust_tree): New function.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGE
gcc/ChangeLog
2020-01-16 Kewen Lin
* config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): New macro.
(rs6000_stride_dform_valid_p): New function.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_STRIDE_DFORM_VALID_P): New hook.
* target.def (stride_
gcc/ChangeLog
2020-01-16 Kewen Lin
* tree-ssa-loop-ivopts.c (struct iv_group): New field dform_p.
(struct iv_cand): New field dform_p.
(struct ivopts_data): New field mark_dform_p.
(record_group): Initialize dform_p.
(mark_dform_groups): New function.
gcc/testsuite/ChangeLog
2020-01-16 Kelvin Nilsen
Kewen Lin
* gcc.target/powerpc/p9-dform-0.c: New test.
* gcc.target/powerpc/p9-dform-1.c: New test.
* gcc.target/powerpc/p9-dform-2.c: New test.
* gcc.target/powerpc/p9-dform-3.c: New test.
The patterns used by aarch64_split_sve_subreg_move only support
integer modes, so if the widest mode is a float, we should get
its integer equivalent.
Fixes gcc.target/aarch64/sel_3.c for big-endian targets.
Tested on aarch64-linux-gnu and aarch64_be-none-elf.
Richard
2020-01-16 Richard Sandi
On Jan 16, 2020, Alexandre Oliva wrote:
> On Jan 9, 2020, Alexandre Oliva wrote:
>> On Jan 9, 2020, Richard Biener wrote:
>>> Did I miss the actual (non-documentation) patch?
>> No, I didn't post it. It's kind of big, and only yesterday did I get it
>> to work as expected and now extensivel
Hi,
On Thu, Jan 16 2020, Gerald Pfeifer wrote:
> On Wed, 15 Jan 2020, Martin Jambor wrote:
>> when going over stuff linked from the SummerOfCode wiki page,
>> I found out that doc/install.texi still refers to Subversion.
>
> We've got a fair number of references left in various places;
> working
Hi, second version of the patch here cleaning up an unnecessary change.
Does not introduce regressions with make check-jit.
Andrea
gcc/jit/ChangeLog
2020-??-?? Andrea Corallo
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
plus add version paragraph.
*
this affects the linux kernel and technically a wrong code bug
so this fix tries to be backportable (fixing all issues with
-fpatchable-function-entry=N,M will likely require new option).
gcc/ChangeLog:
2020-01-16 Szabolcs Nagy
PR target/92424
* config/aarch64/aarch64.c (aarch
identifier is then used publicly, it
will
refer to something else.
Committed to trunk.
Martin also suggested for git gcc-descr --full to also include date (commit
date) in the string, so instead of
r10-5998-g2588197b6c2175d7ef9f05a8636f58dfeab12b1d
print
r10-5998-20200116
If a TARGET_EXPR has poly-int size, the gimplifier would treat it
like a VLA and use gimplify_vla_decl. gimplify_vla_decl in turn
would use an alloca and expect all references to be gimplified
via the DECL_VALUE_EXPR. This caused confusion later in
gimplify_var_or_parm_decl_1 when we (correctly)
On Wed, Jan 15, 2020 at 09:52:57PM +0100, Jakub Jelinek wrote:
> This looks wrong. For one, this function is used for two purposes now and
> you tweak it for one, but more importantly, whether he initial stmt
> you see is a PHI or not can't make a difference, how is that case e.g.
> different from
The separate shrinkwrapping pass may insert stores in the middle
of atomics loops which can cause issues on some implementations.
Avoid this by delaying splitting of atomic patterns until after
prolog/epilog generation.
Bootstrap completed, no test regressions on AArch64.
Andrew, can you verify
Wilco Dijkstra writes:
> The separate shrinkwrapping pass may insert stores in the middle
> of atomics loops which can cause issues on some implementations.
> Avoid this by delaying splitting of atomic patterns until after
> prolog/epilog generation.
>
> Bootstrap completed, no test regressions on
On 16/01/20 07:42 +0100, François Dumont wrote:
On 1/15/20 10:52 PM, Jonathan Wakely wrote:
On 15/01/20 21:48 +, Jonathan Wakely wrote:
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10:53 PM, Jonathan Wakely wrote:
On 13/01/20 22:41 +0100, François Dumont wrote:
For the mul
Hi.
One obvious dump fix that I've just tested.
I'm going to install it.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
gcc/ChangeLog:
2020-01-15 Martin Liska
* value-prof.c (dump_histogram_value): Fix
obvious spacing issue.
---
gcc/
Ping.
On 22/11/2019 11:06, Andrew Stubbs wrote:
This test case causes an ICE (reformatted for email):
void test(int k)
{
unsigned int x = 1;
#pragma acc parallel loop async(x)
for (int i = 0; i < k; i++) { }
}
t.c: In function 'test':
t.c:4:9: error: invalid argumen
On 15/01/2020 16:59, Richard Earnshaw (lists) wrote:
As discussed on IRC, this adds a couple more checks in the customization
setup for git. If the variables user.name and user.email are not set
anywhere in the git config hierarchy, we set some local values. We
always ask about the values we
On 27/11/2019 18:00, Jakub Jelinek wrote:
> On Wed, Nov 27, 2019 at 05:48:21PM +, Joseph Myers wrote:
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
>> __fundam
On Thu, Jan 16, 2020 at 02:42:29PM +, Szabolcs Nagy wrote:
> what is the expected way to fix this issue?
>
> i see hppa-linux-gnu baseline was updated to remove
> the decimal rtti symbols, but other targets were not.
>
> is it better to update the baseline or wait for a
> generic fix?
My pre
Please find attached patch to fix this regression.
OK for master and 9 branch?
Change logs:
gcc/fortran
Mark Eggleston
PR fortran/93236
* resolve.c (resolve_types): Declare boolean recursive and set with the
value of the recursive attribute of namespace proc_name symbol
On Wed, Jan 15, 2020 at 5:56 PM Joseph Myers
wrote:
> A reasonable replacement for those push rules might be command aliases
> (e.g. "git upush " to push the user branch ).
>
And/or git mpush for push origin HEAD:master
Jason
On Jan 16 2020, Richard Earnshaw (lists) wrote:
> diff --git a/contrib/gcc-git-customization.sh
> b/contrib/gcc-git-customization.sh
> index dae2c35bb57..1cde6fd8224 100755
> --- a/contrib/gcc-git-customization.sh
> +++ b/contrib/gcc-git-customization.sh
> @@ -11,9 +11,9 @@ ask () {
> read a
On Wed, Jan 15, 2020 at 10:48:23PM +, Joseph Myers wrote:
> A reasonable replacement for those push rules might be command aliases
> (e.g. "git upush " to push the user branch ).
Would we have then separate aliases for pushing to one vendor branch and
another vendor branch?
Couldn't one alias
Szabolcs Nagy writes:
> this affects the linux kernel and technically a wrong code bug
> so this fix tries to be backportable (fixing all issues with
> -fpatchable-function-entry=N,M will likely require new option).
Even for the backportable version, I think it would be better
not to duplicate so
On 1/13/20 10:05 AM, Kyrill Tkachov wrote:
> Hi Stam,
>
> On 1/10/20 6:45 PM, Stam Markianos-Wright wrote:
>> Hi all,
>>
>> This is a respin of patch:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01448.html
>>
>> which has now been split into two (similar to the Aarch64 version).
>>
>> Th
On 1/13/20 10:43 AM, Kyrill Tkachov wrote:
> Hi Stam,
>
> On 1/10/20 6:47 PM, Stam Markianos-Wright wrote:
>> Hi all,
>>
>> This patch is part 2 of Bfloat16_t enablement in the ARM back-end.
>>
>> This new type is constrained using target hooks TARGET_INVALID_CONVERSION,
>> TARGET_INVALID_UNARY_
On 16/01/20 13:25 +, Jonathan Wakely wrote:
On 16/01/20 07:42 +0100, François Dumont wrote:
On 1/15/20 10:52 PM, Jonathan Wakely wrote:
On 15/01/20 21:48 +, Jonathan Wakely wrote:
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10:53 PM, Jonathan Wakely wrote:
On 13/01/20
Hi Frederik!
On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_property-2.c
I suggest to rename this one to 'acc_get_property-nvptx.c'.
> @@ -0,0 +1,68 @@
> +/* Test the `acc_get_property' and '`acc_get_property_
On 1/9/20 3:54 PM, Richard Sandiford wrote:
> Please update the names of the testsuite files to match the ones
> in the bfloat16_t patch. (Same for the usdot/sudot patch -- sorry
> for forgetting there.)
>
> OK with that change, thanks.
>
Done and committed as r10-6006-gf275d73a57f1e5a07fbd49
On 1/9/20 3:48 PM, Richard Sandiford wrote:
> OK, thanks.
>
Committed as r10-6004-g8c197c851e7528baba7cb837f34c05ba2242f705
Thank you!
Stam
> Richard
>
> Stam Markianos-Wright writes:
>> On 12/30/19 10:21 AM, Richard Sandiford wrote:
>>> Stam Markianos-Wright writes:
On 12/20/19 2:13 P
On 1/10/20 6:48 PM, Stam Markianos-Wright wrote:
>
>
> On 12/18/19 1:25 PM, Stam Markianos-Wright wrote:
>>
>>
>> On 12/13/19 10:22 AM, Stam Markianos-Wright wrote:
>>> Hi all,
>>>
>>> This patch adds the ARMv8.6 Extension ACLE intrinsics for dot product
>>> operations (vector/by element) to th
On 1/8/20 3:18 PM, Stam Markianos-Wright wrote:
>
>
> On 12/10/19 5:03 PM, Kyrill Tkachov wrote:
>> Hi Stam,
>>
>> On 11/15/19 5:26 PM, Stam Markianos-Wright wrote:
>>> Pinging with more correct maintainers this time :)
>>>
>>> Also would need to backport to gcc7,8,9, but need to get this appro
Using git ls-remote, refs for vendor branches can be seen e.g.:
1a7bff0abccf167830c6e0443f3591380b960cb0
refs/vendors/redhat/heads/gcc-9-branch
Using git branch -r and there is no sign of that branch.
What needs to be done to access vendor branches?
--
https://www.codethink.co.uk/privacy.htm
On Thu, Jan 16, 2020 at 04:14:18PM +, Mark Eggleston wrote:
> Using git ls-remote, refs for vendor branches can be seen e.g.:
>
> 1a7bff0abccf167830c6e0443f3591380b960cb0
> refs/vendors/redhat/heads/gcc-9-branch
>
> Using git branch -r and there is no sign of that branch.
>
> What needs to b
On 1/16/20 3:47 PM, Mark Eggleston wrote:
Please find attached patch to fix this regression.
OK for master and 9 branch?
OK for both – thanks!
As note to others:
* Up to Fortran 2008, 'recursive' attribute is required if a proc is
recursively used; since Fortran 2018 recursive is the default
Hi!
The PR87488 changes include:
* lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-urls=never.
Unfortunately, this broke all the compat.exp etc. compatibility testing with
alternate compilers, because those compilers (likely) don't understand this
new option and thus all alt compilati
The initial structure for vendor and personal branches makes use of the
default remote (normally origin) for the upstream repository).
Unfortunately, this causes some confusion, especially for personal
branches because a push will not push to the correct upstream location.
This can be 'fixed' b
Matthew Malcomson writes:
> This patch is necessary for sve-ld1ro intrinsic I posted in
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00466.html .
>
> I had mistakenly thought this option was already enabled upstream.
>
> This provides the option +f64mm, that turns on the 64 bit floating point
>
On 14/01/20 08:56 -0800, Jason Thorpe wrote:
On Jan 14, 2020, at 8:49 AM, Kamil Rytarowski wrote:
On 10.01.2020 17:11, Jonathan Wakely wrote:
On 07/01/20 12:44 -0800, Jason Thorpe wrote:
On Jan 7, 2020, at 7:43 AM, Jonathan Wakely wrote:
For Jason and Krister's benefit, that last comme
On Thu, 2020-01-16 at 18:01 +0100, Jakub Jelinek wrote:
> Hi!
>
> The PR87488 changes include:
> * lib/prune.exp (TEST_ALWAYS_FLAGS): Add -fdiagnostics-
> urls=never.
> Unfortunately, this broke all the compat.exp etc. compatibility
> testing with
> alternate compilers, because those compile
ping
Testing shows the setting of 32:16 for jump alignment has a significant codesize
cost, however it doesn't make a difference in performance. So set jump-align
to 4 to get 1.6% codesize improvement.
OK for commit?
ChangeLog
2019-12-24 Wilco Dijkstra
* config/aarch64/aarch64.c (ne
ping
Enable the most basic form of compare-branch fusion since various CPUs
support it. This has no measurable effect on cores which don't support
branch fusion, but increases fusion opportunities on cores which do.
Bootstrapped on AArch64, OK for commit?
ChangeLog:
2019-12-24 Wilco Dijkstra
> On Jan 16, 2020, at 9:24 AM, Jonathan Wakely wrote:
>
> Thanks to everyone for their feedback. I've pushed the patch to GCC
> master now (I think it's reasonable to consider "doesn't build on
> NetBSD anymore" as a regression and so fixable at this point in GCC's
> development).
>
> Please l
ping
The current pressure scheduler doesn't appear to correctly track register
pressure and avoid creating unnecessary spills when register pressure is high.
As a result disabling the early scheduler improves integer performance
considerably and reduces codesize as a bonus. Since scheduling floa
On 19/12/2019 17:39, Richard Sandiford wrote:
Andrew Stubbs writes:
This patch changes the operand predicates such that vector constants are
permitted during compilation. This prevents ICEs caused by the compiler
trying to emit such instructions without checking.
That sounds like a target-in
I doubt there's many references to https://gcc.gnu.org/cvs.html
left, but just in case - Git is the new SVN is the new CVS. :-)
Gerald
---
htdocs/.htaccess | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/.htaccess b/htdocs/.htaccess
index acaac093..a28af129 100644
---
Hi.
The patch is fixes a regression in libgcrypt package where
we incorrectly forget to stream out a definition of a no-reorder symbol.
It's caused by LTO balanced map reversion, where we do not revert
also best_noreorder_pos.
It's pre-approved patch by Honza and I'm going to install it.
Patch c
> Hi.
>
> The patch is fixes a regression in libgcrypt package where
> we incorrectly forget to stream out a definition of a no-reorder symbol.
> It's caused by LTO balanced map reversion, where we do not revert
> also best_noreorder_pos.
>
> It's pre-approved patch by Honza and I'm going to inst
On 1/16/20 5:01 PM, Jonathan Wakely wrote:
On 16/01/20 13:25 +, Jonathan Wakely wrote:
On 16/01/20 07:42 +0100, François Dumont wrote:
On 1/15/20 10:52 PM, Jonathan Wakely wrote:
On 15/01/20 21:48 +, Jonathan Wakely wrote:
On 14/01/20 22:25 +0100, François Dumont wrote:
On 1/13/20 10
Pushed.
Gerald
---
htdocs/index.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/index.html b/htdocs/index.html
index 89bcfcca..41bcfe18 100644
--- a/htdocs/index.html
+++ b/htdocs/index.html
@@ -32,7 +32,7 @@ of native and cross targets (including GNU/Linux), and
Hello world,
here is my first patch made from the git world. It certainly took
enough time to work out how to to this, but I think I have it
figured out now...
Anyway, the fix is rather straightforward. We cannot have a reference
on a function. If this slipped through on parsing, let's issue th
I recently added an assert to cp-gimplify to catch any
TARGET_EXPR_DIRECT_INIT_P being expanded without a target object, and this
testcase found one. We started out with a TARGET_EXPR around the
CONSTRUCTOR, which would normally mean that the member initializer would be
used to directly initialize
...usually by simplifying and removing the link.
(And add a blank linke between the and tags where
there was none.)
Pushed.
Gerald
---
htdocs/projects/beginner.html | 4 ++--
htdocs/projects/cfo.html | 3 +--
htdocs/projects/cli.html | 3 +--
ht
Hi,
while analyzing code size regression in SPEC2k GCC binary I noticed that we
perform some inline decisions because we think that number of executions are
very high.
In particular there was inline decision inlining gen_rtx_fmt_ee to find_reloads
believing that it is called 4 billion times. This
This patch makes a start on making the branch information from
svn.html available in git.html. The list is copied, some notes added
on devel/, refs/dead/heads/ and refs/vendors/ naming, and inactive
branches from the general section (ones not present in
refs/heads/devel/, automatically moved to re
On Thu, Jan 16, 2020 at 11:22:15PM +, Joseph Myers wrote:
> Committed. I think the main remaining things that need work in our git
> documentation on the website are:
Shouldn't we move some of the branches from Active Development to Inactive?
I mean, some branches haven't been touched since
Thanks, patch committed.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
The following testcase ICEs on powerpc64le-linux. The problem is that
get_vectype_for_scalar_type returns NULL, and while most places in
tree-vect-stmts.c handle that case, this spot doesn't and punts only
if it is non-NULL, but with different number of elts than expected.
Fixed thusly, boot
On Fri, 17 Jan 2020, Jakub Jelinek wrote:
> On Thu, Jan 16, 2020 at 11:22:15PM +, Joseph Myers wrote:
> > Committed. I think the main remaining things that need work in our git
> > documentation on the website are:
>
> Shouldn't we move some of the branches from Active Development to Inacti
On Thu, 2020-01-16 at 23:43 +, Joseph Myers wrote:
> Thanks, patch committed.
Beat me to it :-) I spun it yesterday, but didn't get around to
committing it.
jeff
On Thu, 16 Jan 2020, Alexandre Oliva wrote:
> And here's a followup that fixes a limitation (bug?) in libiberty that
> was hit when I attempted a last-minute simplification in lto-wrapper.
>
> Regstrapped separately on x86_64-linux-gnu. Ok to install?
>
>
> [libiberty] output empty args as a p
On Thu, Jan 16, 2020 at 5:14 AM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > The separate shrinkwrapping pass may insert stores in the middle
> > of atomics loops which can cause issues on some implementations.
> > Avoid this by delaying splitting of atomic patterns until after
> > pro
On Thu, Jan 16, 2020 at 5:51 PM Andrew Pinski wrote:
>
> On Thu, Jan 16, 2020 at 5:14 AM Richard Sandiford
> wrote:
> >
> > Wilco Dijkstra writes:
> > > The separate shrinkwrapping pass may insert stores in the middle
> > > of atomics loops which can cause issues on some implementations.
> > > A
I have a merge commit to devel/c++-coroutines, which is intended to refect
the state at the point of commit to trunk.
However, I cannot push that commit because:
remote: *** This update introduces too many new commits (284), which would
remote: *** trigger as many emails, exceeding the current
On Thu, 2020-01-16 at 09:14 +0100, Jakub Jelinek wrote:
> On Wed, Jan 15, 2020 at 06:56:48PM -0500, David Malcolm wrote:
> > gcc/analyzer/ChangeLog:
> > PR analyzer/93281
> > * region-model.cc
> > (region_model::convert_byte_offset_to_array_index): Convert
> > offset_cst to ssizetyp
On Fri, 17 Jan 2020, Iain Sandoe wrote:
> So I know that the policy is under review (and agree, from my PoV, that
> something that represents these in a similar way to the SVN single mail
> containing all the changes is probably optimum).
>
> However, right now I’m stuck - and really want to get
Here we had been recursing in tsubst_copy_and_build if type2 was a TREE_LIST
because that function knew how to deal with pack expansions, and tsubst
didn't. But tsubst_copy_and_build expects to be dealing with expressions,
so we crash when trying to convert_from_reference a type.
Tested x86_64-pc
On Thu, Jan 16, 2020 at 11:34:43PM +0100, Thomas Koenig wrote:
> diff --git a/gcc/testsuite/gfortran.dg/function_reference_1.f90
> b/gcc/testsuite/gfortran.dg/function_reference_1.f90
> new file mode 100644
> index 000..78c92a6f20d
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/function
After the recent optimization that went in despite in stage 4 I wonder
why I never got any feedback for this one.
https://gcc.gnu.org/ml/libstdc++/2019-05/msg00166.html
I forgot to note that this is the simplest reply to an old Paolo's
request to recycle std::deque's "nodes". And this one is a
On Thu, 16 Jan 2020, David Malcolm wrote:
> On Thu, 2020-01-16 at 09:14 +0100, Jakub Jelinek wrote:
> > On Wed, Jan 15, 2020 at 06:56:48PM -0500, David Malcolm wrote:
> > > gcc/analyzer/ChangeLog:
> > > PR analyzer/93281
> > > * region-model.cc
> > > (region_model::convert_byte_offset_to_arr
On Fri, 17 Jan 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on powerpc64le-linux. The problem is that
> get_vectype_for_scalar_type returns NULL, and while most places in
> tree-vect-stmts.c handle that case, this spot doesn't and punts only
> if it is non-NULL, but with diff
Really old git versions (like 1.6.0) require
"git log --pretty=tformat:%p:%t:%H"
or else we see:
Updating GIT tree
Current branch master is up to date.
fatal: invalid --pretty format: %p:%t:%H
Adjusting file timestamps
Touching gcc/config.in...
Touching gcc/config/arm/arm-tune.md...
...and an emp
Hello,
> You should include Joel on such questions as the expert on the hooks.
>
> I don't know whether there's something to put in the commit message to say
> "allow this merge of more than 100 commits". I don't think a squashed
> merge is the right workaround, supposing you do want the git a
81 matches
Mail list logo
