For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly, making the array variant slower. Any union
variant is
On 25/07/07, S.SRIDHAR [EMAIL PROTECTED] wrote:
Hi...
Now i am working on GCC v3.3.2 and kernel 2.4,i want to upgrade both to
the latest version GCC v4.2 and kernel 2.6,i don't know how to do so can u
help me
That depends on which flavour of GNU/Linux you are using. This mailing
Hi,
Firstly, I would say my message is somewhere completely off the topic on
either of the lists. But I dont know where to ask for help. I searched and
searched for all pointers on libelf.
Now, I use an age-old version probably - libelf.so.0.8.2.
I donno from where I got it, but probably
Ben Elliston wrote:
On Tue, 2007-07-24 at 10:48 +0100, Manuel López-Ibáñez wrote:
GCC is thoroughly tested. None the less, there is always room for
improvement, so if you have time to implement your ideas or write
documentation, you are welcome to contribute.
If you build the compiler
On 7/25/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly,
[EMAIL PROTECTED] wrote:
On 25/07/07, S.SRIDHAR [EMAIL PROTECTED] wrote:
Hi...
Now i am working on GCC v3.3.2 and kernel 2.4,i want to upgrade both to
the latest version GCC v4.2 and kernel 2.6,i don't know how to do so
can u
help me
That depends on which flavour of GNU/Linux
On Wed, Jul 25, 2007 at 03:51:57PM +0530, Anitha Boyapati wrote:
Firstly, I would say my message is somewhere completely off the topic on
either of the lists. But I dont know where to ask for help. I searched and
searched for all pointers on libelf.
The fact remains that it is off-topic.
Ben Elliston wrote:
If you build the compiler with coverage instrumentation and run the
testsuite, you might get a shock. It's not as well tested as you might
think.
On Wed, Jul 25, 2007 at 07:05:36AM -0400, Robert Dewar wrote:
If it gave anyone a shock to find out that the test suite did
On 25 July 2007 18:00, Joe Buck wrote:
On Wed, Jul 25, 2007 at 03:51:57PM +0530, Anitha Boyapati wrote:
Firstly, I would say my message is somewhere completely off the topic on
either of the lists. But I dont know where to ask for help. I searched and
searched for all pointers on libelf.
2007/7/25, Joe Buck [EMAIL PROTECTED] wrote:
On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote:
Patch it to investigate it a little bit more.
After runned it, see quickdirty.log and post here your report's summary.
No, please do not. This is not the libelf list; use that list.
On Wed, 2007-07-25 at 09:02 +0100, Manuel López-Ibáñez wrote:
To everybody else: Would it be possible to implement a filter such the
first mail ever from someone gets bounced back with a message about
what the list is about and suggesting sending the mail again if the
sender is sure that it
System is Solaris 8 Sparc. Totally up to date. Vendor provided compiler is
Sun ONE Studio 8 also patched up to date.
My boot strap of GCC 4.2.1 fails at stage 2. Here is what I know.
My approach with GCC has always been to bootstrap at least twice and then
run the testsuites to verify that
On Wednesday 25 July 2007 14:40, David A. Greene wrote:
Has anyone had a chance to look at bug 32346 yet? The fact that its status
is still UNCONFIRMED and unassigned leads me to think not.
Forgot to add that this bug still exists on trunk.
-Dave
Has anyone had a chance to look at bug 32346 yet? The fact that its status
is still UNCONFIRMED and unassigned leads me to think not.
-Dave
On Mon, 2007-07-23 at 00:52 +0300, Evgeniy Filatov wrote:
I am programmer, i am writing C/C++ programs for Nokia Series 60
devices, and often i need to run some parts of code directly on
device. I think, not only me, but other symbian developers got same
problem. There are no C compiler, that
On Wed, Jul 25, 2007 at 08:50:13PM +0200, J.C. Pizarro wrote:
2007/7/25, Joe Buck [EMAIL PROTECTED] wrote:
On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote:
Patch it to investigate it a little bit more.
After runned it, see quickdirty.log and post here your report's
summary.
On Wed, Jul 25, 2007 at 08:32:33PM +0200, J.C. Pizarro wrote:
Patch it to investigate it a little bit more.
After runned it, see quickdirty.log and post here your report's summary.
No, please do not. This is not the libelf list; use that list.
Joe Buck wrote:
Right. However, some coverage-oriented methodologies explicitly mark code
that is expected to be unreachable, and produce unit tests to exercise at
least some of the defensive code that no longer gets run by the compiler
as a whole. If any volunteers would like to take on the
Patch it to investigate it a little bit more.
After runned it, see quickdirty.log and post here your report's summary.
;)
libelf-0.8.2_quickdirtyprint.patch
Description: Binary data
On Wed, 2007-07-25 at 07:05 -0400, Robert Dewar wrote:
If you build the compiler with coverage instrumentation and run the
testsuite, you might get a shock. It's not as well tested as you might
think.
If it gave anyone a shock to find out that the test suite did not
provide 100%
--- Comment #14 from dominiq at lps dot ens dot fr 2007-07-25 06:38 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
There were two modifications between these revs:
123620 format.c
123623 write.c
Yes, but the first one is very short and not
--- Comment #15 from dominiq at lps dot ens dot fr 2007-07-25 06:41 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
Forgot to say in my previous mail that libgfortran/config.h for
gcc4.2.1 contains:
...
/* Define if fpclassify is broken. */
/* #undef
--- Comment #4 from nathan at gcc dot gnu dot org 2007-07-25 07:53 ---
2007-07-24 Nathan Sidwell [EMAIL PROTECTED]
* method.c (implicitly_declare_fn): Increase alignment if member
function pointer format requires it.
--
nathan at gcc dot gnu dot org changed:
in gcc (GCC) 4.2.1 20070705 (prerelease) (SUSE Linux)
# gcc -c -O2 -fPIC x.i
x.i: In function 'mi_open':
x.i:104: warning: incompatible implicit declaration of built-in function
'strlen'
x.i:111: internal compiler error: in delete_output_reload, at reload1.c:7926
attaching testcase to this bug
--- Comment #1 from b dot gunreben at web dot de 2007-07-25 08:20 ---
Created an attachment (id=13971)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13971action=view)
testcase x.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
--- Comment #9 from falk at debian dot org 2007-07-25 08:24 ---
(In reply to comment #8)
You may only access union members through the union, not through other
pointers.
Where is this documented? I thought it should be in extend.texi, but I couldn't
find it...
--
--- Comment #2 from b dot gunreben at web dot de 2007-07-25 08:26 ---
just to add some more information:
# gcc -v
Using built-in specs.
Target: hppa2.0-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--- Comment #17 from dorit at gcc dot gnu dot org 2007-07-25 08:40 ---
This looks like an unrelated problem - the vectorizer does not perform loop
peeling here so it's not an issue of natural alignment. Lets open a separate PR
for this one, unless there's already one open. In the
--- Comment #3 from jb at gcc dot gnu dot org 2007-07-25 08:46 ---
Related to this, a string library for libgfortran:
http://gcc.gnu.org/ml/fortran/2007-07/msg00463.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
--- Comment #18 from dorit at gcc dot gnu dot org 2007-07-25 08:51 ---
Subject: Bug 25413
Author: dorit
Date: Wed Jul 25 08:51:12 2007
New Revision: 126904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126904
Log:
2007-07-25 Dorit Nuzman [EMAIL PROTECTED]
Devang
--- Comment #19 from dorit at gcc dot gnu dot org 2007-07-25 08:52 ---
problem fixed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org
[EMAIL PROTECTED] wrote
In the meantime, would you please try this patch?:
Of course after my patch for PR 16660, the patch here should be
changed to just return true always.
Thanks,
Andrew Pinski
--- Comment #20 from pinskia at gmail dot com 2007-07-25 09:12 ---
Subject: Re: wrong alignment or incorrect address computation in vectorized
code on Pentium 4 SSE
On 25 Jul 2007 08:40:09 -, dorit at gcc dot gnu dot org
[EMAIL PROTECTED] wrote
In the meantime, would you please
--- Comment #4 from cnstar9988 at gmail dot com 2007-07-25 09:13 ---
I download GCC from ftp.gnu.org, 4.2.1 release.
gcc -O3 -Wall test.c
can gernerate warning on gcc-4.2.1 on x86
but no warning on gcc-4.2.1/x64. even -m32 or -m64.
I only think the behavior on both platform is the
--- Comment #21 from dorit at gcc dot gnu dot org 2007-07-25 11:11 ---
Of course after my patch for PR 16660, the patch here should be
changed to just return true always.
In this case, Ryan, could you please also try to see if Andrew's patch
This is a follow up to PR 30814 (which implemented a run-time check).
The following test case should rise a compile-time error:
NAG f95:
Error: a.f90, line 3: Different vector lengths (19 and 30)
ifort:
Error: a.f90, line 3: The shapes of the array expressions do not
conform. [NEIGHBRS]
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-25 11:39 ---
Reminder: If implemented, change the PACK library function to print out the
size of LHS/RHS array (cf. PR 30814 PR 32890).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-25 11:46 ---
Created an attachment (id=13972)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13972action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32891
In 4.2 with -O2 we use 1.5GB compiling the testcase while with 4.1 we only
needed
360MB. Using -fno-tree-pre fixes the memory regression.
Some recent 4.3 ICEs for me on the testcase (you need -O2 -fpermissive) with
/usr/include/boost/regex/v4/basic_regex_creator.hpp:515: internal compiler
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-25 12:50 ---
break build2_stat if code == INIT_EXPR !useless_type_conversion_p
(arg0-common.type, arg1-common.type)
and you reach the offending tree build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
--- Comment #6 from dir at lanl dot gov 2007-07-25 12:56 ---
I did the build with --with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar and there
is no visible ecj anywhere on my machine. ecj1 is in
./java/libexec/gcc/powerpc-apple-darwin8.10.0/4.3.0/. With ecj1 -help, ecj1
sits using nearly
--- Comment #1 from jbuehler at spirentcom dot com 2007-07-25 13:09 ---
This bug is also present in 4.0.1 for powerpc-ibm-aix5.2.0.0. Change the
registers in the problematic code to r14, r15, r16, r17 -- one of the registers
is not set by the optimized routine, but is by the
--- Comment #2 from jbuehler at spirentcom dot com 2007-07-25 13:22 ---
The same bug is present in the following versions of gcc for
sparc-sun-solaris2.9:
2.95.3
2.95
3.0.2
3.0.4
3.1.1
3.2.3
3.3.6
3.4.6
4.0.1
4.0.4
4.1.2
4.2.0
Use registers l1, l2, l3, l4 in the sample code to
--- Comment #3 from jbuehler at spirentcom dot com 2007-07-25 13:28 ---
I would appreciate a fix for this because the code being compiled is the GHC
compiler itself. I have to compile GHC for hppa without optimization because I
have been unable to find a compiler options workaround for
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-25 13:48 ---
With -fstrict-aliasing we claim the conversion is neccessary because the
pointed
to alias sets of the two pointers are different. For -fno-strict-aliasing the
frontend later says via the langhook that the two
--- Comment #7 from pcarlini at suse dot de 2007-07-25 14:46 ---
Cannot be reproduced anymore.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-25 15:05
---
Created an attachment (id=13973)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13973action=view)
Fix: adjust div cost for -Os on i386
Patch was tested with 4.2.1, I guess it will apply to other versions
--- Comment #3 from vda dot linux at googlemail dot com 2007-07-25 15:09
---
Created an attachment (id=13974)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13974action=view)
Auto-generated test program with 15000 constant divs/mods
Test program, bzipped.
Build with
gcc
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-25 15:22
---
Forgot to mention:
* generator tests signed and unsigned divisions and modulus, both const / x and
x / const, and also tests u = a / b; v = a % b; construct.
* you need to filter gen_test output to weed out
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-25 15:17
---
Created an attachment (id=13975)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13975action=view)
Test program generator
Test program was generated using gen_test.c
--
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-25 15:30 ---
This fixes the PR but is not regtested:
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(révision 126835)
---
--- Comment #35 from danglin at gcc dot gnu dot org 2007-07-25 15:32
---
Subject: Bug 31836
Author: danglin
Date: Wed Jul 25 15:32:33 2007
New Revision: 126914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126914
Log:
PR libstdc++/31836
*
--- Comment #11 from pbrook at gcc dot gnu dot org 2007-07-25 15:47 ---
Should be fixed now.
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from danglin at gcc dot gnu dot org 2007-07-25 15:36
---
Fixed on hppa by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host:
/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/../../gfortr
an -B/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/../../ -w -O -c -o
/home/dave/gcc-4.3/objdir/gcc/testsuite/gfortran/pr32417.o
/home/dave/gcc-4.3/gc
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:20 ---
Well, that was silly. I couldn't reproduce the problem because I had a patch
in my local tree. Here is the patch I created, I will submit it to
gcc-patches.
Basically, get_vectype_for_scalar_type can return a NULL_TREE
--- Comment #2 from sje at cup dot hp dot com 2007-07-25 16:49 ---
Yes, that patch (now in the main line) seems to have fixed the problem. The
failures have gone away so I will close this defect.
--
sje at cup dot hp dot com changed:
What|Removed
--- Comment #7 from sje at cup dot hp dot com 2007-07-25 16:52 ---
Carolyn has checked in a patch to var-tracking.c and I can bootstrap IA64 Linux
so I am going to close this out as fixed. The patch that fixed this was:
2007-07-18 Caroline Tice [EMAIL PROTECTED]
*
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-25 16:56 ---
*** Bug 32892 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32527
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-25 16:56 ---
I should be committing a fix for this issue soon.
*** This bug has been marked as a duplicate of 32527 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from eweddington at cso dot atmel dot com 2007-07-25 17:05
---
Patch to document AVR progmem attribute:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01832.html
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-25 17:15 ---
This fixes the PR but is not regtested:
Patch looks OK and regtests on x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31211
--- Comment #2 from eweddington at cso dot atmel dot com 2007-07-25 17:29
---
Confirmed on 4.2.1.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #2 from eweddington at cso dot atmel dot com 2007-07-25 17:57
---
The AVR test results for a 4.2.1 prerelease still shows failure on -O0 only:
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00335.html
However the results for a 4.3 snapshot shows failure on all -O
--- Comment #3 from eweddington at cso dot atmel dot com 2007-07-25 17:42
---
Confirmed for 4.2.1 on mingw host.
test.cpp: In function 'T* rom(const T) [with T = uint8_t]':
test.cpp:21: instantiated from here
test.cpp:10: internal compiler error: Segmentation fault
--
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-25 17:57 ---
Paul, thanks for the tip.
I'll have a look.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-25 18:58 ---
This is now fixed with the new DSE on the trunk which came in with the dataflow
merge (which was really a rewrite of flow.c :) )
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from danglin at gcc dot gnu dot org 2007-07-25 18:56
---
Fixed by dataflow merge on hppa.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from sje at gcc dot gnu dot org 2007-07-25 20:24 ---
Subject: Bug 32218
Author: sje
Date: Wed Jul 25 20:24:15 2007
New Revision: 126931
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126931
Log:
PR target/32218
* tree-vect-patterns.c
--- Comment #1 from boz283 at ece dot northwestern dot edu 2007-07-25
21:28 ---
Created an attachment (id=13976)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13976action=view)
Intermediate file for the program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:53 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
Can you attach the dump of -fdump-rtl-expand-details ?
Attached.
Dave
--- Comment #14 from dave at hiauly1 dot hia dot nrc
--- Comment #4 from tjk at tksoft dot com 2007-07-25 21:24 ---
I got the same problem using sed 3.02 to build. Upgrading to sed 4.1.5
fixed the problem.
The fixincl program runs sed scripts for glibc pthread checks which fail on sed
3.02, but succeed on sed 4.1.5.
What happens is that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
There's no code to attach, as this failure is simply for a gcc-4.2.1 build,
using binutils-2.17 and initiated with gcc-3.3.6; to be specific:
CC=gcc336 CFLAGS=-O2 -g -mpa-risc-2-0 /usr/local/src/gcc-4.2.1/configure \
--host=hppa64-hp-hpux11.11 --with-local-prefix=/usr/local/64bit \
--- Comment #6 from andreast at gcc dot gnu dot org 2007-07-25 20:11
---
Fine with me, thanks and sorry for the delay. Pls ci.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
--- Comment #15 from pcarlini at suse dot de 2007-07-25 21:56 ---
By the way, s390x-linux apparently is also affected...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-25 21:32 ---
Or TLS not working with your version of glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
I have been able to compile and run the application correctly with -fopenmp
flag, but when I also add -static flag I can compile the application. However
while running it i get a segmentation fault error.
I have used gdb to see where the program crashes, and it seems to be somewhere
in openmp
The following invalid code snippet is accepted since GCC 4.2.0:
=
namespace N { }
int N::i;
=
--
Summary: [4.2/4.3 regression] Definition of variable N::i outside
namespace N not rejected
Product: gcc
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-25 21:36
---
So we have:
(insn 6 5 7 2
/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set
(mem/s/c:SI (plus:SI (reg/f:SI 3 %r3)
(const_int 8 [0x8])) [10 b.D.57473.D.57333._M_w+0 S4
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-07-25 23:00
---
More info for everyone.
Under Cygwin, reading and writing from/to /dev/conin$ and /dev/conout$
respectively works fine with gfortran now. (Thanks David Korn for info)
I think this is sufficient for Cygwin.
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-25 21:49
---
Can you attach the dump of -fdump-rtl-expand-details ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
--- Comment #7 from kristerw at gcc dot gnu dot org 2007-07-25 23:51
---
Subject: Bug 30058
Author: kristerw
Date: Wed Jul 25 23:51:47 2007
New Revision: 126937
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126937
Log:
2007-07-24 Krister Walfridsson [EMAIL PROTECTED]
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-25 23:57 ---
Confirmed.
Volker's suggestion is the correct fix. I have a patch
and test case. I'm regression testing I as I type.
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from kristerw at gcc dot gnu dot org 2007-07-26 00:01
---
Fixed on trunk for NetBSD 2.x, 3.x, and 4.x.
--
kristerw at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
21:31 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
The appears to be a problem with the sched passes. If I compile with
-fno-schedule-insns and -fno-schedule-insns2, the test doesn't
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-25
22:07 ---
Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test
So the aliasing set of bitset5 is 88 and the store for
b.D.57473.D.57333._M_w
is done in aliasing set 10. Someone has to debug
void test(void)
{
struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile(in r28, 0x2F : : : r28);
x.d = 6;
}
$ avr-gcc.exe -v
Using built-in specs.
Target: avr
Configured with: ../gcc-4.1.1/configure
--prefix=/c/WinAVR --target=avr
--enable-languages=c,c++
--- Comment #4 from sje at cup dot hp dot com 2007-07-25 22:56 ---
The test case is still not working for me on IA64 HP-UX. I also still see
gfortran.dg/c_kind_params.f90 failing at all optimization levels.
c_char_tests.f03 also fails
--
sje at cup dot hp dot com changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-26 01:23 ---
I am just going to close this as being fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-07-25 21:58
---
;; b.D.57473.D.57333._M_w = 7
(insn 5 4 6
/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/bitset:572 (set
(reg:SI 94)
(const_int 7 [0x7])) -1 (nil))
(insn 6 5 0
Points-to memory with these is almost nothing, so don't look at meef.
It looks like size goes up for each function and is not fully
recovered by the time we start the next.
On 25 Jul 2007 22:25:22 -, debian-gcc at lists dot debian dot org
[EMAIL PROTECTED] wrote:
[forwarded from
--- Comment #4 from boz283 at ece dot northwestern dot edu 2007-07-25
22:15 ---
How can i check to see if the pthreads library is being linked correctly or
find out if the problem is caused by TLS?
Thanks
Berkin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32896
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-25 20:45 ---
Andrew, makes sense to you?
I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY
which is why it does not work but I have not looked into it at all.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-25 20:43 ---
thanks a lot for checking both patches!
With this patch zlib appears to compile successfully. The loop is
vectorized with an alignment of access forced using peeling note and linked
apps no longer segfault.
I'd
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-25 19:43 ---
This may actually have been fixed by my cfglayout work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17234
--- Comment #4 from dtemirbulatov at gmail dot com 2007-07-26 01:16 ---
this issue could not be reproduced on the mainline after dataflow-branch merge
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31552
1 - 100 of 127 matches
Mail list logo
