Re: r113817 - in /trunk/gcc: ChangeLog config/mips/...
On Tue, 2006-05-16 03:49:57 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: dj > Date: Tue May 16 03:49:57 2006 > New Revision: 113817 > > * doc/tm.text (TARGET_LIBGCC_SDATA_SECTION): Document. > > Modified: > trunk/gcc/doc/tm.texi if [ xinfo = xinfo ]; then \ makeinfo --split-size=500 --no-split -I . -I /tmp/build-temp-vax-linux-uclibc/ src/gcc/gcc/doc \ -I /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/doc/include -o doc/gccint. info /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/doc/gccint.texi; \ fi /tmp/build-temp-vax-linux-uclibc/src/gcc/gcc/doc//tm.texi:6221: No matching [EMAIL PROTECTED] defmac'. makeinfo: Removing output file `doc/gccint.info' due to errors; use --force to preserve. make[1]: *** [doc/gccint.info] Error 1 MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: mips: -G0 vs __dso_handle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
DJ Delorie wrote:
> 2006-05-15 DJ Delorie <[EMAIL PROTECTED]>
>
> * crtstuff.c (__dso_handle): Set section from
> TARGET_LBIGCC_SDATA_SECTION if defined.
> * doc/tm.text (TARGET_LIBGCC_SDATA_SECTION): Document.
> * config/mips/mips.h (TARGET_LIBGCC_SDATA_SECTION): Define.
Nitpicking: Two minor typos ("LBIGCC" and "tm.text") here.
> [EMAIL PROTECTED] TARGET_LIBGCC_SDATA_SECTION
[...]
> +access these variables whether it uses small data or not.
> +
> @defmac FORCE_CODE_SECTION_ALIGN
You've missed the "@end defmac" part which is causing
a bootstrap failure.
Thanks,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEaWQyYb1hx2wRS48RAjZgAJwLSJtETjsEU+fIWmlWIrZwKn5RogCfYfKT
78RyVZR8fesXg1LSUWdDU+I=
=kR0U
-END PGP SIGNATURE-
Re: simple c compiler
This list isn't for these type of questions. On May 15, 2006, at 9:31 PM, Bill Cunningham wrote: Where's the simplest part of the source tree to learn from? GCC? Does that directory contain the compiler simple? No, gcc isn't simple, though, what you can learn from it is more valuable, if your intent is to learn.
simple c compiler
Where's the simplest part of the source tree to learn from? GCC? Does that directory contain the compiler simple? I've pulled some inodes containing an old c compiler from a unix v7 but it's old k&r C. I want to see a multiple pass C compiler in ansi. Bill
Re: mips: -G0 vs __dso_handle
> > How about this one? > > OK. Thanks; committed.
Re: can we define a comment?
On May 15, 2006, at 7:08 PM, Eric Fisher wrote: Anybody knows that if we can define a comment? Wrong list. comp.lang.c or gcc-help is more appropriate. Short answer, no, not really. Longer answer: #define COMMENT(X)
can we define a comment?
hi, Anybody knows that if we can define a comment? For a statement such as, COMMENT this is a comment. will be preprocessed as, // this is a comment. or something valid and transparent to the compiler? Of cause we can't directly use, #define COMMENT // Thanks. Eric.
Re: problem with GCC Wiki
[EMAIL PROTECTED] wrote: > Hi, > > I was not able to find who is maintaining the GCC Wiki at > http://gcc.gnu.org/wiki/HomePage > I have found one strange problem and I would like to discuss it in private. There are plenty of known problems, security related and otherwise. I am the maintainer, feel free to email me about it.
Re: problem with GCC Wiki
On May 15, 2006, at 4:33 PM, [EMAIL PROTECTED] wrote: I was not able to find who is maintaining the GCC Wiki at http://gcc.gnu.org/wiki/HomePage I have found one strange problem and I would like to discuss it in private. Private, what's that?! :-) If you want, I'll entertain a discussion.
problem with GCC Wiki
Hi, I was not able to find who is maintaining the GCC Wiki at http://gcc.gnu.org/wiki/HomePage I have found one strange problem and I would like to discuss it in private. Thanks, Manuel. PS: I have noticed that Andrew Pinski is notified of page changes. On the other hand, many changes have been done also by Daniel Berlin. I decided that the best way to find out the actual maintainer was to write here, rather than pestering individual people one by one. I hope not to cause much trouble if I chose the wrong decision.
Re: GCC 4.1.1 Status Report (2006-05-15)
Andrew Pinski wrote: > Mark, > >> Therefore, effective midnight tonight (i.e., 12:00AM May 17th in >> California), the 4.1 branch will be frozen. (I previously announced May >> 15th as a target release date.) After that point, all changes, >> including previously approved patches, need my explicit approval. I'll >> create 4.1.1 RC1 tomorrow. > > Just for clearification, is the freeze time tonight, the 15th or Wednesday, > the 17th? Shucks, that's a mess. I meant tonight, the 15th. > This is a backport of a patch that went in last week. Let's get that done then -- unless we think the backport is unreasonably dangerous. I'm happy to make that call, if pointed at the patch, and if the original submitter is uncomfortable making the decision. >> 27603cri P1 NEW [4.1/4.2 >> Regression] wrong code, apparently due >> to bad VR... > This patch just went on the mainline but has not gone on the 4.1 branch yet. Similarly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.1 Status Report (2006-05-15)
Mark, > Therefore, effective midnight tonight (i.e., 12:00AM May 17th in > California), the 4.1 branch will be frozen. (I previously announced May > 15th as a target release date.) After that point, all changes, > including previously approved patches, need my explicit approval. I'll > create 4.1.1 RC1 tomorrow. Just for clearification, is the freeze time tonight, the 15th or Wednesday, the 17th? And about the P1s, more for extra info. > 27549 nor P1 NEW [4.1 > Regression] ICE in coalesce_abnormal_edges This is a backport of a patch that went in last week. > 27603 cri P1 NEW [4.1/4.2 > Regression] wrong code, apparently due > to bad VR... This patch just went on the mainline but has not gone on the 4.1 branch yet. Thanks, Andrew Pinski
Re: mips: -G0 vs __dso_handle
DJ Delorie wrote: >> I'll pre-approve that change, but I'll also defer to any other >> maintainer who has a solution they prefer. > > How about this one? OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
GCC 4.1.1 Status Report (2006-05-15)
There are now 98 serious regressions open against GCC 4.1, including 9 P1s. However, none of these are -- as far as I can tell -- regressions from 4.1.0; they are all regressions from previous releases. Given that we've fixed 114 bugs since 4.1.0, I think it's time to create a 4.1.1 release. Therefore, effective midnight tonight (i.e., 12:00AM May 17th in California), the 4.1 branch will be frozen. (I previously announced May 15th as a target release date.) After that point, all changes, including previously approved patches, need my explicit approval. I'll create 4.1.1 RC1 tomorrow. For reference, here are the open P1s. Some of these do seem quite serious, and it would be nice to get fixes, if at all possible. 26435 nor P1 powerpc64-linux NEW [4.1/4.2 regression] ICE with -O1 -ftree-loop-linear and ... 26600 nor P1 32bits [EMAIL PROTECTED] ASSI [4.1/4.2 Regression] internal compiler error: in push_rel... 26719 cri P1 NEW [4.1/4.2 Regression] Computed (integer) table changes wit... 26757 blo P1 NEW [4.1/4.2 regression] C++ front-end producing two DECLs wi... 26885 nor P1 [EMAIL PROTECTED] ASSI [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit o... 26969 nor P1 NEW [4.1/4.2 Regression] ICE with -O1 -funswitch-loops -ftree... 27339 nor P1 NEW [4.1/4.2 Regression] out-of-class definition of value tem... 27549 nor P1 NEW [4.1 Regression] ICE in coalesce_abnormal_edges 27603 cri P1 NEW [4.1/4.2 Regression] wrong code, apparently due to bad VR... Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: mips: -G0 vs __dso_handle
> I'll pre-approve that change, but I'll also defer to any other
> maintainer who has a solution they prefer.
How about this one?
2006-05-15 DJ Delorie <[EMAIL PROTECTED]>
* crtstuff.c (__dso_handle): Set section from
TARGET_LBIGCC_SDATA_SECTION if defined.
* doc/tm.text (TARGET_LIBGCC_SDATA_SECTION): Document.
* config/mips/mips.h (TARGET_LIBGCC_SDATA_SECTION): Define.
Index: crtstuff.c
===
--- crtstuff.c (revision 113799)
+++ crtstuff.c (working copy)
@@ -225,6 +225,9 @@ STATIC void *__JCR_LIST__[]
in one DSO or the main program is not used in another object. The
dynamic linker takes care of this. */
+#ifdef TARGET_LIBGCC_SDATA_SECTION
+extern void *__dso_handle __attribute__ ((__section__
(TARGET_LIBGCC_SDATA_SECTION)));
+#endif
#ifdef HAVE_GAS_HIDDEN
extern void *__dso_handle __attribute__ ((__visibility__ ("hidden")));
#endif
Index: doc/tm.texi
===
--- doc/tm.texi (revision 113799)
+++ doc/tm.texi (working copy)
@@ -6217,6 +6217,18 @@ registers initialized in the function pr
constant pools don't end up too far way in the text section.
@end defmac
[EMAIL PROTECTED] TARGET_LIBGCC_SDATA_SECTION
+If defined, a string which names the section into which small
+variables defined in crtstuff and libgcc should go. This is useful
+when the target has options for optimizing access to small data, and
+you want the crtstuff and libgcc routines to be conservative in what
+they expect of your application yet liberal in what your application
+expects. For example, for targets with a @code{.sdata} section (like
+MIPS), you could compile crtstuff with @code{-G 0} so that it doesn't
+require small data support from your application, but use this macro
+to put small data into @code{.sdata} so that your application can
+access these variables whether it uses small data or not.
+
@defmac FORCE_CODE_SECTION_ALIGN
If defined, an ASM statement that aligns a code section to some
arbitrary boundary. This is used to force all fragments of the
Index: config/mips/mips.h
===
--- config/mips/mips.h (revision 113799)
+++ config/mips/mips.h (working copy)
@@ -466,6 +466,8 @@ extern const struct mips_rtx_cost_data *
#endif
#endif /* IN_LIBGCC2 */
+#define TARGET_LIBGCC_SDATA_SECTION ".sdata"
+
#ifndef MULTILIB_ENDIAN_DEFAULT
#if TARGET_ENDIAN_DEFAULT == 0
#define MULTILIB_ENDIAN_DEFAULT "EL"
Re: GCC 4.1: too strict aliasing?
On May 15, 2006, at 8:56 AM, Igor Bukanov wrote:
Consider the following code that starting with GCC 4.1.0 generates
'dereferencing type-punned pointer will break strict-aliasing rules'
warning:
Yup. Kinda does seem a flaw in the C language. You could switch to C
++. :-)
~> cat test.c
struct inner {
struct inner *next;
};
struct outer {
struct inner base;
int value;
};
/* List of outer elements where all outer.base.next point to struct
outer */
struct outer_list {
struct outer *head;
};
struct outer *search_list(struct outer_list *list, int value)
{
struct outer *elem, **pelem;
Instead, try struct inner **pelem;,
pelem = &list->head;
Instead try:
struct inner_list ilist_node;
struct inner_list *ilist = &ilist_node;
ilist->head = list->head;
pelem = &ilist->head;
and keep all the types as **inner. At the end, you can then
list->head = ilist->head;
But why the warning is generated?
The two I don't think are compatible types. An example of this might
be:
[#5] EXAMPLE 2 After the declarations
typedef struct s1 { int x; } t1, *tp1;
typedef struct s2 { int x; } t2, *tp2;
type t1 and the type pointed to by tp1 are compatible. Type
t1 is also compatible with type struct s1, but not
compatible with the types struct s2, t2, the type pointed to
by tp2, or int. |
Doesn't it guaranteed that offsetof(struct outer, base) == 0 and
one can always safely cast struct inner* to struct outer* if struct
inner is a part struct outer so struct* outer can alias struct* inner?
Yes, but this isn't used to decide the aliasing of two pointers.
Re: Re: configure: error: building in source directory is not supported in this release
> > > Union-Souths-Computer:~/developer UnionSouth$ ../gcc-5250/configure > creating cache ./config.cache > checking host system type... powerpc-apple-darwin7.9.0 > checking target system type... powerpc-apple-darwin7.9.0 > checking build system type... powerpc-apple-darwin7.9.0 > checking for a BSD compatible install... /usr/bin/install -c > checking whether ln works... yes > checking whether ln -s works... yes > checking for gcc... no > checking for cc... no > configure: error: no acceptable cc found in $PATH > --- > > I had cctools in my /developer folder, but I do not know how to > generate cc from it? Look at config.log and see why it fails. -- Pinski
Re: Re: configure: error: building in source directory is not supported in this release
Union-Souths-Computer:~/developer UnionSouth$ ../gcc-5250/configure creating cache ./config.cache checking host system type... powerpc-apple-darwin7.9.0 checking target system type... powerpc-apple-darwin7.9.0 checking build system type... powerpc-apple-darwin7.9.0 checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... no checking for cc... no configure: error: no acceptable cc found in $PATH --- I had cctools in my /developer folder, but I do not know how to generate cc from it? eric
Re: What to do with MAPPED_LOCATION
Robert Dewar wrote:
Can someone point me to a clear high level spec for the proposed
interface for MAPPED_LOCATION support.
I don't know of any high-level spec, except libcpp/include/line-map.h.
A "line_map" (singular) specifies how a sub-range of source_location
integer cookies are to be interpreted. The "line_maps" table (there
is normally only one) is a collection of line_map mappings, in order
of the lowest source_location value mapped by each line_map, so finding
the correct line_map is a matter of binary search. (And of course
normally there is quite a bit of locality, especially when initially
parsing.)
Each line_map has a filename ('to_file') and starting line ('to_line'),
and then it's a simple calculation to map a source_location to a line
and column number.
Each line_map also has an "included_from" field which is normally the
index of the line_map of that included this line_map: i.e. the outer
line_map in the include stack. It seems plausible to generalize the
"included_from" field to also be used for "expanded from" or
"instantiated from", but I haven't tried to think through that.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
Re: What to do with MAPPED_LOCATION
Steven Bosscher wrote: So now we have a half-completed conversion to USE_MAPPED_LOCATION which is currently broken (doesn't bootstrap for me with --enable-mapped-locations). Oops. Looks like I made and posted a patch, but never checked it in: http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00882.html -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
GCC 4.1: too strict aliasing?
Consider the following code that starting with GCC 4.1.0 generates
'dereferencing type-punned pointer will break strict-aliasing rules'
warning:
~> cat test.c
struct inner {
struct inner *next;
};
struct outer {
struct inner base;
int value;
};
/* List of outer elements where all outer.base.next point to struct outer */
struct outer_list {
struct outer *head;
};
struct outer *search_list(struct outer_list *list, int value)
{
struct outer *elem, **pelem;
pelem = &list->head;
while ((elem = *pelem)) {
if (elem->base.value == value) {
/* Hit, move atom's element to the front of the list. */
*pelem = (struct outer*)elem->base.next;
elem->base.next = &list->head->base;
list->head = elem;
return elem;
}
/*** LINE GENERATING WARNING */
pelem = (struct outer **)&elem->base.next;
}
return 0;
}
~> gcc -c -Wall -O2 test.c
test.c: In function 'search_list':
test.c:29: warning: dereferencing type-punned pointer will break
strict-aliasing rules
But why the warning is generated? Doesn't it guaranteed that
offsetof(struct outer, base) == 0 and one can always safely cast
struct inner* to struct outer* if struct inner is a part struct outer
so struct* outer can alias struct* inner?
RFC cse weirdness
Hello, when cse replaces registers in an insn it tries to avoid calls to validate_change, what causes trouble in some situations. >From validate_canon_reg: /* If replacing pseudo with hard reg or vice versa, ensure the insn remains valid. Likewise if the insn has MATCH_DUPs. */ if (insn != 0 && new != 0 && REG_P (new) && REG_P (*xloc) && (((REGNO (new) < FIRST_PSEUDO_REGISTER) != (REGNO (*xloc) < FIRST_PSEUDO_REGISTER)) || GET_MODE (new) != GET_MODE (*xloc) || (insn_code = recog_memoized (insn)) < 0 || insn_data[insn_code].n_dups > 0)) validate_change (insn, xloc, new, 1); else *xloc = new; Lets assume the following instruction: [rA + rB] = [rA + rB] & 3; canon_regs likes to replace rA with HARD reg RC and rB with another pseudo rD. So we have 4 resulting changes: 1. SRC rB -> rD 2. SRC rA -> RC 3. DEST rB -> rD 4. DEST rA -> RC Lets assume that the insn already has been recognized. Then the first change is done without calling validate_change using the 'else' branch. The second change replaces a pseudo with an hard reg so validate_change is called. For the third change validate_change is used because the last change has set the recog_memoized flag for the insn to -1. And the last change again replaces a pseudo with an hard reg and therefore uses validate_change. The resulting change group therefore contains only the last 3 changes. If the subsequent call to apply_change_group fails we end up with: [rA + rB] = [rA + rD] & 3; Which now could still be invalid as it is on s390 because we want MEM operands in these kind of instructions to be the same on both sides. I would propose to always do the changes via validate_change what would trivially fix this issue. But as usual there will be people who care much more about compile time than I do and they will probably come up with a better solution. Bye, -Andreas-
Re: intl directory: gcc vs. src
> What do people who build in a combined tree do with intl? Do they use > the GCC version or the src tree version? Is there any consensus about > whether or not there should be a single version of intl, and if so, > which one should be used? FWIW, I have always given preference to the gcc version. -- Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
Wrong link?
LS, The link crossgcc FAQ in the middle of the page: "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that offers the cross-gcc faq. Instead it appears to be a site of a consultant trying to sell his services. Kind regards, Ernst. Ernst Steenbrink Imtech ICT Technical Systems Henry Dunantstraat 38 3822 XE Amersfoort Tel + 31 (0)33 454 33 51 Fax + 31 (0)33 454 33 35 E-mail: [EMAIL PROTECTED] Info www.imtechict.nl
Re: Disabling -fsee at -O3
> @item -fsee
> @opindex fsee
> Eliminates redundant extension instructions and move the non redundant
> ones to optimal placement using LCM.
> Enabled at level @option{-O3}.
>
> Would you mind adjusting this as well
Thanks. I've updated doc/invoke.texi correspondingly. Mircea
Re: What to do with MAPPED_LOCATION
On May 14, 2006, at 11:54 AM, Daniel Berlin wrote: The other languages don't do that. ObjC/ObjC++ kinda do :-( I have a dream, one day...
