On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote:
> --- a/libgcc/configure.ac
> +++ b/libgcc/configure.ac
> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI
> directives], [libgcc_cv_cfi],
>[libgcc_cv_cfi=yes],
>[libgcc_cv_cfi=no])])
>
> -# Check 32bit or
Hi,
I have been exploring non-deterministic failures in cactusADM (when
autopar is enabled with a low threshold)' on a Power7 multi core machine.
The failure actually reoccurs in several other spec2006 benchmarks
when the threshold is lowered to allow for more loops to get parallelized.
The sc
> %ymm0 is all ones (this is code from the auto-vectorization).
> (2) is not useless, %ymm6 contains the mask, for auto-vectorization
> (3) is useless, it is there just because the current gather insn patterns
> always use the previous value of the destination register.
Sure, I am constantly mix In
On Thu, Nov 03, 2011 at 01:37:09PM +0400, Kirill Yukhin wrote:
> > %ymm0 is all ones (this is code from the auto-vectorization).
> > (2) is not useless, %ymm6 contains the mask, for auto-vectorization
> > (3) is useless, it is there just because the current gather insn patterns
> > always use the p
Hi Joel,
> The sparc libgcc configure magic looks very
> different on the head versus 4.6. sparc-rtems4.11
> was not building because it was missing crti.
>
> In 4.6, we got the makefile stub from sparc/t-crtin
> but that no longer exists. It looks like the
> rules are on t-sol2 now.
>
> I made
I have separated out a master patchset for the cxx-mem-model work:
http://quesejoda.com/redhat/cxx-mem-model-diffs-from-trunk-at-180790/
When would be a good time to ask for a trunk freeze/slush to do a merge?
Aldy
On 11/03/2011 08:06 AM, Rainer Orth wrote:
Hi Joel,
The sparc libgcc configure magic looks very
different on the head versus 4.6. sparc-rtems4.11
was not building because it was missing crti.
In 4.6, we got the makefile stub from sparc/t-crtin
but that no longer exists. It looks like the
rul
On 11/02/2011 05:30 PM, David Miller wrote:
From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500
Is this similar to what I just got for sparc-rtems when compiling
libgcc2 with -mcpu=v8?
/tmp/cczMc4jN.s: Assembler messages:
/tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled
> No, I'd like to avoid non-Solaris targets using Solaris config fragments
> if at all possible. AFAICS there's nothing Solaris-specific in
> config/sparc/sol2-c[in].S. If so, the simplest solution would be to
> rename the files to crt[in].S. On RTEMS, the generic crt[in].o rules in
> Makefile.i
Eric Botcazou writes:
>> No, I'd like to avoid non-Solaris targets using Solaris config fragments
>> if at all possible. AFAICS there's nothing Solaris-specific in
>> config/sparc/sol2-c[in].S. If so, the simplest solution would be to
>> rename the files to crt[in].S. On RTEMS, the generic crt
On Thu, Nov 03, 2011 at 09:05:49AM -0500, Aldy Hernandez wrote:
> >Could you please fix up whitespace in the patch, at least leading tabs
> >and trailing whitespace?
> >On the patch it is easy to do, something like:
> >sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
> >\{32\}/+\1\t\t\
Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
../../work/gcc/collect2.c: In function 'int main(int, char**)':
../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr'
[-Werror=unused-variable]
cc1plus: all warnings being treated as errors
Note that I did not find any en
On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres wrote:
> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>
> ../../work/gcc/collect2.c: In function 'int main(int, char**)':
> ../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr'
> [-Werror=unused-variable]
> cc1plus
On Thu, Nov 3, 2011 at 3:22 PM, Richard Guenther
wrote:
> On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres
> wrote:
>> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>>
>> ../../work/gcc/collect2.c: In function 'int main(int, char**)':
>> ../../work/gcc/collect2.c:1094:7: error: u
On Nov 3, 2011, at 3:23 PM, Richard Guenther wrote:
> On Thu, Nov 3, 2011 at 3:22 PM, Richard Guenther
> wrote:
>> On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres
>> wrote:
>>> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>>>
>>> ../../work/gcc/collect2.c: In function 'int m
Hi Joel,
>> No, I'd like to avoid non-Solaris targets using Solaris config fragments
>> if at all possible. AFAICS there's nothing Solaris-specific in
>> config/sparc/sol2-c[in].S. If so, the simplest solution would be to
>> rename the files to crt[in].S. On RTEMS, the generic crt[in].o rules i
On 11/03/2011 09:29 AM, Rainer Orth wrote:
Hi Joel,
No, I'd like to avoid non-Solaris targets using Solaris config fragments
if at all possible. AFAICS there's nothing Solaris-specific in
config/sparc/sol2-c[in].S. If so, the simplest solution would be to
rename the files to crt[in].S. On RT
> The same solution seems to apply here: just rename the files to
> crt[in].S and use the generic rules. They don't seem Solaris-specific
> either.
The renaming for SPARC is OK if it is done for i386 as well, but this doesn't
really seem to be necessary, see below.
> The rules are generic and h
Eric Botcazou writes:
>> The same solution seems to apply here: just rename the files to
>> crt[in].S and use the generic rules. They don't seem Solaris-specific
>> either.
>
> The renaming for SPARC is OK if it is done for i386 as well, but this doesn't
> really seem to be necessary, see below
Is this necessary for the entire patch, or just the parts that touch
existing parts of the toolchain. For example, do you want me to run
this on libitm/, etc? I'm really trying to minimize changes (even
whitespace stuff) at the last minute, but if you think it's
imperative, I will do so.
Wel
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
> Rainer Orth writes:
>
>> Ian Lance Taylor writes:
>>
>>> Michael Haubenwallner writes:
>>>
But still: given that x86-solaris started with some Pentium, I just
can't believe gcc can "optimize" for real 80386 CPU on Solaris now.
Especially as i386 (from config.guess) is the
On 11/03/2011 09:44 AM, Rainer Orth wrote:
Eric Botcazou writes:
The same solution seems to apply here: just rename the files to
crt[in].S and use the generic rules. They don't seem Solaris-specific
either.
The renaming for SPARC is OK if it is done for i386 as well, but this doesn't
really
Well at this point I am getting results like this :
=== gcc Summary ===
# of expected passes74735
# of unexpected failures790
# of expected failures 212
# of unresolved testcases 1
# of unsupported tests 1039
/opt/bw/src/GCC/gcc-4.6.2_S
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> > We don't want to do such large changes on the trunk and really the
> > amount of whitespace issues in the patch is huge. The script changes
> > only leading and trailing whitespace, so it shouldn't make any
> > difference to code generation, an
Have you ever posted the patch, or only made it available via the website?
Have you not seen the last 3 years of patches to gcc-patches? They're
prefixed by [trans-mem]. Perhaps you're filtering them out.
Just scanning
http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/comp
On Thu, Nov 3, 2011 at 5:09 PM, Aldy Hernandez wrote:
>
>> Have you ever posted the patch, or only made it available via the website?
>
> Have you not seen the last 3 years of patches to gcc-patches? They're
> prefixed by [trans-mem]. Perhaps you're filtering them out.
>
>> Just scanning
>> http
Reviewable patches as in what goes in gcc-patches? Or do you want something
else?
Reviewable branch merge patch(es). You can't expect everyone to
follow all development branches that may or may not end up being merged.
Is what I posted not in a way that can be reviewed? Did you download
On Thu, Nov 3, 2011 at 5:16 PM, Aldy Hernandez wrote:
>
>>> Reviewable patches as in what goes in gcc-patches? Or do you want
>>> something
>>> else?
>>
>> Reviewable branch merge patch(es). You can't expect everyone to
>> follow all development branches that may or may not end up being merged.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/03/11 10:14, Richard Guenther wrote:
>
> Reviewable branch merge patch(es). You can't expect everyone to
> follow all development branches that may or may not end up being
> merged.
Precisely.
Aldy, what folks are asking for is reasonably co
Index: gcc/c-opts.c
===
--- gcc/c-opts.c(.../trunk) (revision 0)
+++ gcc/c-opts.c(.../branches/transactional-memory) (revision
180773)
@@ -0,0 +1,1773 @@
+/* C/ObjC/C++ command line option handling.
+ Copy
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> Have you not seen the last 3 years of patches to gcc-patches? They're
> prefixed by [trans-mem]. Perhaps you're filtering them out.
That's not how things are supposed to be, sorry. The private branches
don't require reviews, and hence also won
> Again, can you please hit reload on your browser?
I have it too.
--
Eric Botcazou
Aldy, what folks are asking for is reasonably contained patches from
the branch that can be reviewed. Ideally they could be installed
independently, but it's not strictly necessary.
I already did so:
compiler/
libitm/
libstdc++-v3/
misc/
toplevel/
The ChangeLog's are at the top. The testsu
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> > re-generates gcc/c-opts.c which was moved to gcc/c-family. I suppose
> > sth was screwed up during some trunk->branch merge. Please review the
> > patches yourself and look for these issues and fix them.
>
> Again, can you please hit reload o
Hi,
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> What Richi is complaining about is something that got fixed yesterday
> and is no longer in the branch, and can easily be fixed by hitting
> reload on his browser.
We want to look at proper patch submissions not at websites that change
from time
We want to look at proper patch submissions not at websites that change
from time to time. I really don't know what you take issue with, or where
the difficulty is. patch submission via gcc-patches@ is a requirement
since forever, not something arbitrarily imposed on specifically you to
annoy
On Thu, 3 Nov 2011, Aldy Hernandez wrote:
> What I'd like to know is why I am constantly being asked for more stuff on the
> transactional memory branch, whereas the memory model stuff got approved
> without even asking for a complete diff (and I know what I'm being asked for,
> cause I'm doing bo
Hello Everyone,
Is it possible in GCC to create a label that is some-how dependent on a
RTL INSN (i.e. if the RTL INSN moves, the label moves with it)?
For example: In the below code
...
Add r1, r2, r3
Call some_function
LABELX:
Sub
I am trying to test the proposed merge of the transactional memory branch on
x86_64-apple-darwin11. Since the posted patches on gcc-patches seem to have
malformed sections, I used the merge patches from
http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/
instead (with the adjustm
On 11/03/2011 12:54 PM, Iyer, Balaji V wrote:
> Is it possible to make sure that the "LABELX" occurs right after the "Call
> some_function" instruction (and the instruction scheduler moves the label
> with the call INSN)? I insert the label right after the call is expanded and
> LABELX is being
Snapshot gcc-4.5-2003 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-2003/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
From: Jakub Jelinek
Date: Thu, 3 Nov 2011 09:22:51 +0100
> On Wed, Nov 02, 2011 at 11:41:08PM -0400, David Miller wrote:
>> --- a/libgcc/configure.ac
>> +++ b/libgcc/configure.ac
>> @@ -255,11 +255,12 @@ AC_CACHE_CHECK([whether assembler supports CFI
>> directives], [libgcc_cv_cfi],
>>[libgc
43 matches
Mail list logo
