/ChangeLog b/gcc/testsuite/ChangeLog
index 884fb62..d781c02 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-23 Martin Sebor
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c: Scan
+ assembly for lvx in
On 03/21/2015 01:48 PM, Iain Sandoe wrote:
Hi Martin,
I've applied your latest patch to top of trunk and looked at the code gen on
powerpc-darwin9 (and a cross from x86-64-darwin12 => powerpc64-linux-gnu).
Thanks for the review!
2015-03-13 Anton Blanchard
PR target/63354
* config/rs6000/rs6000.c (rs6000_keep_leaf_when_profiled): New
function.
2015-03-24 Martin Sebor
PR target/63354
* gcc.target/powerpc/pr63354.c: New test.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 31b46ea..f1508b9 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs
The attached patch adds tests to lib/target-supports.exp
to avoid unnecessarily invoking the compiler on non-ARM
targets to check for the support for a number of ARM
vectorization features.
Okay to commit to trunk?
Martin
2015-03-23 Martin Sebor
* lib/target-supports.exp
f non-nul characters. Tested on
powerpc64.
Martin
2015-04-09 Martin Sebor
* gfortran.dg/pr32627.f03 (strptr): Change size to match the number
of non-nul characters.
diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03
index f8695e0..d9e2b13 100644
---
tools designed to post-process log files
(e.g., grep) that are intended to work with text files (i.e.,
files not containing nuls). Control characters can cause the
tools to fail in non-C locales (such as UTF-8).
On 04/09/2015 12:54 PM, Martin Sebor wrote:
We've been debugging a problem where nul
* include/std/tuple
In the hunk below, should the sizes_match template parameter
be privatized (since it isn't part of the public interface)?
Or perhaps even removed if it's not used?
Martin
@ -457,6 +457,73 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
};
+
+ // Concept utility fun
On 06/08/2015 09:12 AM, Jonathan Wakely wrote:
The linker script assumes that std::mbstate_t has the name __mbstate_t
for linkage purposes, but that's not necessarily true. For mingw32
it's just a typedef for int, so the patterns don't match.
This adds a new mingw32-specific pattern for codecvt_
function (since
every function has main as its direct or indirect caller).
Tested on powerpc64le and x86_64 Linux.
Martin
The ChangeLog entries for gcc and testsuite:
2015-06-11 Martin Sebor
* c-family/c.opt (-Wbuiltin-address): New warning option.
* doc/invoke.texi
OK. You can go ahead and commit the libbacktrace fix.
Committed in r224402.
Let's hold off on the testsuite fixes until we've got the sanitizer &
libbacktrace fixes installed.
Okay.
Martin
Are there any concerns with or suggestions for changes to
the following patch?
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00886.html
Thanks
Martin
)(int) = __builtin_ffs;
int main () { return r (0); }
/build/tmp/u.cpp:1:34: error: invalid initialization of a reference with
a builtin function
static constexpr int (&r)(int) = __builtin_ffs;
^
2015-06-21 Martin Sebor
PR c/66516
* c/c-typeck.c (default
It seems like this patch regresess pr59630.c testcase; I don't see
the testcase being addressed in this patch.
Thanks for the review and for pointing out this regression!
I missed it among all the C test suite failures (I see 157
of them in 24 distinct tests on x86_64.)
pr59630 is marked ice-on
On 06/23/2015 04:29 AM, Jakub Jelinek wrote:
On Tue, Jun 23, 2015 at 12:18:30PM +0200, Marek Polacek wrote:
Is it intended that programs be able to take the address of
the builtins that correspond to libc functions and make calls
to the underlying libc functions via such pointers? (If so,
the pa
Is this patch okay for trunk?
On 06/18/2015 11:15 AM, Martin Sebor wrote:
Are there any concerns with or suggestions for changes to
the following patch?
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00886.html
Thanks
Martin
.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Martin
2015-06-28 Martin Sebor
pr c/66516
* tree.h (DECL_IS_GCC_BUILTIN): New macro.
* doc/extend.texi (Other Builtins): Document when the address of
a builtin function can be taken.
2015-06-28 Martin Sebor
pr c/66516
* c-tree.h
In the debian reproducible builds project we have considered several
options to address this issue. We considered redefining the __DATE__ and
__TIME__ defines by command line flags passed to gcc, but as you say,
that triggers warnings, which could become errors when building with
-Werror and thus
hed is an updated patch with these changes.
Martin
gcc/ChangeLog
2015-07-04 Martin Sebor
pr c/66516
* tree.h (DECL_IS_GCC_BUILTIN): New macro.
* doc/extend.texi (Other Builtins): Document when the address of
a built-in function can be taken.
gcc/c/ChangeLog
2015-07-04 Martin Sebor
This is a small change to diagnose unsafe calls to
__builtin_{frame,return}_address (with an argument > 2) than
tend to return bogus values or lead to crashes at runtime.
A review would be appreciated.
Thanks
Martin
On 06/26/2015 05:49 PM, Martin Sebor wrote:
Is this patch okay for trunk?
+1,9 @@
+2015-02-21 Martin Sebor
+
+ PR testsuite/63175
+ * gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c: Correct
+ expected string.
+
2015-02-18 Jakub Jelinek
PR gcov-profile/64634
Index: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c
+ ABI_CHECK (fcldi, (s, 1, 1.0, -2));
+ ABI_CHECK (fcldu, (s, 1, 1.0, 2));
+ ABI_CHECK (fceld, (s, 1, 1.0));
+ ABI_CHECK (fciiedl, (s, 1, 2, 1.0, 3));
+ ABI_CHECK (fididisdsid, (1, 1.0, 2, 2.0, -1,
+ (sparm){3, 3.0}, 4.0, (sparm){5, 5.0},
+ 6, 7.0));
+
return 0;
}
Ind
Incorporating the feedback I got on the -Wformat-diag checker
provided an opportunity to tighten up existing and implement
a small number of few additional rules based on GCC Coding
Conventions (https://gcc.gnu.org/codingconventions.html).
The checker now also warns for incorrect uses of the follo
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member.
(decode_format_type): Adjust sign
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or some non-trivial cases
of ordinary automatic variables[1].
The attached patch extends the implementation of the warning to
detect t
On 5/23/19 9:57 PM, Alex Henrie wrote:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407#c6
---
gcc/c-family/c.opt | 4
gcc/c/c-decl.c | 4 +++-
gcc/config/i386/i386-options.c | 12 ++--
gcc/testsuite/c-c++-common/pr8640
On 5/21/19 3:53 AM, Richard Biener wrote:
On Tue, May 21, 2019 at 4:13 AM Martin Sebor wrote:
On 5/20/19 3:16 AM, Richard Biener wrote:
On Mon, May 20, 2019 at 10:16 AM Marc Glisse wrote:
On Mon, 20 May 2019, Richard Biener wrote:
On Sun, May 19, 2019 at 6:16 PM Marc Glisse wrote
On 5/28/19 4:24 AM, Martin Liška wrote:
On 5/28/19 11:31 AM, David CARLIER wrote:
Hi,
Here a tiny patch to fix few build warnings.
Kind regards.
Hi.
Well, I see a lot of these struct/class discrepancies when building GCC with
LLVM.
Question is whether it worth changing?
I think it's nic
On 5/24/19 9:49 AM, Alex Henrie wrote:
On Fri, May 24, 2019 at 2:01 AM Richard Biener wrote:
I'm not sure we really need a new warning for this.
On Fri, May 24, 2019 at 9:23 AM Martin Sebor wrote:
I don't think GCC makes a formal distinction between function
attributes that a
On 5/29/19 11:45 AM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or some non-trivial cases
of ordinary auto
On 5/30/19 9:13 AM, Jeff Law wrote:
On 5/30/19 8:52 AM, Martin Sebor wrote:
On 5/29/19 11:45 AM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't t
On 5/30/19 10:15 AM, Jeff Law wrote:
On 5/30/19 9:34 AM, Martin Sebor wrote:
If the alias oracle can be used to give the same results without
excessive false positives then I think it would be fine to make
use of it. Is that something you consider a prerequisite for
this change or should I
On 5/28/19 3:30 PM, Sean Gillespie wrote:
This adds a new warning, -Wglobal-constructors, that warns whenever a
decl requires a global constructor or destructor. This new warning fires
whenever a thread_local or global variable is declared whose type has a
non-trivial constructor or destructor. W
On 5/30/19 12:58 AM, Aldy Hernandez wrote:
Hi.
We have zero_p in the API, but we don't have non_zero_p. Instead we use
a non-API function range_is_nonnull. I've fixed this.
I have also gotten rid of the duplicity of using the non-API
range_is_null in favor of value_range_base::zero_p().
On 5/30/19 5:49 PM, Jeff Law wrote:
On 5/22/19 10:34 AM, Martin Sebor wrote:
Incorporating the feedback I got on the -Wformat-diag checker
provided an opportunity to tighten up existing and implement
a small number of few additional rules based on GCC Coding
Conventions (https://gcc.gnu.org
On 5/31/19 10:12 AM, Sean Gillespie wrote:
On Thu, May 30, 2019 at 4:28 PM Martin Sebor wrote:
On 5/28/19 3:30 PM, Sean Gillespie wrote:
This adds a new warning, -Wglobal-constructors, that warns whenever a
decl requires a global constructor or destructor. This new warning fires
whenever a
Given a poiner to array p, tree dumps for expressions like &(*p)[2]
actually show &*p[2]. That's not right -- the parentheses are
important to differentiate indexing into the array the pointer
points to from indexing into the pointer.
The attached patch adjusts the tree pretty printer to add the
I spent a bunch of time the other day trying to understand why
the second of the two assignments below to a char array was
apparently not being done by trunk
a[0] = 1;
a[1] = 0;
The optimized GIMPLE dump simply shows:
MEM[(char *)&a] = 1;
when in the past it showed:
MEM[(char[2] *)&a2
A patch with a ChangeLog this time is attached.
On 6/1/19 9:53 AM, Martin Sebor wrote:
I spent a bunch of time the other day trying to understand why
the second of the two assignments below to a char array was
apparently not being done by trunk
a[0] = 1;
a[1] = 0;
The optimized GIMPLE
On 6/3/19 4:34 AM, Richard Biener wrote:
On Mon, Jun 3, 2019 at 10:57 AM Jakub Jelinek wrote:
On Mon, Jun 03, 2019 at 10:36:42AM +0200, Richard Biener wrote:
To avoid this confusion the attached patch adds to the dump
a cast to the MEM_REF type for accesses whose size is not equal
to the size
I posted the patch right on the cusp of stage 4, thinking it was
still stage 3. I thought I could finish it quickly but after
the last round of comments I decided to move on to stage 4 stuff.
I've contemplating coming back to it at some point.
That being said, the patch fixes the reported bug wi
While testing a different -Wreturn-local-addr bug fix/enhancement
I noticed that in functions that return integers as opposed to
pointers such as:
intptr_t f (int i) { return (intptr_t)&i; }
the converted address is folded to zero. This can be detected
by strictly conforming programs so it's
On 5/31/19 2:46 PM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or some non-trivial cases
of ordinary auto
On 6/3/19 5:24 PM, Martin Sebor wrote:
On 5/31/19 2:46 PM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a function but the warning
doesn't try to handle alloca or VLAs, or som
On 6/5/19 6:51 AM, Richard Biener wrote:
The following was inspired by Marins work on escapes of locals
and the discussion there. It teaches points-to analysis that
the point of function return is special and thus escapes through
that a) do not influence other points-to solutions, b) can be
pru
On 5/31/19 12:20 PM, Jeff Law wrote:
On 5/31/19 9:56 AM, Martin Sebor wrote:
On 5/30/19 5:49 PM, Jeff Law wrote:
So in several places there's a comment which indicates that debugging
dumps and the like do not follow conventions. Presumably you've tried
to keep a narrow scope on the
One of my new tests for the strlen/sprintf integration tripped
over an incomplete handling of VLAs by the strlen pass. Where
it can determine the length of a substring at some offset with
other kinds of arrays, the pass fails with VLAs because they
are represented as pointers to arrays.
The atta
On 6/6/19 3:39 AM, Jakub Jelinek wrote:
On Wed, May 22, 2019 at 10:34:00AM -0600, Martin Sebor wrote:
gcc/ChangeLog:
* config/i386/i386-features.c (ix86_get_function_versions_dispatcher):
Adjust quoting and hyphenation.
* convert.c (convert_to_real_1): Same
On 6/6/19 2:01 AM, Martin Liška wrote:
Hi.
The patch is about addition of warn_unused_attribute for malloc-like function.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I like this change (as you know :) Just one question: should
all allocation functions be also annot
On 6/6/19 9:42 AM, Jakub Jelinek wrote:
On Thu, Jun 06, 2019 at 08:45:56AM -0600, Martin Sebor wrote:
Changes for the same change shouldn't be separated by empty newlines in the
ChangeLog. Furthermore, you've managed to commit only the first part (until
varasm.c) and not the rest.
To avoid trailing whitespace in my commits I have my editor set
to highlight them. While integrating the strlen/sprintf passes
and making more extensive changes than usual, I keep getting
distracted by the highlighting pointing out trailing spaces that
predate my changes. Rather than "fixing" th
Hi Jeff,
It looks like the updated comment for get_range_strlen didn't make
it into the strlen fixup commits last December and the function
still has the old description. (Not surprising given there are
at least two overloads of the same function and things moving
between them.) I'm going to ch
On 6/7/19 6:57 AM, Christophe Lyon wrote:
On Wed, 5 Jun 2019 at 20:33, Martin Sebor wrote:
On 5/31/19 12:20 PM, Jeff Law wrote:
On 5/31/19 9:56 AM, Martin Sebor wrote:
On 5/30/19 5:49 PM, Jeff Law wrote:
So in several places there's a comment which indicates that debugging
dumps an
On 6/7/19 6:13 AM, Martin Liška wrote:
On 6/7/19 2:09 PM, Richard Biener wrote:
On Fri, Jun 7, 2019 at 2:03 PM Martin Liška wrote:
On 6/7/19 10:57 AM, Richard Biener wrote:
On Mon, Jun 3, 2019 at 3:35 PM Martin Liška wrote:
On 6/1/19 12:06 AM, Jeff Law wrote:
On 5/22/19 3:13 AM, Martin L
On 6/6/19 11:27 PM, Martin Liška wrote:
On 6/6/19 5:17 PM, Martin Sebor wrote:
On 6/6/19 2:01 AM, Martin Liška wrote:
Hi.
The patch is about addition of warn_unused_attribute for malloc-like function.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
I like this change
On 6/6/19 3:53 PM, Jeff Law wrote:
On 6/5/19 4:51 PM, Martin Sebor wrote:
One of my new tests for the strlen/sprintf integration tripped
over an incomplete handling of VLAs by the strlen pass. Where
it can determine the length of a substring at some offset with
other kinds of arrays, the pass
On 6/7/19 2:10 PM, Matthew Beliveau wrote:
This patch adds a new warning option: Winaccessible-base, so that
users are able to selectively control the warning. The warning is
enabled by default; however, for the virtual bases' warning, it only
triggers with -Wextra flag.
With few exceptions the
The attached update adds the MEM_REF type in pointy braces like
in the -gimple format, but without the access size:
MEM [(char *)&a] = 1;
Martin
On 6/4/19 4:57 AM, Richard Biener wrote:
On Mon, Jun 3, 2019 at 5:13 PM Martin Sebor wrote:
On 6/3/19 4:34 AM, Richard Biener wrote:
On
On 6/10/19 1:29 PM, Jakub Jelinek wrote:
On Mon, Jun 10, 2019 at 01:23:28PM -0600, Martin Sebor wrote:
+ else if (integer_zerop (TREE_OPERAND (node, 1))
+ /* Dump the types of INTEGER_CSTs explicitly, for we can't
+ infer them and MEM_ATTR caching will share MEM
On 6/11/19 7:59 AM, Matthew Beliveau wrote:
Hello,
Correct me if I'm wrong, but before the function checks for virtual
bases, an if-statement checks for extra_warnings on line 6049(when my
patch is applied). The check was there before I made my changes, and
my test fails
without -Wextra. Below
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout, in favor of one--
contains_p. There should
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans up the various contains, may_contain, and
The sprintf and strlen passes both work with strings but
run independently of one another and don't share state. As
a result, lengths of strings dynamically created by functions
that are available to the strlen pass are not available to
sprintf. Conversely, lengths of strings formatted by
the sp
On 6/11/19 3:02 PM, Aldy Hernandez wrote:
On 6/11/19 12:52 PM, Martin Sebor wrote:
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
On 6/12/19 5:37 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
@@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
location_t loc = gimple_location (g);
if (fdecl)
- warning_at (loc, OPT_Wunused_result,
-
On 6/12/19 9:25 AM, Michael Matz wrote:
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
Otherwise LGTM as the patch, but I'd like to hear from others whether
it is kosher to add such a special case to the warn_unused_result
attribute warning. And if the agreement is yes, I think it shou
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
But GCC doesn't support such an implementation, does it?
Why would that be relevant?
Obviously because it makes no sense to cater to all conceivable
extensions provided by all sor
On 6/12/19 3:33 PM, Rainer Orth wrote:
Richard Biener writes:
On Mon, Jun 10, 2019 at 10:37 PM Martin Sebor wrote:
On 6/10/19 1:29 PM, Jakub Jelinek wrote:
On Mon, Jun 10, 2019 at 01:23:28PM -0600, Martin Sebor wrote:
+ else if (integer_zerop (TREE_OPERAND (node, 1))
+ /* Dump the
On 6/13/19 4:44 AM, Jakub Jelinek wrote:
On Thu, Jun 13, 2019 at 10:53:55AM +0200, Rainer Orth wrote:
Even with that fixed, I see many failures:
+FAIL: g++.dg/tree-ssa/pr31146.C -std=gnu++14 scan-tree-dump forwprop1
"MEM[.*&i][j.*] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C -s
On 6/13/19 9:34 AM, Jakub Jelinek wrote:
On Thu, Jun 13, 2019 at 09:30:37AM -0600, Martin Sebor wrote:
The size of the access above doesn't look right. The test is:
It is correct. You have MEM [(int *)&i], which is
the same thing as i itself, and on this you apply an ARRAY_REF,
Attached is a fix for the fold_build call with inconsistent
argument types introduced in a recent commit of mine.
Tested on x86_64-linux.
Martin
PR tree-optimization/90662 - strlen of a string in a vla plus offset not folded
gcc/ChangeLog:
PR tree-optimization/90662
* tree-ssa-strlen.c (get_
On 6/13/19 10:46 AM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> I'd like to move C-alloca support to the ash heap of history. But I'm
Jeff> not sure we can realistically do that.
Are there still platforms or compilers in use where it's needed?
For gdb I was planning to just remove t
While integrating the strlen and sprintf passes and investigating
optimization opportunities that it opens up I noticed a few related
to a strcmp optimization implemented in GCC 9. One is to take
advantage of the fact that a nul-terminated string of a known
length cannot be equal to a string whos
On 6/16/19 10:10 AM, Marek Polacek wrote:
On Sat, Jun 15, 2019 at 10:39:13AM -0400, Marek Polacek wrote:
On Sat, Jun 15, 2019 at 04:33:26PM +0200, Jakub Jelinek wrote:
On Sat, Jun 15, 2019 at 10:29:17AM -0400, Marek Polacek wrote:
[dcl.attr.noreturn] says "The first declaration of a function s
On 6/16/19 1:10 PM, Marek Polacek wrote:
While messing with [[noreturn]] I also found out that we don't detect
the case when an attribute specifier that takes no arguments contains
an attribute-argument-clause.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-06-16 Marek Polacek
On 6/18/19 2:38 AM, Christophe Lyon wrote:
On Fri, 14 Jun 2019 at 03:35, Jeff Law wrote:
On 6/13/19 1:10 PM, Martin Sebor wrote:
Attached is a fix for the fold_build call with inconsistent
argument types introduced in a recent commit of mine.
Tested on x86_64-linux.
Martin
gcc-90662.diff
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 6/11/19 7:31 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the
On 6/18/19 12:59 PM, Jeff Law wrote:
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c
Let me try that again to the right list.
On 6/18/19 9:14 PM, Martin Sebor wrote:
Bug 90923 shows that even though GCC hash-table based containers
like hash_map can be instantiated on types with user-defined ctors
and dtors they invoke the dtors of such types without invoking
the corresponding
On 6/14/19 2:59 PM, Jeff Law wrote:
On 6/4/19 1:40 PM, Martin Sebor wrote:
On 6/3/19 5:24 PM, Martin Sebor wrote:
On 5/31/19 2:46 PM, Jeff Law wrote:
On 5/22/19 3:34 PM, Martin Sebor wrote:
-Wreturn-local-addr detects a subset of instances of returning
the address of a local object from a
On 6/19/19 5:11 AM, Vladislav Ivanishin wrote:
Hi,
This patch (partially) adds displaying inlining context for
-W{maybe,}uninitialized warnings. This is not as trivial to enable as
simply supplying the "%G" format specifier, so I have some questions
below.
I need this hunk
void
percent_K_
On 6/19/19 10:46 AM, Jeff Law wrote:
On 6/18/19 1:21 PM, Martin Sebor wrote:
On 6/18/19 12:59 PM, Jeff Law wrote:
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
gcc
On 6/14/19 2:03 PM, Jeff Law wrote:
On 6/13/19 5:50 PM, Martin Sebor wrote:
While integrating the strlen and sprintf passes and investigating
optimization opportunities that it opens up I noticed a few related
to a strcmp optimization implemented in GCC 9. One is to take
advantage of the fact
On 6/20/19 4:23 PM, Jeff Law wrote:
As outlined in the BZ, our alias analysis code is context insensitive.
So when we copy-propagate pointers, we can can and do copy PTA
information from members to the representative pointer in the copy-of
chain (we do this when the representative pointer has no
On 6/21/19 4:16 PM, Ian Lance Taylor wrote:
On Wed, Jun 19, 2019 at 12:49 PM Martin Sebor wrote:
gcc-wformat-diag-checker.diff
gcc/c-family/ChangeLog:
* c-format.c (function_format_info::format_type): Adjust type.
(function_format_info::is_raw): New member
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs. One of these
is the subject of this patch. The bug results in stripping
trailing
On 6/22/19 9:37 PM, Jason Merrill wrote:
On 6/21/19 8:05 PM, Martin Sebor wrote:
The solution we implemented in GCC 9 to get the mangling of
non-type template arguments of class types containing array
members consistent regardless of the form of their
initialization introduced a couple of bugs
The attached patch cleans up a number of outstanding -Wformat-diag
instances. I plan to commit it tomorrow.
With it applied, an x86_64-linux bootstrap shows just 79 unique
instances of the warning originating in 17 files. 49 of those are
in the Go front-end that Ian is already dealing with. I
On 11/26/18 8:45 PM, Sandra Loosemore wrote:
On 11/26/18 8:32 PM, Martin Sebor wrote:
On 11/26/18 11:13 AM, Sandra Loosemore wrote:
On 11/26/18 10:17 AM, Martin Sebor wrote:
On 11/25/18 6:40 PM, Sandra Loosemore wrote:
I've checked in the attached patch for PR79738.
I think we have
In a recent discussion a user asked us to clarify the effects
of attributes const and pure on member functoons of trivial
structs vs. non-trivial classes, and functions with pointer
vs. reference arguments.
I think this is worth explaining in some general statement
rather than for individual attr
Last week we agreed to clarify that attribute aligned on a function
can decrease its alignment if it hasn't been previously declared
with one. Attached is this change.
Besides the above, I also mention that the attribute specifies
the alignment of the first instruction of the function (in case
t
On 12/4/18 12:09 AM, Sandra Loosemore wrote:
On 12/3/18 4:23 PM, Martin Sebor wrote:
gcc/ChangeLog:
* doc/extend.texi (attribute const, pure): Clarify.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision
On 12/4/18 12:20 AM, Sandra Loosemore wrote:
On 12/3/18 8:23 PM, Martin Sebor wrote:
Last week we agreed to clarify that attribute aligned on a function
can decrease its alignment if it hasn't been previously declared
with one. Attached is this change.
Besides the above, I also mention
On 12/4/18 2:04 PM, Sandra Loosemore wrote:
On 12/4/18 9:26 AM, Martin Sebor wrote:
Thanks for the comments. Attached is an updated patch with
the typos fixed. I've left the rest as is.
Well, I still think a number of points I commented on before need to be
clarified in the text. I
On 12/5/18 6:09 AM, Rainer Orth wrote:
Hi Martin,
The tests for the new __builtin_has_attribute function have been
failing on a number of targets because of a couple of assumptions
that only hold on some.
First, they expect that it's safe to apply attribute aligned with
a smaller alignment tha
On 12/4/18 8:49 PM, Sandra Loosemore wrote:
On 12/4/18 8:13 PM, Martin Sebor wrote:
On 12/4/18 2:04 PM, Sandra Loosemore wrote:
On 12/4/18 9:26 AM, Martin Sebor wrote:
[snip]
+The keyword @code{__attribute__} allows you to specify various special
+properties of types. Some type attributes
On 12/5/18 3:04 AM, Richard Sandiford wrote:
Thanks for doing this,
Martin Sebor writes:
Martin suggested we update the Coding Conventions to describe
the expected style for function declarations with a pointer
return types, and for overloaded operators. Below is the patch.
As an aside
On 12/5/18 12:13 PM, Jeff Law wrote:
On 12/5/18 11:59 AM, David Edelsohn wrote:
Jeff,
Thanks for the patch.
I continue to see a failure on AIX 32 bit mode (2 byte wchar).
FAIL: gcc.dg/strlenopt-58.c scan-tree-dump-times optimized
"call_in_true_branch_not_eliminated" 0
I'm not certain if this
The __builtin_has_attribute function fails with an ICE when
its first argument is an expression such as INDIRECT_REF, or
many others. The code simply assumes it's either a type or
a decl. The attached patch corrects this oversight.
While testing the fix I also noticed the C++ front end expects
Bug 88372 - alloc_size attribute is ignored on function pointers
points out that even though the alloc_size attribute is accepted
on function pointers it doesn't have any effect on Object Size
Checking. The reporter, who is implementing the feature in Clang,
wants to know if by exposing it under
1101 - 1200 of 3588 matches
Mail list logo
