ssion I
understood that
the diagnostics stuff doesn't depend on much of GCC's data structures, and
doesn't rely on
the garbage collector. Is there something preventing that? (Other than
"it's-a-matter-of-time/effort",
of course.)
Pedro Alves
On 2022-07-12 7:50 p.m., Jonathan Wakely wrote:
> Yeah, and I don't think optimizing for indentation is the right trade off.
> Putting something in a namespace with a three-letter name just so you don't
> have to re-indent some statements in a few years seems odd.
>
> I see no technical difficu
On 2022-07-12 7:36 p.m., David Malcolm wrote:
> On Tue, 2022-07-12 at 17:40 +0100, Pedro Alves wrote:
>>>
>>
>> If that's the approach, then GCC should import std::unique_ptr,
>> std::move,
>> std::foo, std::bar into the gcc namespace too, no? A
On 2022-07-12 7:36 p.m., Pedro Alves wrote:
> On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
>>
>>
>> On Tue, 12 Jul 2022, 17:40 Pedro Alves, > <mailto:pe...@palves.net>> wrote:
>>
>> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
>>
>&g
On 2022-07-12 7:22 p.m., Jonathan Wakely wrote:
>
>
> On Tue, 12 Jul 2022, 17:40 Pedro Alves, <mailto:pe...@palves.net>> wrote:
>
> On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
>
> >> So once GCC requires C++14, why would you want to preserve
&
On 2022-07-12 4:14 p.m., Jonathan Wakely wrote:
>> So once GCC requires C++14, why would you want to preserve
>> once-backported symbols in a namespace other than std, when you no longer
>> have a reason to?
>> It will just be another unnecessary thing that newcomers at that future time
>> will
On 2022-07-12 2:45 p.m., Jonathan Wakely wrote:
> On Tue, 12 Jul 2022 at 14:24, Pedro Alves wrote:
>>
>> On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:
>>
>>> I tried adding it to gcc/system.h, but anything that uses it needs to
>>> hav
On 2022-07-12 1:25 a.m., David Malcolm via Gcc-patches wrote:
> I tried adding it to gcc/system.h, but anything that uses it needs to
> have std::unique_ptr declared, which meant forcibly including
> from gcc/system.h
Did you consider making gcc/system.h include gcc/make-unique.h itself
if INCL
smatches may cause portability issues. In C++, such mismatches
> +are an error. In C, this warning is enabled by @option{-Wall}.
Should it also be enabled by -Wc++-compat?
Pedro Alves
On 2022-05-05 13:41, Martin Liška wrote:
> On 5/5/22 14:29, Richard Biener wrote:
>> Can we then use static_assert (...) instead and remove the
>> macro?
>
> Oh yes, we can ;)
>
>> Do we have C compiled code left (I think we might,
>> otherwise we'd not have __cplusplus guards in system.h),
>> in
, so that just shifts the "inconsistent" behavior
elsewhere.
Pedro Alves
associated declaration in its own, unique section, as in option (2).
>
To me, if I use attribute((used)), and the linker still garbage
collects the symbol, then the toolchain has a bug. Is there any
use case that would suggest otherwise?
Thanks,
Pedro Alves
uration, that is
where host != target, matching the documented behaviour. We have no way
to support non-native `gdbserver', and native `gdbserver' is usually of
no use with cross-GDB of the chosen host.
gdbserver/ChangeLog:
2020-02-12 Maciej W. Rozycki
Pedro Alves
Sk
msg00706.html
FWIW, I've considered completely disabling -Wmaybe-uninitialized in
GDB instead of downgrading it from -Werror to a warning with -Wno-error.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--
Pedro Alves
rtial deduplication would be possible, preserving
type distinction. But since CTF doesn't include these, this is moot
for now.
Thanks,
Pedro Alves
ctf hack to skip
emitting those things?
>
> In most cases local types etc are a fairly small contributor to the
> total volume -- but macros can contribute a lot in some codebases. (The
> Linux kernel's READ_ONCE macro is one I've personally been bitten by in
> the past, with a new local struct in every use. GCC doesn't deduplicate
> any of those so the resulting bloat from tens of thousands of instances
> of this identical structure is quite incredible...)
>
Sounds like something that would be beneficial to do with DWARF too.
Thanks,
Pedro Alves
he linker. I usually see compression ratios of
> roughly 3 or 4 to 1: e.g. I just tried it with a randomly chosen binary,
> /usr/lib/libgtk-3.so.0.2404.3, and got these sizes:
DWARF can be compressed too, with --compress-debug-sections.
Thanks,
Pedro Alves
sked to.
(Side note: the Cauldron page is missing slides for your
presentation, so I couldn't go and recheck some things
mentioned above.)
Thanks,
Pedro Alves
nt further.
FWIW and FYI, this is what GDB does (gdb/warning.m4).
Thanks,
Pedro Alves
On 8/12/19 8:34 PM, Pedro Alves wrote:
> Let me share my 2c -- the format GDB uses doesn't affect most GCC forks
I meant most GCC folks.
Thanks,
Pedro Alves
use -Wformat-nonliteral
with -Wno-format.
* configure: Regenerate.
* NEWS: Mention awesome feature.
gdb/testsuite/ChangeLog:
2013-12-12 John Doe
PR gdb/
* Makefile: Test changes for awesome feature.
"
Pedro Alves
s, etc all caught
> numerous (dozens) of real bugs. I mention it because it's one of the
> ways I know packages are building with -Wall -Werror :-)
Thanks,
Pedro Alves
On 12/11/2018 02:25 PM, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves wrote:
>> Ian earlier mentioned that we've wanted to avoid malloc because some
>> programs call the demangler from a signal handler, but it seems like
>> we already do, thes
mance
reasons, for example by making it possible to reuse a growing buffer
across demangling invocations.
> therefore on some targets alloca (or VLAs) are the only
> option, and for small sizes even if mmap is available using it is too
> costly.
>
> Though, I like Jason's suggestion of just adding a maxinum of the number
> of components and number of substitutions and failing if we need more.
>
> Jakub
Thanks,
Pedro Alves
/msg00257.html>
and Tromey's response.
> and alloca can be abused
> in all kinds of interesting ways.
Thanks,
Pedro Alves
hat was still being minimally maintained, because it was needed
to build&maintain some legacy stuff. That was maybe over 8 years ago, and
it was off trunk. It's probably dead by now. And if isn't dead,
whoever maintains the compiler off trunk certainly can also maintain old-ish
binutils & gdb off trunk.
Thanks,
Pedro Alves
>> Also, noticed a typo here:
>>
>>> +/* If DMGL_NO_RECURE_LIMIT is not enabled, then this is the value used as
>>
>> Typo: "RECURE"
>
> Oops - thanks.
>
> OK, revised (v5) patch attached. Is this version acceptable to all ?
>
This is fine with me.
Thanks,
Pedro Alves
, then this is the value used as
Typo: "RECURE"
> + the maximum depth of recursion allowed. It should be enough for any
> + real-world mangled name. */
> +#define DEMANGLE_RECURSION_LIMIT 1024
> +
Thanks,
Pedro Alves
ached. */
> + return 0;
> +}
> +
> + recursion_level ++;
> +
There's still a static recursion level counter here?
Thanks,
Pedro Alves
the recursion limit would be a very
> rare event, possibly only ever done once in an executable's runtime,
> so I doubt that there will ever be any real-life thread safety
> problems associated with it. But I do understand that this is just
> an assumption, not a guarantee.
See above.
Thanks,
Pedro Alves
d making work toward that direction harder. (Keeping in mind that
if this recursion detection feature is useful for binutils, then it should
also be useful for GDB.)
Thanks,
Pedro Alves
t;>> ./simple-object-elf.c:1284:14: note: each undeclared identifier is
>>> reported only once for each function it appears in
>>>
>>> Suggested fix:
>>
>> Works for me, thus OK. I'm going to check it in to make 8.2.
>
> Thanks.
>
> Joel/Pedro, is this okay for GDB's copy of libiberty, master and
> branch?
Yes.
Thanks,
Pedro Alves
the compiler in c++11 its deleted and may
> not be used.
The macro already exists --- DISABLE_COPY_AND_ASSIGN in include/ansidecl.h.
Thanks,
Pedro Alves
[adding gdb-patches]
On 06/05/2018 06:56 PM, David Malcolm wrote:
> On Tue, 2018-06-05 at 17:13 +0100, Pedro Alves wrote:
>> On 06/05/2018 03:49 PM, David Malcolm wrote:
>>> On Tue, 2018-06-05 at 04:40 -0400, Trevor Saunders wrote:
>>>> You may want to look at gd
ood to share this header between GCC and GDB;
> CCing Pedro; Pedro: hi! Does this sound sane?
> (for reference, the GCC patch we're discussing here is:
> https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01685.html )
Sure!
Thanks,
Pedro Alves
On 04/27/2018 02:41 AM, Alan Modra wrote:
> This patch adds ATTRIBUTE_NONSTRING, which will be used to curb
> -Wstringop-truncation warnings in binutils. OK to apply?
>
> * ansidecl.h (ATTRIBUTE_NONSTRING): Define.
+1, FWIW.
Thanks,
Pedro Alves
On 04/17/2018 11:10 PM, Joshua Watt wrote:
> On Tue, 2018-04-17 at 22:50 +0100, Pedro Alves wrote:
>> On 04/17/2018 06:24 PM, Joshua Watt wrote:
>>> Ping? I'd really like to get this in binutils, which apparently
>>> requires getting it here first.
>>
>>
On 04/17/2018 06:24 PM, Joshua Watt wrote:
> Ping? I'd really like to get this in binutils, which apparently
> requires getting it here first.
I think it would help if you mentioned what this is and
what is the intended use case.
Was this discussed on the binutils or gdb lists?
Th
On 04/02/2018 11:34 PM, Martin Sebor wrote:
> On 04/02/2018 12:09 AM, Sandra Loosemore wrote:
>> On 03/27/2018 03:21 PM, Pedro Alves wrote:
>>> On 03/27/2018 09:19 PM, Martin Sebor wrote:
>>>> On 03/27/2018 01:38 PM, Pedro Alves wrote:
>>>>&g
On 03/27/2018 09:19 PM, Martin Sebor wrote:
> On 03/27/2018 01:38 PM, Pedro Alves wrote:
>> On 03/27/2018 07:18 PM, Martin Sebor wrote:
>>> +Because a @code{pure} function can have no side-effects it does not
>>
>> FWIW, I'd suggest rephrasing as:
>>
>&
to have no side effects", which gave me pause
when I read it the first time, and is the opposite of
what you mean.
Thanks,
Pedro Alves
On 02/14/2018 09:47 PM, Manuel López-Ibáñez wrote:
> On 14 Feb 2018 8:16 pm, "Pedro Alves" <mailto:pal...@redhat.com>> wrote:
>
> Instead of a class that has to have a constructor for every type
> you want to pass as plural selector to the _n functions,
thing", "%wu things", i);
This is similar in spirit to std::to_string, etc.
BTW, the "plural_form" naming above comes from ngettext's documentation
of the N parameter:
char * ngettext (const char *msgid1, const char *msgid2, unsigned long int n);
"The parameter n is used to determine the plural form."
Pedro Alves
to make it self-describing?
Something around:
/* Comment/url here. */
unsigned long
plural_form_for (unsigned HOST_WIDE_INT val)
{
return (val > ULONG_MAX
? (val % 100) + 100
: val);
}
and then:
inform_n (loc, plural_form_for (eltscnt),
"while %qT decomposes into %wu element",
"while %qT decomposes into %wu elements",
type, eltscnt);
Pedro Alves
ic patch
that will help open GCC to many more use cases. The fact that
plugins don't work on Windows has been a sore spot, IMO.
I for one am very happy that this make gdb's libcc1 plugin
a viable option for Windows. Puts us one step closer to the
long term plan of making GDB always use GCC for C/C++
expression parsing/evaluation. Yay. :-)
Thanks,
Pedro Alves
an use include/ansidecl.h's DISABLE_COPY_AND_ASSIGN for
this [1], and then you don't need the comment, as it's
self-documenting.
[1] - https://marc.info/?l=gcc-patches&m=150549025810729&w=2
(gcc.gnu.org seems to be unreachable for me today.)
Thanks,
Pedro Alves
f-assign from this->speed_p? should the "speed_p" param
>> be renamed, e.g. to "speed_p_")
>
> Yes. Fixed.
The convention also says:
"When structs and/or classes have member functions, prefer to name
data members with a leading m_".
So in this case, the preference would be to rename this->speed_p to
m_speed_p instead.
Thanks,
Pedro Alves
rs [numeric.wide_integer.cons]
constexpr wide_integer() noexcept = default;
Effects: A Constructs an object with undefined value.
~~~
Thanks,
Pedro Alves
now
> about it.
There is: make the base class destructor protected.
Thanks,
Pedro Alves
that,
#2 - whether there's an easy to install package providing a
new-enough compiler.
and it turns out that that was true for all. Meanwhile another year
has passed and there have been no complaints.
Thanks,
Pedro Alves
to grok and spot the bug.
In the case above, I'd much prefer if the compiler tells me
I missed initializing 't' than initializing it to 0 "just
in case".
Thanks,
Pedro Alves
ves T::i default initialized, i.e.,
uninitialized, while T() value-initializes T::i, i.e.,
initializes it to zero.
So if that's a concern, maybe you could use "= default"
conditionally depending on #if __cplusplus >= C++11, so that
you'd get it for stages after stage1.
Or just start requiring C++11 already. :-)
Thanks,
Pedro Alves
On 10/23/2017 07:15 PM, David Malcolm wrote:
> OK for trunk?
FAOD, FWIW, LGTM.
Thanks,
Pedro Alves
use (or they should!). FWIW, GDB also doesn't want
such naked abort() calls, I don't recall people-sneaking-in-abort-()-calls
ever being a problem over there.
Thanks,
Pedro Alves
em headers (or
something like that), then you wouldn't need this manual management
of header dependencies in gcc/system.h and the corresponding
'#define INCLUDE_FOO' contortions. There's nothing that you can reasonably
do with a reference to a poisoned symbol in a system header, other than
avoid having the system header have the '#pragma poison' in effect when
its included, which leads to contortions like system.h's. Note that
the poisoned names are _still used anyway_. So can we come up with
a GCC change that would avoid having to worry about manually doing
this? It'd likely help other projects too.)
Thanks,
Pedro Alves
std::unique_ptr is defined:
#if __cplusplus >= 201103
/* In C++11 mode, all we need is import the standard
std::unique_ptr. */
template using unique_ptr = std::unique_ptr;
> Ok to unbreak bootstrap.
Thanks,
Pedro Alves
d time
>> to do it for GCC8.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> Makes sense to me.
+1 from me, FWIW.
Thanks,
Pedro Alves
a very
recent libstdc++ commit from Jon had:
* include/bits/stl_map.h (map::insert(value_type&&))
(map::insert(const_iterator, value_type&&)): Add overload for rvalues.
I.e., simply use the full prototype as function name, since it's
really what it is in C++.
Thanks,
Pedro Alves
("gcc111" in the
> compile farm; gcc 4.8 i.e. gnu++03)
>
> Is this OK?
Looks great to me.
> +/* Verify that gnu::unique_malloc_ptr works. */
Typo: malloc -> xmalloc. Appears in other comments too.
Thanks,
Pedro Alves
Might make
sense to switch to using gnu::unique_xmalloc_ptr instead.
GDB does have an xfree function that we call instead
of free throughout (that's where the reference David fixed
comes from). We can most probably just switch to free too nowadays.
Also, gdb nowadays also has a gdb::unique_xmalloc_ptr specialization
that this patch is missing (because the specialization was added
after switching to C++11):
[pushed] Allow gdb::unique_xmalloc_ptr
https://sourceware.org/ml/gdb-patches/2017-08/msg00212.html
So we'd need that before switching. I don't recall off hand whether
it's easy to make that work with the C++03 version.
Thanks,
Pedro Alves
gine that it'd
be much objectionable, and having a standard type may help
tooling give better diagnostics and suggestions.
Thanks,
Pedro Alves
sers follow the advice, they'll end up with:
void foo (const char *s = "...");
typedef void F (...);
F *pf = (F *)foo;
pf ();
which still compiles silently and calls the foo
function incorrectly.
Thanks,
Pedro Alves
extern void foo (int, int);
typedef void (type_erased_func) (); // note: void dropped
type_erased_func *func = (type_erased_func *) foo;
int main ()
{
func (1, 2); // whoops, now silently compiles
}
I think it'd be good if this were weighed in as well. If 'void ()'
is picked as the special type, then maybe the above could
be at least addressed in the documentation, and/or
diagnostics/notes.
Thanks,
Pedro Alves
uiltin. Then it'd work on C++03 as well, and the compiler of course
can precisely validate whether the cast is valid. (It's quite possible
that there's a better check than is_polymorphic as I've written above.)
Just a passing thought.
Thanks,
Pedro Alves
On 09/15/2017 05:15 PM, Pedro Alves wrote:
> On 09/15/2017 01:04 PM, Nathan Sidwell wrote:
>>
>>
>> Pedro, would you like me to port to gdb's libiberty, or will you do a
>> merge in the near future?
>
> I wasn't planning to, but I'm doing it n
On 09/15/2017 01:04 PM, Nathan Sidwell wrote:
>
>
> Pedro, would you like me to port to gdb's libiberty, or will you do a
> merge in the near future?
I wasn't planning to, but I'm doing it now.
Thanks much for the fix!
--
Pedro Alves
ncing
the trees, I'm pushing the patch to gcc as is.
Thanks,
Pedro Alves
>From 47ba729a29c6fa2283835d95d2ab5695d8c5d732 Mon Sep 17 00:00:00 2001
From: Nick Clifton
Date: Mon, 31 Jul 2017 15:08:32 +0100
Subject: [PATCH] Fix compile time error when using ansidecl.h with an old
version of GCC.
On 09/15/2017 01:53 PM, Jakub Jelinek wrote:
> On Mon, Aug 07, 2017 at 02:17:17PM +0100, Pedro Alves wrote:
>> I happened to skim this patch and notice a couple issues.
>> See below.
>
> Note I've just posted updated patch based on this to gcc-patches.
Thanks ( FWIW :-)
eprecated.
> @end table
I think you meant to say that gnu++1z is deprecated, not gnu++17.
Thanks,
Pedro Alves
ine.
>>>
>>> libiberty/
>>> * dwarfnames.c (DW_CFA_DUP): New define.
>>>
I'd like to add a +1 vote for this patch. I was confused more than once
in the iterations of the pending gdb patch that were adding references
to "DW_CFA_GNU_window_save" in Aarch64 code that has absolutely nothing
to do with SPARC register windows, and asked Jiong whether we could add
an Aarch64-specific name for the constant.
Thanks,
Pedro Alves
On 09/05/2017 05:52 PM, Manuel López-Ibáñez wrote:
> On 05/08/17 20:05, Pedro Alves wrote:
>> That'd be an "obvious" choice, and I'm not terribly against it,
>> though I wonder whether it'd be taking over a name that has a wider
>> scope than intende
On 09/04/2017 11:31 AM, Richard Biener wrote:
> On Fri, Aug 11, 2017 at 10:43 PM, Jonathan Wakely wrote:
>> On 05/08/17 20:05 +0100, Pedro Alves wrote:
>>>
>>> On 08/04/2017 07:52 PM, Jonathan Wakely wrote:
>>>>
>>>> On 31/07/17 19:46 -0400, tbs
;, but not if C_COMPILER_NAME is
already:
"$whatever_triplet_libcc1_happened_to_be_built_with" + "-gcc"
because we end up with:
"$gdb_specified_triplet_re" + "-"
"$whatever_triplet_libcc1_happened_to_be_built_with" + "-gcc"
which is the problem case.
In sum, I think the libcc1.so (not the plugin) should _not_ have baked
in target awareness, and thus C_COMPILER_NAME should always be "gcc", and
then libcc1's regex should be adjusted to also tolerate a suffix in
the final compiler binary name regex.
WDYT?
Thanks,
Pedro Alves
On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote:
> On Wednesday, August 23 2017, Pedro Alves wrote:
>
>> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote:
>>> The GCC patch improves the libcc1::compiler_triplet_regexp::find and
>>> libcp1::compiler_triplet
ndependently of the presence of the triplet
> string in the compiler name. I am sorry about the cross-post, but these
> patches are really dependent on one another.
Is there a backward/forward compatibility impact?
Does new GDB work with old GCC?
Does old GDB work with new GCC?
Thanks,
Pedro Alves
to put this macro in include/ansidecl.h so that
>>> other projects can use it too.
>>>
>>> Boostrapped on x86_64-linux-gnu. Is it OK?
>>>
>>> include:
>>>
>>> 2017-07-19 Yao Qi
>>> Pedro Alves
>>
t think
there's a reason it can't work with vec. Since std::sort is
a template, the inlining + indirection avoidance often results
in faster sorts (potentially at the expense of compile time).
Consistency checking could be implemented by adding a a gcc::sort
wrapper around std::sort (and calling the former throughout).
Thanks,
Pedro Alves
ng) == CLK_GNUCXX1Z)
> _cpp_define_builtin (pfile, "__cplusplus 201703L");
>else if (CPP_OPTION (pfile, lang) == CLK_CXX14
>
Thanks,
Pedro Alves
obvious" choice, and I'm not terribly against it,
though I wonder whether it'd be taking over a name that has a wider
scope than intended? I.e., GNU is a larger set of projects than the
GNU toolchain. For example, there's Gnulib, which already compiles
as libgnu.a / -lgnu, which might be confusing. GCC doesn't currently
use Gnulib, but GDB does, and, there was work going on a while ago to
make GCC use gnulib as well.
Thanks,
Pedro Alves
www.sourceware.org/gdb/onlinedocs/stabs.html
https://www.sourceware.org/gdb/onlinedocs/stabs.html#Source-Files
Thanks,
Pedro Alves
; for a while first.
OK.
BTW, for extra thoroughness, to confirm we're handling both
const & non-const arrays correctly, I had written this testsuite
tweak too. Would you like to have this in?
>From 3f7adab8bab68955aafd760467bb860057140d40 Mon Sep 17 00:00:00 2001
From: Pedro Alves
\
"-DSTACK_SIZE=[dg-effective-target-value stack_size]" \
{ target { stack_size } } } */
Might be less magical and simpler to implement too.
Thanks,
Pedro Alves
On 06/08/2017 12:19 PM, Marek Polacek wrote:
> On Thu, Jun 08, 2017 at 12:01:03PM +0100, Pedro Alves wrote:
>> On 06/08/2017 11:29 AM, Marek Polacek wrote:
>>> On Wed, Jun 07, 2017 at 08:02:42PM +0100, Pedro Alves wrote:
>>>> Hi Marek,
>>>>
>>>>
On 06/08/2017 11:29 AM, Marek Polacek wrote:
> On Wed, Jun 07, 2017 at 08:02:42PM +0100, Pedro Alves wrote:
>> Hi Marek,
>>
>> Nice warning! Just to confirm, would the patch warn with code like:
>
> Thanks. BTW, if you (or anyone) could come up with a better name,
&
);
default:
return "";
}
#undef CASE
};
?
I think it shouldn't, but I couldn't tell from the tests,
and the only similar instance I found in gcc is guarded
behind an #ifdef (in eh_data_format_name).
Thanks,
Pedro Alves
On 05/20/2017 02:27 AM, DJ Delorie wrote:
>
> Pedro Alves writes:
>> That sounds to me like the root issue that should be fixed,
>> so that these fallback definitions don't come into into play at all.
>> I.e., why isn't HAVE_ENVIRON_DECL defined on mingw when
&g
On 05/20/2017 01:38 AM, DJ Delorie wrote:
>
> Pedro Alves writes:
>> Ah, yeah. AFAICS, all the declaration checks in libiberty.h are
>> HAVE_DECL checks. This suggests to me that this declaration guard
>> should be HAVE_DECL too [1].
>
> Except the ones in t
/libiberty_m4
I never tried adjusting gcc, but even if it wouldn't
work there, it'd still be a net win.
Wonder what others think of that approach.
Thanks,
Pedro Alves
igure defines HAVE_DECL_STRNLEN. Header guards need
> to be coordinated across all the users, not just libiberty.
>
The "user" in this case is libiberty itself.
Thanks,
Pedro Alves
On 05/19/2017 04:40 PM, Eli Zaretskii wrote:
>> Cc: gdb-patc...@sourceware.org, Thomas Schwinge
>> From: Pedro Alves
>> Date: Fri, 19 May 2017 16:22:55 +0100
>>
>> But then, xstrndup.c has at the top:
>>
>> #ifdef HAVE_STRING_H
>> #include
eclare/define
it is if it weren't?
That sounds to me like the root issue that should be fixed,
so that these fallback definitions don't come into into play at all.
I.e., why isn't HAVE_ENVIRON_DECL defined on mingw when
setenv.o is built? Sounds like a decl check is missing
in configure.ac.
Thanks,
Pedro Alves
er whether we could just unconditionally remove the waitpid
replacement instead.
Thanks,
Pedro Alves
NG_H
#include
#else
# ifdef HAVE_STRINGS_H
# include
# endif
#endif
So I would expect your build to pick the strnlen declaration from
one of the string.h or strings.h mingw headers. Why didn't it?
Thanks,
Pedro Alves
and later)
terms -- i.e., say "value-initializing it" instead.
> + T (bzero, (p, sizeof *p));// { dg-warning "bzero" }
> + T (memset, (p, 0, sizeof *p)); // { dg-warning "memset" }
> + T (memset, (p, i, sizeof *p));// { dg-warning "memset" }
Thanks,
Pedro Alves
On 05/17/2017 02:55 AM, Martin Sebor wrote:
> On 05/16/2017 04:48 PM, Pedro Alves wrote:
>> On 05/16/2017 08:41 PM, Jason Merrill wrote:
>>
>>> I agree that it makes sense to
>>> check for a trivial assignment operator specifically. I guess we want
>>&g
;s no longer strictly about "trivial" in the
standard C++ sense. The documentation talks about "The safe way",
and "does not warn on safe calls", so maybe call it -Wunsafe-memaccess?
(I spotted a couple typos in the new patch: "otherwse", "becase", btw.)
Thanks,
Pedro Alves
t; but I'm starting to think
> that rather than adding yet another option to GCC it might be better
> to extend your -Wenum-conversion once it's committed to cover those
> cases (and also to avoid issuing multiple warnings for essentially
> the same problem). Let me ponder that some more.
Thanks,
Pedro Alves
t, (unsigned char *) src, sizeof (*src)); //
doesn't warn
}
I can understand how we end up like that, given char's magic properties, but
still
I think many will reach for "void" first if they (really really) need to add a
cast to
silence the warning. In any case, I think it'd be very nice to add cases with
such
casts to the new tests, and maybe mention it in the documentation too.
Thanks,
Pedro Alves
On 04/28/2017 08:01 PM, Pedro Alves wrote:
> On 04/28/2017 05:28 PM, Martin Sebor wrote:
>> On 04/28/2017 05:47 AM, Nathan Sidwell wrote:
>
>>>> @@ -427,9 +429,31 @@ static void output_lines (FILE *, const source_t
>>>> *);
>>>> static cha
uses
at compile time:
https://sourceware.org/ml/gdb-patches/2017-04/msg00378.html
https://sourceware.org/ml/gdb-patches/2017-04/msg00381.html
Thanks,
Pedro Alves
1 - 100 of 257 matches
Mail list logo
