On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
>
> On 03/12/19 09:11 +0100, Christophe Lyon wrote:
> >On Mon, 16 Sep 2019 at 04:34, Tom Honermann wrote:
> >>
> >> A revised patch is attached that modifies the tests for deleted ostream
> >> inserters to require C++2a. This is required by the
On Thu, Dec 05, 2019 at 09:56:46AM +0800, Hongtao Liu wrote:
> --- a/gcc/config/i386/i386-expand.c
> +++ b/gcc/config/i386/i386-expand.c
> + /* Using vector move with mask register. */
> + cmp = force_reg (cmpmode, cmp);
> + /* Optimize for mask zero. */
> + op_true =
> +
Hi!
In the following testcase, sym is the current function, we have created
earlier .__result as the PARM_DECL containing pointer to the length to be
returned and ..__result is a local VAR_DECL which contains the string length
inside of the function and is at the end copied to *.__result.
The rea
On 12/5/19 9:10 AM, Jakub Jelinek wrote:
In the following testcase, sym is the current function, we have created
earlier .__result as the PARM_DECL containing pointer to the length to be
returned and ..__result is a local VAR_DECL which contains the string length
inside of the function and is at
Hi!
The huge LTO testcase in the PR ICEs, because in a function
where optimize_function_for_speed_p (cfun) and when targetting
-march=i686 optab_handler (movstrict_optab, E_QImode) is
CODE_FOR_movstrictqi, but when the *movstrictqi instruction is being matched
during vregs pass, the condition:
!TA
On Wed, 4 Dec 2019, Jakub Jelinek wrote:
> On Wed, Dec 04, 2019 at 03:20:59PM +0100, Richard Biener wrote:
> > Currently IL verification errors trigger "confused by earlier errors"
> > messages with a release compiler but compiling with -fchecking.
> > That is because those use error() before inte
On Thu, Dec 5, 2019 at 9:21 AM Jakub Jelinek wrote:
>
> Hi!
>
> The huge LTO testcase in the PR ICEs, because in a function
> where optimize_function_for_speed_p (cfun) and when targetting
> -march=i686 optab_handler (movstrict_optab, E_QImode) is
> CODE_FOR_movstrictqi, but when the *movstrictqi
The comment in the patch give the reason, why that line is missing with
AMDGCN (and nvptx). – For the extra line of nvptx, see referenced PR
(last comment).
Applied as Rev. 278986 after testing w/o offloading configured and with
nvptx + amdgcn offloading.
Cheers,
Tobias
And with attached patch …
On 12/5/19 9:39 AM, Tobias Burnus wrote:
The comment in the patch give the reason, why that line is missing
with AMDGCN (and nvptx). – For the extra line of nvptx, see referenced
PR (last comment).
Applied as Rev. 278986 after testing w/o offloading configured and
w
Segher Boessenkool wrote:
> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>> On 12/4/19 2:50 PM, Segher Boessenkool wrote:
>>> It would be nice to keep *some* dfp test(s) to make sure we don't ICE.
>>> If we disabled all such tests already, like with this patch, we wouldn't
>>> h
On 12/4/19 6:27 PM, Jeff Law wrote:
On 12/4/19 8:24 AM, Wilco Dijkstra wrote:
Hi Jeff,
I've noticed quite significant package failures caused by the revision.
Would you please consider documenting this change in porting_to.html
(and in changes.html) for GCC 10 release?
I'm not in the office
The following patch fixes invariant vector construction in vector CTOR
optimization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2019-12-05 Richard Biener
PR tree-optimization/92803
* tree-ssa-forwprop.c (simplify_vector_constructor): Fix
On 12/5/19 10:16 AM, Martin Liška wrote:
I would like to mention here that key work is to report and explain that
to upstream. Only that will help for the future to reduce number of
packages
that will need the -fcommon option. That's the biggest effort in my
opinion.
For this, it would help t
On 05/12/2019 07:05, Harwath, Frederik wrote:
Hi,
the inline assembly "p" modifier ("An operand that is a valid memory address is
allowed",
cf.
https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-Constraints)
is not supported on AMD GCN. This causes an ICE during the compilation o
On Fri, 29 Nov 2019 at 15:41, Richard Biener wrote:
>
> On Fri, Nov 22, 2019 at 12:40 PM Prathamesh Kulkarni
> wrote:
> >
> > On Wed, 20 Nov 2019 at 16:54, Richard Biener wrote:
> > >
> > > On Wed, 20 Nov 2019, Richard Sandiford wrote:
> > >
> > > > Hi,
> > > >
> > > > Thanks for doing this. Ad
Hi,
this patch fixes ICE in g++.dg/torture/pr59226.C which was triggered by
new comdat_local sanity check. What happens here is that function gets
inlined into its own thunk which makes it !comdat_local_p but the updating
code does not notice since thunk calls comdat local alias of the function
it
Hi,
this patch makes tree-ssa-threadupdate to not leave basic blocks with
undefined counts in the program.
create_block_for_threading sets counts as follows:
/* Zero out the profile, since the block is unreachable for now. */
rd->dup_blocks[count]->count = profile_count::uninitialized ();
Here's a revised version based on the feedback so far. Changes in v2:
- Don't move instructions that set or use allocatable hard registers.
- Check legitimate_combined_insn
- Check cannot_copy_insn_p when keeping the original insn in parallel
- Disable the pass if HAVE_cc0
I compared v1 and v2 in
ping?
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01667.html
Kyrill approved the previous version modulo a typo fix, but Richard
wanted a better name for a variable.
Is that version OK?
Thanks,
Christophe
On Tue, 26 Nov 2019 at 16:29, Christophe Lyon
wrote:
>
> ping?
>
> On Mon, 18 Nov 2019
This PR shows that we weren't checking for bitwise-identical values
when trying to encode a VECTOR_CST, so -0.0 was treated the same as
0.0 for -fno-signed-zeros. The patch adds a new OEP flag to select
that behaviour.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2
Hi,
On Tue, 3 Dec 2019 at 15:46, Richard Biener wrote:
>
>
> The PR shows I added the bail-out prematurely.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2019-12-03 Richard Biener
>
> PR tree-optimization/92758
> * tree-ssa-forwprop.c (simp
Hi all,
This patch implements the .cfi_negate_ra_state to be consistent with
LLVM (https://reviews.llvm.org/D50136). The relevant DWARF code
DW_CFA_AARCH64_negate_ra_state
is multiplexed on top of DW_CFA_GNU_window_save, as per
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00753.html
I believe
Sorry, wrong list address from my side, please ignore.
Kyrill
On 12/5/19 10:59 AM, Kyrill Tkachov wrote:
Hi all,
This patch implements the .cfi_negate_ra_state to be consistent with
LLVM (https://reviews.llvm.org/D50136). The relevant DWARF code
DW_CFA_AARCH64_negate_ra_state
is multiplexed on
The following fixes a typo in the vec_perm to bit_insert pattern
and adjusts forwprop heuristic to make it trigger. This improves
code-gen for the testcase back to a simple movhpd like we emitted
with GCC 9.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2019-12-05 Richard
MSP430 RTL patterns for conditional branch instructions allow the post
increment addressing mode to be used for the "dest" operand of CMP instructions
used in these patterns.
This is currently causing trunk to FTB for msp430-elf since these instructions
are being generated using an autoinc for the
On 05/12/19 09:00 +0100, Christophe Lyon wrote:
On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
On 03/12/19 09:11 +0100, Christophe Lyon wrote:
>On Mon, 16 Sep 2019 at 04:34, Tom Honermann wrote:
>>
>> A revised patch is attached that modifies the tests for deleted ostream
>> inserters to
On Fri, Nov 29, 2019 at 01:03:13PM +0100, Tobias Burnus wrote:
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -60,7 +60,8 @@ gfc_omp_is_allocatable_or_ptr (const_tree decl)
>
> /* True if the argument is an optional argument; except that false is also
> returned f
On Thu, 5 Dec 2019, Christophe Lyon wrote:
> Hi,
>
>
> On Tue, 3 Dec 2019 at 15:46, Richard Biener wrote:
> >
> >
> > The PR shows I added the bail-out prematurely.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
> >
> > Richard.
> >
> > 2019-12-03 Richard Biener
> >
>
On Wed, Dec 4, 2019 at 10:52 PM Jan Hubicka wrote:
>
> Hi,
> with recent fixes to proile updating I noticed that we get more regressions
> compared to gcc 9 at Firefox testing. This is because Firefox train run is
> not covering all the benchmarks and gcc 9, thanks to updating bugs sometimes
> opt
Hi.
One obvious about superfluous void_type_node in __gcov_exit
declaration.
I'm going to install the patch.
Martin
gcc/ChangeLog:
2019-12-05 Martin Liska
PR gcov-profile/92817
* coverage.c (build_gcov_exit_decl): Remove superfluous
void_type_node.
---
gcc/coverage
On 12/5/19 1:30 PM, Richard Biener wrote:
I wonder if the behavior shouldn't be the default? The only thing we lose
is failing to notice really cold calls (error paths) in programs?
I would also consider enabling that by default.
I'm sending a language correction for the option documentation:
On Thu, Dec 5, 2019 at 11:26 AM Richard Sandiford
wrote:
>
> This PR shows that we weren't checking for bitwise-identical values
> when trying to encode a VECTOR_CST, so -0.0 was treated the same as
> 0.0 for -fno-signed-zeros. The patch adds a new OEP flag to select
> that behaviour.
>
> Tested
On Thu, Dec 5, 2019 at 1:41 PM Martin Liška wrote:
>
> On 12/5/19 1:30 PM, Richard Biener wrote:
> > I wonder if the behavior shouldn't be the default? The only thing we lose
> > is failing to notice really cold calls (error paths) in programs?
>
> I would also consider enabling that by default.
* include/bits/stl_algobase.h (lexicographical_compare_three_way):
Define for C++20.
* testsuite/25_algorithms/lexicographical_compare_three_way/1.cc: New
test.
* testsuite/25_algorithms/lexicographical_compare_three_way/
constexpr.cc: New test.
Tes
On Thu, 5 Dec 2019, Prathamesh Kulkarni wrote:
> On Fri, 29 Nov 2019 at 15:41, Richard Biener
> wrote:
> >
> > On Fri, Nov 22, 2019 at 12:40 PM Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 20 Nov 2019 at 16:54, Richard Biener wrote:
> > > >
> > > > On Wed, 20 Nov 2019, Richard Sandiford
Hi.
As mentioned in the PR, there are classes in cgraph.h that are
not PODs and are initialized with ggc_alloc_cleared. So that I'm suggesting
to use proper constructors. I added ggc_new function that can be used
at different locations as well.
I'm attaching optimized dump file with how ctor exp
On Thu, Dec 5, 2019 at 1:50 PM Martin Liška wrote:
>
> Hi.
>
> As mentioned in the PR, there are classes in cgraph.h that are
> not PODs and are initialized with ggc_alloc_cleared. So that I'm suggesting
> to use proper constructors. I added ggc_new function that can be used
> at different locatio
> Hi.
>
> As mentioned in the PR, there are classes in cgraph.h that are
> not PODs and are initialized with ggc_alloc_cleared. So that I'm suggesting
> to use proper constructors. I added ggc_new function that can be used
> at different locations as well.
>
> I'm attaching optimized dump file wi
On Wed, 4 Dec 2019, Jakub Jelinek wrote:
--- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100
+++ gcc/match.pd2019-12-03 13:36:01.084435697 +0100
@@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY
/* A - (A +- B) -> -+ B */
/* A +- (B -+ A) -> +- B */
(si
On Thu, 5 Dec 2019 at 12:59, Richard Biener wrote:
>
> On Thu, 5 Dec 2019, Christophe Lyon wrote:
>
> > Hi,
> >
> >
> > On Tue, 3 Dec 2019 at 15:46, Richard Biener wrote:
> > >
> > >
> > > The PR shows I added the bail-out prematurely.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-g
On 12/5/19 1:59 PM, Richard Biener wrote:
Isn't there ggc_alloc for this? Also ggc_alloc_no_dtor in case you
want to handle finalization yourself.
No, if I see correctly it only calls Dtor:
template
inline T *
ggc_alloc (ALONE_CXX_MEM_STAT_INFO)
{
if (need_finalization_p ())
return sta
After the PR92818 commit there's one function in the testcase below
remaining not using bit-inserts. The following fixes this.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2019-12-05 Richard Biener
PR tree-optimization/92819
* match.pd (VEC_PERM_
Hi,
Add entries for the default change in changes.html and porting_to.html.
Passes the W3 validator.
Cheers,
Wilco
---
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index
e02966460450b7aad884b2d45190b9ecd8c7a5d8..304e1e8ccd38795104156e86b92062696fa5aa8b
100644
--- a/htd
Hi,
I have updated the documentation patch here and added relevant maintainers
so hopefully this can go in soon:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00311.html
I moved the paragraph in changes.html to the C section like you suggested. Would
it make sense to link to the porting_to entry
The change
2019-12-04 David Edelsohn
* cp-gimplify.c: Include tm_p.h.
appears to have broken the build for SPARC. I see
In file included from ./tm_p.h:4:0,
from
/scratch/jmyers/glibc-bot/src/gcc/gcc/cp/cp-gimplify.c:38:
/scratch/jmyers/glibc-bot/src/gcc/gcc/config/
On 21/11/19 19:56 -0500, JeanHeyd Meneide wrote:
Thank you for the review!
- I moved the concepts back into the class and changed them to
template aliases because class local concepts aren't a thing that
works.
+ They are not inline constexpr bools because that ICE's GCC
pretty hard, as you
On 05/12/19 13:49 +, Jonathan Wakely wrote:
This also causes two new FAILs in 23_containers/span/lwg3255.cc but
that turns out to be a bug in the test, which fails now t hat you've
fixed a bug in span. I'll fix that as well.
Here's that fix for the buggy test.
Tested powerpc64le-linux, com
On December 5, 2019 2:03:58 PM GMT+01:00, "Martin Liška" wrote:
>On 12/5/19 1:59 PM, Richard Biener wrote:
>> Isn't there ggc_alloc for this? Also ggc_alloc_no_dtor in
>case you
>> want to handle finalization yourself.
>
>No, if I see correctly it only calls Dtor:
But its odd to handle finaliza
> On December 5, 2019 2:03:58 PM GMT+01:00, "Martin Liška"
> wrote:
> >On 12/5/19 1:59 PM, Richard Biener wrote:
> >> Isn't there ggc_alloc for this? Also ggc_alloc_no_dtor in
> >case you
> >> want to handle finalization yourself.
> >
> >No, if I see correctly it only calls Dtor:
>
> But its o
On 12/5/19 2:53 PM, Richard Biener wrote:
On December 5, 2019 2:03:58 PM GMT+01:00, "Martin Liška" wrote:
On 12/5/19 1:59 PM, Richard Biener wrote:
Isn't there ggc_alloc for this? Also ggc_alloc_no_dtor in
case you
want to handle finalization yourself.
No, if I see correctly it only call
Sorry. I had to add tm_p.h because Jakub's earlier patch to add
output.h to cp-gimplify.c broke AIX.
We certainly can add memmodel.h to cp-gimplify.c.
Thanks, David
On Thu, Dec 5, 2019 at 8:32 AM Joseph Myers wrote:
>
> The change
>
> 2019-12-04 David Edelsohn
>
> * cp-gimplify.c: In
Hi
While looking at vect_model_reduction_cost function, it seems Richard's
change in a recent commit r278611 missed an update to the following if
condition. Since the check for EXTRACT_LAST_REDUCTION is now split
above, the same check in the if condition will never be true.
gcc/ChangeLog
2019
On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> output.h to cp-gimplify.c broke AIX.
>
> We certainly can add memmodel.h to cp-gimplify.c.
I'd say so. E.g. c-family/c-cppbuiltin.c which also includes output.h
inc
> "Martin" == Martin Liška writes:
Martin> + /* Default constructor. */
Martin> + symtab_node (symtab_type t)
FWIW, in gdb, we normally make single-argument constructors "explicit".
This helps avoid surprises with implicit conversions.
Tom
Done.
r279003.
- David
On Thu, Dec 5, 2019 at 9:33 AM Jakub Jelinek wrote:
>
> On Thu, Dec 05, 2019 at 09:25:40AM -0500, David Edelsohn wrote:
> > Sorry. I had to add tm_p.h because Jakub's earlier patch to add
> > output.h to cp-gimplify.c broke AIX.
> >
> > We certainly can add memmodel.h to
On December 5, 2019 3:09:40 PM GMT+01:00, "Martin Liška" wrote:
>On 12/5/19 2:53 PM, Richard Biener wrote:
>> On December 5, 2019 2:03:58 PM GMT+01:00, "Martin Liška"
> wrote:
>>> On 12/5/19 1:59 PM, Richard Biener wrote:
Isn't there ggc_alloc for this? Also ggc_alloc_no_dtor in
>>> case yo
On 12/5/19 2:03 PM, Jan Hubicka wrote:
Hi.
As mentioned in the PR, there are classes in cgraph.h that are
not PODs and are initialized with ggc_alloc_cleared. So that I'm suggesting
to use proper constructors. I added ggc_new function that can be used
at different locations as well.
I'm attachi
On December 5, 2019 3:35:17 PM GMT+01:00, Tom Tromey wrote:
>> "Martin" == Martin Liška writes:
>
>Martin> + /* Default constructor. */
>Martin> + symtab_node (symtab_type t)
>
>FWIW, in gdb, we normally make single-argument constructors "explicit".
>This helps avoid surprises with implici
On Wed, Nov 20, 2019 at 02:06:18PM +0100, Tobias Burnus wrote:
> ** Included in the attached patch are the following previously posted
> patches: [1] the trivial libgomp/oacc-mem.c change, [2] only the remaining
> single-line change in omp-low.c, [3] the trans-openmp.c changes (which had
> to be mo
On December 5, 2019 2:03:24 PM GMT+01:00, Marc Glisse
wrote:
>On Wed, 4 Dec 2019, Jakub Jelinek wrote:
>
>> --- gcc/match.pd.jj 2019-12-03 10:20:00.244913801 +0100
>> +++ gcc/match.pd 2019-12-03 13:36:01.084435697 +0100
>> @@ -2159,20 +2159,26 @@ (define_operator_list COND_TERNARY
>> /* A
On 12/5/19 4:12 PM, Richard Biener wrote:
Isn't there std::default_constructible? Also after your patch it's far from
obvious which api to use.
Will it work with:
struct Foo
{
Foo(int) {}
};
...
if (std::default_constructible ())
ptr = new ptr T ();
?
Wouldn't we end up with a compila
Hi Jakub,
thanks for the review – committed as Rev. 279004.
On 12/5/19 12:46 PM, Jakub Jelinek wrote:
On Fri, Nov 29, 2019 at 01:03:13PM +0100, Tobias Burnus wrote:
--- a/gcc/fortran/trans-openmp.c
+ && TREE_TYPE (decl) != pvoid_type_node
Is it always pvoid_type_node, or could it be s
On 12/5/19 4:17 PM, Martin Liška wrote:
On 12/5/19 4:12 PM, Richard Biener wrote:
Isn't there std::default_constructible? Also after your patch it's far from
obvious which api to use.
Will it work with:
struct Foo
{
Foo(int) {}
};
...
if (std::default_constructible ())
ptr = new ptr
Hi Richard,
On 29/11/2019 13:00, Richard Sandiford wrote:
> Hi Dennis,
>
> Sorry for the slow response.
>
> Dennis Zhang writes:
>> 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
On 12/5/19 2:16 AM, Martin Liška wrote:
>
>>
>> Of the ~450 packages affected I'd estimate that even with the opt-out
>> mechanism we're still going to have to fix ~100 packages immediately
>> because they don't honor the flags injection mechanisms which the
>> opt-out approach relies upon.
>
> F
On 12/5/19 4:32 AM, Jozef Lawrynowicz wrote:
> MSP430 RTL patterns for conditional branch instructions allow the post
> increment addressing mode to be used for the "dest" operand of CMP
> instructions
> used in these patterns.
>
> This is currently causing trunk to FTB for msp430-elf since these
Hi!
;-P Jakub, thanks for furnishing me a fit occasion here:
On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote:
> [...] much more indented though, but you could
> use a temporary, like:
> tree nullarg = null_pointer_node;
I object to cluttering the code by introducing tempora
On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote:
> Hi!
>
> ;-P Jakub, thanks for furnishing me a fit occasion here:
>
> On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote:
> > [...] much more indented though, but you could
> > use a temporary, like:
> > tree nulla
On 12/5/19 2:44 AM, Iain Sandoe wrote:
> Segher Boessenkool wrote:
>> On Wed, Dec 04, 2019 at 03:53:30PM -0600, Peter Bergner wrote:
>>> Sure, I can add a test in gcc.target/powerpc/ that uses both a builtin
>>> and an overloaded builtin to make sure we don't ICE when DFP is disabled.
>>
>> Great,
On Thu, 5 Dec 2019 at 12:43, Jonathan Wakely wrote:
>
> On 05/12/19 09:00 +0100, Christophe Lyon wrote:
> >On Tue, 3 Dec 2019 at 10:16, Jonathan Wakely wrote:
> >>
> >> On 03/12/19 09:11 +0100, Christophe Lyon wrote:
> >> >On Mon, 16 Sep 2019 at 04:34, Tom Honermann wrote:
> >> >>
> >> >> A revi
On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner
> stated that even he is not using a 80 x 24 terminal anymore, and that
> should tell us something. ;-)
>
> So, I formally propose that we lift this characters per line restricti
> On Dec 5, 2019, at 11:17 AM, Joseph Myers wrote:
>
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>
>> In the relevant session at the GNU Tools Cauldron 2019, Michael Meissner
>> stated that even he is not using a 80 x 24 terminal anymore, and that
>> should tell us something. ;-)
>>
>> So,
On 12/5/19 8:13 AM, Martin Liška wrote:
On 12/5/19 2:03 PM, Jan Hubicka wrote:
Hi.
As mentioned in the PR, there are classes in cgraph.h that are
not PODs and are initialized with ggc_alloc_cleared. So that I'm
suggesting
to use proper constructors. I added ggc_new function that can be used
a
Hi,
On Thu, 5 Dec 2019, Richard Biener wrote:
> On December 5, 2019 3:35:17 PM GMT+01:00, Tom Tromey wrote:
> >> "Martin" == Martin Liška writes:
> >
> >Martin> + /* Default constructor. */
> >Martin> + symtab_node (symtab_type t)
> >
> >FWIW, in gdb, we normally make single-argument con
On 12/5/19 9:24 AM, Paul Koning wrote:
>
>
>> On Dec 5, 2019, at 11:17 AM, Joseph Myers
>> wrote:
>>
>> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>>
>>> In the relevant session at the GNU Tools Cauldron 2019, Michael
>>> Meissner stated that even he is not using a 80 x 24 terminal
>>> anymore
Hello,
(oh a flame bait :) )
On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> So, I formally propose that we lift this characters per line restriction
> from IBM punch card (80) to mainframe line printer (132).
>
> Tasks:
>
> - Discussion.
I object to cluttering code in excuse for using sensibl
On 12/5/19 6:18 AM, Wilco Dijkstra wrote:
> Hi,
>
> I have updated the documentation patch here and added relevant maintainers
> so hopefully this can go in soon:
> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00311.html
>
> I moved the paragraph in changes.html to the C section like you sugges
* Paul Koning:
> That's certainly a general rule. There is a reason why books aren't
> wide, and why newspapers have columns. The eye can't deal well with
> long lines. So while 132 column lines are certainly possible with
> modern computers, it doesn't mean they are desirable.
If the line sta
On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote:
>
> Hello,
>
> (oh a flame bait :) )
>
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
>
> > So, I formally propose that we lift this characters per line restriction
> > from IBM punch card (80) to mainframe line printer (132).
> >
> > Tasks:
> >
> >
Sudakshina Das writes:
> Hi
>
> While looking at vect_model_reduction_cost function, it seems Richard's
> change in a recent commit r278611 missed an update to the following if
> condition. Since the check for EXTRACT_LAST_REDUCTION is now split
> above, the same check in the if condition will
On Dec 5 2019, Michael Matz wrote:
(oh a flame bait :) )
Quite. I shall try not to make it too much worse, but there's another point
that needs mentioning.
I find long names hard to read, with either short or long lines, especially
when combined with variants like negotiate_twisty_little_pas
On Thu, 5 Dec 2019 08:41:48 -0700
Jeff Law wrote:
> On 12/5/19 4:32 AM, Jozef Lawrynowicz wrote:
> > MSP430 RTL patterns for conditional branch instructions allow the post
> > increment addressing mode to be used for the "dest" operand of CMP
> > instructions
> > used in these patterns.
> >
> >
This libgo patch arranges for go-context.S to always be marked as
using a non-executable stack. This is not required for all targets,
but should do little harm. Bootstrapped on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On 05/12/2019 16:17, Joseph Myers wrote:
Longer lines mean less space for multiple terminal / editor windows
side-by-side to look at different pieces of code. I don't think that's an
improvement.
Here's a data-point
My 1920 pixel-wide screen, in the default font, allows 239 columns; not
Hi Richard
On 05/12/2019 17:04, Richard Sandiford wrote:
> Sudakshina Das writes:
>> Hi
>>
>> While looking at vect_model_reduction_cost function, it seems Richard's
>> change in a recent commit r278611 missed an update to the following if
>> condition. Since the check for EXTRACT_LAST_REDUCTION
On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 16:44, Michael Matz wrote:
> >
> > Hello,
> >
> > (oh a flame bait :) )
> >
> > On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> >
> > > So, I formally propose that we lift this characters per line restriction
> >
Richard Smith proposed adding a synonym for __is_same_as, to accomodate the
convention of exposing std::SOME_TRAIT::value as __SOME_TRAIT(A, B).
So add that alias, and also adjust the C++ printer. I didn't bother changing
the RID_ identifier.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
On 12/5/19, Andrew Stubbs wrote:
> On 05/12/2019 16:17, Joseph Myers wrote:
>> Longer lines mean less space for multiple terminal / editor windows
>> side-by-side to look at different pieces of code. I don't think that's
>> an
>> improvement.
>
> Here's a data-point
>
> My 1920 pixel-wide sc
Ping.
Richard Sandiford writes:
> This patch makes the C++ frontend work with the verify_type_context hook
> [https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00942.html]. We need
> some new type contexts for features that don't exist in C, but otherwise
> the patch is very similar to the C one.
>
My IBM Selectric golfball electronic printer only does 90 characters on A4 in
portrait mode………(at 10 cps)
(as for my all electric TELEX Teleprinter machine !)
Is this debate for real ?! - or is this a Christmas spoof ?
External observer…..keep up the great work. :)
(while I punch out a few
On Thu, Dec 05, 2019 at 06:21:14PM +, Richard Sandiford wrote:
> Ping.
>
> Richard Sandiford writes:
> > This patch makes the C++ frontend work with the verify_type_context hook
> > [https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00942.html]. We need
> > some new type contexts for features th
On 12/4/19 5:43 PM, Marek Polacek wrote:
@@ -,12 +2243,24 @@ reduced_constant_expression_p (tree t)
return false;
if (field)
{
+ retry:
if (idx != field)
- return false;
+ {
+ /* Empty class fi
On 12/5/19 8:46 AM, Thomas Schwinge wrote:
Hi!
;-P Jakub, thanks for furnishing me a fit occasion here:
On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote:
[...] much more indented though, but you could
use a temporary, like:
tree nullarg = null_pointer_node;
I object to
All,
As a certified Old Guy (coding in FORTRAN since 1967) my default mode is to
stop at 72 characters. It would be nice to push the max out a bit, but I’ll
most likely keep my lines (and my function and variable names!) short. As
always, brevity is the soul of wit.
And yes, please keep up t
On Thu, Dec 05, 2019 at 01:37:45PM -0500, Jason Merrill wrote:
> On 12/4/19 5:43 PM, Marek Polacek wrote:
> > @@ -,12 +2243,24 @@ reduced_constant_expression_p (tree t)
> > return false;
> > if (field)
> > {
> > + retry:
> > if (idx != field)
> > -
On December 5, 2019 5:31:59 PM GMT+01:00, Michael Matz wrote:
>Hi,
>
>On Thu, 5 Dec 2019, Richard Biener wrote:
>
>> On December 5, 2019 3:35:17 PM GMT+01:00, Tom Tromey
>wrote:
>> >> "Martin" == Martin Liška writes:
>> >
>> >Martin> + /* Default constructor. */
>> >Martin> + symtab_node
On 12/5/19 1:11 PM, Marek Polacek wrote:
Richard Smith proposed adding a synonym for __is_same_as, to accomodate the
convention of exposing std::SOME_TRAIT::value as __SOME_TRAIT(A, B).
So add that alias, and also adjust the C++ printer. I didn't bother changing
the RID_ identifier.
Bootstrapp
On 12/5/19 2:28 PM, Marek Polacek wrote:
On Thu, Dec 05, 2019 at 01:37:45PM -0500, Jason Merrill wrote:
On 12/4/19 5:43 PM, Marek Polacek wrote:
@@ -,12 +2243,24 @@ reduced_constant_expression_p (tree t)
return false;
if (field)
{
+ retry:
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to branch "dmalcolm/analyzer" on the GCC git mirror.
gcc/ChangeLog:
* analyzer/sm-signal.cc
(signal_delivery_edge_info_t::add_events_to_path): Add FINAL
OVERRIDE to vfunc.
---
gcc/analyzer/sm-signal.cc
Hi!
On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> C++17 introduces a nice feature, with rationale similar to declaring
> variables in a for-loop init-statement:
>
> if (auto var = foo(); bar(var))
Similar to GNU C statement expressions, which are *also* only a good
idea to u
1 - 100 of 130 matches
Mail list logo
