Re: Inserting profiling function calls

[Frank Ch. Eigler]

"Michael Gong" <[EMAIL PROTECTED]> writes:

> I don't know about inserting call at the basic block level, but I am
> quite sure inserting calls at the function level could be done by
> aspect-oriented-programming (AOP). [...]

Another possibility, coming soon[1], is to use systemtap[2] probes:

% stap -e 'probe process("./a.out").function("*") { log (probefunc()) }'

Among major differences between this approach and AOP are:

- no recompilation of the target program is required: it's more like
  running a quick background scriptable debugger
- the instrumentation instead would be inserted into the
  programs on the fly via breakpoints, probably overall slower
- we rely on OS kernel facilities for those breakpoints,
  which means Linux only at this time
- the instrumentation (log...) language is rubber-padded and safe
- there can be no interference amongst concurrently running
  instrumentation packages, or upon the main program: it's non-intrusive

FWIW, yet another technology possibility I know of for this sort of
data collection is frysk[3].

- FChE

[1] "coming soon" == as soon as those kernel facilities allow
ptrace-style breakpoint insertion into user space.  At this time,
we can only probe the kernel proper.
[2] http://sources.redhat.com/systemtap/
[3] http://sources.redhat.com/frysk/

Re: mudflap vs bounds-checking

[Frank Ch. Eigler]

Christophe LYON <[EMAIL PROTECTED]> writes:

> What is the difference between the [bounds-checking and mudflap]
> systems?

Mudflap is a tree-level rewriting pass amidst the optimizers that
limits its attention to pointer dereference and addressable object
lifetime events.  It's upstream, having been donated to the FSF.

Last time I checked (quite some time back), the bounds-checking code
instrumented many more low-level pointer operations with first-class
function calls, and ran considerably slower as a consequence.  It's
not (C) FSF.

Their runtimes are different and probably have different performance
and portability/flexibility/diagnostic capabilities.  The development
intensity on both projects appears to have come down since around the
same point in time.  It would be nice not to duplicate so much, but
that's how it goes sometimes.

- FChE

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

[Frank Ch. Eigler]

Karel Gardas <[EMAIL PROTECTED]> writes:

> [...]
> class Foo
> {
> public:
> virtual unsigned short
> iiop_version() const = 0;
> };
> 
> and when I compile it, GCC emits warning from subject, although this class
> is really abstract and will never be instantiated. [...]

I guess GCC assumes that some instances of a derived class will
eventually exist, and will be dealt with via a Foo* abstract pointer.
Is it common to never attempt to delete it via that Foo* value (which
would require a virtual destructor)?


- FChE

Re: help with mudflap testsuite result analysis

[Frank Ch. Eigler]

mrs wrote:

> [...]  The question is, how decent are the results and can you spot
> any systematic wrongs that appear and/or can you identify any
> non-portableness to darwin of mudflap?  I started from 89
> passes... > :-) [...]

Most of the FAILs are "output pattern test" failures, related to some
mf-runtime.c problem locating "nearby" objects in mudflap error
messages.  Maybe this code has signedness problems on darwin.  Maybe
the malloc's from the test cases weren't being interposed at all.  For
dynamic linkage, this requires your dynamic linking system to resolve
malloc-related calls to libmudflap, whence dlsym(RTLD_NEXT..)  can
find the system malloc.  Try building one of the test cases by hand,
and run it with env MUDFLAP_OPTIONS="-trace-calls".  You should see
the registration (corresponding to malloc), and a number of successful
checks, and at an unsuccessful check.

The heap-scalestress FAIL may relate to a mf-hooks* or mf-runtime.c
portability problem, where an object registration is attempted that
overlaps the startup-time registration of the stdin/out/err FILE
objects.  A trace would again help.  Similar to Jim Wilson's findings,
the stdio-related mf-hook* calls may need autoconf parametrization to
do the right thing on your libc.  This problem is triggered by a
few other tests too.

The hook-allocstuff FAIL may again relate to malloc/realloc
interposition problems, as might pass11/12/16/...  A "-trace-calls"
run should again help identify the culprit.

The pass-stratcliff FAIL may relate to the absence of a
stpncpy/mempcpy declaration or implementation on darwin.

The pass35 FAIL may be a darwin linker oddness.  __mf_register()
should be callable explicitly from C code.

The pass55 FAILs may be a varasm problem.  I'd look at the
intermediate assembler code and work backward.

The pass40 FAILs look to me like they shouldn't happen.  This is the
multithreaded test that prints out a few numbers to validate the run.
Maybe there is a CR/LF problem in the test case or the dejagnu driver?


Overall, it looks close, though the number of PASSes are inflated
somewhat by crediting merely successful compilation.  The probable
malloc interception problem has to be solved, and should make most of
the failures go away.  That's what I would look at next.


- FChE

Re: Major bootstrap time regression on March 30

[Frank Ch. Eigler]

dnovillo wrote:

> [...]
> I rebooted the machine into a new kernel on 2005-03-31
> (2.6.10-1.770_FC3).  The slowdown coincided with the box being
> rebooted into the new kernel:
> [...]
> 2005-03-305,704   <-- 2.6.10-1.760_FC3
> 2005-03-317,026   <-- 2.6.10-1.770_FC3
> [...]
> I'm rebooting the machine into the previous kernel right now to
> see if it changes things.  [...]

Another alternative is to rerun the test of the 2005-03-30 code
snapshot on the new kernel, just once, so we can recalibrate the
subsequent stream of numbers to a controlled reference.


- FChE

Re: mudflap cache question

[Frank Ch. Eigler]

Hi -


Herman ten Brugge <[EMAIL PROTECTED]> writes:

> [...]
> I looked at the code in mf-runtime.c and found the cache
> functions. The code [...]
> __mf_uncache_object (__mf_object_t *old_obj)
>  [...]
>   unsigned idx_low = __MF_CACHE_INDEX (low);
>   unsigned idx_high = __MF_CACHE_INDEX (high);
>   for (i = idx_low; i <= idx_high; i++)
>   [... check cache slot at index i ...]
> [...]
> __MF_CACHE_INDEX(ptr) is (ptr >> 2) & 0x3ff at startup.
>
> Suppose we have an old_obj->low of 0x1 and an old_obj->high of
> 0x2. Then the cache entries we look at is just entry 0. Which I
> believe is just wrong.  Any pointer between 0x1 and 0x2 must
> fill other cache entries. [...]

You're right, one can't treat this way a data structure that is trying
to be a hash table.  Probably this wasn't found before because it
would result in false no-error indications, which are quiet.

> Should I write a bug report?

Not necessary, this is fine.  Thank you.


- FChE

Re: mudflap: compiler flags changed?

[Frank Ch. Eigler]

Hi -

Eyal wrote:

> [...]
> In the past -fmudflapth did the job. Something changed.
> The help suggests that the two options have a function but it
> is not clear (to me) what it is. [...]

This could be an unintended side-effect of rth's libmudflap pthreads
changes a week or two ago.

- FChE


pgpBPoW57cQu7.pgp
Description: PGP signature

Re: Selective Mudflap

[Frank Ch. Eigler]

"Jon Levell" <[EMAIL PROTECTED]> writes:

> I'm trying to debug a large C application that (amongst other things)
> starts a JVM and uses Java's JDBC to connect to databases via JNI.

Brave!

> If I use the sourceforge bounds checking patch I get a sensible list
> of errors (none from the JVM). I'd also like to use Mudflap however
> running the program with mudflap generates huge numbers of errors
> caused by the (uninstrumented) libjvm.so. [...]

Do these errors arise from malloc-type operations performed by the
JVM?  Or from your code's use of JVM-provided pointers?  Sadly, there
is no valgrind-style exclusion facility around.  However, if the JVM
interface is used predominantly in one direction (C code calling into
the JVM), it may be possible to programatically turn off mudflap
enforcement when your code is about to jump into the jvm.  Maybe
something similar can be done for JVM-invoked C code too.

#ifdef _MUDFLAP
  __mf_set_options("-mode-nop");
#endif

   ... invoke JVM

#ifdef _MUDFLAP
  __mf_set_options("-mode-check"); /* IIRC */
#endif


- FChE

Re: Selective Mudflap

[Frank Ch. Eigler]

Hi -

On Fri, Sep 02, 2005 at 03:55:27PM +0100, Jon Levell wrote:
> [...]
> > Do these errors arise from malloc-type operations performed by the
> > JVM?  Or from your code's use of JVM-provided pointers?  [...]
> 
> The errors stem from inside the JVM. I presume when it is using 
> pointers that the C application has provided because it was't 
> compiled with mudflap itself. (I'm new to mudflap but the violations
> claim to be of type "register"). [...]

"register" operations occur when a new memory-resident object is made
known to libmudflap.  If it overlaps with another existing object, a
"register" type error is indicated.  Chances are that it is ordinary
memory allocation performed by the JVM that is triggering the problem.

Unfortunately, from what I recall, the JVM invocation interface does
not include hooks to override the JVM's memory allocation primitives.
That, coupled with libmudflap's weaknesses with multithreaded
programs, makes this a difficult nut to crack.

- FChE


pgpbQlXCpPmhc.pgp
Description: PGP signature

Forw: Question about mudflap

[Frank Ch. Eigler]

Date: Wed, 16 Nov 2005 03:20:54 -0500
From: "Doug Graham" <[EMAIL PROTECTED]>
To: "Frank Ch. Eigler" <[EMAIL PROTECTED]>
Subject: Question about mudflap

Hi,

Not sure whether I should report this as a bug or not, because there
might be something going on that I don't understand.

What I'm wondering is whether or not mudflap should instrument accesses
to globals that it doesn't know the size of.  In the following code:

   extern int global[];
   
   int main(void)
   {
 printf("%d\n", global[3]);
 global[5] = 42;
   }

Mudflap does not emit any __mf_check calls.  It does warn during
compilation:

  t4-1.c:10: warning: mudflap cannot track unknown size extern 'global'

and I understand that, but I don't understand why this would prevent
it from checking accesses to the array.  Is that a deliberate design
decision, or a bug?  I'd much prefer if it did go on and check all
accesses to the array because in my case, global[] will always be
registered by the compilation unit in which it is defined.  It's pretty
common to have extern decls whose sizes aren't known.

Thanks,
Doug.

Re: Question about mudflap

[Frank Ch. Eigler]

Hi -

> What I'm wondering is whether or not mudflap should instrument accesses
> to globals that it doesn't know the size of.  In the following code:
> [...]
>  printf("%d\n", global[3]);
> [...] Mudflap does not emit any __mf_check calls.

It is probably kicking in an optimization that says that if the
indexes are literals and thus statically checkable against array
bounds, then there is no need for a runtime check.  The problem here
is of course that we can't do the static check after all because of
the extern[].  There is also another complication (unhelpful
TREE_ADDRESSABLE flag setting for this and a few other cases).

> [...]  I'd much prefer if it did go on and check all accesses to the
> array because in my case, global[] will always be registered by the
> compilation unit in which it is defined.  [...]

On the other hand, mudflap can't know that this extern[] will be
registered by that other compilation unit, since that might be
compiled without -fmudflap.  An mf_check against it would then fail.

- FChE

Re: GCC mailing list archive search omits results after May 2005

[Frank Ch. Eigler]

mrs wrote:

> I think we should remove all traces of any search that doesn't work.
> [...]

We'll try to set up mnogosearch again on the machine.  Please stand by.

- FChE

Re: porting gcc/binutils

[Frank Ch. Eigler]

<[EMAIL PROTECTED]> writes:

> The original intention was that CGEN would eventually be able to
> generate the MD file for GCC.  When I last used CGEN 2 years ago, it
> was not able to do that at the time, and I suspect the problem is
> very complex for real machines [...]

There exists a CGEN/SID/GCC port where cgen rtl instructions are
automagically turned into suitable gcc builtins.  This port has some
other unusual capabilities (arbitrary relocation expressions for
evaluation at link time, rich parallelism, VLIW), but might not end up
in mainline.

- FChE

Re: Libmudflap and MIPS, does it work?

[Frank Ch. Eigler]

Hi -

> >Has anyone ever gotten mudflap working on mips?
> I've never tried, but I think that mudflap isn't guaranteed to work  
> for cross compilers. Frank?

The compiler portion (tree-mudflap.c) should work about as well for
crosses as for native builds.  The part that poses porting problems is
the libmudflap runtime.

> >If not would it be a good idea to disable mudflap by default on mips?
> Tried native? If that also doesn't work I'd be up for disabling.

I was under the impression that libmudflap was disabled by default
almost everywhere.  Unless libmudflap is ported for the libc in
question, it should not be built.

- FChE

Re: GCC Bugzilla (and other) timeouts

[Frank Ch. Eigler]

Hi -

> > Bugzilla and httpd are very slow, but I haven't had any git timeouts.
> > If you're using anonymous access that gets throttled more aggressively
> > than authenticated access (using git+ssh:// for the protocol).

Yeah, we're aware of reduced performance lately.  Suspecting one disk
is on the fritz, which doesn't help.  The switchover to the new server
can't happen soon enough - next week or two.

- FChE

Re: gcc mailing list is not being archived

[Frank Ch. Eigler]

Hi -

> one more point: The gcc mailing list including this discussion is
> currently not being archived, the last message is from 2020-03-06.

Found & fixed a permission problem with the mailmnan archives.
Let's see if this one makes it in now.

- FChE

Re: gcc-10-20200308 is now available

[Frank Ch. Eigler]

Hi -

> Is it expected that
> https://gcc.gnu.org/pub/gcc/snapshots/10-20200308/sha512.sum is not
> present?
> There is a sha512.sum file in previous snapshot dirs.

system & per-user cron job items have not been brought forward
en masse.  Copied a relevant one over now
(/sourceware/infra/bin/make-sha /var/ftp/pub)

- FChE

Re: text/x-* attachments strippe

[Frank Ch. Eigler]

Hi -

Thanks for the kind words.

> Could this have gone a bit smoother? Yes.  More collaborative? Maybe.

We tried: the plan to migrate to mailman was included by reference
from the systemwide announcement blast two weeks ago:
https://sourceware.org/sourceware-wiki/MigrationStatus/

We continue to welcome advice & help.

- FChE

Re: Offer of help with move to git

[Frank Ch. Eigler]

Joseph Myers  writes:

> [...]
> FWIW, Jason's own trial conversion with reposurgeon got up to at least 
> 45GB memory consumption on a 32GB repository.

(The host sourceware.org box has 72GB.)

- FChE

Re: svn timeouts

[Frank Ch. Eigler]

pmatos wrote:

> Am I the only one regularly getting svn timeouts lately?
> svn: E210002: Unable to connect to a repository at URL
> 'svn://gcc.gnu.org/svn/gcc/trunk'
> svn: E210002: Network connection closed unexpectedly

Hard to be sure unless you can supply a timestamp so we can go log
hunting.  But each svn service acceptance is limited by load average
and concurrent # of clients per IP address; once started, they are
limited by cpu (1800s) & memory (5G) consumption.  Those look like
generous limits, so that may or may not be what you hit.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

>> cagney = Andrew Cagney 
> cag...@gnu.org?

Good point.  The email identities of people change over time; forcing
a single arbitrary one to label all contributions is at best imprecise
and at worse a miscrediting.  (This is one way in which the impersonal
use...@gcc.gnu.org aliases work better.)

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Hi -

> [...]
> >- rewrite history - use some totally arbitrary, and quickly outdated,
> >internet identity

> I think this is main reason why @gnu.org or @gmail.com style addresses 
> are preferred over employer addresses when there's > 1 address on file.

That makes sense, but how many people are in cagney's shoes (with more
than one non-gcc.gnu.org email address in their commit history)?  It
sounds like they should all be canonicalized to u...@gcc.gnu.org.

- FChE

http access to ftp://gcc.gnu.org

[Frank Ch. Eigler]

Hi -

At the request of tbsaunders, we're experimenting with
provinding http[s] access to parts of the ftp://gcc.gnu.org/
contents.  Please see http://gcc.gnu.org/ftp/ .

- FChE

Re: http access to ftp://gcc.gnu.org

[Frank Ch. Eigler]

Hi -

> > [...]  Please see http://gcc.gnu.org/ftp/ .
> Got 403:

Thanks, fixed.

- FChE

Re: gnu-gabi group

[Frank Ch. Eigler]

mark wrote:

> [...]
>> [...]
>> >> Having a local gnu-gabi group on sourceware.org would be better IMHO.
>> > +1
>> +1
>
> Great. I'll ask overseers to create a mailinglist. [...]

Done [1] [2].  If y'all need a wiki too, just ask.

[1] gnu-g...@sourceware.org
[2] https://sourceware.org/ml/gnu-gabi/

- FChE

Re: Deprecating basic asm in a function - What now?

[Frank Ch. Eigler]

jwakely.gcc wrote:

> [...] (When we switched Fedora to using GCC 6, with C++14 enabled by
> default, dozens and dozens of C++ packages failed to compile,
> because even in 2016 nobody had ever tried to compile them with
> C++11 features enabled.)

And one shouldn't blame those that choose to stick with CXXFLAGS=-std=c++98
instead of porting their code, which after all is working & stable.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

Jason Merrill  writes:

> [...]  gcc.gnu.org already refuses git connections fairly frequently
> due to overloading [...]

With the corresponding reduction in cpu load from svn users, plus the
ready adjustability of those xinetd thresholds, please don't let that
hold you back.

- FChE

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

joseph wrote:

> Thanks, here are further authors map additions for new committers.
> [...]
> avieira = Andre Vieira 
> [...]

FWIW, I thought at one point the consensus was that the mailmap would
expand only to $use...@gcc.gnu.org rather than $userid@$organization,
esp. considering the case where there is no single $organization that
accurately covers the whole contribution timespan of the given $userid.

- FChE

Re: Who played with the GCC Bugzilla git repo?

[Frank Ch. Eigler]

Frédéric Buclin  writes:

> Someone played with the GCC Bugzilla git repo last week with no real reason:
> Author: root 
> Date:   Fri Oct 7 15:28:43 2016 +
> snap-data
> [...]

That was little old me, with the reason being to conserve local changes
with version control.

> Looks like the goal was to drop all CSS and JS files in data/assets/.

No, I believe there was some other sourceware-oriented customization in
there, but I forget the details.

> [...]  Moreover, this means that the GCC Bugzilla git repo is no
> longer in sync with the upstream Bugzilla git repo, because the one
> who played with git also committed my local changes (I didn't do it
> for a reason). I can no longer view my local changes, nor can I easily
> sync both repos with a fast-forward merge (I think). [...]

That's just a matter of tracking upstream bugzilla on one branch, and
the sourceware installation of bugzilla on another branch, and merging
from the former into the latter periodically.  I renamed "5.0" to
"5.0-sourceware", and recreated the "5.0" branch to assist this.

- FChE

Re: git server is stuck

[Frank Ch. Eigler]

The cron-based svn-to-git script running under bernie's account on
gcc.gnu.org is still stuck/spinning, even after a restart.  I am
planning to suspend it later tonight, until y'all can figure out what's
going on.

- FChE

Re: using C++ STL containers in GCC/gfortran source code

[Frank Ch. Eigler]

Pedro Alves  writes:

> [...]
> malloc will fail, new will throw bad_alloc, and GCC will abort and
> maybe generate a core dump, instead of gracefully printing
> something like:
>cc1: out of memory allocating  bytes ...
> and existing with error status.

Consider having the main() function catch bad_alloc etc. and print
prettier error messages than the builtin uncaught-exception aborter?

- FChE

ssl support for https://gcc.gnu.org/

[Frank Ch. Eigler]

Hi -

Thanks to help from Lisa Marie Maginnis , we now have a
valid ssl/tls certificate for gcc.gnu.org, so the web server now makes
https://gcc.gnu.org/* files available.  Please let me/overseers know if
you see any problems.

One complication is the use of literal http://gcc.gnu.org/FOO";...>
type data inside many of the web pages, including the front page.  These
should be switched to something like   to make them work
both with http and https.

- FChE

Re: [website, changes] (was: Re: warning about const multidimensional array as function parameter)

[Frank Ch. Eigler]

Hi -

> > thank you, I tried creating an account, but it said: Unknown action 
> > newaccount.
> Frank, do you know what the problem might be?

Yes, this facility was temporarily disabled, as a load-shedding
measure.  I'll turn it back on for a few hours.


- FChE

Re: GCC wwwdocs move to git done

[Frank Ch. Eigler]

Hi -

Thanks - good job with moving this to git!

> Note 1: someone with the right access needs to create the symlink 
> /sourceware/git/gcc-wwwdocs.git -> 
> /sourceware/projects/gcc-home/wwwdocs.git (and anything else needed for 
> anonymous git access to that repository).

Done.

- FChE

Re: Call for volunteers: GCC Bugzilla account approval

[Frank Ch. Eigler]

David Edelsohn  writes:

> [...]
> Because of SPAM, the GCC Community had to disable the creation of new
> accounts.  We need a few dedicated, reliable individuals who can
> review account requests and manage the process of authorizing Bugzilla
> accounts.  [...]

It would to have y'all also figure out what "review" consists of: what
degree of vetting do you expect?  If it's nothing but "copy data into
web form, hit POST", then maybe this role isn't worth being filled by
a human being.

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

msebor wrote:

> I'm having trouble bringing up bugs or updating them.  Has anyone else
> noticed Bugzilla (and/or other services running on gcc.gnu.org) being
> very slow or timing out?

One failed disk in the server has been replaced yesterday.  Please let
us know if problems persist or reoccur.

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Problems are still occurring for me; Bugzilla gives me 504 Gateway
> Time-outs when I try to access it tonight...

OK, we reworked some of the database routine maintenance workload,
e.g., a nightly cleanup pass that was quite likely excessive, and
will keep monitoring.


- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

On Tue, Jan 23, 2018 at 11:26:42AM +0100, Richard Biener wrote:
> [...]
> > OK, we reworked some of the database routine maintenance workload,
> > e.g., a nightly cleanup pass that was quite likely excessive, and
> > will keep monitoring.
> 
> With all such administrative workloads keep in mind that "night" might
> be "day" in another timezone ;)

Sure, but there are only one or two of you ne'erdowells on the wrong
side of the planet. :-)

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Thanks for looking into it.  I'm still (or again) seeing very
> poor responsiveness.  Right now, bringing up an existing bug
> takes an entire minute.

There has been quite a burst in activity on sourceware.org over the
last few hours.  Will look further into why, but quite a bit of it may
be anti-spam processing.

https://sourceware.org/grafana/index.html#/dashboard/file/default.json

- FChE

Re: Bugzilla timing out

[Frank Ch. Eigler]

Hi -

> Many copies of a 5 MB message have apparently been timing out in 
> sourceware's spam processing, resulting in sourceware repeatedly accepting 
> the message while the sender's mail server also times out (sooner) and 
> keeps resending it. [...]

Thanks for the pointer.  I tightened up some of the timeouts / parallelism
associated with spam filtering.

- FChE

Re: So what's the status of the Git migration?

[Frank Ch. Eigler]

esr wrote:

> [...]
>> Another year; another release; and still no sign of progress on the git
>> migration.
> [...]
> The current issue - and, I think, the last major one - is that there are
> over 150 nid-branch deletes to be resolved.

Is there a mandate that this conversion be Perfect?

How harmful would it be to retain some ambiguity / imperfection in the
resulting git repo, considering that the svn repo can stick around
indefinitely as a historical reference?

- FChE

Re: ChangeLog's: do we have to?

[Frank Ch. Eigler]

siddhesh wrote:

> [...]  We had discussed making addition of ChangeLog entries into the
> commit message mandatory but the issue there is that commit logs
> cannot be (or more precisely, should not be) modified after they're
> pushed so errors in ChangeLog entries will remain.  [...]

In such a rare case, it would be possible to add a subsequent commit
that carries the corrected text, but no other changes (--allow-empty).
Or even revert the previous patch, then re-commit with a fixed text.
Watch out for "perfect is the enemy of the good" syndrome here (as in
the svn-git conversion).

- FChE

Re: temporarily giving up using Git for GCC MELT

[Frank Ch. Eigler]

Miles Bader  writes:

> [...]
> Do you use the http: or git: protocol for cloning?  The official gcc git
> repo only supports the "old" git http: protocol, which is almost useless
> on slow/high-latency networks...

gcc.gnu.org does talk git:// too.  By "new http", you are probably
referring to the git-http-backend widget, which we can investigate
setting up.

- FChE

Re: git mirror corrupted?

[Frank Ch. Eigler]

dnovillo wrote:

> In trying to clone the git mirror, I'm getting:
> $ git clone git://gcc.gnu.org/git/gcc.git
> Cloning into gcc...
> remote: Counting objects: 1191223, done.
> remote: aborting due to possible repository corruption on the remote side.
> [...]

This may be because of cpu runtime limits recently tightened on the
anonymous git daemon, after we found some processes spinning for
a very long time.  I'll relax the limits.

- FChE

Re: git mirror corrupted?

[Frank Ch. Eigler]

"H.J. Lu"  writes:

> [...]
> GCC git mirror hasn't been updated for more than 30 hours.

git svn fetch was blocked on a "index mismatch: ..." error,
apparently necessitating a full git-svn metadata rebuild.  It
should be done in a few more hours.  Darn fragile thing, git-svn.

- FChE

Re: On the toplevel configure and build system

[Frank Ch. Eigler]

dj wrote:

>> [...]
> I see no reason to stop people from building in a combined source tree
> for multiple targets, and expecting it to work.

Perhaps if we do move to git for all the /src stuff, we can have a
/toplevel git repository with different branches suitable for each of
your tastes of such policy.

- FChE

Re: Bugzilla down

[Frank Ch. Eigler]

octoploid  writes:

>> Actually, the whole gcc.gnu.org since yesterday seems rather flaky. At 
>> the moment it works fine for me, though.
>
> Same symptoms as those on kernel.org 

In gcc.gnu.org's case, apparently this was being caused by someone
hammering on the bugzilla server.  A case of excessive popularity
perhaps rather than anything too suspicious.

> before the intrusion was detected.  Perhaps someone should run
> chkrootkit on the gnu servers?

This is being regularly done already.

- FChE

Re: Problem with static linking

[Frank Ch. Eigler]

Andrew Haley  writes:

>> [...] It makes heavy use of
>> C++, STL, and boost and we'd like to (if possible) link *everything*
>> statically.  This means libc, libgcc, libstdc++, boost, libpthread,
>> etc.
> [...]
> However, I really implore you: by all means link statically to everything
> else, but leave libc dynamically linked.  I'm not aware of any reason not
> to link libc dynamically, and not doing so leads to a ton of problems.

If they actually encounter that ton of problems, then they will
change their minds about libc, regardless of preemptive imploring.


- FChE

Re: how to use expand_builtin_alloca

[Frank Ch. Eigler]

> Janboe Ye  writes:

>> normally gcc will use expand_builtin_alloca to handle variable array.
>> But mudflap will force this function to return immediately to invoke
>> alloca explicit.
>>
>> Is there some way to still use expand_builtin_alloca without changing
>> gcc source code?

I don't think so.


Ian Lance Taylor  writes:

> mudflap can't check accesses to memory allocated using alloca unless
> it overrides __builtin_alloca.

It can't currently.  But instead of redirecting the call to a
heap-based alloca() wannabe in libmudflap/mf-hooks1.c, perhaps
mudflap could instrument alloca() by generating code like this
instead:

  __builtin_alloca(N)  -->  GIMPLE_TRY_FINALLY( try {
ptr = __builtin_alloca(N)
__mf_register(ptr ...)
ptr;
   } finally (attached to the function scope) {
__mf_unregister(ptr ...)
   }

Or perhaps not, if alloca() can be used in loops in way that
prevents clean nesting of the try/finally.  

OTOH, I believe the original poster's case came from gcc-synthesized
alloca's, coming from variable-length array allocation.  Those in turn
might be represented with almost the normal mf_xform_decls(), while
letting __builtin_alloca() remain.

Either of these requires gcc changes though.


> [...]  Although, of course, you could simply not use mudflap for the
> code in question.

The original poster's purpose is specifically to build bits of the
linux kernel with mudflap instrumentation.


- FChE

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

[Frank Ch. Eigler]

Robert Dewar  writes:

> [...]
>>> b) you should ignore all such discussions, since they invariablly
>>>include lots of legal-sounding opinions from people who are not
>>>lawyers and don't know, and often have significant misconceptions.
>>
>> This is not about legal issues.  It's about FSF policy.  [...]

(Perhaps this was a poorly chosen summary sentence; Florian's next
paragraph more clearly asks the GCC developers' opinion:

# It seems to me that the new GCC run-time library license has the
# side effect of forcing GPLed software to upgrade to GPL version 3 to
# remain redistributable in compiled form.  If this is not your intent
# (as GCC developers), I think the Steering Committee should ask the
# FSF for official clarification on this matter.


> Discussion of FSF policy on licensing issues is also off-topic for
> this mailing list.

Perhaps, yet the libgcc exception licensing issues were quite
prominently discussed right here, and not too many months ago.
Florian's concern sounds linearly connected to that.  If this is as
trivial a matter as some people seem to hint, perhaps someone can
supply a link to a prior discussion for it.


- FChE

Re: gcc git's performance problem Fwd: git gc expanding packed data?

[Frank Ch. Eigler]

Hi -

Nicolas wrote:

> Anyone has an idea of the git version running on gcc.gnu.org?  It is
> certainly buggy and needs fixing.

It was 1.6.3.2 now it's 1.6.4, practically spring chickens.

> Anyway... To solve your problem, you simply need to run 'git gc' with
> the --prune=now  [...]
> And BTW, using 'git gc --aggressive' with a later git version (or
> 'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects
> directory size of 310 MB [...]

Unfortunately, git gc --aggressive / repack proceed consume several
gigabytes of memory, which on the 32-bit host sometimes fails.


- FChE

Re: GCC Status Report (2009-08-23)

[Frank Ch. Eigler]

mitch...@codesourcery.com (Mark Mitchell) writes:

> [...]  In my opinion, the single hardest issue we face with respect
> to 4.5 is how to handle the VTA branch.  [...]  The problem it's
> setting out to solve is definitely important, but the scope of this
> particular solution frightens me.  [...]

I can only address the "benefits" side of this.

I think VTA (and control-flow-related followup technologies) would
mark the beginning of the end of the entrenched idea that "if you want
to debug your code, you have to compile with -O0", which have lead to
a proliferation of asserts, ad-hoc conditional printfs, compiled-in
debugging-only functions.

With the extra dwarf metadata, already existing consumer programs will
be able to trace/debug final deployed binaries.  Developers will be
able to better see into what's going on in released, running programs,
not just ones built differently in one's own sandbox.  It should
enable new whole new development tools.

This is the grand promise, anyway.  I think it's a big step forward.

- FChE

Re: [lto] Reader-writer compatibility?

[Frank Ch. Eigler]

Ryan Mansfield  writes:

> The objects were created with rev 15 and being read using 151271.
> No, I can't reproduce the ICE using the same version.
> Thanks for confirming this is not expected to work.

Is it the intent that this work properly in the future?  It is not
absurd to imagine that someone with a treeful of .o files might suffer
an unexpected compiler upgrade before a later reuse/relink attempt.

- FChE

Re: LTO branch merged into trunk - trunk remains CLOSED

[Frank Ch. Eigler]

Diego Novillo  writes:

> The LTO branch has been merged into trunk at revision 152434.
> [...]

Congrats.

> [...]  That's it.  The result should, in principle, execute faster
> but our IPA cost models are still not tweaked for LTO.  We've seen
> speedups as well as slowdowns in benchmarks (see the LTO testers at
> http://gcc.opensuse.org/).  [...]

Would it make sense to keep -flto unemphasized in NEWS etc., until
some consistently positive performance results of some sort have been
identified?

- FChE

Re: gccgo: A gcc frontend for Go, a new programming language

[Frank Ch. Eigler]

Ian Lance Taylor  writes:

> [...]  Go, a new experimental systems programming language designed
> by a small group at Google.  [...]  The frontend is written in, yes,
> C++. [...]

Neat.  Are there any plans to have a front-end written in its own
language (and use the current C++ one only for bootstrapping)?

- FChE

outage 2009-12-12 weekend, gcc.gnu.org / sourceware / cygwin

[Frank Ch. Eigler]

Hi -

Please be aware of an impending temporary outage machines hosting
gcc.gnu.org, sourceware.org, sources.redhat.com, cygwin.com, and a few
other sites.  All email, web, ftp, cvs, git, etc. services will be off
line while the machines are being moved between two colocation
facilities this coming weekend: Dec. 12-13.  We are sorry for the
inconvenience.

The machines will receive new IP addresses, but will be otherwise
unchanged.  You may monitor #overseers on irc.freenode.net during the
weekend to see the recovery progress.

- FChE


pgp1qtJAqfPJo.pgp
Description: PGP signature

Re: Git mirror needs a run of "git gc"

[Frank Ch. Eigler]

Florian Weimer  writes:

> Right now, each fresh clone needs to create a compressed pack, which
> takes quite a while.

I ran "git repack -a -d", HTH.

- FChE

test listarch

[Frank Ch. Eigler]

Hi -

This is a test for gcc.gnu.org's listarch for this mailing list,
which has interrupted.

- FChE

Re: Hash Function for "switch statement"

[Frank Ch. Eigler]

Jae Hyuk Kwak  writes:

> [...]
> Is that true that current implementation of gcc on i386 optimizes
> switch statement with decision tree?
> I was expecting somebody who can confirm this.

You can see for yourself by writing a variety of switch{} statements
and observing the assembly code (-fverbose-asm) and/or dump
intermediate output (-d).  To see more of the spectrum of
possibilities, make tables large/small, sparse/clustered/dense, case
blocks small/large/fallthrough,

> I tried to find the specific implementation on the file, i386.c.
> But it is very big file and I have only limited knowledge of gcc yet.
> If you can point more specific implementation part, I may be able to
> catch up what you meant.

See gcc/stmt.c for starters.

- FChE

Re: State of the mercurial mirror

[Frank Ch. Eigler]

Thomas Capricelli  writes:

> The mercurial mirror of the gcc repository, at
> http://gcc.gnu.org/hg/gcc has been broken for months. and the
> contact listed there does not answer emails.
>
> Can somebody here at least remove those misleading pages..?

If there is concensus here to remove this obsolete mirror, we can
remove it instantly.  If there is a volunteer to maintain it, we can
probably let her try too.

- FChE

Re: State of the mercurial mirror

[Frank Ch. Eigler]

Thomas Capricelli  writes:

> The mercurial mirror of the gcc repository, at
> http://gcc.gnu.org/hg/gcc has been broken [...]

Or rather, it has gotten stale.  I started up update process that
should, very very slowly, let it catch up with the present day.  If
that completes in reasonable time, maybe I'll keep it running.  I seem
to recall that the reason it was turned off was because the time neeed
to update the hg repository (via hgpullsvn) was longer than the mean
time between checkins into the svn repository.  If that's true and
unfixable, that's madness.

- FChE

Re: Viewvc perms problem ?

[Frank Ch. Eigler]

Hi -

>   Looking at the GCC viewvc, for example:
> http://gcc.gnu.org/viewcvs/branches/gcc-4_5-branch/
> 
>   All the graphics and style information are missing [...]

This was an unintended consequence of a viewvc rpm update.
It's fixed now.

- FChE

Re: Libmudflap-failures-gcc4.1.2

[Frank Ch. Eigler]

"mal reddy y" <[EMAIL PROTECTED]> writes:

> I am getting libmudflap crash test failures like this,
> any help will be appreciated.
> [...]
> FAIL: libmudflap.c/fail1-frag.c crash test
> FAIL: libmudflap.c/fail10-frag.c crash test
> FAIL: libmudflap.c/fail11-frag.c crash test
> [...]

All these tests are designed to cause mudflap to detect a pointer
dereference error, and generate an abort().  So for some reason that's
not happening.  Maybe testsuite/libmudflap.log will have more
information.


- FChE

Re: Libmudflap-failures-gcc4.1.2

[Frank Ch. Eigler]

Hi -

On Thu, Nov 20, 2008 at 10:49:48AM +0530, mal reddy y wrote:


> The libmudflap.log contains ,
> [...]
> Executing on mips-sony-linux: /tmp/fail10-frag.exe.32708(timeout = 3000)
> call-remote
> standard exec
> Executing mips-sony-linux:/tmp/fail10-frag.exe.32708  <
> /*usr/bin/ssh output is ***
> mudflap violation 1 (check/write): [...]
> XYZ0ZYX [...then more libmudflap output...]
> *FAIL: libmudflap.c/fail10-frag.c crash test*

It appears as though the remote-executed program fails to return a
failed rc to the dejagnu rsh wrapper (in the XYZ0ZYX string).  So
dejagnu thinks that the task succeeded, even though it was supposed to
abort().  I don't know why that would be - maybe something's odd with
the mips toolchain or glibc or somesuch.

- FChE

Re: libmudflap and emutls question

[Frank Ch. Eigler]

Jie Zhang  writes:

> I encountered a recursive call problem between libmudflap and emutls
> when testing libmudflap for Blackfin. But I think this issue affects
> all targets without TLS.

Thank you for the report.

> One libmudflap test case in the testsuite calls __wrap_calloc. In
> __wrap_calloc, __mf_state_1 is looked by __mf_get_state to see if
> it's in_malloc, reentrant or active. With emutls, HAVE_TLS is
> defined as 1 now. So __mf_state_1 has type of __thread. When emults
> tries to simulate TLS for __mf_state_1, it recursively calls
> __wrap_calloc in __emutls_get_address.

Interesting.

> To break the recursive loop, one solution is to force emutls to call
> the real calloc. [...]

If it were acceptable to change emutls on account of mudflap, this
sort of thing could work.  Other alternatives would include having
emutls define something in addition to HAVE_TLS that activates the
!HAVE_TLS implementation in libmudflap/mf-hooks3.c.

- FChE

Re: libmudflap and emutls question

[Frank Ch. Eigler]

On Tue, Jan 06, 2009 at 01:12:08AM +0800, Jie Zhang wrote:

> >[...]  Other alternatives would include having
> >emutls define something in addition to HAVE_TLS that activates the
> >!HAVE_TLS implementation in libmudflap/mf-hooks3.c.
>
> Thanks for your help! How about the attached patch, which follows your 
> advice?

That makes sense to me, but I'd appreciate others' advice too (rth?).

- FChE

Re: CGEN-generated files vs GPL

[Frank Ch. Eigler]

DJ Delorie  writes:

> What are the implications (GPL-wise) of using CGEN-generated files in
> gcc?  Specifically, I'm working on a second attempt to contribute the
> MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
> of them - most opcodes have an intrinsic).  [...]

My understanding is that since CGEN constitutes a mechanical
translation process, it cannot change the copyright situation of the
underlying human-written input file.  (The extent to which CGEN's own
source code is being copied into the output is trivial and is
disclaimed by the cgen's bison-based license.)

- FChE

Re: Revised GCC Runtime Library Exception

[Frank Ch. Eigler]

Ian Lance Taylor wrote:

> [...]  Earlier Bradley Kuhn had indicated that this would be covered
> in the updated FAQ, but I don't really see it there.  I sent him a
> separate message asking him to update it.

Joe Buck wrote:

> [...] Since the FSF is the copyright owner, even if your reading is
> held by someone to be correct, then the FSF's FAQ would count as an
> additional permission. [...]


Is anyone else uncomfortable that an important license is to
require clarification by a separately updated, possibly
contradictory FAQ?


- FChE

Making CFLAGS=-g1 bigger but more useful

[Frank Ch. Eigler]

Hi -

I'm working on a little patch that extends the data produced for the
little-used (?)  -g1 mode.  Normally, this produces very little DWARF
data (basically just function declaration locus, PC range, and basic
backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
is very small.

It would be desirable to have an additional level in between -g1 and
-g2, one that also emits just enough data to decode ordinary
functions' parameters at the entry point.  No locals or blocks for
what's inside the function, such as data for inlined functions.  Just
enough to generate call-graphy traces.

The attached patch is a stab in the dim, and eyeballing the results
seems to accomplish the goal (as tested by systemtap gaily tracing
function call graphs with parameters), at the cost of enlarging the
debug data.  For a fedoraish linux kernel (vmlinux), I get these
numbers:

  vmlinux size
stripped18299708
old-style -g1   23307848  <--
new   -g1   58265716  <--
  -g2   93232955

The stab-in-the-dim -g1 is ten times bigger than the old -g1, but half
the size of -g2.  I am certain that a "stab-in-the-bright" version
should be smaller, if a wise one treaded upon dwarf2out.c more
gingerly than my stomp of a hack.

The basic question though is whether there is interest here for this
sort of -g1.5 mode.  We could ...

- ignore the value of this enlarged -g1 and forget the idea

- adopt the enlarged definition for -g1 and live with the size penalty

- introduce a new -g1.5 (between DINFO_LEVEL_TERSE and DINFO_LEVEL_NORMAL)
  to select the enlarged definition (syntax suggestions wanted)

Suggestions please?


- FChE


diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 69cdb03..eb2116c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -13437,7 +13437,7 @@ dwarf2out_abstract_function (tree decl)
 
   /* Be sure we've emitted the in-class declaration DIE (if any) first, so
  we don't get confused by DECL_ABSTRACT.  */
-  if (debug_info_level > DINFO_LEVEL_TERSE)
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
 {
   context = decl_class_context (decl);
   if (context)
@@ -13520,7 +13520,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   if (!declaration && !origin && !old_die
   && DECL_CONTEXT (decl) && TYPE_P (DECL_CONTEXT (decl))
   && !class_or_namespace_scope_p (context_die)
-  && debug_info_level > DINFO_LEVEL_TERSE)
+  && debug_info_level >= DINFO_LEVEL_TERSE)
 old_die = force_decl_die (decl);
 
   if (origin != NULL)
@@ -13592,7 +13592,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
add_AT_flag (subr_die, DW_AT_external, 1);
 
   add_name_and_src_coords_attributes (subr_die, decl);
-  if (debug_info_level > DINFO_LEVEL_TERSE)
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
{
  add_prototyped_attribute (subr_die, TREE_TYPE (decl));
  add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
@@ -13740,7 +13740,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   /* In the case where we are describing a mere function declaration, all we
  need to do here (and all we *can* do here) is to describe the *types* of
  its formal parameters.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+  if (debug_info_level < DINFO_LEVEL_TERSE)
 ;
   else if (declaration)
 gen_formal_types_die (decl, subr_die);

Re: VTA merge?

[Frank Ch. Eigler]

Alexandre Oliva  writes:

>> Do you have any of them handy (memory use, compile time with release
>> checking only, etc) so that we can start the public
>> argument^H^H^H^H^H^discussion?

> I don't, really.  Part of the guidance I expected was on what the
> relevant measures should be.  [...]

Well, disregard "disruptiveness" for now, which people can judge for
themselves by looking at the new code.

As for "costs" in terms of compile time/space and output size, you
should definitely present some preliminary data please.  For example,
the time/space for a plain bootstrap with vs. without the vta patches
applied.  Then another one with "-g" vs "-g0" vs whatever corresponds
to "full vta" - local variable debuginfo.

As for "benefits", you could give some gdb (or systemtap :-) session
transcripts that show the new data being used.


- FChE

Re: VTA Linux kernel compilation comparison

[Frank Ch. Eigler]

Jakub Jelinek  writes:

> [...]  With make allyesconfig; [...]
> .debug_info+.debug_loc+.debug_abbrev section sum grew by 1.9MB out
> of 422MB, 

I assume this was with var-tracking turned on (due to the toplev.c
AUTODETECT_VALUE logic).

> [...] there locations weren't really changing.

You mean the location lists didn't change much?  If so, that would be
a surprise.


- FChE

Re: Why not contribute? (to GCC)

[Frank Ch. Eigler]

Mark Mielke  writes:

> [...]  What are clean room implementations for if not for avoiding
> copyright violation?

It's a paranoid measure to preclude the appearance of the possibility
of conceivable copyright violation.  (It's also sometimes used in the
case of trade secrets.)

> At my company, we took things seriously [...]

I hope this degree of defensiveness is well justified and not too
costly in terms of your productiveness.

- FChE

Re: GFDL/GPL issues

[Frank Ch. Eigler]

Basile Starynkevitch  writes:

> [...]
> So what should I do?
> [...]
> c. change the licenses of the melt*texi files [I certainly won't do that
> without explicit approval] to something compatible. Perhaps the fact
> that I am the only contributor to these files might help.

Would dual-licensing the .texi files (GFDL + GPL3) solve these problems?


- FChE

Re: Using C++ in GCC is OK

[Frank Ch. Eigler]

Gabriel Dos Reis  writes:

> [...]  I do not think so, and I would not suggest that the use of
> C++ is an excuse do ditch the possibility of bootstrapping with
> anything other than GCC.

Right.  It would be good to enumerate any language/design constraints
that other noteworthy C++ compilers would impose on the GCC source
base.  The remaining language feature set could be noted as the "upper
limit" of C++ being adopted.


> As for the subset of C++ to use, yes we need to be conservative. [...]

...  at least at first, as the gcc developer population learns the
language.  Whatever constraints are adopted for purposes of
simplifying the language/system for C-only developers should be
thought of as temporary "lower limits" that accomplish a gentle
introduction.  In the longer run, there may be no reason to hold back
approaching the "upper limit" of the full language, as people learn
and learn to love it.

It may also help the training process to identify not just initial
constraints on the language, but to name those parts of gcc that could
most obviously benefit from C++y abstraction.  These areas should be
enumerated and analyzed by C++-familiar developers, to ensure that the
initial "lower limit" feature set is sufficient to make a dent into
those areas.


- FChE

Re: Scheduling x86 dispatch windows

[Frank Ch. Eigler]

Andi Kleen  writes:

> [...]
> Yes but you can't easily pass data back, like accurate instruction lengths.

Wouldn't it be too late by then?  Or are you imagining having the
compiler pass trial data to the assembler to create a feedback loop?

- FChE

Re: Patch pinging

[Frank Ch. Eigler]

NightStrike  writes:

> [...]
>> So who actually said no?
>
> The Frederic guy didn't like my fake-looking fake name, and wanted a
> real-looking-but-just-as-fake name, or he wouldn't create a account
> for me.

In consultation with other overseers, I rejected your request.  I did
not ask for a "real-looking-but-just-as-fake name", but a "real name".
You falsely presume zero vetting.

> He then ignored my followup emails asking for clarification.

You said no.  There was nothing further to discuss.


- FChE

Re: Crucial C++ inlining broken under -Os

[Frank Ch. Eigler]

Joern Rennecke  writes:

> [...]  But if the function is very simple, the only reason to keep
> it would be if its address was taken somewhere, or if we tailcall
> it.

... or to make it available from gdb as an inferior call.

- FChE

Re: Merging Apple's Objective-C 2.0 compiler changes

[Frank Ch. Eigler]

Jack Howarth  writes:

> [...]
>Alternatively, perhaps Apple could clarify their own license file to
> clearly indicate that they do not prohibit their GPLv2 code from being
> relicensed as GPLv3-only code. After all, this doesn't really change
> the licensing status of Apple's changes in their gcc sources as they stay
> at GPLv2.

There is no *licensing* problem with putting a piece of GPLv2+ code
into a GPLv3+ application, or having a mixture of copyright holders.
It's just that the FSF is not interested in merging such code into FSF
GCC releases for policy reasons.

(Anyone else could legally ship such a merged copy; see the FSF
license compatibility matrix at http://www.gnu.org/licenses/gpl-faq.html)

- FChE

Re: Discussion about merging Go frontend

[Frank Ch. Eigler]

Dave Korn  writes:

> [...]  From Ian's description, gccgo has the exact same requirements
> as LTO: be able to parse an object file, get a list of sections, and
> get raw binary access to the data contained within a named section.
> This is a problem which we already have solved.  (And indeed LTO's
> solution also has object writing capabilities that gccgo doesn't
> need.)  [...]

By the way, is there some necessity in accomplishing this by means of
a linked library, as opposed to via a spawned objcopy process?

- FChE

Re: Discussion about merging Go frontend

[Frank Ch. Eigler]

Hi -

> > By the way, is there some necessity in accomplishing this by means of
> > a linked library, as opposed to via a spawned objcopy process?

> Probably none in theory, but it certainly seems messy and likely to
> be slow in practice.

Yes, maybe.

> Is there a reason that this would be desirable?

It would seem to moot the present discussion about competing elf
consumer libraries.  "none of the above" is a possible answer.

- FChE

Re: RFC: Add zlib source to src CVS resposity

[Frank Ch. Eigler]

"H.J. Lu"  writes:

> [...]  By default, the in-tree zlib is used.  If you configure
> binutis using --with-system-zlib, system zlib will be used.  [...]

Can you summarize what modern platforms lack a system zlib, and what
justifies using the proposed in-tree copy by default?

- FChE

Re: A possible super feature to add to gcc

[Frank Ch. Eigler]

AspertameMan wrote:

>  Back in the 1970's when we ran fortran on an IBM machine we had this
>  really powerful command called CALL FDUMP that if inserted into a
>  program would send the names and values of every variable, at the time
>  of its call, to a printer or file. [...]

This sounds like a job for a scriptable debugger, or systemtap
   probe process("a.out").statement("*...@file.c:444") { log($$vars$$) }
or somesuch run-time tool.

- FChE

Re: gcc.gnu.org Bugzilla: Perl error Can't locate mro.pm in @INC

[Frank Ch. Eigler]

Tobias Burnus  writes:

>>> Can't locate mro.pm in @INC
>> [...]

This may be fixed now, with a hand-made dummy mro.pm file.

- FChE

Re: mudflap extention request

[Frank Ch. Eigler]

Herman ten Brugge <[EMAIL PROTECTED]> writes:

> [...]  Finally the question. Is it possible to add this extension to
> mudflap so the above problem is found here as well.

It is likely possible.

The first one (array embedded in struct, indexed by run-time
expression) is tricky.  There is IIRC no code that specially handles
comparing run-time array indexes with statically-declared bounds.
This would require emitting a new comparison block, likely in addition
to the current pointer-bounds based one.  It may be straightforward,
but it would be new code.

With many tree-ssa optimizations and some subtle tree flag changes
since the original work, some tree-mudflap.c checks have to be
re-tuned to avoid eliding checks (and object registrations) where
still actually necessary.  The second of your two cases you point out
sounds like one that could be detected by just such a tweak.

Similarly, mudflap could exploit some of the clever ssa analysis such
as VRP or alias stuff, which should allow us to elide some checks that
the compiler can prove as unnecessary.

All these just require an interested programmer with some spare time.
(I wish I had enough of the latter.)

- FChE

Re: Reconsidering gcjx

[Frank Ch. Eigler]

"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:

> [...] IMHO, writing your frontend in the same language it's intended
> to compile causes it to be marginalized.  It no longer becomes part
> of the default bootstrap sequence and gets much less testing.  [..]

Even if so, it may be worth spelling out some of the obvious benefits
of writing a compiler in its own language:

- genuine bootstrapping capability (to compile itself, being a source
  of realistic test coverage)

- supplies "virtuous circle" motivation for improvement (speed,
  quality, ...), since it itself directly benefits

- providing a concrete, educational systems application of the
  language (rather than saying "language X would be great for writing
  compilers, but by the way here is an X compiler written in Y.)


- FChE

Re: Making a variable addressable in GIMPLE

[Frank Ch. Eigler]

Yoav Etsion <[EMAIL PROTECTED]> writes:

> The transformation is simple: mudflap already injects a call to
> __mf_register when an addressable variable is declared. I want to do
> the same for all pointer variables [...]

Why?  If those pointers are not themselves taken address of, what kind
access to the pointer value is worth checking?


- FChE

Re: Making a variable addressable in GIMPLE

[Frank Ch. Eigler]

Yoav Etsion <[EMAIL PROTECTED]> writes:

> The pointer variable's address is used as the pointer's unique ID in
> a database, collecting information about each pointer variable -
> mostly its legal bounds.  That way I can test when a pointer crosses
> its object's bounds.

If I understand correctly, you mean to figure out the legally
reachable address ranges of individual pointer variables.  I don't
know what identifying the pointer *declarations* will do for you though.
After all, many such declarations may be manufactured for temporary
address values.

You might instead hook up only to the "mudflap2" pass that tracks
actual pointer dereferences.  You could analyze the operand of the
INDIRECT_REF etc. nodes to figure out which source-level spot caused
the dereference.  You may be able to follow the links back to a
pointer declaration, should one exist.

But I may misunderstand the nature of checking you intend.  Could you
summarize your intended overall algorithm?

- FChE

Re: GCC-4.1.x include/ssl/*.h ??

[Frank Ch. Eigler]

Hi -

On Sun, Feb 26, 2006 at 10:54:09PM +0100, Gerald Pfeifer wrote:
> On Sun, 26 Feb 2006, Ralf Corsepius wrote:
> > Cross building and installing gcc-4.1.0 rc2 (--prefix=/usr/local)
> > installs these headers:
> > [...]
> Related problems include Bugzilla #23935 ($PREFIX/include/ffi.h),
> #25938 ($PREFIX/include/gomp.h), and #18244 (include/mf-runtime.h).
> Frank, any chance you could look into the mudflup one?

I'm not fresh on gcc configury details.  If anyone can send a pointer
to the relevant autoconf or derived value, that would be great.

- FChE

Re: -fmudflap and -fmudflapth

[Frank Ch. Eigler]

"Rafael Espíndola" <[EMAIL PROTECTED]> writes:

> Use `-fmudflapth' instead of `-fmudflap' to compile and to link if
> your program is multi-threaded. [...but...]
> gate_mudflap (void) { return flag_mudflap != 0 }

Maybe something broke this, but -fmudflapth used to imply setting both
flag_mudflap and flag_mudflap_threads.

- FChE

Re: using libmudflap with non-instrumented shared libraries

[Frank Ch. Eigler]

rafael.espindola wrote:

> [...]
> extern char *p;
> [...]
>char a = p[0];
> [...]
> compile and link with
> gcc -shared -fPIC a.c -o liba.so
> gcc  -fmudflap -lmudflap b.c -la -L. -o b

Did the compiler give you a warning about inability to track the
lifetime of "p"?  It should have.

- FChE

Re: Mudflap and freeing C runtime memory upon exit (feature request)

[Frank Ch. Eigler]

"Vesselin Peev" <[EMAIL PROTECTED]> writes:

> [...]  I have a feature request for mudflap. It should have an
> option to run glibc's _libc_freeres function that forces the C
> runtime library to free all of its memory [...]

Good idea.  (It should not take more than a dozen lines of code - a
threshold below which one may not even need a copyright assignment in
order to contribute.)

- FChE

Re: a mudflap experiment on freebsd

[Frank Ch. Eigler]

Hi, Jim -


> A customer expressed interest in mudflap, so I tried to see if I
> could use it compile something large.  [...]

Thanks for giving it a try.

For what it's worth, I've run entire gcc bootstraps on Linux with the
instrumentation running (using BOOT_CFLAGS rather than CFLAGS).  Each
time, it seems to take some tweaks in libmudflap or tree-mudflap to
work again (pass cleanly).  This indicates that there is a source of
regressions that is not represented in the test suite.

Regarding -fmudflap => -lmudflap, it used to do that.  The problem was
that the simplest use of specs machinery creates a final sequence of
"-lFOO" options that sometimes cannot work.  libmudflap must be in a
particular spot on the command line so it can intercept calls into
libc and other libraries, and from libgcc.  Adding -lmudflap once to
the beginning or end of all the libraries/objects is not sufficient
IIRC.

Regarding registering fopen return values, indeed libmudflap needs
autoconf assistance.  The issue is that on some libc implementations,
fopen runs malloc to allocate the FILE, which we can sometimes
intercept in libmudflap.  Other implementations call private routines
that we cannot intercept, so must register fopen return values
manually.

Regarding mmap/malloc recursion, this is similar to the fopen
situation.  Some reentrancy is expected; some is tolerated and
prevented.  You should not have to invent any further static counters
for this stuff: the __mf_state variable should be able to do the right
thing.

Regarding error reports containing good application-level PCs, you're
right that using builtin_return_address(0) is not sufficient for
interior routines.  Solutions would include snapshotting that value on
a border function, hiding it in a per-thread global or widening the
internal interfaces to pass it down.

Regarding varargs, there is a libmudflap test case or two for that.
The most problematic aspect seems to be ensuring that the variables
being passed in varargs slots be registered with libmudflap, so
va_arg() dereferencing is permitted.  I recall at one point va_arg()
being deliberately made uninstrumented, because doing the real
registration work was too difficult.  Either should at least shut
libmudflap up.

Regarding registration of static strings, this is one of the areas
that seems to suffer from tree-ssa churn.  tree-mudflap tries to
arrange string constants and other static objects to be registered,
but I recall tree flags switching interfering with this.  In general
the code is supposed to err on the side of registration.

Regarding memory consumption, perhaps libmudflap's default backtrace
parameter should be set to zero, for both speed and space reasons.

Regarding the torrent of warnings/errors you encountered for the one
or two actual bugs it found, yeah, it's not a great return.  Once
libmudflap is properly ported to *bsd, and the instrumentation-side
regressions are fixed again, it will be much saner.


- FChE

Re: Vandalised wiki page

[Frank Ch. Eigler]

Hi -

> > Looking at http://gcc.gnu.org/wiki/RecentChanges shows that the GCC wiki
> > is being spammed a lot. Somebody should employ some kind of spam protection.

Several other sourceware-hosted moin wikis have adopted a group-ACL-based
protection, which has eliminated the problem.  This involves maintaining
a special wiki page that lists approved editors (and is editable by those
editors).  If you're interested in trying this, please send me an initial
list of editor WikiNames.

- FChE

Re: Vandalised wiki page

[Frank Ch. Eigler]

Hi -

On Fri, Aug 23, 2013 at 04:06:22PM +0100, Jonathan Wakely wrote:
> [...]
> (Assuming we want to go down the ACL route.)

Done! :-)

> > Is there an easy way to revert a spam change to a page? I don't see one.
> Doh, found it in the "more actions" dropdown.

(It's only accessible there to "admin" moin users.)

- FChE

Re: Warning about __DATE__ and __TIME__

[Frank Ch. Eigler]

Gerald Pfeifer  writes:

> To make it easier to reproduce builds of software and entire GNU/Linux 
> distributions, RMS had the idea of adding a warning to GCC that warns 
> about the use of __DATE__ and __TIME__. [...]

How about instead adding a --time=X option to gcc (cpp?) instead,
so that someone interested in reproducing a build can rerun gcc with
the original --time value?  (gcc -grecord-gcc-switches could emit
the then-current timestamp to enable this.)

- FChE

Re: Report on the bounded pointers work

[Frank Ch. Eigler]

Yury Gribov  writes:

>[...]
>> [mudflap] never reached a point where interoperability across objects with
> and without mudflap instrumentation worked
>
> Could you add more details? E.g. I don't see how mudflap
> interoperability is different from AdressSanitizer which seems to be
> state of the art.

My sense is that asan and mudflap are comparable with respect to
support of interoperation between instrumented and uninstrumented
code.  The trick is how to handle pointers arriving from the latter.
libmudflap handled this issue in two ways: by attempting to intercept
all heap allocations from libraries (at the glibc/dlsym level), and by
heuristics for recognizing addresses that might have come from
unintercepted static/auto allocations.  The former is tricky and was
an uphill battle trying to catch everything, so in practice heuristics
were almost always necessary.

(There are of course many differences.  They have different tradeoffs
as to speed versus memory-consumption - asan is hard-coded in the
opposite direction than libmudflap's (configurable) default.  asan's
multi-threading support may be superior.  mudflap's tuning/features
were not completed.  asan sports more recent developers.)

- FChE

Re: git mirror hasn't been updated for 8 hours

[Frank Ch. Eigler]

Hi -

There appears to have been a problem with bernie's cron-based
git-svn-fetch job, due to a corrupted (emptied) .git/svn/.cache/XXX.db
file.  With that file removed, the cron job is running again.  A
little bit extra logging was added to help pinpoint the cause next
time.

- FChE

Re: GCC Wiki, struggling to make a new user

[Frank Ch. Eigler]

Hi -

> I'm trying to create a new account for the GCC wiki using the
> account creation page at:
>   http://gcc.gnu.org/wiki/HomePage?action=newaccount
> but things are not going well.
> 
> I fill in the form and click create account. After thinking for a
> while the page returns a Gateway Error. [...]

This mirrors the symptoms of other sourceware-hosted moinmoin wikis
that had been overrun with spam users.  We cleaned a bunch of them off
of glibc the other day, basically removing all but the
trusted-editors, and things are much faster.  (Legitimate non-editor
users can create new users, or email to restore their purged info.)

Are y'all interested in the same treatment for the gcc wiki?


- FChE

Re: GIT Mirror Down?

[Frank Ch. Eigler]

"Iyer, Balaji V"  writes:

> Is the GIT mirror for GCC down? I tried clicking on the snapshot
> link near a commit and it is timing out.

It could be that generating the snapshot is taking more CPU time
than the web server is configured to permit.  Consider making
your own git clone, and generate snapshot tarballs from that.

- FChE

Re: Function parameter debug info at -O0

[Frank Ch. Eigler]

Senthil Kumar Selvaraj  writes:

> [...]
> The following program, when compiled with -O0 -g3 (x86_64 target, but
> doesn't seem to matter), shows wrong values for p (function parameter)
> when debugging. [...]

This sounds like .

- FChE