Good day fine fellows!
[...]
Mark Wielaard a écrit:
> Also Dodji, Jose and Gwen (on CC) are trying to coordinate a Fosdem
> devroom for the various projects. Please contact them if you want to
> help out with that.
So, José, Guinevere and myself have requested a "Binary Tools" devroom
as well
[I have changed Tom Tromey's email address to his current one]
Hello Tobias,
Just for the record -- as I am trimming the original post for legibility
-- the initial message I am replying to can be read at
https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html.
Tobias Burnus writes:
[...]
> Do you h
Hello Prathamesh,
Prathamesh Kulkarni writes:
> I have written notes for "libabigail - Towards Better ABI
> compatibility checking" presented at Cauldron. I would be grateful if
> you would review it for me.
Thank you for writing these notes.
[...]
> A first official release is available at:
Prathamesh Kulkarni writes:
>
> Shall it be correct then to replace calls to error() and friends,
> taking only format string with no-argument specifiers
> to error_at_no_args() ? (similarly we shall need warning_at_no_args,
> pedwarn_no_args, etc.)
I would guess so, yes.
>>
>> Also, you'd need
"Joseph S. Myers" a écrit:
> On Wed, 22 Jan 2014, Prathamesh Kulkarni wrote:
>
>> Unfortunately, I am not clear on how to check for format specifiers in
>> string.
>> Should I do it manually by checking the format string for specifiers
>> and call abort if found a no-argument specifier,
>> or is
Hello Robert,
Robert Schiele a écrit:
> in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48778 Manuel
> López-Ibáñez mentioned that starting with gcc 4.7 there is supposed to
> be infrastructure to figure out for diagnostics whether the location
> of an error was created by macro expansion and tha
Jason Merrill a écrit:
> If we already give an error, we don't want to give a redundant
> warning. I'm confused about what you're asking here.
Ah, I thought g++ was just emitting an error with -std=something. It's
actually is emitting the error by default. It's just cc1 that needs
changing the
Jonathan Wakely a écrit:
> A return statement with no operand is always wrong, but -Wreturn-type
> also warns about this, which is valid:
>
> int f(int c)
> {
> if (c)
>return 0;
> function_that_never_returns();
> }
>
[...]
> So maybe it makes sense to split -Wreturn-type to sep
Sylvestre Ledru a écrit:
> I would like to propose the activation by default of -Wreturn-type.
>
> The main objective would to provide a warning for such code:
>
> int foo() {
> return;
> }
>
> For now, it is only enabled when we have -Wall:
> $ gcc -c foo.c
> $ gcc -Wall -c foo.c
> foo.c:
Gerald Pfeifer a écrit:
> I am happy to announce Dodji Seketeli as diagnostics framework
> maintainer.
>
> Thanks for your contributions and agreeing to fill this role, Dodji!
Thank you!
> And thanks to Gaby for his contributions in this area over the years
> and the prof
Jonathan Wakely a écrit:
> I've reverted or deleted all the spam I could find (and that you
> hadn't already done) and have added lots of people to the EditorGroup
> who had made good changes in the past.
Thank you for doing this. It's appreciated.
--
Dodji
Richard Biener a écrit:
> Support for constructing and destructing GC objects will be another
> story of course.
Just curious. Does supporting this take more than just defining new and delete
operators that call ggc_alloc_*/ggc_free in there?
(OK, that and defining the object walking routines
Jason Merrill a écrit:
> I'd like to make some changes to the GCC git-svn mirror.
> Specifically, I want to move all the SVN branches from remotes/ into
> heads/ and split the subdirectory branches (redhat, google, etc) into
> the individual branches.
>
> Should I leave the SVN branches as they a
Alec Teal a écrit:
> I'd love to help with GCC, without documentation (in fact, without
> instructions) I have no hope of doing so. Maybe instruct/ask people to
> do stuff?
If I may propose something, I think a reasonable way of starting is to
pick an (easy) bug from bugzilla and try to fix it.
Konstantin Serebryany a écrit:
> When we have a code like X++ (either RMW, or a regular increment) it
> is enough for asan to instrument it just once (either as a read or a
> write, doesn't matter).
> LLVM implementation does this optimization for regular increments,
> while GCC does not (yet).
>
Jiri Palecek a écrit:
> Ulf Magnusson wrote:
>> On Wed, Nov 14, 2012 at 6:10 PM, Piotr Wyderski
>> wrote:
>>> The following snippet:
>>>
>>> class A {};
>>> class B : public A {
>>>
>>> typedef A super;
>>>
>>> public:
>>>
>>> class X {};
>>> };
>>>
>>>
>>> class C : public B {
>>>
>>>
Hello,
This message is just an excuse to kick off a discussion about how we
should proceed to prepare the merge of the AddressSanitizer branch
into trunk, as the not-yet known date of the stage1 closing seems to
be approaching fast now.
Here are some topics that I think would be interesting to di
Diego Novillo writes:
> On 2012-10-02 05:45 , Richard Guenther wrote:
>
>> Anybody else with things they want to merge during stage1?
> Finally, I've been thinking of porting asan/tsan to replace
> mudflap. Dodji, you expressed interest in it recently.
Yes I did. A bit too recently, I am afrai
Hello Jiří,
I think this question should be directed at gcc-h...@gcc.gnu.org.
Please send any response to this email there.
Jiří Paleček a écrit:
> I tried to run "make check-c++" from the top directory of the source
> code.
Quoted from http://gcc.gnu.org/install/configure.html:
we highly
Richard Guenther a écrit:
> On Mon, Jun 11, 2012 at 12:03 AM, Gerald Pfeifer wrote:
>> On Mon, 31 Oct 2011, Ian Lance Taylor wrote:
>>> No opinion on your actual question, but note that there is no more
>>> stage2. We now go directly from stage1 to stage3. This is just another
>>> feature of g
Alberto Lozano Alelu a écrit:
> Hello.
Hello Alberto,
> I'am developing an statement detector for c++ and I would like to
> detect if an statement is expanded from macro.
I guess you are doing this from a plugin?
> Can I detect in ast tree if an statement is expanded code from macro?
As Manu
Hello Rick,
Since nobody responded, I'll try. :-)
rick shelton a écrit:
> How does the compiler handle an in-class function definition?
> Example:
>
> // File A.h
>
> class A {
> int foo(void) { return x; }
> int bar(void);
> int x;
>
> }
>
> // File A.cc
> #include "A.h"
> int A::bar(void)
niXman a écrit:
> Hi,
Hello niXman,
> Can you please tell, auto is implemented based on the decltype
> implementation with some semantics, or they are two completely
> different implementations?
I think they are different.
> And one more question: in which files/functions I can view the
> imp
Diego Novillo a écrit:
> https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4
3. Debugging. [...] the compiler would show a stuck dump [...]
Maybe you meant a stack dump?
--
Dodji
Alberto Lozano Alelu a écrit:
> When I get a typedef, I would like to show the definition. I use:
>
> tree v_next_type=DECL_ORIGINAL_TYPE(TYPE_NAME(v_type));
>
> But this expression isn't always correct.
You are correct. There are times where typedefs are thrown away
(stripped) and only the und
Joern Rennecke a écrit:
> I think the right balance if good visibility is considered important would be
> to have this as a plugin that is shipped with the gcc distribution and
> installed by default.
That, or that a group of motivated plugins authors gets together to
create a "blessed" plugin r
er the
obvious rule.
Sorry for the inconvenience.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eeed56d..83da507 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -10,6 +10,10 @@
2011-10-20 Dodji Seketeli
+ * ggc-zone.c (ggc_internal_alloc
Romain Geissler a écrit:
> I tried to fix PLUGIN_FINISH_DECL as well to include typedefs in C++.
>
> The followings does not currently trigger the PLUGIN_FINISH_DECL
> (or not in all cases), but should them ?
> - function parameters (in the function prototype)
> - definition (with a function bo
Gabriel Charette a écrit:
>>>
>>> Hence, given that they only depend on start_location, I just have to
>>> calculate an offset between the serialized start_location and the
>>> start_location as it would be (highest_location + 1) in the C file
>>> including the header, and offset all of the sourc
Gabriel Charette a écrit:
> Actually from my understanding, highest_location is not equal to the
> last start_location, but to the last source_location returned by
> either linemap_line_start or linemap_positition_for_column (which is
> >>= to the start_location of the current line_map).
Right,
Gabriel Charette a écrit:
> From what I understand, the source_locations allocated for
> everything in a given set of headers (from the LC_ENTER for the
> header in the line_table up to, and including everything in between,
> the corresponding LC_LEAVE) is dependent on only one thing; the
> value
Gabriel Charette a écrit:
> Alright, so after looking even more at the linemap code, here is what
> I'm thinking now:
>
> So the main problem is:
> with the linemap logic is that linemap_line_start adds a new table
> entry if line_delta < 0 (I don't understand why this is needed, my
> assumption
Gabriel Charette a écrit:
>> Gabriel> @tromey: I hear you are the person in the know when it comes down to
>> Gabriel> linemaps, do you have any hint on how we could rebuild a valid
>> Gabriel> line_table given we are obtaining the bindings from the last one in
>> Gabriel> the file to the first o
Hello Boris,
Boris Kolpackov a écrit:
> Hi Dodji,
>
> Dodji Seketeli writes:
>
>> Boris Kolpackov a =C3=A9crit:
>>
>> > struct s {};
>> >
>> > typedef s s_t;
>> > typedef s_t my_s_t;
>> >
>> > my_s_t x;
&
Hello Boris,
Boris Kolpackov a écrit:
> I am trying to figure out how to get a typedef hierarchy from the C/C++
> tree in GCC. Consider the following declarations:
>
> struct s {};
>
> typedef s s_t;
> typedef s_t my_s_t;
>
> my_s_t x;
>
> Giveb 'x' VAR_DECL I can have this traversal using TYPE_
Hello Ludovic,
ludovic.cour...@inria.fr (Ludovic Courtès) a écrit:
> The attached plug-in builds a function like this:
>
> my_function (void * parm.0)
> {
> __builtin_puts (parm.0);
> }
>
> However, the generated assembly clears the first-argument register
> (%edi) before calling ‘puts’
Richard Henderson writes:
> On 02/10/2011 06:32 AM, Dodji Seketeli wrote:
>> For the sake of archiving these tricks how do you postpone garbage
>> collection in practise?
>
> Set --param ggc-min-heapsize to a very large value.
That wouldn't work for pieces of
Joern Rennecke writes:
> Quoting Tom Tromey :
>
>>> "Basile" == Basile Starynkevitch writes:
>>
>> Basile> So I need to understand who is writing the 0x101 in that field.
>
>
>> One thing to watch out for is that the memory can be recycled. I've
>> been very confused whenever I've forgotten
Hello GCC hackers!
You might know it already but the 2012 edition of the FOSDEM[1]
conference is approaching. Fast. It turns out the GNU project will have
a dedicated development room this time. So it would be nice if GCC
people could talk about their work there.
Please find below the formal Call
s involving dependent typedefs.
[1]: This is based on the resolution of PR c++/43800 at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01241.html
Tested on x86_64-unknown-linux-gnu against trunk and the 4.5
branch. OK to commit to both branches?
commit d9a0f93c1fda1d97cda5747003de84edd3812bda
Author: Dod
check out the relevant page of the GUADEC's
website[2].
[1]: GNOME Users And Developers Conference:
http://www.guadec.org/index.php/guadec/index
[2]: http://www.guadec.org/index.php/guadec/2010/schedConf/accommodation
--
Dodji Seketeli
On Wed, Mar 10, 2010 at 07:04:20PM +0100, Roger Ferrer Ibáñez wrote:
> Is this a known bug or I should fill a PR?
I see that you have just filed a PR for this at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43327
Thanks.
Dodji
On Sat, Jan 30, 2010 at 01:47:03AM +0200, Timothy Madden wrote:
> So nobody here wants to try a big thing ? :(
This question strikes me as being not very fair because many GCC people
are already pretty much involved. Would you fancy giving a hand?
> How long would it take for someone to understa
On Fri, Dec 04, 2009 at 12:23:27PM (+0100), Rainer Emrich wrote:
> Unfortunally this doesn't solve the issue!
It would be helpful if you could file a proper bug report with a standalone
reproducer.
Thanks.
Dodji
t
him again :)
Thanks.
--
Dodji Seketeli
Red Hat
Hello,
It seems the git mirror git://gcc.gnu.org/git/gcc.git didn't sync'ed to
the gcc svn tree since last Friday as git fetch wont grab any bits newer
than that date. Cloning from that address works OK though. It's just that
the bits are a bit old.
Is this a known issue ?
Th
w if people follow gcc-regression@).
It would certainly be useful to me at least as I check gcc-regression
before fetching new bits from the gcc repository.
Thanks.
- --
Dodji Seketeli
Red Hat, Inc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Matt,
Matt Hoosier a écrit :
> Hi,
>
> I'm having trouble compiling the following with g++ 4.2.1:
>
> class Uncopyable
> {
> public:
> Uncopyable(int x) {}
> private:
> Uncopyable(const Uncopyable & other) {}
> };
>
>
Jan Engelhardt a écrit :
On Thursday 2009-01-01 03:05, Andrew Pinski wrote:
On Wed, Dec 31, 2008 at 9:02 PM, Jan Engelhardt wrote:
Hi,
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
test.c: In function 'p
49 matches
Mail list logo
