[Fwd: ARM char array on stack]
--- Begin Message ---
Hi,
if I define this type:
typedef unsigned char UCHAR __attribute__((aligned(32)));
void func(void) {
char example;
UCHAR vector[40];
...
}
The vector array is 4 byte alignment in any case?
Regards Michael
--- End Message ---
Re: [avr-gcc-list] Re: AVR byte swap optimization
On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote: > Use gcc head, __builtin_bswap and make sure the AVR backend > implements the > bswap rtl patterns. There's the problem. You can't just glibly say "make sure the AVR backend implements the bswap rtl patterns". There are precious few volunteers who are familiar enough with gcc internals and the avr port in particular to go do just that. AFAIK, there is no bswap rtl pattern in the avr port, at least there doesn't seem to be in 4.1.1. Why is that a problem? Do you have a different solution in mind? > Future versions of gcc may also be able to recognise these > idioms without > using the builtin, but AFAIK that's not been implemented yet. Plus there is a long lead time between when it is implemented on HEAD, then branched, released from a branch, and then when it shows up in binary distributions. That happens with all improvements that are implemented between releases, so I don't see your point. Gr. Steven
Re: strict aliasing question
> On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote: > > while speaking about uninitialized variables gcc developers probably want > > to look at their own sources first: > > gcc/testsuite/gcc.dg/vect/vect-27.c > > If any code in the testsuite is broken, it should be changed. should be fixed now dorit > And this > is not really part of the compiler so you will not get wrong code from > the compiler, just the testcase will break. If you find some, report it > instead of just complaining about it. > > Thanks, > Andrew Pinski >
Re: Abt long long support
On Mon, 6 Nov 2006, Ian Lance Taylor wrote:
> gcc always supports "long long" for all targets.
I just noticed that while the base compiler may support "long long", this
extension fails to interact well with at least one other extension: hash_map<>
in libstdc++.
Specifically, the following example program will fail to compile with
error: no match for call to '(const __gnu_cxx::hash) (const
long long int&)'
Example program:
#include
using namespace __gnu_cxx;
typedef long long T;
void f() {
hash_set t;
t.insert(1);
t.erase(1);
}
Now filed as libstdc++/29898.
Gerald
PATCH for Re: Missing web link
Bruce, On Thu, 19 Oct 2006, Bruce Korb wrote: > I was going to re-subscribe my dropped subscription to gcc-patches, > but the only links (that I can find) on gcc.gnu.org lead to the archives, > not to the subscription page. Thanks - Bruce I understand your immediate issue has been addressed already, but I agree that there is something we should (and can) improve on the web pages. The patch below, which I just installed, is my first attempt to do so. Add pointers to subscription instructions and list policies to the beginning of the page. Do you have further ideas that would have helped you? Gerald Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.99 diff -u -3 -p -r1.99 lists.html --- lists.html 21 Sep 2006 14:17:36 - 1.99 +++ lists.html 19 Nov 2006 14:43:31 - @@ -16,6 +16,8 @@ (and http://gcc.gnu.org/lists.html#searchbox";>searchable) as well as in ftp://gcc.gnu.org/pub/gcc/mail-archives/";>mbox format. +Please make yourself familiar with our policies +before subscribing and posting to these lists. @@ -140,7 +142,7 @@ as well as in To post a message, just send mail to listname@gcc.gnu.org. -Policies +Policies Our lists have a maximum message size of 100KB, only the gcc-prs list allows for a larger maximum message size of 2MB. If your message exceeds
Re: 4.1.1 spec files missing, FAQ misinformation
On Wed, 4 Oct 2006, Daniel Jacobowitz wrote: >>> "This file can be found in the same directory that >>> contains cc1 (run gcc -print-prog-name=cc1 to find it)." >> I think that indicates someone trying to be overly clever when they >> configured your gcc package. Normally libdir and libexecdir point to the >> same >> dir. What output do you see from "gcc -v"? > Not any more. The default changed some time ago. Some distributors > configure them to the same location. > > Jeff, for background, up until a few releases ago cc1 and specs would > always be in the same directory. Daniel, Dave, if one of you could have a look at http://gcc.gnu.org/faq.html#rpath and update that, that would be great! If you prefer, just provide any edits/changes to me, and I'll take care of updating that web page, markup and committing. Thanks, Gerald
Re: Volatile operations and PRE
On 11/15/06, Richard Guenther <[EMAIL PROTECTED]> wrote: On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]> > > > > > > * gimplify.c (fold_indirect_ref_rhs): Use > > > STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS. > > > > Regtested x86-64-gnu-linux. The only interesting failure was > > mayalias-2.c, but that also fails before the patch. > > This is OK for active branches. I have committed this to mainline and will continue with the branches after testing. Done. Richard.
RE: [avr-gcc-list] Re: AVR byte swap optimization
> -Original Message- > From: Steven Bosscher [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 19, 2006 3:55 AM > To: Eric Weddington > Cc: Paul Brook; gcc@gcc.gnu.org; Shaun Jackman; > avr-gcc-list@nongnu.org > Subject: Re: [avr-gcc-list] Re: AVR byte swap optimization > > On 11/19/06, Eric Weddington <[EMAIL PROTECTED]> wrote: > > > Use gcc head, __builtin_bswap and make sure the AVR backend > > > implements the > > > bswap rtl patterns. > > > > There's the problem. You can't just glibly say "make sure > the AVR backend > > implements the bswap rtl patterns". There are precious few > volunteers who > > are familiar enough with gcc internals and the avr port in > particular to go > > do just that. AFAIK, there is no bswap rtl pattern in the > avr port, at least > > there doesn't seem to be in 4.1.1. > > Why is that a problem? > Do you have a different solution in mind? > > > > Future versions of gcc may also be able to recognise these > > > idioms without > > > using the builtin, but AFAIK that's not been implemented yet. > > > > Plus there is a long lead time between when it is > implemented on HEAD, then > > branched, released from a branch, and then when it shows up > in binary > > distributions. > > That happens with all improvements that are implemented between > releases, so I don't see your point. The original message went to the avr-gcc-list mailing list. I wasn't aware that it also went to the gcc mailing list. There are different sets of assumptions based on the audience. A lot depends on where the OP is coming from, in wanting help: Does the OP want a pre-built toolchain? Does the OP build the toolchain from source? Is the OP familiar with even patching the toolchain? There are a number of people on the avr-gcc-list that when they say they want help, they want the final, pre-built toolchain from a distributor to fix their problem. They don't want to build the toolchain from source, or they don't even know how to. Yes there are also people who can and will build the toolchain from source but they are a small minority. The point that I was making was to the original OP: yes, it would be great to get it fixed, permanently. Historically there has never been enough volunteers with the knowledge, capability, and the time on the avr port. The audience on the gcc list is a completely different sort with different assumptions. My apologies for annoying the people on the gcc list. And yes I do have a different solution in mind: Shaun, could you open a GCC bug report on this issue? Rask, could you then post your implementation to that GCC bug report as a patch? Steven and Paul, could you eyeball Rask's implementation and see if it is reasonable impelementation? Rask, do you have FSF paperwork in place? If not, then could somebody else, with FSF assignments in place, create a patch? After all, you guys have a process to follow, right? ;-) Eric Weddington
RE: 4.1.1 spec files missing, FAQ misinformation
On 19 November 2006 16:07, Gerald Pfeifer wrote: > On Wed, 4 Oct 2006, Daniel Jacobowitz wrote: "This file can be found in the same directory that contains cc1 (run gcc -print-prog-name=cc1 to find it)." >>> I think that indicates someone trying to be overly clever when they >>> configured your gcc package. Normally libdir and libexecdir point to the >>> same dir. What output do you see from "gcc -v"? >> Not any more. The default changed some time ago. Some distributors >> configure them to the same location. >> >> Jeff, for background, up until a few releases ago cc1 and specs would >> always be in the same directory. > > Daniel, Dave, if one of you could have a look at > http://gcc.gnu.org/faq.html#rpath > and update that, that would be great! If you prefer, just provide any > edits/changes to me, and I'll take care of updating that web page, markup > and committing. > > Thanks, > > Gerald I'm not quite sure how we tell people where to find the right default directory for it anymore. Did libgcc move to libdir from libexecdir as well? Otherwise I can't think of any file that's guaranteed to be there to look for with -print-file-name. Modulo that minor difficulty, here's a proposed re-wording: However, if you feel you really need such an option to be passed automatically to the linker, you can create a GCC specs file and add it there. The http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html#Spec-Files"specs file is the mechanism used by gcc to control which options are passed to which of the sub-stages of compiling, assembling and linking; GCC normally operates according to a built-in set of specs, but these defaults can be overridden by providing an external specs file. This file can either be passed to the compiler by supplying the --specs= option, or can be placed in the same directory that contains (run gcc -print-file-name=??? to find it), where gcc will locate and use it automatically every time it runs. You can then add linker flags such as -R or -rpath, depending on platform and linker, to the *link or *lib specs. cheers, DaveK -- Can't think of a witty .sigline today
Re: [avr-gcc-list] Re: AVR byte swap optimization
On Sun, Nov 19, 2006 at 08:31:22AM -0700, Eric Weddington wrote: > Rask, do you have FSF paperwork in place? Yes, it was completed recently. -- Rask Ingemann Lambertsen
Re: Why does flow_loops_find modify the CFG, again?
Hello,
> I'm running into some troubles with an if-conversion pass that runs
> after reload, where we have to avoid lifting insns across a loop
> exit edge into a loop. ifcvt.c uses flow_loops_find to find loops
> and mark all loop exit edges:
>
> if ((! targetm.cannot_modify_jumps_p ())
> && (!flag_reorder_blocks_and_partition || !no_new_pseudos
> || !targetm.have_named_sections))
> {
> struct loops loops;
>
> flow_loops_find (&loops);
> mark_loop_exit_edges (&loops);
> flow_loops_free (&loops);
> free_dominance_info (CDI_DOMINATORS);
> }
>
> I was wondering why we would sometimes *not* mark exit edges, but then
> I remembered that for some reason flow_loops_find modifies the CFG,
> which may lead to problems that we have to work around here.
>
> But if we do not mark loop exit edges, we can sometimes end up doing
> unprofitable if-conversions!
>
> It seems to me that a function called "flow_loops_find" is supposed to
> do *just* analysis, and not transformations. Apparently it now first
> transforms all loops into some canonical form, but that is completely
> inappropriate and unnecessary for some users of this loops analysis.
>
> Is this something that could be easily fixed? E.g. can we make it
> that flow_loops_find only performs transformations if asked to (by
> adding a function argument for that)?
yes. However, you won't be able to use most of the functions for work
with loops then. mark_loop_exit_edges should work, though.
Zdenek
Re: AVR byte swap optimization
On Fri, Nov 17, 2006 at 04:30:53PM -0700, Shaun Jackman wrote:
> Is there anything I can do to help GCC along here? I'm using GCC 4.1.0
> with -O2.
>
> I won't bother to show bswap_32 here, which produces a real disaster!
> Think 47 instructions, for what should be 6.
You may get better code if you write it something like this:
#include
uint32_t bswap_32 (uint32_t x)
{
unsigned char c[4], temp;
memcpy (c, &x, 4);
temp = c[0];
c[0] = c[3];
c[3] = temp;
temp = c[1];
c[1] = c[2];
c[2] = temp;
memcpy (&x, c, 4);
return (x);
}
It isn't only on the AVR that bswap_32() is nontrivial to get right.
These two versions would rule on the i386 if GCC would be just a little bit
smarter:
#include
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
uint32_t bswap_32_a (uint32_t y)
{
uint16_t d[2];
uint32_t x = y;
memcpy (d, &x, sizeof (d));
d[0] = BSWAP_16 (d[0]);
memcpy (&x, d, sizeof (x));
x = ((x >> 16) & 0x) | ((x & 0x) << 16);
memcpy (d, &x, sizeof (d));
d[0] = BSWAP_16 (d[0]);
memcpy (&x, d, sizeof (x));
return (x);
}
/*
bswap_32_a:
subl$16, %esp
movl20(%esp), %eax
movl%eax, 12(%esp)
rolw$8, 12(%esp)
roll$16, 12(%esp)
rolw$8, 12(%esp)
movl12(%esp), %eax
addl$16, %esp
ret
*/
uint32_t bswap_32_b (uint32_t y)
{
union { uint16_t d[2]; uint32_t x; } t;
t.x = y;
t.d[0] = BSWAP_16 (t.d[0]);
t.x = ((t.x >> 16) & 0x) | ((t.x & 0x) << 16);
t.d[0] = BSWAP_16 (t.d[0]);
return (t.x);
}
/*
bswap_32_b:
movl4(%esp), %edx
movl%edx, %eax
rolw$8, %ax
movw%ax, %dx
movl%edx, %eax
roll$16, %eax
movl%eax, %edx
rolw$8, %ax
movw%ax, %dx
movl%edx, %eax
ret
*/
--
Rask Ingemann Lambertsen
Re: building gcc4-4.3.0-20061104/11 failure on OSX 10.3
> Let me know if that works for you.
After applying the Andrew Pinski's patch for pr29879, the build of snapshot
20061118 went without problem on OSX 10.3.9. So your patch fixes the
problem I have reported. Thanks a lot.
If I may abuse of the situation, I am using the following patches:
Index: gcc/config/rs6000/darwin7.h
===
--- gcc4/gcc/config/rs6000/darwin7.h(revision 112376)
+++ gcc4/gcc/config/rs6000/darwin7.h(working copy)
@@ -29,3 +29,1 @@
-#define LIB_SPEC "%{!static:\
- %:version-compare(!< 10.3 mmacosx-version-min= -lmx)\
- -lSystem}"
+#define LIB_SPEC "%{!static:-lSystem -lmx}"
this is required to avoid a lot of warnings with ld, as discussed in
a thread around 21/08/2005, and
Index: gcc/config/i386/darwin-libgcc.10.4.ver
===
--- gcc4/gcc/config/i386/darwin-libgcc.10.4.ver (revision 112376)
+++ gcc4/gcc/config/i386/darwin-libgcc.10.4.ver (working copy)
@@ -7,6 +7,7 @@
__Unwind_GetDataRelBase
__Unwind_GetGR
__Unwind_GetIP
+__Unwind_GetIPInfo
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
===
--- gcc4/gcc/config/rs6000/darwin-libgcc.10.4.ver (revision 112376)
+++ gcc4/gcc/config/rs6000/darwin-libgcc.10.4.ver (working copy)
@@ -7,6 +7,7 @@
__Unwind_GetDataRelBase
__Unwind_GetGR
__Unwind_GetIP
+__Unwind_GetIPInfo
__Unwind_GetLanguageSpecificData
__Unwind_GetRegionStart
__Unwind_GetTextRelBase
which have been put sometime ago in darwin-libgcc.10.5.ver. Is there any
good reason why such patches are not applied in the distributions. If no,
could they be included?
TIA
Dominique
Re: Abt RTL expression
> Can any one get me the information/implementation of below mentioned > functions? > > 1. operands[0] = gen_rtx_REG (SImode,REGNO (set_dest)); > 2. operands[0] = gen_highpart (SImode, set_dest); Sure, emit-rtl.c, lines 488 and 1165. Ben
Re: AVR byte swap optimization
It isn't only on the AVR that bswap_32() is nontrivial to get right. These two versions would rule on the i386 if GCC would be just a little bit smarter: I prefer the single instruction bswap that we now generate for __builtin_bswap[32,64] myself... -eric
Re: build gcc with distcc
> On a somewhat related note, I'd be interested to hear if ccache > could be snuck into bootstrapping to speed up recompiles in the > intermediate stages, especially with incremental changes. (Anyone > tried this?) I've noted that ccache-ing only speeds up the first > stage, as one would expect. > There might be a subtle issue with ccache assuming that the compiler > that created a cache-hit object did not change. I'm only aware of > ccache verifying compiler versions (string compare) in the > hit-check, which alone doesn't suffice to guarantee that the cache > is (or should be) hit. No, it records the timestamp of the compiler driver. These would always be different in a bootstrap run, so you would never get any cache hits for second and third stage object files. Ben
Re: build gcc with distcc
> > There might be a subtle issue with ccache assuming that the compiler > > that created a cache-hit object did not change. I'm only aware of > > ccache verifying compiler versions (string compare) in the > > hit-check, which alone doesn't suffice to guarantee that the cache > > is (or should be) hit. > > No, it records the timestamp of the compiler driver. These would > always be different in a bootstrap run, so you would never get any > cache hits for second and third stage object files. Ah, wasn't sure that it did that, but thanks for pointing that out. Bummer. "No ccache for you!!!" Fang
Re: odd severities in bugzilla
[EMAIL PROTECTED] wrote: > So, are we using "P1" instead to mark release-blocking bugs? Should > we fix the severities of existing bugs? I am using priorities to indicate how important it is to fix a bug before the next release. This is consistent with the meanings of the terms "priority" and "severity". In particular, the "severity" indicates how severe the problem is, if you are affected by the bug. The "priority" indicates how important it is to fix it. In various commercial environments I've worked in, customers set "severity" (e.g., help, this bug is really getting in my way!) and developers/support set "priority (this bug is affecting only one customer, so it's medium priority). So, that's a long answer, but basically: "yes, we're using P1 to mark release-critical bugs". Also, in the paradigm described above, "blocker" should mean "blocks the user from making progress, there is no workaround", not "blocks the release". (In my experience, severities are normally things like "mild", "critical", "emergency.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: alias slowdown?
In the meantime, is there a simple way to disable this "more correct" mechanism so I can get my timings? You'll get testsuite failures if you disable it because it fixes a bunch of bugs. You can always disable all of PTA, but i would not recommend it. With the attached patch, it should take less than 60 seconds per PTA run for all.i (i have no copy of cplusplus_grammar.i, and it's not clear where to get it). includes.diff Description: Binary data
