In handle_aligned_attributes in c-common.c, at line 5146, it does
type = TREE_TYPE (decl);
Then at 5179 it does
TREE_TYPE (decl) = *type;
In between, type doesn't change so that's really
TREE_TYPE (decl) = * TREE_TYPE (decl);
or
TREE_TYPE (decl) = TREE_TYPE
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks
Finally, I've tried it the dirty way, ie by commenting out all the
stfd instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
stfd are used to save fpu registers and were always executed, even
if no float/double arguments were involved in the call and if no fpu
is
Patrick Olinet writes:
Finally, I've tried it the dirty way, ie by commenting out all the
stfd instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
stfd are used to save fpu registers and were always executed, even
if no float/double arguments were
Patrick Olinet writes:
I thought that fpu emulation worked by trapping cpu exceptions when a
fpu instruction is being executed and then emulating this instruction
on software level.
Yes.
Isn't the mechanism implemented by the --with-float=soft option ?
No. FPU
Rask Ingemann Lambertsen wrote:
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post the testcase, the best
Hello all,
gmon.out file is created in mcleanup function.This function however
doesn't dump the data in the grof gmon.out data format. When i looked
into the code for i386 and sparc in the backend nothing has been done
to store the profiling info the required format. How is it that the
file thus
Hello,
as a result of my decision to leave STMicroelectronics by the end of the
month, I'm stepping down as the maintainer of the st/cli development
branch (the home of the CLI back-end).
In my next job, I will be working in quite a different field; I already
know it won't be compatible with a
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've done everything to
eradicate the previous reloads
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've done everything to
Bernd Schmidt wrote:
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can't post
On 5/15/07, Roberto COSTA [EMAIL PROTECTED] wrote:
Hello,
as a result of my decision to leave STMicroelectronics by the end of the
month, I'm stepping down as the maintainer of the st/cli development
branch (the home of the CLI back-end).
In my next job, I will be working in quite a different
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
Bernd
--
This footer brought to you by insane German
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index: reload1.c
Bernd Schmidt wrote:
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
I'm afraid I'm not sure exactly
On 5/14/07, Mike Stump [EMAIL PROTECTED] wrote:
it gets farther. Anyone want to claim this is obvious? I glanced at
the code and it seems reasonable.
Nothing has changed in dwarf2out.c since April 24.
Now on the other hand c-format.c changed, which might have been the
problem
Hello,
Does anyone know of a good web site for sample C code supported by GCC
3.3.2?
Specifically, I am looking for code that can read files from a directory and
do I/O.
thanks,
Craig
_
PC Magazines 2007 editors choice for
I'm sure there are some at your school's website. Or you can ask you
TA for help with your homework.
-bw
On May 15, 2007, at 11:33 AM, craig clow wrote:
Hello,
Does anyone know of a good web site for sample C code supported by
GCC 3.3.2?
Specifically, I am looking for code that can read
The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org
ftp site for a couple of days now. Should we consider gcc
4.2.0 is be released now?
Jack
Hi developers,
For the current trunk of GCC, thinking about
the related thing of gprof and option -pg of GCC,
it's important to output correctly the data with non-fatal accuracy,
preferably 4 digits decimal instead of 2, e.g 0. ms instead of 0.00 s.
It's important so that the Amdahl's Law
2007/5/15, J.C. Pizarro [EMAIL PROTECTED] wrote:
http://en.wikipedia.org/wiki/Amdahl's_law
It's a wrong link, the next is the correct
http://en.wikipedia.org/wiki/Amdahl%27s_law
2007/5/12, Mike Stump [EMAIL PROTECTED] wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
On 5/12/07, Mark Mitchell [EMAIL PROTECTED] wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
1. Can you localize its last output that stops in its internal
infinite loop?
On Tue, May 15, 2007 at 04:28:33PM -0400, Jack Howarth wrote:
The tarballs for gcc 4.2.0 have been up on the gcc.gnu.org
ftp site for a couple of days now.
Actually, they've been up for less than 24 hours. As a general
rule, the announcement isn't posted until 24 hours after the
tarballs go
On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote:
For the current trunk of GCC, thinking about
the related thing of gprof and option -pg of GCC,
it's important to output correctly the data with non-fatal accuracy,
preferably 4 digits decimal instead of 2, e.g 0. ms instead of
2007/5/15, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, May 15, 2007 at 10:32:09PM +0200, J.C. Pizarro wrote:
For the current trunk of GCC, thinking about
the related thing of gprof and option -pg of GCC,
it's important to output correctly the data with non-fatal accuracy,
preferably 4 digits
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
2007/5/15, Joe Buck [EMAIL PROTECTED] wrote:
[ explanation of why gprof is as it is ]
It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
it is free software after all. This list usually
2007/5/16, Joe Buck [EMAIL PROTECTED] wrote:
On Wed, May 16, 2007 at 12:02:57AM +0200, J.C. Pizarro wrote:
2007/5/15, Joe Buck [EMAIL PROTECTED] wrote:
[ explanation of why gprof is as it is ]
It's not well reasoned.
If you don't like my explanation, feel free to rewrite the software;
it is
The GCC 4.2.0 release is done, so the 4.2 branch is now open for
checkins under the usual branch rules: regression fixes only.
I know that the GCC 4.2.0 release was a long time coming. Thanks to
everyone who worked on it, and for the constructive comments and
criticisms!
I'll be thinking about
Here are some build/test results for the 4.2.0 release.
#1: i686-pc-linux-gnu on RHEL 3, booted with gcc 3.4.2
(all languages except Ada).
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00713.html
(NOTE: booting with the RHEL-supplied compiler fails the
compare).
#2:
On Tue, May 15, 2007 at 06:04:11PM -0700, Joe Buck wrote:
#3: sparc-sun-solaris2.8: failure in building jv-convert (while
building libjava).
I think this is due to libiconv problems. It's a machine I don't control
where someone put a GNU libiconv in /usr/local, which tends to mess things
Mohamed Shafi [EMAIL PROTECTED] writes:
gmon.out file is created in mcleanup function.This function however
doesn't dump the data in the grof gmon.out data format. When i looked
into the code for i386 and sparc in the backend nothing has been done
to store the profiling info the required
2007/5/16, J.C. Pizarro [EMAIL PROTECTED] wrote:
For instance, this tuple stored in the memory's cell of the user
process gives an idea
* number of quantum's subcontext: long64
* moment of time that the subcontext started: long64 (CPU cycles, from RDTSC)
* (optional) moment subcontext
On May 15, 2007, at 2:20 AM, Patrick Olinet wrote:
Finally, I've tried it the dirty way, ie by commenting out all the
stfd instructions at the beginning of the ppc_closure.S file and
things seem to work !!!
Wonderful. If you could, would you submit the patch to gcc-
patches... I suspect
This has nothing to do with the development of gcc, so please take it
elsewhere.
On May 15, 2007, at 2:03 PM, J.C. Pizarro wrote:
2007/5/12, Mike Stump [EMAIL PROTECTED] wrote:
On May 11, 2007, at 3:36 PM, J.C. Pizarro wrote:
On 5/12/07, Mark Mitchell [EMAIL PROTECTED] wrote:
PR 31797: An infinite loop in the compiler while building RTEMS.
1. Can you localize its last
Matt Thomas [EMAIL PROTECTED] writes:
In handle_aligned_attributes in c-common.c, at line 5146, it does
type = TREE_TYPE (decl);
Then at 5179 it does
TREE_TYPE (decl) = *type;
In between, type doesn't change so that's really
TREE_TYPE (decl) = * TREE_TYPE (decl);
On 5/12/07, Paul Brook [EMAIL PROTECTED] wrote:
But for the following example
int a = 1;
int b = 2;
int c = 3;
c = c + a * b;
the MAC pattern is not getting recognized, instead it is still using
PLUS and MULT patterns.
Your example is bogus. This is optimized to c = 5 well before
--- Comment #10 from elizabeth dot l dot yip at boeing dot com 2007-05-15
07:48 ---
The following code exposes the problem relating to conjg(transpose(.)), with
which gfortran returns the wrong answer. If we break conjg(transpose(.)) into
two lines, then we can get the right answer.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 08:52 ---
This patch fixes this.
+ else
+ *dest = NULL;
This patch fixes the actual problem and should be committed. Thanks Jerry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31922
--- Comment #27 from rguenth at gcc dot gnu dot org 2007-05-15 08:59
---
Yes, that's a (part of!) a diff of a -details dump with the following patch
Index: passes.c
===
--- passes.c(revision 124501)
+++ passes.c
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-05-15 09:05 ---
Well, 4.0 didn't have struct aliasing, so yes. Though it's unlikely to be
fixed
for 4.1.x.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following code is invalid as shapes of X and Y are not identical:
$ cat atan2.f90
real :: x(3), y(2) ! same rank but different shapes
x = atan2(x,y)
end
$ gfortran-svn -fdump-tree-original atan2.f90
$ cat atan2.f90.003t.original
MAIN__ ()
{
real4 y[2];
real4 x[3];
F95, 7.1.5, Conformability rules for elemental operations
An elemental operation is an intrinsic operation or a de#64257;ned elemental
operation. Two entities are in shape conformance if both are arrays of the same
shape, or one or both are scalars.
Thus, for bes[jy]n the following should be
--- Comment #6 from chrbr at gcc dot gnu dot org 2007-05-15 10:30 ---
I dropped the 4.1 and implemented a -finvert-loops option on the trunk.
This option allows a basic induction variable to be decremented instead of
incremented to support exit testing against 0.
I'm validating a
--- Comment #11 from rob1weld at aol dot com 2007-05-15 10:46 ---
Here are my results with gcc version 4.2.0 20070505 (prerelease).
/wonka# ./vte
logMessage is called
/root/downloads/gcc-4_2-branch/libjava/classpath/native/jni/gtk-peer/gthread-jni.c:1242:
AWT JNI failure
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-15 10:56 ---
(In reply to comment #8)
The patch below works and regtests OK.
I told a lie - the version that regtests OK has the line
+ if (!integer_onep (info-stride[dim]))
+ stride_ne_one = 1;
a
I compiled gcc version 4.2.0 20070505 (prerelease) and decided to try some of
the Mauve tests ( http://sources.redhat.com/mauve/ ) as suggested on
http://gcc.gnu.org/install/test.html .
I did read http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16662 but when I tried
to re-open the bug it was not
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 11:17 ---
Subject: Bug 31915
Author: burnus
Date: Tue May 15 10:16:46 2007
New Revision: 124741
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124741
Log:
2007-05-15 Tobias Burnus [EMAIL PROTECTED]
PR
Parts of gcc are compiled without libiconv even if it's present in the system
and --with-libiconv-prefix specified correctly.
The reason for this is usage of HAVE_ICONV_H macro.
1. The check for iconv.h in configure does not use the value of
--with-libiconv-prefix option.
2. HAVE_ICONV_H is
--- Comment #1 from serg at vostok dot net 2007-05-15 11:25 ---
Created an attachment (id=13557)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13557action=view)
Removes HAVE_ICONV_H from source code.
This should fix the bug. And, probably, some other problems with gcc not using
program main
implicit none
real(kind=10) :: a
a = 1.1_10
write(10) a
end program main
Maybe someone could check real(16) as well. I assume only real(10) is affected,
though.
Gives:
==4217== Syscall param write(buf) points to uninitialised byte(s)
==4217==at 0x5601550: write (in
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-15 11:29 ---
Filled PR 31933 for the valgrind errors. These seem to be related to REAL(10),
but are independent of convert.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from segher at kernel dot crashing dot org 2007-05-15 13:07
---
Bisecting shows that the original bug (powerpc64 Linux build
errors out) is caused by r122781. I didn't actually test on 4.2
but the same patch is applied there (as r122782).
If the reduced testcase in
I'm seeing differences between the DWARF data being generated by gcc 3.4.6 and
4.1.2.
Compiling the following (-g -mno-quickcall):
int f(int a)
{
return a;
}
generates the following code (in both 3.4.6 and 4.1.2):
_f:
0: 6d f6 mov.w r6,@-r7
2: 0d 76
--- Comment #10 from patchapp at dberlin dot org 2007-05-15 13:40 ---
Subject: Bug number PR31867
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00961.html
--
gfortran -O3 -ftree-loop-linear -ftree-vectorize air.f90
gives:
air.f90: In function 'MAIN__':
air.f90:28: internal compiler error: Segmentation fault
Using -O2 or dropping one of the -f options removes the error. Occurs also with
-m32. This is with today's GCC 4.3 (r124742). It was working
--- Comment #1 from pault at gcc dot gnu dot org 2007-05-15 13:49 ---
This does the trick on all fronts:
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (révision 124614)
--- gcc/fortran/check.c (copie de travail)
--- Comment #1 from supermar at gmx dot de 2007-05-15 14:09 ---
I can confirm the bug for i486-unknown-linux-gnu, too.
--
supermar at gmx dot de changed:
What|Removed |Added
--- Comment #12 from ubizjak at gmail dot com 2007-05-15 15:06 ---
Patch for several other missing conversions:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00966.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24659
The option -fbacktrace gives a backtrace on various library and check errors.
If used in conjunction with -ffpe-trap=list, it could be useful to get a
backtrace for the fpe as well. Currently, the only output on fpe is Floating
point exception (or similar), which in itself isn't very helpful.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-15 15:17 ---
*** This bug has been marked as a duplicate of 31189 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-15 15:17 ---
*** Bug 31936 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-15 15:33 ---
This code has been removed in 4.3.0 anyways as the java source parser is gone.
Only the bytecode parser exists on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31932
--- Comment #47 from manu at gcc dot gnu dot org 2007-05-15 16:15 ---
(In reply to comment #46)
I've been looking at this again recently. I have a patch that changes
dg-error
and dg-warning only for languages that define gcc_error_prefix and
gcc_warning_prefix. I have tested it
PowerPC CPU without FPU (such as the PPC405EP) doesn't pass the libffi
testsuite. Most of the tests crash with an illegal instruction error message,
even those that don't manipulate double/float. For instance, it crashes with
the cls_uint test.
After investigating, I think the problem comes from
Casting a 32 bit integer to a 16 bit integer on armeb with -Os causes the
compiler to generate wrong code.
Short sample:
int foo = 4;
int blah()
{
int bar;
bar = (unsigned short)foo;
return bar;
}
This function returns 0 when compiled with -Os on GCC 4.2.0, -Os on
--- Comment #9 from dberlin at gcc dot gnu dot org 2007-05-15 16:51 ---
Each one of thousands of temporary variables ends up with 12000 fields.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #29 from niemayer at isg dot de 2007-05-15 16:54 ---
That's sad - while memory gets cheaper, it has still not become cheap enough to
cope with that huge increase in memory usage imposed by gcc 4.2. Seems I have
to stick with 4.1 until that problem is fixed...
--
--- Comment #30 from pluto at agmk dot net 2007-05-15 17:04 ---
looks like related to PR30052.
--
pluto at agmk dot net changed:
What|Removed |Added
CC|
--- Comment #3 from serg at vostok dot net 2007-05-15 17:29 ---
(In reply to comment #2)
This code has been removed in 4.3.0 anyways as the java source parser is
gone.
Only the bytecode parser exists on the trunk.
That still means 4.1 and 4.2 branches can be fixed.
Also not only
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-15 17:31 ---
Created an attachment (id=13558)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13558action=view)
Patch
Since PR 30498 is fixed, gfortran supports backtraces. However, they are only
displayed for library
Conversion to UCS-2 encoding in GNU libiconv returns bytes in network
order. gcj wants to have them in host order. The hack in libgcj swaps bytes
when necessary. However, command line arguments slip by the swapper (or
go through it even number of times).
This produces unrecognizable for a program
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-05-15 17:47 ---
(In reply to comment #8)
My recommendations are to document, in the description of test directives in
the GCC Internals manual, that xfail for dg-do is only honored for dg-do run
and ignored for other keywords,
With gcc 4.1.2, this short code:
void f1(int);
void f2(int x)
{
if (x != -2147483647 - 1)
f1(-x);
}
causes GCC to segfault.
$ gcc/bin/gcc -c -O -ftree-vrp -ftrapv trapv-ice.c
trapv-ice.c: In function #8216;f2#8217;:
trapv-ice.c:3: internal compiler error: Segmentation fault
Please
--- Comment #1 from serg at vostok dot net 2007-05-15 18:05 ---
This bug is relevant only for iconv that have the UCS-2 encoding with byte
order different from native byte order of the platform, e.g. GNU libiconv on
i386.
There are actually two subjects here.
1. Fix source code to use
--- Comment #2 from serg at vostok dot net 2007-05-15 18:11 ---
Created an attachment (id=13559)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13559action=view)
A hack to use UCS-2-INTERNAL instead of plain UCS-2
For subject 1.
Works only for those who actually have
--- Comment #3 from serg at vostok dot net 2007-05-15 18:33 ---
For subject 1.
Can java/gcj even be used without iconv in general?
Considering that java.io.File assumes all file names in OS are encoded in UTF-8
and java.String stores it's data in UCS-2 (UTF-16), the answer should be
With the attached source, 4.0 prints and error and then says that it got
confused by earlier errors. In 4.1 and 4.2, however, it gets confused
without actually printing the earlier error:
[EMAIL PROTECTED]:~$ g++-4.0 -c digikam-libmetadatawidgets.ii
--- Comment #1 from tbm at cyrius dot com 2007-05-15 18:38 ---
Created an attachment (id=13560)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13560action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
--- Comment #2 from tbm at cyrius dot com 2007-05-15 18:40 ---
This is on ia64. Apparently x86_64 shows an error. Can someone confirm what
I see on ia64?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31941
On hppa, using either of the following gcc's (Debian sid and Ubuntu feisty):
gcc version 4.1.3 20070429 (prerelease) (Debian 4.1.2-6)
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4hppa1)
results in the following:
% cat xx.c; gcc -pie -fPIC -fPIE xx.c ./a.out
int main(int n,const**p) { ; return
--- Comment #48 from janis at gcc dot gnu dot org 2007-05-15 19:29 ---
Created an attachment (id=13561)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13561action=view)
patch for testsuite infrastructure
This patch overrides dg-error and dg-warning if gcc_error_prefix and
--- Comment #4 from pcarlini at suse dot de 2007-05-15 19:30 ---
I don't think libstdc++ (the C++ runtime library) has anything to do with this.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2007-05-15 19:41 ---
The patch is incomplete, as libcpp/configure.in still checks for iconv.h.
Anyway the best thing to do here is submit a patch or patches to the
gcc patch list. Include a ChangeLog entry, etc.
--
tromey at gcc
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-15 19:43 ---
libcpp is the C PreProcessor (not the standard C++ library).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-15 19:44 ---
THis is more likely the dyanmic load's fault rather than GCC's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31942
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-15 20:06 ---
Paul thanks for your patch :)
Nonetheless, I found that this is a problem that should be addressed more
globally. I have a proposal that fixes PR31919, PR31329 and PR31930 (probably
together with many other, yet
--- Comment #7 from serg at vostok dot net 2007-05-15 20:08 ---
Created an attachment (id=13562)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13562action=view)
Removes HAVE_ICONV_H from source code.
Added libcpp/configure and libcpp/configure.ac to the patch.
--
serg at
--- Comment #8 from serg at vostok dot net 2007-05-15 20:34 ---
(In reply to comment #6)
libcpp is the C PreProcessor (not the standard C++ library).
Thanks. Now I know how to expose the bug here as well. It's -f*-charset options
of cpp.
--
serg at vostok dot net changed:
--- Comment #4 from patchapp at dberlin dot org 2007-05-15 21:05 ---
Subject: Bug number PR31919
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01003.html
--
--- Comment #9 from sje at cup dot hp dot com 2007-05-15 21:06 ---
I am going to close this defect as WORKSFORME. The bug can be reproduced with
124216 but is fixed in 124217 and later version. Whether the bug is really
fixed or became latent is not clear but it doesn't happen with
please look at the 32-bit asm. dump:
_Z3msby:
pushl %ebx
movl12(%esp), %edx
movl8(%esp), %eax
popl%ebx
movl%edx, %eax
xorl%edx, %edx
shrl$24, %eax
movzbl %al,%ecx
movzbl %cl, %eax
ret
wow!
--- Comment #1 from pluto at agmk dot net 2007-05-15 21:47 ---
Created an attachment (id=13563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13563action=view)
sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-15 22:15 ---
Try with -fomit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #3 from pluto at agmk dot net 2007-05-15 22:17 ---
(In reply to comment #2)
Try with -fomit-frame-pointer.
Andrew, please look at the makefile. -fomit.. is there already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31943
--- Comment #12 from rearnsha at gcc dot gnu dot org 2007-05-16 00:06
---
Confirmed fixed
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
The file fs/ocfs2/dlm/dlmmaster.c from the 2.6.20 kernel triggers an endless
loop in gcc 4.1 built for the hppa64-linux-gnu target.
It occurs at -O2, but not at -O1 or -O0. Also specifying -fno-cse-follow-jumps
workaround the problem.
Thanks to Randolph Chung we have a reduced testcase:
struct
1 - 100 of 110 matches
Mail list logo
