Thanks for the review, much appreciated. Agreed on all those points,
I'll remove it from -Wextra and just leave it as a standalone warning,
and I'll add those tests you suggested.
On 02/06/2025 19:08, Joseph Myers wrote:
On Sun, 1 Jun 2025, Peter Frost wrote:
Ping https://gcc.gnu.org/piperma
On Sun, 1 Jun 2025, Peter Frost wrote:
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
This needs various coding style fixes. Lines should be broken before
binary operators such as && or || rather than after, and there should be a
space before '(' in function and macr
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
Missed the version 15 freeze with the last ping, I believe the project
is open for general development again now?
On 2/5/25 3:43 PM, Peter Frost wrote:
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
We're in regression fixes only phase of our development cycle. This
doesn't fix a regression, so it'll need to wait for the next development
window to open before it gets further at
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
v3 Patch:
* adds documentation
* fixes formatting
* minor code cleanup
Currently the behaviour of Wmissing-field-initializers is inconsistent
between C and C++. The C warning assumes that missing designated
initializers are deliberate, and does not warn. The C++ warning doe
On 11/22/24 4:31 AM, Jakub Jelinek wrote:
On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
On Wed, 6 Nov 2024, Jakub Jelinek wrote:
+ error_at (loc, "%<:%> constraint operand is not address "
+"of a function or non-automatic variable
On Fri, 22 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
> > On Wed, 6 Nov 2024, Jakub Jelinek wrote:
> >
> > > + error_at (loc, "%<:%> constraint operand is not address "
> > > + "of a function or non-automatic v
On Fri, 22 Nov 2024, Jakub Jelinek wrote:
> On Tue, Nov 19, 2024 at 01:52:06PM +0100, Jan Hubicka wrote:
> > > On Tue, Nov 19, 2024 at 11:23:31AM +0100, Jakub Jelinek wrote:
> > > > On Tue, Nov 19, 2024 at 10:25:16AM +0100, Richard Biener wrote:
> > > > > I think it's pretty clear and easy to desc
On Fri, 22 Nov 2024, Jakub Jelinek wrote:
> On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
> > On Wed, 6 Nov 2024, Jakub Jelinek wrote:
> >
> > > + error_at (loc, "%<:%> constraint operand is not address "
> > > + "of a function or non-automatic v
On Tue, Nov 19, 2024 at 01:52:06PM +0100, Jan Hubicka wrote:
> > On Tue, Nov 19, 2024 at 11:23:31AM +0100, Jakub Jelinek wrote:
> > > On Tue, Nov 19, 2024 at 10:25:16AM +0100, Richard Biener wrote:
> > > > I think it's pretty clear and easy to describe to users what "m " and
> > > > what "mC" do.
On Thu, Nov 21, 2024 at 11:57:13PM +, Joseph Myers wrote:
> On Wed, 6 Nov 2024, Jakub Jelinek wrote:
>
> > + error_at (loc, "%<:%> constraint operand is not address "
> > +"of a function or non-automatic variable");
>
> I think a testcase for this error
Hi,
This patch makes it clear that vector sizes and capacities are not
negative. With recent change to ipa-fnsummary this should not affect
inlining and improves codegen of some vector manipulation functions.
I tested clang build. Looking for throw_bad calls there are only 3
called considerably
This was responsible for a bunch of SVE FAILs with --param vect-force-slp=1
Bootstrapped and tested on x86_64-unknown-linux-gnu.
* tree-vect-slp.cc (arg1_arg3_map): New.
(arg1_arg3_arg4_map): Likewise.
(vect_get_operand_map): Handle IFN_SCATTER_STORE,
IFN_MASK_SCAT
On Mon, 28 Oct 2024, Jakub Jelinek wrote:
> Ok, here is an updated patch, which for ubsan checks just for negative
> count and nothing else, does that check before using TRUNC_MOD_EXPR on
> the argument and uses it on unsigned types in all cases.
> The c_fully_fold_internal new wording is removed
On Fri, Oct 25, 2024 at 08:06:36PM +, Joseph Myers wrote:
> If sanitizing makes sense for these built-in functions, surely it should
> check for all negative shifts, including those that are multiples of the
> width (and there should be tests for it in the testsuite). So sanitizing
> would
On Fri, 30 Aug 2024, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 04:58:58PM +, Joseph Myers wrote:
> > On Thu, 15 Aug 2024, Jakub Jelinek wrote:
> >
> > > + else
> > > + {
> > > + if (res > INTTYPE_MAXIMUM (off_t))
> > > + cpp_error_with_line (pfile, CPP_DL_ERROR, loc,
On Fri, Aug 16, 2024 at 05:14:42PM +, Joseph Myers wrote:
> On Fri, 16 Aug 2024, Jakub Jelinek wrote:
>
> > Ok. So for now, should I work on a patch variant which tries to follow
> > what is in C23 right now?
>
> Not sure how useful having such a patch variant would be until we have a
> bet
On Fri, Aug 16, 2024 at 04:58:58PM +, Joseph Myers wrote:
> On Thu, 15 Aug 2024, Jakub Jelinek wrote:
>
> > + else
> > + {
> > + if (res > INTTYPE_MAXIMUM (off_t))
> > + cpp_error_with_line (pfile, CPP_DL_ERROR, loc, 0,
> > +"too larg
On Thu, 15 Aug 2024, Jakub Jelinek wrote:
> +#embed __FILE__ gnu::base64(1) prefix() suffix() /* { dg-error "expected
> character string literal" } */
> +#embed __FILE__ gnu::base64() prefix() suffix() /* { dg-error "expected
> character string literal" } */
Maybe also test this error with a no
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> Ok. So for now, should I work on a patch variant which tries to follow
> what is in C23 right now?
Not sure how useful having such a patch variant would be until we have a
better idea of what the desired semantics actually are.
--
Joseph S. Myers
jo
On Fri, Aug 16, 2024 at 04:05:52PM +, Joseph Myers wrote:
> On Fri, 16 Aug 2024, Jakub Jelinek wrote:
>
> > > Apart from any consequences for arguments of prefix/suffix/is_empty
> > > (where
> > > there is a plausible argument that the argument should get expanded at
> > > some point and th
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote:
> > My reading of it wasn't that whether it is
> > # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> > or
> > # embed < h-char-sequence > embed-parameter-sequence[opt] new-
On Fri, 16 Aug 2024, Jakub Jelinek wrote:
> > Apart from any consequences for arguments of prefix/suffix/is_empty (where
> > there is a plausible argument that the argument should get expanded at
> > some point and that the current wording is undesirable for usability),
> > this would also mean
On Fri, Aug 16, 2024 at 01:43:58AM +0200, Jakub Jelinek wrote:
> My reading of it wasn't that whether it is
> # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> or
> # embed < h-char-sequence > embed-parameter-sequence[opt] new-line
> or
> # embed pp-tokens new-line
> depends sole
On Thu, Aug 15, 2024 at 10:07:00PM +, Joseph Myers wrote:
> On Thu, 15 Aug 2024, Jakub Jelinek wrote:
>
> > + D(embed, T_EMBED,STDC23,INCL | EXPAND) \
>
> I'd like to query the macro expansion handling. My understanding is that
> a #embed directive only gets macro
On Thu, 15 Aug 2024, Jakub Jelinek wrote:
> + D(embed, T_EMBED,STDC23,INCL | EXPAND) \
I'd like to query the macro expansion handling. My understanding is that
a #embed directive only gets macro-expanded if it fails to match either of
the forms
# embed < h-char-
Changed in v3:
* Moved the testsuite to a separate patch
* Updated copyright year
* class text_sink: New.
* class file: Add default ctor, copy ctor, move ctor; make m_inner
non-const
* class physical_location: Add default ctor
* class logical_location: Make m_inner non-const
* class execution_pat
Hi!
Here is a new version of the gnu::base64 parameter support, the only changes
are in using the EMBED_PARAMS registry of parameters.
2024-08-15 Jakub Jelinek
libcpp/
* internal.h (struct cpp_embed_params): Add base64 member.
(_cpp_free_embed_params_tokens): Declare.
On Wed, Aug 14, 2024 at 09:58:04PM +, Joseph Myers wrote:
> On Tue, 18 Jun 2024, Jakub Jelinek wrote:
>
> > The following patch implements the C23 N3017 "#embed - a scannable,
> > tooling-friendly binary resource inclusion mechanism" paper.
>
> Some initial comments, not yet reviewed the whol
The following adds a target hook to specify whether regs of MODE can be
used to transfer bits. The hook is supposed to be used for value-numbering
to decide whether a value loaded in such mode can be punned to another
mode instead of re-loading the value in the other mode and for SRA to
decide whe
Hello Richard:
All comments are addressed.
Common infrastructure using generic code for pair mem fusion of different
targets.
rs6000 target specific code implement virtual functions defined by generic code.
Target specific code are added in rs6000-mem-fusion.cc.
Bootstrapped and regtested on p
On Fri, 11 Aug 2023, Jakub Jelinek wrote:
> All that is diagnosed is when result is bool or enum (any kind). Even for
I'd suggest tests that other nonsense cases are diagnosed, such as
floating-point or pointer arguments or results (hopefully such cases are
already diagnosed and just need test
On Thu, Aug 10, 2023 at 10:31:12PM +, Joseph Myers wrote:
> > The following patch (on top of the stdckdint.h patch and _BitInt patch
> > series) adds a test for _BitInt diagnostics of ckd_{add,sub,mul} macros.
>
> I remain unconvinced that diagnosing use with types where it's clear what
> the
On Mon, 26 Jun 2023, Qing Zhao wrote:
>
>
> > On Jun 23, 2023, at 7:27 PM, Alexandre Oliva wrote:
> >
> > On Jun 23, 2023, Qing Zhao via Gcc-patches wrote:
> >
> >> It?s better to add this definition earlier in the list of the ?three
> >> basic values?, to make it ?four basic values?, like t
> On Jun 23, 2023, at 7:27 PM, Alexandre Oliva wrote:
>
> On Jun 23, 2023, Qing Zhao via Gcc-patches wrote:
>
>> It’s better to add this definition earlier in the list of the “three
>> basic values”, to make it “four basic values”, like the following:
>
> Oh, my, sorry for being so dense, I
On Jun 23, 2023, Qing Zhao via Gcc-patches wrote:
> It’s better to add this definition earlier in the list of the “three
> basic values”, to make it “four basic values”, like the following:
Oh, my, sorry for being so dense, I had managed to miss that bit all
this time somehow :-(
> The sentence
On 11/04/2023 15:23, Jørgen Kvalsvik wrote:
> On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is particularly important in the a
On 11/04/2023 15:23, Jørgen Kvalsvik wrote:
> On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
>> This patch adds support in gcc+gcov for modified condition/decision
>> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
>> test/code coverage and it is particularly important in the a
Bootstrapped and reg-tested overnight for x86 and aarch64.
Applied to master, thanks!
Philipp.
On Tue, 9 May 2023 at 09:13, Richard Biener wrote:
>
> On Tue, Dec 20, 2022 at 1:23 PM Manolis Tsamis
> wrote:
> >
> > When using SWAR (SIMD in a register) techniques a comparison operation
> > with
On Tue, Dec 20, 2022 at 1:23 PM Manolis Tsamis wrote:
>
> When using SWAR (SIMD in a register) techniques a comparison operation within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potenti
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industries for safety-cri
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industries for safety-cri
Hi Richard and Tamar,
I just wanted to ping you about this patch. Is there a chance to get
this into GCC13?
Thanks,
Manolis
On Tue, Dec 20, 2022 at 2:31 PM Manolis Tsamis wrote:
>
> On Tue, Dec 20, 2022 at 2:23 PM Manolis Tsamis
> wrote:
> >
> > When using SWAR (SIMD in a register) techniques
On Tue, Dec 20, 2022 at 2:23 PM Manolis Tsamis wrote:
>
> When using SWAR (SIMD in a register) techniques a comparison operation within
> such a register can be made by using a combination of shifts, bitwise and and
> multiplication. If code using this scheme is vectorized then there is
> potenti
When using SWAR (SIMD in a register) techniques a comparison operation within
such a register can be made by using a combination of shifts, bitwise and and
multiplication. If code using this scheme is vectorized then there is potential
to replace all these operations with a single vector comparison
On 05/12/2022 10:40, Jørgen Kvalsvik wrote:
> This patch adds support in gcc+gcov for modified condition/decision
> coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
> test/code coverage and it is particularly important in the avation and
> automotive industries for safety-cri
This patch adds support in gcc+gcov for modified condition/decision
coverage (MC/DC) with the -fprofile-conditions flag. MC/DC is a type of
test/code coverage and it is particularly important in the avation and
automotive industries for safety-critical applications. MC/DC it is
required for or reco
On 10/26/22 16:40, David Malcolm via Gcc-patches wrote:
Changed in v3: added include of
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604137.html
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598189.html
On Tue, 2022-07-12 at 07:48 +0100, Jonathan Wakely wrote:
On Tue, 1
Changed in v3: added include of
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604137.html
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598189.html
On Tue, 2022-07-12 at 07:48 +0100, Jonathan Wakely wrote:
> On Tue, 12 Jul 2022, 01:25 David Malcolm,
> wrote:
>
> > On Fri,
On 8/31/22 07:14, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
This hunk now seems worth factoring out of the four places it occurs.
It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> This hunk now seems worth factoring out of the four places it occurs.
>
> It also seems the comment for _cpp_valid_utf8 needs to be updated: it
> currently says it's not called when parsing a string.
Ok, so like this?
2022-08-31 J
On Sat, 27 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* There shouldn't
GCC emits pedwarns unconditionally when comparing pointers of
different types, for example:
int xdp_context (struct xdp_md *xdp)
{
void *data = (void *)(long)xdp->data;
__u32 *metadata = (void *)(long)xdp->data_meta;
__u32 ret;
if (metadata + 1 > data)
On Tue, Jul 05, 2022 at 04:44:41PM -0400, Jason Merrill wrote:
> On 7/4/22 11:50, Jakub Jelinek wrote:
> > On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
>
> > > > Hmm, why do we need to handle complex in the !preeval case? I'd think
> > > > we
> > > > want t
On 7/4/22 11:50, Jakub Jelinek wrote:
On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches wrote:
Hmm, why do we need to handle complex in the !preeval case? I'd think we
want to preevaluate all complex values or components thereof.
Because the late evaluation of the ini
On Mon, Jun 27, 2022 at 06:31:18PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Because the late evaluation of the initializer could have touched
> the destination, so we need to reevaluate it.
> Same reason why we call get_or_insert_ctor_field again in the second
> loop as we call it in the first
On Wed, Jul 21, 2021 at 12:42 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > "H.J. Lu via Gcc-patches" writes:
> >> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
> >> wrote:
> >>>
> >>> "H.J. Lu" writes:
> >>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> >>> > index 39ab
Richard Sandiford writes:
> "H.J. Lu via Gcc-patches" writes:
>> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
>> wrote:
>>>
>>> "H.J. Lu" writes:
>>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> > index 39ab139b7e1..1972301ce3c 100644
>>> > --- a/gcc/builtins.c
>>> > +++ b/gcc/builti
On Wed, Jul 21, 2021 at 12:20 PM Richard Sandiford
wrote:
>
> "H.J. Lu via Gcc-patches" writes:
> > On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
> > wrote:
> >>
> >> "H.J. Lu" writes:
> >> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> >> > index 39ab139b7e1..1972301ce3c 100644
> >> > --
"H.J. Lu via Gcc-patches" writes:
> On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
> wrote:
>>
>> "H.J. Lu" writes:
>> > diff --git a/gcc/builtins.c b/gcc/builtins.c
>> > index 39ab139b7e1..1972301ce3c 100644
>> > --- a/gcc/builtins.c
>> > +++ b/gcc/builtins.c
>> > @@ -3890,13 +3890,16 @@ exp
On Wed, Jul 21, 2021 at 7:50 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > diff --git a/gcc/builtins.c b/gcc/builtins.c
> > index 39ab139b7e1..1972301ce3c 100644
> > --- a/gcc/builtins.c
> > +++ b/gcc/builtins.c
> > @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target,
>
"H.J. Lu" writes:
> diff --git a/gcc/builtins.c b/gcc/builtins.c
> index 39ab139b7e1..1972301ce3c 100644
> --- a/gcc/builtins.c
> +++ b/gcc/builtins.c
> @@ -3890,13 +3890,16 @@ expand_builtin_strnlen (tree exp, rtx target,
> machine_mode target_mode)
>
> static rtx
> builtin_memcpy_read_str (
1. Replace scalar_int_mode with fixed_size_mode in the by-pieces
infrastructure to allow non-integer mode.
2. Rename widest_int_mode_for_size to widest_fixed_size_mode_for_size
to return QI vector mode for memset.
3. Add op_by_pieces_d::smallest_fixed_size_mode_for_size to return the
smallest integ
h of an opinion on the approach itself (adding
> an attribute to avoid the error). I'm trying to help improve
> the usability of the feature to prevent gaps (underspecified
> aspects) in new attributes that are then hard to sort out after
> the attribute has been introduced. This
On Wed, Feb 17, 2021 at 09:34:34AM -0800, H.J. Lu wrote:
> -fretain-used-symols.
> +/* Add the NAME attribute to *ANODE. */
> +
> +static void
> +add_attribute (tree *anode, int flags, tree name, tree args, tree ns,
> +const bool cxx11_attr_p,
> +const struct attribute_spec
N
> > + if (flag_gnu_retain
> > && (new_section->common.flags & SECTION_NAMED)
> > && decl != nullptr
> > && DECL_P (decl)
>
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -16
-fcf-protection is automatically enabled in libstdc++ on Linux/x86.
Starting from
commit 77d372abec0fbf2cfe922e3140ee3410248f979e
Author: H.J. Lu
Date: Thu Jan 14 05:56:46 2021 -0800
x86: Error on -fcf-protection with incompatible target
GCC issues an error on -fcf-protection with incompa
On 11/26/20 10:09 AM, Jakub Jelinek wrote:
Sorry, thought I had replied to this before.
The following patch removes the mask from the new native_interpret_aggregate
moved to fold-const.c altogether. Instead, the code uses the
__builtin_clear_padding infrastructure (new entrypoint in there).
If
On Wed, Nov 25, 2020 at 07:52:44PM -0500, Jason Merrill wrote:
> > > I think you want to check DECL_PADDING_P here; the C and C++ front ends
> > > set
> > > it on unnamed bit-fields, and that's what is_empty_type looks at.
> >
> > Ok, changed in my copy. I'll also post a patch for
> > __builtin_
On Fri, 20 Nov 2020, Jakub Jelinek wrote:
> On Fri, Nov 20, 2020 at 09:19:31AM +, Richard Biener wrote:
> > > --- gcc/builtins.c.jj 2020-11-19 12:34:10.749514278 +0100
> > > +++ gcc/builtins.c2020-11-19 16:23:55.261250903 +0100
> > > @@ -11189,6 +11189,13 @@ fold_builtin_1 (locatio
On Fri, Nov 20, 2020 at 09:19:31AM +, Richard Biener wrote:
> > --- gcc/builtins.c.jj 2020-11-19 12:34:10.749514278 +0100
> > +++ gcc/builtins.c 2020-11-19 16:23:55.261250903 +0100
> > @@ -11189,6 +11189,13 @@ fold_builtin_1 (location_t loc, tree exp
> > return build_empty_stmt (loc)
On 11.11.20 03:25, Jakub Jelinek wrote:
On Wed, Nov 11, 2020 at 03:14:59AM -0800, Erick Ochoa wrote:
Using the Dead Field Analysis, Dead Field Elimination
automatically transforms gimple to eliminate fields that
are never read.
2020-11-04 Erick Ochoa
* gcc/Makefile.in: add file to
On Wed, Nov 11, 2020 at 03:14:59AM -0800, Erick Ochoa wrote:
>
> Using the Dead Field Analysis, Dead Field Elimination
> automatically transforms gimple to eliminate fields that
> are never read.
>
> 2020-11-04 Erick Ochoa
>
> * gcc/Makefile.in: add file to list of sources
> * gcc/ipa
Field reordering of structs at link-time
2020-11-04 Erick Ochoa
* gcc/Makefile.in: add new file to list of sources
* gcc/common.opt: add new flag for field reordering
* gcc/passes.def: add new pass
* gcc/tree-pass.h: same
* gcc/ipa-field-reorder.c: New file
* gcc/ipa
Using the Dead Field Analysis, Dead Field Elimination
automatically transforms gimple to eliminate fields that
are never read.
2020-11-04 Erick Ochoa
* gcc/Makefile.in: add file to list of sources
* gcc/ipa-dfe.c: New
* gcc/ipa-dfe.h: Same
* gcc/ipa-type-escape-analysis.h: E
2020-11-04 Erick Ochoa
* gcc/Makefile.in: Add file to documentation sources
* gcc/doc/dfe.texi: New section
* gcc/doc/gccint.texi: Include new section
---
gcc/Makefile.in | 3 +-
gcc/doc/dfe.texi| 187
gcc/doc/gccint.texi |
We add a heuristic in order to be able to transform functions which
receive void* arguments as a way to generalize over arguments. An
example of this is qsort. The heuristic works by first inspecting
leaves in the call graph. If the leaves only contain a reference
to a single RECORD_TYPE then we
On Sun, Jul 26, 2020 at 4:02 AM Andreas Schwab wrote:
>
> On Jul 25 2020, Fāng-ruì Sòng wrote:
>
> > On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab
> > wrote:
> >>
> >> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
> >>
> >> > This is to mimick nearly lines. collect2 should filter out opt
On Jul 25 2020, Fāng-ruì Sòng wrote:
> On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab wrote:
>>
>> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
>>
>> > This is to mimick nearly lines. collect2 should filter out options like
>> > -fno-lto, -flto, -fuse-ld= before passing to ld. -f* are ha
On Sat, Jul 25, 2020 at 12:09 AM Andreas Schwab wrote:
>
> On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
>
> > This is to mimick nearly lines. collect2 should filter out options like
> > -fno-lto, -flto, -fuse-ld= before passing to ld. -f* are handled by case
> > 'f'. --ld-path needs its o
On Jul 24 2020, Fangrui Song via Gcc-patches wrote:
> This is to mimick nearly lines. collect2 should filter out options like
> -fno-lto, -flto, -fuse-ld= before passing to ld. -f* are handled by case 'f'.
> --ld-path needs its own `else if`.
If you handle --ld-path as -fld-path then you don't
4
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1077,7 +1077,7 @@ proper position among the other output files. */
LINK_PLUGIN_SPEC \
"%{flto|flto=*:%max_errors = value;
break;
+case OPT__ld_path_:
case OPT_fuse_ld_bfd:
case OPT_fuse_ld_gold:
case OPT_fuse_ld_lld:
>
On 2020-07-01, Martin Liška wrote:
On 6/30/20 5:32 PM, Fāng-ruì Sòng wrote:
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
COMPI
On 6/30/20 5:32 PM, Fāng-ruì Sòng wrote:
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
COMPILER_PATH is not used)?
I would rec
There is some concern about clang's -fuse-ld=path
http://lists.llvm.org/pipermail/cfe-dev/2020-June/065710.html and use
of COMPILER_PATH vs PATH.
Shall we introduce another option like -fld-path=path (PATH is used,
COMPILER_PATH is not used)?
On Tue, Jun 30, 2020 at 6:04 AM Martin Liška wrote:
>
PING^1
On 5/29/20 3:10 AM, Fangrui Song wrote:
On 2020-05-25, Martin Liška wrote:
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54
On 2020-05-25, Martin Liška wrote:
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54b080f7 100644
--- a/gcc/collect2.c
+++ b/gcc/coll
"Kewen.Lin" writes:
> Hi,
>
> Gentle ping patches as below:
>
> 1/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540171.html
> 2/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541387.html
> 3/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545643.html
>
> Or shall
Hi,
Gentle ping patches as below:
1/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540171.html
2/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541387.html
3/4 v3 https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545643.html
Or shall I ping them seperately?
Thanks!
Kew
On 5/22/20 6:42 AM, Fangrui Song wrote:
but I can't fix this one because joining two lines will break the 80-column
rule.
What about this:
diff --git a/gcc/collect2.c b/gcc/collect2.c
index cc57a20e08b..e5b54b080f7 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -1138,8 +1138,8 @@ main (i
On 2020-05-21, Martin Liška wrote:
On 5/21/20 1:52 AM, Fangrui Song wrote:
The above issues motivated me to touch this line in PATCH v2.
Dropped in PATCH v2.
Thank you for the updated patch.
The patch is fine except coding style issues:
$ ./contrib/check_GNU_style.py
/tmp/0001-Add-fuse-ld-to
On Mon, Jan 20, 2020 at 6:46 PM Maciej W. Rozycki wrote:
>
> Ian: Can we please coordinate this somehow? The libgo/ part, like all,
> relies on config/toolexeclibdir.m4, so I can either:
>
> 1. push the whole change all at once and you'll push the libgo/ part to
>your repo independently, whi
On Tue, 21 Jan 2020, Joseph Myers wrote:
> > Provide means, in the form of a `--with-toolexeclibdir=' configuration
> > option, to override the default installation directory for target
> > libraries, otherwise known as $toolexeclibdir. This is so that it is
> > possible to get newly-built lib
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
On Mon, 2 Dec 2019, Maciej W. Rozycki wrote:
> Provide means, in the form of a `--with-toolexeclibdir=' configuration
> option, to override the default installation directory for target
> libraries, otherwise known as $toolexeclibdir. This is so that it is
> possible to get newly-built librari
1 - 100 of 236 matches
Mail list logo
