On 4/17/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know which maintainer ask to review it :(
I think this patch needs re-testing (because of my cfglayout
On 4/16/07, Jan Hubicka [EMAIL PROTECTED] wrote:
If you just want to scan every function you have around, the obvious
way to do it is
For each function
FOR_EACH_BB_FN (function).
This is probably slightly slower than
For each function
if cgraph_function_body_availability !=
On 4/17/07, Steven Bosscher [EMAIL PROTECTED] wrote:
On 4/17/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know which maintainer ask to review it :(
I think this
Hiya,
I'm doing research on which optimization passes to enable in the
various -On flags, and I've stumbled onto a/some minor bug(s) and
problems with the GCC documentation for the 4.1.2 version:
* When using -falign-loops or -fno-align-loops the corresponding
internal variable
On 4/17/07, Richard Guenther [EMAIL PROTECTED] wrote:
Indeed. The patch is ok after a re-bootstrap and re-test.
Actually, please don't commit that patch.
Eric Botcazou has already proposed a fix that looks better:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01065.html
Gr.
Steven
On 4/17/07, Kenneth Hoste [EMAIL PROTECTED] wrote:
* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
corresponding internal flag flag_schedule_insns_after_reload) is
still being used... The reason for disabling fschedule-insns is
increased register pressure (and x86 has few
Thank you for the references at Code Sourcery, regading SJLJ exception
handling I found the paper (which references it): Exception Handling
in the Choices Operating System, is the reference for SJLJ EH?
Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD
On 17 April 2007 11:08, Paulo J. Matos wrote:
Thank you for the references at Code Sourcery, regading SJLJ exception
handling I found the paper (which references it): Exception Handling
in the Choices Operating System, is the reference for SJLJ EH?
Dunno about that, but I found this link
-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues
- finline-functions is enabled at -Os, but isn't listed so
And it seems to have some issues:
Got the documents signed and they are now on their
way.
--- Richard Guenther [EMAIL PROTECTED]
wrote:
On 11/3/06, Ian Blanes [EMAIL PROTECTED] wrote:
The original author of this patch said he sent his
copyright assignment. I
only did minor modification to his work so I don't
I think I
On Apr 17, 2007, at 3:11 AM, Paulo J. Matos wrote:
I wonder, that if I am to use gcc head, how can I do that?
This isn't a trick question is it? Anyway, it is answered by our web
site. Briefly, you check out trunk and then you edit it. patch is
one way to mass edit a source tree for
Kenneth Hoste [EMAIL PROTECTED] writes:
* When using -falign-loops or -fno-align-loops the corresponding
internal variable 'align-loops' should be set to 0 (= use default
setting) or 1 (= no aligning) resp. When parsing the various flags, a
variable 'value' is used to set (value=1) or unset
On 4/17/07, Mike Stump [EMAIL PROTECTED] wrote:
On Apr 17, 2007, at 3:11 AM, Paulo J. Matos wrote:
I wonder, that if I am to use gcc head, how can I do that?
This isn't a trick question is it? Anyway, it is answered by our web
site. Briefly, you check out trunk and then you edit it. patch
On 17 Apr 2007, at 18:18, Eric Weddington wrote:
-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues
- finline-functions is enabled at -Os, but isn't
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
- finline-functions is enabled at -Os, but isn't listed so
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
Comments #4 and #6.
The only real issue here is a wrong expectation: That a certain
combination
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 2:52 PM
To: Eric Weddington
Cc: Kenneth Hoste; gcc@gcc.gnu.org
Subject: Re: GCC -On optimization passes: flag and doc issues
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
As Eric Weddington wrote:
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528 Comments #4
and #6.
The only real issue here is a wrong expectation: That a certain
combination of flags magically does the best thing for every
target.
No, the issue is
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
when perhaps they should
also notice that the efficiency of GCC for -Os has increased
tremendously in the past few years...
That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 2:52 PM
To: Eric Weddington
Cc: Kenneth Hoste; gcc@gcc.gnu.org
Subject: Re: GCC -On optimization passes: flag and doc issues
On 4/17/07, Eric Weddington [EMAIL PROTECTED] wrote:
Eric Weddington [EMAIL PROTECTED] writes:
Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs? I might give it a try to see whether I
can find a more optimal set of parameters.
This was in response to your comment
As Steven Bosscher wrote:
Maybe you can look at the development of code size of AVR over time,
and show a different trend, but I'd be surprised.
Most AVR users use -Os, as small code is fast code in most of the
cases on the AVR. The `overall summary' is that GCC continuously
decreased its
On 4/18/07, Joerg Wunsch [EMAIL PROTECTED] wrote:
As Eric Weddington wrote:
And it seems to have some issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528 Comments #4
and #6.
The only real issue here is a wrong expectation: That a certain
combination of flags magically does
As Ian Lance Taylor wrote:
If the code size increases for AVR, when using -Os, when comparing an
older release to mainline or 4.2 branch, you should report that as a
regression in bugzilla. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--
cheers, Jorg .-.-.
On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
Well this begs the question of why, when there are so many
different targets, are there are only 4 optimization flags
(1,2,3,s), especially when they only get tuned to certain targets?
If you count again, you'll see there are more than 4
No, the issue is that the -Os option is *documented* to *only* include
those optimizations that are known to not increase the code size.
Where exactly is the documented? My documentation says It
enables optimisations that do not *typically* increase code size (emphasis
mine).
Many
-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 4:20 PM
To: Eric Weddington
Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch';
'Anatoly Sokolov'
Subject: Re: GCC -On optimization passes: flag and doc issues
Eric
As Steven Bosscher wrote:
And now that you've shown that for this test case GCC actually may
have regressed on every target, you've shown that perhaps the global
inlining heuristics should be changed. May well be, for all I know.
Tuning heuristics is always hard and never provably optimal.
I
-Original Message-
From: Mike Stump [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 4:28 PM
To: Eric Weddington
Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch';
'Anatoly Sokolov'
Subject: Re: GCC -On optimization passes: flag and doc issues
On Apr 17, 2007, at
Joerg Wunsch [EMAIL PROTECTED] writes:
As Ian Lance Taylor wrote:
If the code size increases for AVR, when using -Os, when comparing an
older release to mainline or 4.2 branch, you should report that as a
regression in bugzilla. Thanks.
increase code size? I feel I must be missing something really
obvious... is
it just that the other optimisations that become possible on inline
code
usually compensate?
That or the savings from not having to save/restore registers, set up
the frame, etc as well.
-eric
On Tue, Apr 17, 2007 at 03:44:36PM -0700, Ian Lance Taylor wrote:
The relevant code is in opts.c:
if (optimize_size)
{
/* Inlining of very small functions usually reduces total size. */
set_param_value (max-inline-insns-single, 5);
set_param_value
On Wed, Apr 18, 2007 at 12:16:32AM +0100, Dave Korn wrote:
Sorry for butting in, but I just can't follow the reasoning here.
Unless a function is only ever used once and is inlined at the single
callsite, or unless the prolog and epilog are several times the size of
the function body, isn't
On Mon, Apr 16, 2007 at 10:09:35PM +0200, Laurent GUERBY wrote:
On Mon, 2007-04-16 at 12:00 -0600, Tom Tromey wrote:
I wonder whether there is a role for the gcc compile farm in this?
For instance perhaps someone could keep a set of builds there and
provide folks with a simple way to
Hello,
i've an idea to improve the report of -fdump-tree- using the HTML
format for its output.
I recommend XHTML-1.0 (26-Jan-2000) from http://www.w3.org/TR/xhtml1/
Note: HTML-4.01 (24-Dec-1999) from http://www.w3.org/TR/html401/
is very popular but very old and it's not XML-1.0
J.C. Pizarro wrote on 04/17/07 21:48:
The visual representation in HTML is more effective for humans than
in text.
No. Heck, no.
On Thu, 12 Apr 2007, FX Coudert wrote:
Hi all,
I reviewed this afternoon the postings from the gcc-testresults
mailing-list for the past month, and we have a couple of gfortran
testsuite failures showing up on various targets. Could people with
access to said targets (possibly maintainers)
Diego Novillo wrote:
J.C. Pizarro wrote on 04/17/07 21:48:
The visual representation in HTML is more effective for humans than
in text.
No. Heck, no.
I agree. PDF is clearly superior ;-)
J.C., Please submit a patch for PDF support.
David Daney
On 4/18/07, Joe Buck [EMAIL PROTECTED] wrote:
Perhaps the number of arguments should be taken into account as well.
We've been doing that for years.
Gr.
Steven
--- Comment #3 from steven at gcc dot gnu dot org 2007-04-17 07:12 ---
To the reporter:
Even though this is already (correctly) closed as INVALID, please let us know
if your code does compile and run correctly if you compile with the suggested
extra command line option,
--- Comment #15 from gcc at magfr dot user dot lysator dot liu dot se
2007-04-17 07:15 ---
I think there are still some kind of problem.
If I try to compile bar.C using g++ -c bar.C then where g++ is g++ (GCC) 4.3.0
20070416 (experimental) (Hm, I'd wish for a revision number in there
--- Comment #16 from gcc at magfr dot user dot lysator dot liu dot se
2007-04-17 07:18 ---
Created an attachment (id=13375)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13375action=view)
Test showing that the current fix causes an ICE
--
--- Comment #5 from dorit at il dot ibm dot com 2007-04-17 07:22 ---
Doing cast motion actually causes about 25 *more* failures in the vectorizer
testsuite.
I'm closing this as won't fix since it seems there was no other reason to do
this.
can you please send me the patch so that I
--- Comment #6 from dorit at il dot ibm dot com 2007-04-17 07:38 ---
can you please send me the patch so that I could look at this failures before
you close this PR?
I'm going over my inbox top down, so I just saw that you had laready sent the
patch... so I will look into it.
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-04-17 07:52
---
Created an attachment (id=13376)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13376action=view)
Patch that allows for module to be overwritten only if they changed
This is the complete patch. Have fun!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
Target Milestone|--- |4.3.0
--- Comment #4 from r dot emrich at de dot tecosim dot com 2007-04-17
07:54 ---
Created an attachment (id=13377)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13377action=view)
Patch
Proposed patch. I added a new target (install-exec-am) to Makefile.am to
enforce the right
/usr/local/bin/gcc -c -I. -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes
-O2 -o rlimits..o rlimits.c
rlimits.c: In function 'bin_unlimit':
rlimits.c:674: error: unrecognizable insn:
/usr/local/bin/gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
This is with gcc version 4.3.0 20070416 (experimental).
The attached program when compiled with g++ and the flags -fopenmp gives the
following diagnostic and aborts compilation:
- /usr/local/gcc-4.3/bin/g++ -fopenmp BugOMP.C
BugOMP.C: In constructor RM::R():
BugOMP.C:18: error: invalid use of
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-04-17 09:21 ---
Created an attachment (id=13378)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13378action=view)
The source code showing the potential bug
--
--- Comment #31 from rguenth at gcc dot gnu dot org 2007-04-17 09:22
---
It's broken as we want the code from comment #1 back.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from amylaar at gcc dot gnu dot org 2007-04-17 09:48 ---
Since I am no longer an SH port maintainer this is no longer of immediate
interest to me.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-17 10:37
---
Closing this bug as WONTFIX, as I was convinced by other maintainers that it's
not really a problem.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pluto at agmk dot net 2007-04-17 12:05 ---
(In reply to comment #5)
Can you unset CFLAGS and try again?
without cflags and with cflags=-O0 - still the same error.
I bet 4.1.2 is being miss compiled at least looking at the logs.
what's wrong in logs? i see only
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-17 12:14 ---
(In reply to comment #3)
To the reporter:
Even though this is already (correctly) closed as INVALID, please let us know
if your code does compile and run correctly if you compile with the suggested
extra command
--- Comment #2 from charlet at adacore dot com 2007-04-17 13:06 ---
Subject: Re: [regression] Ada bootstrap error
You need to add the following in system-xxx.ads:
pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
as done in other system-* files, after
Page here omits doc which is in the pdf manual -
http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
--
Summary: Online gcc doc page is blank - no Attribute-Syntax.html
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity:
GCC HEAD now warns about this testcase for mips-linux, reduced from
gdb/value.c. Compile with -O2 -Wall:
extern int foo();
int show_values (void)
{
int i;
static int num;
if (num = 0)
num = 1;
for (i = num; i num + 10; i++)
foo();
return i;
}
overflow.c:10: warning:
--- Comment #1 from drow at gcc dot gnu dot org 2007-04-17 13:26 ---
Subject: Re: New: Overflow warning causes
GDB -Werror build failure
On Tue, Apr 17, 2007 at 12:21:36PM -, drow at gcc dot gnu dot org wrote:
GCC HEAD now warns about this testcase for mips-linux,
The following program is invalid:
--
module a
implicit none
contains
integer function bar()
bar = 42
end function
end module a
use a
implicit none
integer :: bar
end
--
gfortran -pedantic or gfortran -std=f95 gives the error:
Error: Symbol 'bar' at (1)
Currently, it is far from obvious that rejected code might be compilable with
-std=legacy/-fno-range-check or similar (is there anything else?). I think one
could add a note to the error message:
Examples:
Integer too big for its kind at %C - Integer too big for its kind at %C.
Use
--- Comment #5 from deji_aking at yahoo dot ca 2007-04-17 13:21 ---
Yes adding compiling with -ffixed-line-length-80 solved the issue for me,
thanks to you both. I've noticed the original author of that code used tabs in
a couple of space he should have used spaces, the other compilers
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-04-17 13:33
---
(In reply to comment #8)
The patch looks good, though it would probably be a better idea to use
tmpnam()
to get the name for the temporary file.
Why not. But I like the idea that it is predictable :)
A
--- Comment #9 from tobi at gcc dot gnu dot org 2007-04-17 13:22 ---
Oh, one more issue: do you have an idea how to write testcases for this? I'm a
bit at a loss, though I've only thought about this for a few minutes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
--- Comment #11 from tobi at gcc dot gnu dot org 2007-04-17 13:41 ---
(In reply to comment #10)
(In reply to comment #8)
The patch looks good, though it would probably be a better idea to use
tmpnam()
to get the name for the temporary file.
Why not. But I like the idea that
--- Comment #5 from chtitux at gmail dot com 2007-04-17 13:46 ---
I have the same problem on Gentoo :
http://fr.pastebin.ca/51
I try to compile gcc-4.1.1 with gcc-4.1.1 on AMD Athlon(tm) XP 2600+ :
Please Reopen the bug.
CFLAGS=-march=athlon-xp -O2 -pipe
CXXFLAGS=-march=athlon-xp
+++ This bug was initially created as a clone of Bug #26640 +++
Note that this is a repeatable bug (three times in succession, the last time
with a full delete and re-installation of the source).
The following configure switches were used.
../configure --prefix=/home/gcc410
--- Comment #8 from tobi at gcc dot gnu dot org 2007-04-17 13:20 ---
The patch looks good, though it would probably be a better idea to use tmpnam()
to get the name for the temporary file.
A further thing one could do: instead of threatening If you edit this, you'll
get what you
--- Comment #1 from burnus at gcc dot gnu dot org 2007-04-17 13:14 ---
If one tries to change the attribute of an USE-associated symbol the error is
better:
external omp_get_num_threads, omp_get_thread_num
1
Error: Cannot change attributes of USE-associated
$ cat hello.f90
integer :: tid
!$omp parallel private(tid)
tid = 0
if (tid .eq. 0) write(*,*) 'hello'
!$omp end parallel
end
$ gfortran -fopenmp hello.f90 -g -static
$ ./a.out
zsh: segmentation fault ./a.out
It appears to be due to the combination of
(i) spawning a thread
Most floating point tests fail when GDB is built with GCC trunk for mips-linux.
I assume it shows up on all targets. The miscompiled function is
doublest.c:put_field. Here is a reduced test case:
int put_field (unsigned int start, unsigned int len)
{
int cur_bitshift = ((start + len) % 8) -
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-17 15:03 ---
The page is not blank for me:
5.26 Attribute Syntax
This section describes the syntax with which __attribute__ may be used, and the
constructs to which attribute specifiers bind, for the C language. Some details
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-17 15:59 ---
You check where the segfault is happening.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-17 16:03 ---
4.1.2 != 4.2.0, Anyways this was fixed in 4.2.0 and is a dup of bug 29826.
*** This bug has been marked as a duplicate of 29826 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from 3dw4rd at verizon dot net 2007-04-17 16:17 ---
Created an attachment (id=13380)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13380action=view)
Preprocessed output from the source causing the ICE.
The initial bug creation doesn't seem to allow attachments. :)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-17 16:06 ---
First 3.3 is getting old and no longer being supported.
Second this is a modified version of 3.3 so we don't support it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31596
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-17 16:23 ---
So pthreads is not linking in correctly. This was a known issue I thought and
maybe in a way a non issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
When I compile and run the following program:
Hello world precedes the directory listing if standard output goes to the
console
Hello world follows the directory listing if standard output is redirected to
a file
g95 avoids this inconsistency by flushing all buffers before executing CALL
SYSTEM
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-04-17 16:03
---
*** Bug 31595 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
/home/ed/bin-4.3/bin/g++ -O2 -ffast-math -funroll-loops -fPIC -c
-D__HAVE_OPEN_INVENTOR__ -U__HAVE_XML__ -U__HAVE_SQLITE__ -U__HAVE_MYSQL__
-U__HAVE_PGSQL__ -U__HAVE_ORACLE__ -D__STL_EXTENSION_TR1__ -W -Wall -o
obj/collision.o ./collision.cpp
./collision.cpp: In member function void
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-17 15:56
---
(In reply to comment #2)
Can you check that the pthread functions are being resolved?
Also do you have a libc which crashes for static linked TLS?
How do I know the answer to those two questions? I have a
--- Comment #3 from krebbel at gcc dot gnu dot org 2007-04-17 16:59 ---
Subject: Bug 31576
Author: krebbel
Date: Tue Apr 17 16:59:24 2007
New Revision: 123915
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123915
Log:
2007-04-17 Andreas Krebbel [EMAIL PROTECTED]
PR
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-17 16:12 ---
The strings aren't actually padded. From the assembly output:
_ctl.1000:
.ascii 0z1jan
.space 6
.ascii 1hr
.space 6
.align 5
_tdefi.996:
.ascii 0z1jan
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-17 16:19 ---
The initial bug creation doesn't seem to allow attachments. :)
Which is fixed in bugzilla 3.0 which we will be updating in the near future.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31606
--- Comment #5 from chris at bubblescope dot net 2007-04-17 16:48 ---
I've done a bit of research into this. Looks like, as Andrew says the standard
doesn't have much to say on the issue. Any method of removing this is going to
make some other things a bit more messy I think, and I
--- Comment #6 from pcarlini at suse dot de 2007-04-17 17:04 ---
I also had a look lately, and probably I'm coming to your same conclusions...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
gfortran.dg/achar_4.f90 generates the following snippet of original trees:
{
int8 S.5;
S.5 = 0;
while (1)
{
if (S.5 (D.1394 + 0) - 1) goto L.1;
{
char char.6;
char.6 = (*(char[0:][1:1] *) atmp.0.data)[S.5][1]{lb: 1 sz:
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-17 17:27 ---
Adding pault, as he's the likely culprit :)
Paul, I'm wondering if the testcase is really valid Fortran:
snip
if (any (Up (AbCdEfGhIjKlM) .ne. (/ABCDEFGHIJKLM/))) call abort ()
contains
Character (len=20) Function
gfortran segfaults when I compile the following module. It also segfaults if I
change i = k() to i = j().
MODULE ksbin1_aux_mod
CONTAINS
SUBROUTINE sub
i = k()
END SUBROUTINE sub
FUNCTION j ()
j = 0
ENTRY k ()
k = 0
END FUNCTION j
END MODULE ksbin1_aux_mod
--- Comment #17 from spark at gcc dot gnu dot org 2007-04-17 17:36 ---
I'm testing the following patch (which fixes the ICE).
It turned out to be a latent bug in the warning code not handling pointer types
correctly.
Index: cp/decl2.c
Testcase (4.3.0 20070415):
Character(len=20) string
Logical, Dimension(20) :: a
string = transfer(merge (transfer(achar (ichar('A')), x, len(string)),
string, a), repeat(x, len(string)) )
end
--
Summary: ICE with transfer, merge in gfc_conv_expr_descriptor
--- Comment #15 from rakdver at gcc dot gnu dot org 2007-04-17 17:42
---
Subject: Bug 31360
Author: rakdver
Date: Tue Apr 17 17:42:29 2007
New Revision: 123919
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123919
Log:
PR rtl-optimization/31360
* cfgloopanal.c
--- Comment #18 from pluto at agmk dot net 2007-04-17 17:51 ---
(In reply to comment #14)
Fixed.
will it be backported to 4.2 branch?
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-17 15:45 ---
what's wrong in logs? i see only compilation error due to bad ifdefs.
Right, the other testcases are testing at runtime see the $? = 0 in the log
below?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-17 15:43 ---
(iii) having a statically linked binary
Can you check that the pthread functions are being resolved?
Also do you have a libc which crashes for static linked TLS?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #7 from patchapp at dberlin dot org 2007-04-17 14:05 ---
Subject: Bug number PR14495
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-04/msg01072.html
--
--- Comment #6 from gambaly at gmail dot com 2007-04-17 13:52 ---
Created an attachment (id=13379)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13379action=view)
gcc rebuild failed without test useflag
after that i did this
cd
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-04-17 16:05
---
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 140130416 (LWP 25328)]
0x in ?? ()
(gdb) where
#0 0x in ?? ()
#1 0x0804cdbb in get_external_unit (n=6, do_create=1)
1 - 100 of 184 matches
Mail list logo
