ild these
targets), and we will delete the SPE support during GCC 8 development.
Works for me. There's one old BZ I'm aware of that we would want to
retarget at ARM/AARCH64 since it reproduces there too. But that's easy
enough to do.
jeff
tion by hackers). It's currently most useful for glibc
which has policies WRT unencrypted function pointers, but could well be
used by other projects.
We could also build checkers for resource allocation/deallocation,
locking/unlocking, etc.
I think those checkers are naturally plugins.
jeff
On 03/17/2017 12:47 PM, Bernd Schmidt wrote:
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
I'm provisioning an aarch64 system now.
jeff
?
I can though I don't want to duplicate work since Jeff was going to
provision an aarch64 system. My automated testing is approximately
every hour or so; these commits were within an hour window even.
I did not look into the revisions when I write the email but I suspect
r246227 did NOT cau
e_nondebug_insn
call appears to solve the problem. I will have to do a bootstrap and
make check from scratch to verify. I also noticed that there is a
redundant i1 check in the patch which should be fixed also.
Thanks Jim. My 246226 was just spinning up.
Consider your fixes pre-approved.
jeff
96565).
Seems this is only triggered for arm-netbsdelf, it's running fine for
many/all? other targets in config_list.mk .
FYI, David Malcolm fixed this a week or two ago.
jeff
tapes
containing gcc 0.9 beta? I would really love to find one if so. Maybe
stuffed off in a broom closet somewhere? I know it's not terribly
useful these days... but I find vintage computer stuff fascinating.
ftp://gcc.gnu.org/pub/gcc/old-releases/gcc-1/
Has a gcc-0.9 release in it.
jeff
ariable.
Then, ptr is spilled into pseudo reg 24 which is used as base reg, which
seems to prevent the autoincdec pass to use a4.
Any idea how I could optimize such a code ?
You'd have to dig into the auto-inc pass to see why it doesn't see the
autoincrement opportunity. This looks like a pre-inc to me.
Jeff
ll.) With warn_untested_result
even non-allocation functions (such as fopen) could be decorated,
so that seems like a better approach.
Can you please open an enhancement request in Bugzilla?
Yea, I like it as well.
jeff
esults are
comparable to mine. Interestingly enough the 70-80% coverage we see
for GCC is a "sweet spot" in that several of the ancillary tools I
tested were in the same overall range.
jeff
isting PPC port, I think this
will all be formality.
Andrew -- the ia16 work isn't forgotten either. I'm just starting to
dig into the gcc-8 stuff and the ia16 port is in that list.
jeff
gcc/i386.o differs
gcc/dwarf2out.o differs
I see a similar failure on ia64.
My x86_64 builds ran fine.
jeff
milar failure. Could
easy be the checking flags. I'll do some bisecting here.
jeff
On 05/04/2017 08:31 AM, Jeff Law wrote:
On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote:
Fedora 26 x86_64
r247595
~/src/gcc_current/configure --prefix=/usr/local/gcc_current
--enable-static --enable-checking=no --enable-languages=c,c++,lto
--enable-plugin --disable-multilib
And that may be the
de to allow
other ports to add target_clone support include:Please consider this class of changes pre-approved. There's no reason
to wait for review as you move this stuff around and generalize it slightly.
jeff
erformance difference is measurable. More likely than not
it's just habit.
I tend to perfer the second as it makes the code easier (IMHO) to read.
jeff
imeframe). I'd naively
assumed it would already work in the way you suggested.
Likewise.
jeff
is probably close to if not past that same point as well.
Jeff
Implementation may be made more
difficult by insns that generate > 1 instruction.
Jeff
On 05/16/2017 12:37 PM, Will Hawkins wrote:
> On Tue, May 16, 2017 at 2:33 PM, Jeff Law wrote:
>> On 05/16/2017 12:24 PM, Will Hawkins wrote:
>>> Hello everyone!
>>>
>>> I apologize if this is not the right venue to ask this question and/or
>>> thi
up. Note that I ack'd a patch from Andi that should help here. I
haven't tested it on tor/torsion under typical loads there, but I'd
expect it to really help on -j loads folks typically use on their laptops.
jeff
I generally do "make check -k -j60" on two different trees and compare
Make sure you've got Andi's patch installed and report back. It's
supposed to help with smaller -j loads, but it's unclear if it's enough
to address the problems with higher loads like you're using.
jeff
e, you'll then want to walk each insn within
the bb. So something like this
basic_block bb
FOR_EACH_BB (bb)
{
rtx_insn *insn;
FOR_BB_INSNS (bb, insn)
{
/* Do something with INSN. */
}
}
Note that if you're running too late the CFG may have been released, in
which case this code wouldn't do anything.
jeff
nflicts (the ChangeLogs are the most
common source of conflicts) and you should be good to go.
jeff
On 05/18/2017 01:42 PM, Martin Sebor wrote:
> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote:
>> On 2017.05.18 at 12:41 -0600, Martin Sebor wrote:
>>> On 05/18/2017 11:59 AM, Jeff Law wrote:
>>>> On 05/18/2017 11:41 AM, Martin Sebor wrote:
>>>>> I
On 05/18/2017 02:06 PM, Markus Trippelsdorf wrote:
> On 2017.05.18 at 13:42 -0600, Martin Sebor wrote:
>> On 05/18/2017 12:55 PM, Markus Trippelsdorf wrote:
>>> On 2017.05.18 at 12:41 -0600, Martin Sebor wrote:
>>>> On 05/18/2017 11:59 AM, Jeff Law wrote:
>>>
On 05/17/2017 08:22 PM, Will Hawkins wrote:
> On Wed, May 17, 2017 at 2:59 PM, Will Hawkins wrote:
>> On Wed, May 17, 2017 at 2:41 PM, Will Hawkins wrote:
>>> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wrote:
>>>> On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote
9:13 gcc-8-20170604.tar.xz
Given the breadth that xz already has in the distribution space, I'd
have a hard time supporting moving to lz over xz.
We've got far more important items to tackle than this. But if you want
me to bring it up formally with the SC I can.
jeff
ps. And just
On 06/08/2017 03:27 AM, Antonio Diaz Diaz wrote:
> Jeff Law wrote:
>> We've got far more important items to tackle than this. But if you
>> want me to bring it up formally with the SC I can.
>>
>> ps. And just to be clear, I actually don't like xz and
nitely a linux kernel bug that affected the behavior
of "expect" used by dejagnu in the past.
THe gcc.gnu.org reference to a message from Pinski is the right one --
it identifies the problematical change in the kernel that mucked up
expect's behavior.
In the thread you'll find a reference to:
https://bugzilla.kernel.org/show_bug.cgi?id=96311
This has long since been fixed. BUt I have no idea what version of hte
kernel is in Ubuntu and whether or not it is subject to this problem.
jeff
k
the core issue was Agner had a much too old binutils (2.20-ish).
jeff
turn jumpy code into conditional moves and to do so as early as
possible. So I'd really look at the gimple optimizers first before the
low level RTL if conversion.
Second, final selection of a conditional move should be dependent upon
the predictability of the conditional branches it will eliminate. cmove
shines when the branches are unpredictable, but if the branches are
predictable, then you're better off leaving them as branches.
Jeff
.gnu.org/contribute.html
If you've already done this, please let me know and I'll confirm with
the FSF copyright clerk.
Jeff
Isn't a testcase always required?
Required? No. Preferred? Yes.
jeff
I had suggestions. This was a long standing nasty problem on the
PA as well. For example, you needed to look at the destination register
of for a load from memory to know if the displacement in the memory
address was valid, or whether or not certain indexing address modes were
valid.
We went through many iterations of hacks, none of which were
particularly clean, all of which were weak in terms of GCC's ability to
use the addressing modes available when it was profitable.
You're likely to have to define some secondary reloads.
Good luck,
jeff
>
> Andrew
d it be to split expose the entire mem:
>
> (set (match_operand:SI "register" "=a,b")
> (mem:SI (match_operand:SI "register" "a,b")))
> + variants for reg+const if you have them?
Doesn't that run afoul of the various restrictions on the movXX patterns?
jeff
e flag. Though that's fairly gross.
>
> In general, it's hard to find test cases which show that something
> breaks.
Right.
Jeff
ely be
improved to utilize instructions with volatile memory operands to fill
slots. But it hardly seems worth the effort given the directions in
processor design/implementation over the last 20+ years.
Jeff
ay if you know
> the instruction is valid, and you can look up an insn attribute. That
> suggests passing the insn and not the PATTERN.
Good point. In fact, it opens the possibility that costing could be
attached to the insn itself as just another attribute if it made sense
for the target to describe costing in that manner.
Jeff
good enough coverage at this step with
newlib/glibc.
Anyway, that gives us a basic level of testing the code generator. It
doesn't run the testsuite or anything like that, but it has been useful
in catching problems earlier.
The second problem is once you build the buildbot, then someone has to
actually monitor the results, and either fix the problems or farm them
out to the appropriate engineer :-)
jeff
f someone wants an m68k compiler (to
pick on one I maintain that wouldn't survive), they can always use an
older version of GCC or do the conversion to bring it up to modern
standards. Realistically I'll never do it for the m68k, it's just not
important enough relatively to the other stuff on my plate.
Jeff
ses headers without runtime library exception.
Yes, but that doesn't mean we just blindly put the exception clause on
all the target headers.
>
> https://gcc.gnu.org/ml/gcc-help/2012-08/msg00235.html
>
> See also
>
> https://gcc.gnu.org/PR61152
IMHO the proper thing to do here is identify what parts potentially
introduce *code* into the library. Those need to have the exception
clause. Adding the exception clause to the tm.h files blindly seems
wrong to me.
jeff
On 08/02/2017 01:34 PM, Richard Earnshaw wrote:
> On 26/07/17 18:54, Jeff Law wrote:
>> On 07/17/2017 02:35 PM, Richard Henderson wrote:
>>> On 07/17/2017 12:20 AM, Richard Biener wrote:
>>>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
>>>>> N
check_cpu_load): New proc to check speed limit.
> (gcc_parallel_test_run_p): Modify to call check_cpu_load before
> acquiring a new lock file.
So does this perform better than make -j X -l X? I use that with good
success.
jeff
is a large unexplained
> diff. even originally, the commit messages weren't very verbose. It also
> adds 20 years of effectively "merge local diff to head". however, the
> end result does work well enough to boot, run, etc.
>
> if I go down this road, how can I begin bridging this gap?
Best advice is to break things down into a series of independent
changes. Ideally with testcases.
Jeff
;m contemplating.
They're unfortunately very fragile (in terms of how they behave on
different versions of gdb, kernels, etc), so absolute pass/fail status
isn't particularly helpful.
Jeff
On 08/06/2017 01:59 AM, Boris Kolpackov wrote:
> Hi,
>
> Currently GCC does not write extracted header dependency information
> if there are errors. However, this can be useful when dealing with
> outdated generated headers that trigger errors which would have been
> resolved if we could update it
e've been faulting in work-arounds when ports trip over those problems,
but I'm certain more problems in this space remain.
jeff
equired:
>
> "The delete-expression will call a deallocation function (3.7.3.2)."
>
>
> This was changed by
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#348
Which I think argues that we can safely remove a call to operator delete
when we know the pointer is null. However, we can not assume that an
object passed to operator delete is non-null.
ISTM this would be better implemented in the optimizers rather than in
the front-end. tree-ssa-dce.c would seem fairly natural.
The only wrinkle is we can't do it in C++03 or earlier mode.
jeff
ff865119cc in _dl_start_user () from /lib64/ld64.so.2
>
> $ msgfmt --version
> msgfmt (GNU gettext-tools) 0.18.2
>
> Is it a known issue, has anybody spotted that as well?
Yea, my ppc64le builds from late last week are stumbling on this as
well. Could well be an environment thing -- if I go into
/libstdc++-v3/po and "make", it works just fine.
jeff
) should generate an error as
a constraint -- it's meaningless in that you can't match a constant
integer input to any output.
Jeff
On 08/28/2017 11:33 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 28 Aug 2017, Jeff Law wrote:
>
>>> long a, b = 0;
>>> asm ("" : "=r" (a) : "0" (0));
>> I wouldn't use a matching constraint here. Something like this is
On 08/28/2017 11:56 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 28 Aug 2017, Jeff Law wrote:
>
>> I can't remember matching constraints ever working that way.
>
> They do work exactly so. These uses are all correct, though they place
> some random value into x
never designed to look back through the use-def
chains. In fact, it pre-dates all the SSA work.
In general I'd think if you find yourself wanting operand_equal_p to
look backwards through the use-def chains, then more likely than not a
constant/copy propagation opportunity has been missed somewhere.
jeff
r SSA_NAME if it is self.
> Otherwise it a different optimization pass job to get them to be
> equal.
Exactly.
> In this case most likely FRE or DOM. If they are not doing the job,
> you need to check why and not change operand_equal_p to look back it
> the SSA_NAME's definition.
>
Right.
Jeff
can't see how
POINTER_EXTEND_UNSIGNED plays a significant role here.
MIPS has similar properties and my recollection is they did some
interesting tricks in the target files to fold the extension back into
the arithmetic insns (beyond the usual LOAD_EXTEND_OP,
WORD_REGISTER_OPERATIONS, TRULY_NOOP_TRUNCATION, and PROMOTE_MODE stuff).
My recollection was they defined their key insns with match_operators
that allowed the sign extension to occur in the arithmetic insns. BUt I
don't see any evidence of that anymore. But I can distinctly remember
discussing it with Ian and Meissner eons ago and its impact on reload in
particular.
Jeff
tcase 1, we can see that there is a very similar pattern to
>> the right shift case. We are seeking guidance on where to find the logic (or
>> lack thereof) to eliminate sign_extend on DI mode registers containing SI
>> mode subregs for full width logical ops. Should this logic be in
>> simplify-rtx.c or ree.c?
>
> I believe these patterns can have their sign extension eliminated on riscv
> but REE is not touching them for some reason:
>
> (sign_extend:DI (and:DI (subreg:DI (reg:SI)) (subreg:DI (reg:SI)))
> (sign_extend:DI (or:DI (subreg:DI (reg:SI)) (subreg:DI (reg:SI)))
> (sign_extend:DI (xor:DI (subreg:DI (reg:SI)) (subreg:DI (reg:SI)))
Couldn't can't we factor out the subregs so that you have
(sign_extend:DI (subreg:DI (and:SI (reg1:SI) (reg2:SI
Which something should be able to trivially simplify into:
(sign_extend:DI (and:SI (reg1:SI) (reg2:SI))
That's a generic simplification and ought to be done in simplify-rtx or
somewhere similar. In general, eliminating the subregs like that should
be a good thing.
Jeff
hat was to get pulled out and moved into tree-ssa-threadbackwards.c,
then you can probably skip the step that converts the vector of blocks
into a vector of jump_thread_edge which then gets turned into an array
of blocks. In theory you just turn the vector of blocks into an array
of blocks to match the api for duplicate_thread_path.
Jeff
On 08/06/2017 05:05 PM, Daniel Santos wrote:
> On 08/03/2017 11:45 AM, Jeff Law wrote:
>> On 08/02/2017 11:34 PM, Daniel Santos wrote:
>> So does this perform better than make -j X -l X? I use that with good
>> success.
>>
>> jeff
>
> Sorry for my slow re
On 09/05/2017 06:32 AM, Aldy Hernandez wrote:
> On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law wrote:
>> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
>
>> If you're looking for further cleanups, pulling the rest of the FSM bits
>> out of tree-ssa-threadupdate.c is r
a0,a0,24
>> sext.w a0,a0 # redundant
>> ret
>
> That seems like a missing check somewhere (combine? simplify-rtx? both?) for
> SUBREG_PROMOTED_SIGNED_P. Since Alpha didn't have a 32-bit shift you're in
> new
> territory for this one.
Yea. I'd also expect zero/nonzero bits tracking in combine to catch
this. Shouldn't the sign bit be known to be zero after the shift which
makes the extension redundant regardless of the SUBREG_PROMOTED flag?
jeff
On 09/06/2017 11:17 AM, Richard Henderson wrote:
> On 09/06/2017 09:53 AM, Jeff Law wrote:
>>> I think the easiest solution to this is for combine to notice when IOR has
>>> operands with non-zero-bits that do not overlap, convert the operation to
>>> ADD.
>>
t rn = 2*mn;
>
> assert (bn < mn);
>
> while (rn >= 2 * mn - bn)
In this particular case (ignoring the assert), what you want is better
jump threading exploiting range propagation. But you have to be real
careful here due to the potential overflow.
I'd have to have a self-contained example to dig into what's really
going on, but my suspicion is either overflow or fairly weak range data
and simplification due to the symbolic ranges.
Jeff
ng with type promotion -- Kai did some
work in this space years ago which I found interesting, even if the work
didn't go forward. It showed a real weakness. So I'm certainly
interested in looking at Prathamesh's work -- with the caveat that if it
stumbles across the same issues as Kai's work that it likely wouldn't be
acceptable in its current form.
Jeff
On 09/15/2017 10:19 AM, Segher Boessenkool wrote:
> On Fri, Sep 15, 2017 at 09:18:23AM -0600, Jeff Law wrote:
>> WORD_REGISTER_OPERATIONS works with PROMOTE_MODE. The reason you can't
>> define WORD_REGISTER_OPERATIONS on aarch64 is because that the implicit
>> promoti
nsions in the end. Such pass would likely
> build ontop the VRP pass infrastructure but doing on-demand computation
> on promoted types starting from stmts that require sign-/zero-extension
> at the end.
Hmm, I wonder if we could build this on top of Andrew's infrastructure.
Building ranges as part of walking the use-def chains seems like we'd
have 90% of the infrastructure.
Jeff
estions and issues. Please let me
> know if you find this interesting and what you would like to see
> implemented.
I'd strongly recommend using one of the existing infrastructures. I
know several folks (myself included) are using Jenkins/Hudson. There's
little to be gained building a completely new infrastructure to manage a
buildbot.
Jeff
>
> Kind regards,
>
ut more details (host, target,
flags, cpp output) I can't be 100% sure why it triggers though.
Flow sensitive warnings such as this are very sensitive to a variety of
low level target and IL details.
Jeff
On 09/23/2017 04:57 PM, Eric Gallager wrote:
> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>>
>>
>> On 2017-09-23 12:05 PM, Jeff Law wrote:
>>> On 09/22/2017 08:25 PM, nick wrote:
>>>> Greetings All,
>>>>
>>>> I am wondering i
d as a cleanup that flag ought to be able to replace some of the
existing state flags. I'm thinking about reload_in_progress,
reload_completed, cse_not_expected and likely others.
Jeff
s are unknown until link time. Without
those options the assembler can compute the offset between two objects
within a given section when they come from the same translation unit.
While such tricks aren't valid C code, the compiler and assembler can
work together under the hood to perform these kinds of optimizations.
The documentation is clearly dated. A patch to update it would be
greatly appreciated :-)
Jeff
ne has some guidance here, it would be appreciated. -- Geoff
There are no real mechanisms for doing IPA optimizations or analysis on RTL.
If you could reformulate to work as an IPA pass on gimple that would be
my recommendation. You could probably use pieces of the IPA-ICF
infrastructure to help identify semantically equivalent blocks to stitch
together and outline.
Jeff
nction and each datum into a separate section, which
>> can be placed or removed independently. It is not combining data or
>> altering the order of structures. It allows the linker to position
>> functions and data items as individual components instead of a single
>> obje
tainly a
test in the testsuite where a computed jump can be threaded to a
constant. THe DOM threader aborted/faulted on that in the past.
So I wouldn't lose any sleep if we just didn't handle computed gotos in
the backwards threader and left it to DOM to catch the rare cases were
we can thread to a label/decl.
Jeff
ly from a
modularity standpoint.
?
Jeff
On 10/28/2017 11:18 AM, Richard Biener wrote:
> On October 28, 2017 9:28:38 AM GMT+02:00, Jeff Law wrote:
>>
>> Jan,
>>
>> What's the purpose behind calling vrp_meet and
>> extract_range_from_unary_expr from within the IPA passes?
>>
>> AFAICT th
On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> On 28 October 2017 at 18:28, Jeff Law wrote:
>>
>> Jan,
>>
>> What's the purpose behind calling vrp_meet and
>> extract_range_from_unary_expr from within the IPA passes?
>
> Th
On 10/31/2017 03:49 AM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> On 31 October 2017 at 14:47, Jeff Law wrote:
>> On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote:
>>> Hi Jeff,
>>>
>>> On 28 October 2017 at 18:28, Jeff Law wrote:
>>>>
On 10/31/2017 04:36 AM, Richard Biener wrote:
> On October 31, 2017 10:49:51 AM GMT+01:00, Kugan Vivekanandarajah
> wrote:
>> Hi Jeff,
>>
>> On 31 October 2017 at 14:47, Jeff Law wrote:
>>> On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote:
>>>>
om_binary_expr_1, you'll see it calls
vrp_meet... Sigh. WHich means that everything that calls
extract_range_from_binary_expr_1 needs the equivalences passed around.
Similarly we often call set_value_range* which wants access to the
bitmap obstack as well.
Jeff
Again, the positive is this can be tested very quickly now. The joys of
losing the global and getting some refactoring in done :-)
Jeff
On 11/01/2017 08:24 AM, Richard Biener wrote:
On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law wrote:
On 11/01/2017 12:31 AM, Richard Biener wrote:
In my local tree I'm just passing around the vrp_bitmap_obstack
right
now. Nobody's accessing it via a global anymore. So a
sufficient.
Or he could just report them into the GCC bugzilla.
jeff
ould
pass on *-*-freebsd11.* and perhaps *-*-freebsd10.*.
I don't know if it passes on older FreeBSD. So, I
should I modified the dejagnu pattern?
GIven that FreeBSD 9.x has reached EOL, I'd just remove the xfail.
jeff
g at
some of this stuff, but none of the details.
jeff
file.
GCC already does this for the x87 floating point unit, so you could
probably generalize and build on top of that existing code (reg-stack.c).
jeff
//gcc.gnu.org/wiki/SvnMerge).
>
We've generally considered those clauses under the umbrella of the port
maintainers.
jeff
x27;t object -- we could
always do experiments to see if there's any value in moving it early
(expansion to byte comparisons could possible expose other optimizations).
In general I like what you're suggesting. And on a higher level I like
that we're looking to rationalize where these kinds of things happen
(compiler vs library). It's something I've wanted to see happen for a
long time.
Jeff
On 11/16/2017 03:39 PM, Qing Zhao wrote:
> Hi, Jeff,
> thanks a lot for your comments. please see my reply in below:
>
>
>> On Nov 16, 2017, at 12:47 PM, Jeff Law > <mailto:l...@redhat.com>> wrote:
>>
>>>
>>> B. for strncmp (s1, s2, n) (
hose Min value is larger than the length
> of constant string, with it, we can catch more opportunities.
> let me know when this info is available.
Hoping to have the basics into the trunk within the next few days as
reviews flow in.
jeff
27;s sources themselves
to help determine if a particluar transformation is helpful.
Jeff
to change
>> get_range_strlen.
>
> thanks for the info, Martin.
>
> In my case, it’s the size of “100” cannot be collected in the
> MINMAXLEN[1] for the string “s”.
>
> I need to make sure that the size of variable string s is larger than
> the size of constant string “abc” to guarantee the safety of the
> transformation.
>
> currently, “get_range_strlen” cannot identify the simple VAR_DECL with
> array_type to determine the maximum size of the string.
It sounds more like you want the object_size interfaces. See
tree-object-size.[ch]
Jeff
his to be true. Maybe it's a GCC-local thing?
I think we've routinely made the ChangeLog date the commit date.
> Is this not general practice on FSF projects?
Unsure.
jeff
On 12/21/2017 04:13 PM, Eric S. Raymond wrote:
> Jeff Law :
>> I think we've routinely made the ChangeLog date the commit date.
>
> Ah, so you modify patches as they come in?
Yes we routinely twiddle the ChangeLog dates. In fact we tried to
discourage folks from including the
false positive rates for -Wuninitialized.
Jeff
oing to suggest deprecation for gcc-8 given how badly it was
broken in gcc-7 and the lack of maintenance on the target.
jeff
year.
His work also includes a qsort checking implementation to try and spot
these problems as part of GCC's internal consistency checking mechanisms.
His work is on the development trunk and will show up in the upcoming
gcc-8 release.
jeff
On 01/12/2018 04:07 PM, Joseph Myers wrote:
> On Fri, 12 Jan 2018, Jeff Law wrote:
>
>> I was going to suggest deprecation for gcc-8 given how badly it was
>> broken in gcc-7 and the lack of maintenance on the target.
>
> While we're considering deprecations, what ha
On 01/15/2018 11:11 AM, Joel Sherrill wrote:
>
>
> On 1/15/2018 11:31 AM, Segher Boessenkool wrote:
>> On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote:
>>> On 13/01/18 00:16, Jeff Law wrote:
>>>> On 01/12/2018 04:07 PM, Joseph Myers wrote:
On 01/19/2018 06:33 AM, Georg-Johann Lay wrote:
> On 13.01.2018 00:07, Joseph Myers wrote:
>> On Fri, 12 Jan 2018, Jeff Law wrote:
>>
>>> I was going to suggest deprecation for gcc-8 given how badly it was
>>> broken in gcc-7 and the lack of maintenance on the targ
601 - 700 of 1403 matches
Mail list logo
