small font in gcc online docs
Hello
I noticed that in the default Firefox3 configuration on my 1280x1024 display
your code samples on this page are tiny, and v.hard to read:
http://gcc.gnu.org/onlinedocs/gcc/Inline.html
I see in the HTML this is the code causing the small font:
pre.smallexample { font-size:smaller }
Would you consider just using regular sized text?
The CSS for inline doesn't have this problem, so you could even
display it that way?
Kind regards, Jon
Re: thread build on solaris
> I'm not sure what you are trying to say here - that it should be fixed > locally on my side at the level of the header file? Or something else? That it should be fix-included, see fixincludes/README in the source tree. -- Eric Botcazou
Re: GCC bug when using typeof
On Mon, Oct 20, 2008 at 07:21:49PM -0700, Andrew Pinski wrote: > On Mon, Oct 20, 2008 at 7:19 PM, Peng Yu <[EMAIL PROTECTED]> wrote: > > Could you please help explain what the difference between typeof and > > decltype are? What are c++0x/g++0x modes? > > Well decltype is part of the C++0x standard > (http://gcc.gnu.org/projects/cxx0x.html, > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf ). > typedef is a GCC extension. You meant to say "typeof", of course. Is there a reason why typeof shouldn't just be a synonym for decltype? If there's an extension that's almost the same as a new standard feature, it would seem easiest to make it exactly the same, unless that would cause extensive breakage (if it breaks corner cases that might not be such a big deal, for an extension).
Re: GCC bug when using typeof
On Tue, Oct 21, 2008 at 9:32 AM, Joe Buck <[EMAIL PROTECTED]> wrote: > On Mon, Oct 20, 2008 at 07:21:49PM -0700, Andrew Pinski wrote: >> On Mon, Oct 20, 2008 at 7:19 PM, Peng Yu <[EMAIL PROTECTED]> wrote: >> > Could you please help explain what the difference between typeof and >> > decltype are? What are c++0x/g++0x modes? >> >> Well decltype is part of the C++0x standard >> (http://gcc.gnu.org/projects/cxx0x.html, >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf ). >> typedef is a GCC extension. > > You meant to say "typeof", of course. > > Is there a reason why typeof shouldn't just be a synonym for decltype? Yes. Making it a synonym makes it useless to users (if they want decltype, they can type it, and get portable code), and breaks existing code. > If there's an extension that's almost the same as a new standard feature, > it would seem easiest to make it exactly the same, unless that would > cause extensive breakage (if it breaks corner cases that might not > be such a big deal, for an extension). The reason the standard name is "decltype" is in large part to avoid breaking code which uses the various differing existing implementationf of "typeof", just as with naming the hashed C++ containers unordered_xxx instead of hash_xxx. The legacy names are for backwards compatibility. -- James
need to find functions definitions
Hello, ALL.
I recently started to actively program using C and found that tools like
ctags or cscope do not work properly for big projects. Quite ofthen they
can't find function or symbol definition. The problem here is that they don't
use full code parsing, but just some sort of regular expressions.
I need a tool for automatic code exploration that can at least find definition
for every symbol without problems. If you know any - please tell.
Now, to gcc. It seems to me that existing and working compiler is an ideal
place to embedd such tool - since it already knows all the things required.
I have one idea: i'm almost sure that inside gcc somewhere there is a place
(function
i beleive) that is called each time during compilation when definition of
something (type, variable,function...)
found and in this place gcc has context information - source file and line
where this definition came from.
So if i add something like printf("DEFINITION: %s,%s,%d\n",
info->object_type,info->src_file,info->line) into
that place, i will get information about every thing that compiler found.
What i like more about this way of getting information about symbol definition
is that
i get the only reference to that part of source that was actually compiled.
I.e. if there are
a lot of #ifdef's, it's is hard to know what part of code will be used.
So, my questions is:
1) Is it possible ? Is there a single place where all information is easily
accessible ?
2) If yes - where is it and where can i find details about internals of gcc?
3) Any good alternatives for cscope/ctags? It seemed to me that
eclipse has some good framework, but it looks to be too much integrated with
it...
Thank you!
Re: thread build on solaris
Eric, I'm looking at it, and that's one hell of an amount of work to do for the code that I would maintain. As far as I can see, it requires me to recompile/reinstall the compiler for every issue that I find.. Suppose I find fifty such issues? Is there any way to do this work with an already installed compiler, ie: change the fixincludes.def on the fly and have the installed compiler immediately pick up on the changes from the text file? That would save tons of time.. Ed On Tue, Oct 21, 2008 at 7:48 AM, Eric Botcazou <[EMAIL PROTECTED]> wrote: >> I'm not sure what you are trying to say here - that it should be fixed >> locally on my side at the level of the header file? Or something else? > > That it should be fix-included, see fixincludes/README in the source tree. > > -- > Eric Botcazou >
Re: thread build on solaris
> Is there any way to do this work with an already installed compiler, > ie: change the fixincludes.def on the fly and have the installed > compiler immediately pick up on the changes from the text file? You need to work in a build tree, modify fixincludes.def and follow the instructions given in section 5. Testing fixes (which may or may not work with the new toplevel bootstrap). Then do 'make install' in the dir. -- Eric Botcazou
Re: What to do with hardware exception (unaligned access) ? ARM920T processor
2008/10/1 Vladimir Sterjantov <[EMAIL PROTECTED]>:
> Hi!
>
> Processor ARM920T, chip Atmel at91rm9200.
>
> Simple C code:
>
> char c[30];
> unsigned short *pN = &c[1];
>
> *pN = 0x1234;
>
> causes hardware exeption - memory aborts (used to implement memory
> protection or virtual memory).
>
> We have a lot of source code, with pieces of code like this, which must be
> ported from x86 to ARM9.
>
> Are there any compiler options to handle this exception?
>
Not to this day. Code like this is generally not portable.
You can have a header with something like:
typedef struct __attribute__((packed)) { unsigned short val } un16_t;
and then replace the unsigned short *pN by un16_t *pN, like this:
un16_t *pN = (un16_t *)&c[1];
pN.val = 0x1234;
... but IMHO this is as much work as replacing that by portable code.
See: http://c-faq.com/strangeprob/ptralign.html for furter directions.
Good luck!
Re: need to find functions definitions
2008/10/21 `VL: > 3) Any good alternatives for cscope/ctags? It seemed to me that > eclipse has some good framework, but it looks to be too much integrated with > it... You could look at these, which all provide more than ctags: http://en.wikipedia.org/wiki/OpenGrok http://synopsis.fresco.org/ http://directory.fsf.org/project/global/ Jonathan
Re: thread build on solaris
2008/10/19 Edward Peschko > Constructs of the form > > extern enum vtype iftovt_tab[]; > > are now failing with forgiving > > error: array type has incomplete element type > > This would be fine if it was code that I controlled - but the matter > of fact is that this code is in /usr/include/sys/mode.h, which comes > bundled with solaris 10, and the upshot is that I'm going to have to > somehow hack solaris headers in order to make gcc-4.3.2 be able to > compile perl-5.10.0. > > Which is just plain wrong. sys/mode.h has a comment saying "REQUIRES sys/vnode.h" I would look into why that header is not being included before sys/mode.h Jonathan
gomp lowering question, bug in omp-low.c?
I am looking at a couple of libgomp failures on IA64 HP-UX and I am
pretty sure what the problem is and that it is in omp-low.c but I am
not sure exactly where in omp-low.c it is.
The tests (libgomp.c/loop-5.c and libgomp.c++/loop-8.C) only fail in
32 bit mode on IA64 HP-UX where we use the addp4 instruction to extend
pointers. I think only these two fail because they are they only ones
to use negative indexes (see the simplified test case at the end of
this email).
The problem is in the call to GOMP_loop_ull_dynamic_start and in the
'end' argument to that routine. In the OMP library the 'start' and
'end' arguments are defined to be type gomp_ull (unsigned long long)
but seem to actually contain pointers.
When I look at the code generated by GCC the argument 'start' is being
extended from 32 to 64 bits correctly (via the ptr_extend unspec 24
in instruction 42 below) but the argument 'end' is being extended by a
zero_extend (instruction 45 below), which is wrong because it is really
a pointer and should be extended via the unspec like 'start' is..
Some where in omp-low.c I think I need to make a POINTER_PLUS_EXPR instead
of a PLUS_EXPR but I am not sure where I need to do that. Can someone
point me to the right place? Where are the arguments (and particulary
the 'end' argument) to GOMP_loop_ull_dynamic_start generated?
-
>From x.c.128r.expand:
;; D.3075 = __builtin_GOMP_loop_ull_dynamic_start (1, (long long unsigned int)
&(*D.3067)[3], (long long unsigned int) (&(*D.3067)[63] + 1), 8, 3,
&.istart0.3, &.iend0.4);
(insn 41 40 42 x.c:14 (set (reg:SI 379)
(plus:SI (subreg/s/v:SI (reg/f:DI 375 [ D.3067+-4 ]) 4)
(const_int 12 [0xc]))) -1 (nil))
(insn 42 41 43 x.c:14 (set (reg:DI 380)
(unspec:DI [
(reg:SI 379)
] 24)) -1 (nil))
(insn 43 42 44 x.c:14 (set (reg:SI 381)
(plus:SI (subreg/s/v:SI (reg/f:DI 375 [ D.3067+-4 ]) 4)
(const_int 252 [0xfc]))) -1 (nil))
(insn 44 43 45 x.c:14 (set (reg:SI 382)
(plus:SI (reg:SI 381)
(const_int 1 [0x1]))) -1 (nil))
(insn 45 44 46 x.c:14 (set (reg:DI 383)
(zero_extend:DI (reg:SI 382))) -1 (nil))
=
Test case:
#include
#include
#include
int
test3 (void)
{
int buf[64], *p;
int i;
memset (buf, '\0', sizeof (buf));
#pragma omp parallel for schedule (dynamic, 3)
for (p = &buf[3]; p <= &buf[63]; p += 2)
p[-2] = 6;
for (i = 0; i < 64; i++)
if (buf[i] != 6 * ((i & 1) && i <= 61))
abort ();
return 0;
}
int
main (void)
{
test3 ();
return 0;
}
Re: thread build on solaris
Eric, Yes, I got that from the README. What I was looking for was a *shortcut*, ie: I compile ~1000 packages, so when one doesn't work, I trace down the reason, compose a entry in the 'live' fixincludes.def, and after I'm done with the 1000-or-so packages take all the bugs in one step back to the build directory and release them formally. This would save lots of time - as it stands, the time to iterate through these issues is going to be very expensive. Ed On Tue, Oct 21, 2008 at 12:13 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: >> Is there any way to do this work with an already installed compiler, >> ie: change the fixincludes.def on the fly and have the installed >> compiler immediately pick up on the changes from the text file? > > You need to work in a build tree, modify fixincludes.def and follow the > instructions given in section 5. Testing fixes (which may or may not work > with the new toplevel bootstrap). Then do 'make install' in the dir. > > -- > Eric Botcazou >
c++0x N2756 Non-static data member initializers status
Hi,
I noticed N2756 is not on the gcc c++0x status page (probably because
it's new). Any ideas if and when this would be implemented? It would
be life-changing.
class A {
public:
A() { }
private:
int x = 5;
int y = 0;
};
GCC 4.4.0 Status Report (2008-10-21)
Apology === This report is significantly past due. I apologize. Status == The trunk remains Stage 3, so only bug fixes and documentation changes are allowed. While the various maintainers have discretion in allowing additional changes, they should, at this point, being using that discretion sparingly. We should now be focusing clearly on getting 4.4 out the door, not on adding more things to it. As expected, there are a number of performance and a few correctness issues stemming from IRA. These include bootstrap problems on popular platforms. There are also several issues that seem to be related to the use of assembler CFI directives. Quality Data Priority # Change from Last Report --- --- P1 26 - 2 P2 133 - 2 P32 - 29 --- --- Total 161 - 33 Overall, the bug count is quite a bit lower than at the point of the previous report -- but the P1 and P2 counts are not significantly smaller. Some of the P3s from before likely turned out to be P1s/P2s, so this is progress -- but there seems to be quite some way to go before 4.4 is ready. In fact, some of the P2s (like PR37071, which seems to indicate that EH is broken on PA GNU/Linux) might well qualify as P1s. Previous Report === http://gcc.gnu.org/ml/gcc/2008-09/msg0021.html The next report for 4.4.0 will be sent by Richard. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: thread build on solaris
> Yes, I got that from the README. What I was looking for was a > *shortcut*, "5. Testing fixes" precisely documents a shortcut. -- Eric Botcazou
