, though.
Cheers,
Pedro Alves
Joe Buck wrote:
It might be worth doing. I think that, in addition to a patch,
I'd like to see measurements (maybe just the size increase in
libstdc++.{a,so}). If the cost is small, I will not object.
If the cost turns out non-small, this could be enabled at -g3?
Cheers,
Pedro Alves
am not a big fan of google groups mailinglists, they seem
> to make it hard to subscribe and don't have easy to access archives.
> Having a local gnu-gabi group on sourceware.org would be better IMHO.
+1
--
Pedro Alves
is missing on the web page above.
>
One can also subscribe using the form at:
https://sourceware.org/lists.html
(I used that.)
BTW, is the intention for the mailing lists list on that page to be
fully comprehensive? Off the top of my head, I notice that at least
the infinity@ list is missi
king on it (Keith, Alex, Phil), who could perhaps fill us in on
status. It'd be great if more people got engaged in the project,
of course!
Thanks,
Pedro Alves
s that make use of gnulib. Meaning,
gdb #includes _two_ "config.h" files. See gdb/common/common-defs.h.
Thanks,
Pedro Alves
really _need_ to consider sharing right now.
gcc can start slow, and import and convert to use gnulib modules
incrementally, instead of having it import all the modules
gdb is importing from the get go.
Thanks,
Pedro Alves
test in a particular
mode with the above in mind. Given that reordering the boards makes
a difference, it kind of sounds like some "last checked mode" or some
such variable is bleeding between runs.
Thanks,
Pedro Alves
On 08/23/2016 10:54 AM, Jonathan Wakely wrote:
>> That's being set by prettyprinters.exp and xmethods.exp (so it's GDB's
>> fault! ;-)
:-)
> This seems to work. I'll do some more testing and commit later today.
LGTM.
Though IME, save/restoring globals in a constant source of trouble,
for occa
from the
function name, and end up with _really_ unclear call sites:
observer_notify_user_selected_context (1, 1, 1, 0, 1);
/*foo_p=*/ -style comments would help clarify the intent at the call
sites, but then the compiler won't catch mistakes for you. Enums are
clearly superior, at least compared to multiple boolean parameters, IMO.
Thanks,
Pedro Alves
On 10/05/2016 05:12 PM, Jeff Law wrote:
> On 10/04/2016 03:08 PM, Jason Merrill wrote:
>> On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote:
>>> On 10/04/2016 02:00 PM, Martin Sebor wrote:
This would have been easier if C++ had allowed the same default
value to
be given in both the dec
call xmalloc
instead of malloc. See the GDB url in the PR for an example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822#c19
> And in particular: How do the current uses of
> std::string in GCC deal with this problem? (Do they?)
Doesn't look like they do.
Thanks,
Pedro Alves
On 12/16/2016 06:31 PM, Janus Weil wrote:
> 2016-12-16 18:53 GMT+01:00 Pedro Alves :
>> On 12/16/2016 05:33 PM, Janus Weil wrote:
>>> And in particular: How do the current uses of
>>> std::string in GCC deal with this problem? (Do they?)
>>
>> Doesn't l
On 12/16/2016 06:04 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote:
>> To get to more specific questions ...
>>
>>> Basically the only STL construct used in the Fortran FE right now
>>> seems to be std::swap, and a single instance of std::map in
>>> trans-comm
On 12/16/2016 06:56 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:52:03PM +0000, Pedro Alves wrote:
>> GDB has a string_printf function that prints into a std::string, for
>> example. Like:
>>
>> std::string hello = string_printf ("%s", "hello
On 12/17/2016 10:58 AM, Janus Weil wrote:
> 2016-12-16 19:46 GMT+01:00 Pedro Alves :
> So, it seems like it would be a good idea to follow your suggestion
> from PR 78822:
>
>
>> You can replace the global operator new/new[] to call xmalloc instead of
>> malloc.
>&
to me, as it leaves the problem
with all "new" expressions that call global op new in
the codebase, like I mentioned? (And you'd have to do that
for all containers that you'd want to use.)
Am I missing something?
Thanks,
Pedro Alves
On 12/17/2016 01:07 PM, Jonathan Wakely wrote:
> On 17 December 2016 at 12:28, Pedro Alves wrote:
>> On 12/17/2016 12:23 PM, Jonathan Wakely wrote:
>>> Instead of replacing the global new operator we could write a custom
>>> allocator that uses xmalloc, and we can
On 12/17/2016 05:24 PM, Jakub Jelinek wrote:
> On Sat, Dec 17, 2016 at 11:17:25AM -0500, Frank Ch. Eigler wrote:
>> Pedro Alves writes:
>>
>>> [...]
>>> malloc will fail, new will throw bad_alloc, and GCC will abort and
>>> maybe generate a core dump, in
^^^
So the issue is moot.
> Plus, they can always start the bootstrapping process with GCC 4.9.
They'd have to go much further back than that.
--
Pedro Alves
nks.
Would it make sense for someone to pick this
https://gcc.gnu.org/wiki/GimpleFrontEnd
up where it was left off?
Thanks,
Pedro Alves
le
longer in GDB. But if GCC jumps to C++14, I think GDB would
follow along. Just FYI.
C++03 -> C++11 makes a great difference. Particularly
std::move and rvalue references are a game changer.
Thanks,
Pedro Alves
e
> C++98 + -Wnarrowing, and then GCC 11 could be full C++11. Plus then
> the GCC version numbers would also line up with the version of C++
> being used.
Thanks,
Pedro Alves
and above, which is
GDB's minimum requirement. I'm not sure about 4.8.x patch level.
Thanks,
Pedro Alves
not GCC itself. See:
https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
Thanks,
Pedro Alves
[2] -
<https://channel9.msdn.com/Shows/CppCast/Episode-83-Regular-Void-with-Matt-Calabrese>,
end of last Feb, at min 14 onward.
( Please don't shoot the messenger. :-) )
Thanks,
Pedro Alves
mostly plain old
configure/make/make install IIRC, assuming new-enough tcl/expect.
Building a newer tcl/expect would be a bit more work of course.
Thanks,
Pedro Alves
latter would likely
> take down the driver process, too, so a kernel-originated SIGKILL
> strongly points to the OOM killer.
>
> But the kernel could definitely do better and set a flag for SIGKILL.
Meanwhile, maybe just having the driver check for SIGKILL and
enumerate likely causes would be better than the status quo.
Pedro Alves
others find that useful too.
Thanks,
Pedro Alves
operator new is something that is totally
defined by the standard (unlike -fno-exceptions).
See "global replacements"
at <http://en.cppreference.com/w/cpp/memory/new/operator_new>.
[2] - Or in many cases, use a std::vector instead. And if
you care about not value-initializing elements, see gdb's
gdb/common/{def-vector, default-init-alloc}.h.
Thanks,
Pedro Alves
On 05/22/2018 12:14 PM, Maciej W. Rozycki wrote:
> On Tue, 15 May 2018, Maciej W. Rozycki wrote:
>
>> gdb/
>> * i387-tdep.c (i387_collect_xsave): Make `i' unsigned.
>
> Ping for: <https://patchwork.sourceware.org/patch/27269/>.
OK.
Thanks,
Pedro Alves
hem in bugzilla.
Thanks,
Pedro Alves
easily get lost, the problem is the length of
> the function, not the use of a reference.
>
+1000. This seems really unnecessary. References have the advantage
of implicit never-null semantics, for instance.
Pedro Alves
On 07/12/2018 05:17 PM, Richard Sandiford wrote:
> Pedro Alves writes:
>> (an
>>> alternative to pointers is to return a struct with the wide int result
>>> and the overflow flag),
>>
>> +1. I've been pushing GDB in that direction whenever possible.
&
On Monday 16 February 2009 11:19:52, Vincent R. wrote:
> I used to have .align 0 with gcc-4.1 and now I get a .align 4, how can I
> change that ?
It was a bug in the patches I had sent you months ago. I've posted the
latest patch I had here at cegcc-devel@ --- it should fix this.
config/i386/winnt-cxx.c,
config/i386/winnt-stubs.c for ARM as well. E.g, currently, I've copied
config/i386/winnt.c over the current config/arm/pe.c (completelly replacing
it), and adjusted it a bit to make it work for ARM. As you can see from
the hunk below, the main juice is shareable he
nits_ceil (x + BITS_PER_UNIT - 1) / BITS_PER_UNIT
> bit_unit_remainder x % BITS_PER_UNIT
> units_in_bits x * BITS_PER_UNIT
--
Pedro Alves
On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote:
> Quoting Pedro Alves :
>
> > On Tuesday 23 November 2010 20:09:52, Joern Rennecke wrote:
> >> If we changed BITS_PER_UNIT into an ordinary piece-of-data 'hook', this
> >> would not only cost
Hi!
I noticed the discussions about making cp-demangle use malloc/free instead of
recursion,
and I wonder about signal handlers, and I don't see that mentioned in
https://gcc.gnu.org/wiki/SummerOfCode's description of the project.
See my question to Ian a few years back, here, and his answer:
quux_p, whatnot diverging styles.
And it would be nice if GCC followed the same nomenclature style as GDB, so we
could
have one single guideline for the whole GNU toolchain, so people moving between
codebases
only had to learn one guideline.
Pedro Alves
On 2022-07-12 11:21 a.m., Florian Weimer wrote:
> * Pedro Alves:
>
>> For example, for the type above, we'd have:
>>
>> typedef std::unique_ptr pending_diagnostic_up;
>>
>> and then:
>>
>>
On 2022-07-12 11:45 a.m., Jonathan Wakely wrote:
> On Tue, 12 Jul 2022 at 11:22, Florian Weimer via Gcc wrote:
>>
>> * Pedro Alves:
>>
>>> For example, for the type above, we'd have:
>>>
>>> typedef st
On 2023-05-12 7:01 a.m., Po Lu via Gcc wrote:
> Jason Merrill writes:
>
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which
On 2024-05-01 22:26, Mark Wielaard wrote:
> For now I am cleaning up Sergio's gerrit setup and upgrading it to the
> latest version, so people can at least try it out. Although I must
> admit that I seem to be the only Sourcewware PLC member that believes
> this is very useful use of our resources.
On 2024-05-01 22:04, Simon Marchi wrote:
> The Change-Id trailer works very well for Gerrit: once you have the hook
> installed you basically never have to think about it again, and Gerrit
> is able to track patch versions perfectly accurately. A while ago, I
> asked patchwork developers if they w
e satisfied by the interfaces I and other previous plugin authors have
already added to GCC by then.
But, note it's clearly the plugin author that needs to write #2. #1 too,
obviously. :-)
--
Pedro Alves
sn't
seem to be a good reason other users couldn't also use it, and hence it
should get a non-hackish name and be documented; or it isn't sensible, and
then it shouldn't exist. Why the second-class treatment?
--
Pedro Alves
? I haven't seen any hint on what the better, cleaner,
way to accomplish this is.
--
Pedro Alves
set to be able to use -Werror, such as e.g., GDB.
Certainly not insurmountable (just add a -Wno-all), but does
require actively tweaking the build system. I'm sure there
are many projects affected similarly.
--
Pedro Alves
cally
> I don't think we should warn about unused static functions or variables
> by default.
Yes, I would agree more with something like that.
--
Pedro Alves
't help GCC's cause when people keep repeating that outdated info :-)
Spelling out the obvious, IWBVN if someone from the gcc camp did a
similar comparison using a current gcc. Is there such a page somewhere?
--
Pedro Alves
s should be the ones doing the
> comparisons really ;-)
Excellent, thank you!
--
Pedro Alves
ode is
already "clean" enough. It would simply be documented as:
"-W3: Warn yet more. -W3 turns on all warnings specified by -W2 and also ...".
I'll also note the parallel with -glevel, not just -O.
So, 'gcc -glevel -Wlevel -Olevel' feels quite natural to me.
--
Pedro Alves
On 04/12/2012 04:52 PM, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 10:43 AM, Pedro Alves wrote:
>> On 04/12/2012 04:23 PM, Gabriel Dos Reis wrote:
>>
>>> because -Os says it optimizes for size, the expectation is clear.
>>> -O3 does not necessarily
. All else
is pretty much as good as new to me. :-)
--
Pedro Alves
55 matches
Mail list logo
