actually, I just find out that this seems a 4.4 issue, compiled with 4.3 the
gdb session just goes fine... I also seem to be able to debug small examples
with either 4.3 or 4.4, just CP2K seems to cause troubles (as usual ;-)
I've filed PR39073 for this, somehow hope this can be solved before
I would like to add stack traces to my program (Cygwin/MinGW, Windows XP).
I've already implemented a stack walker, but there is an open problem with
symbol name/line lookup. The compiler (GCC 4.4-trunk) emits DWARF2-compatible
debug information, but I don't know how to reach the appropriate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/09 10:06 PM, Sean Callanan wrote:
(1) register_callback is an unnecessary API. It's already possible to
use dlsym() to get a pointer to a symbol in a plug-in. A plug-in could
export a function symbol corresponding to each hook it is
Two quick questions:
(1) Is the feature roadmap for 4.5, 4.6 ... published anywhere
(2) What is the recommended way to force 32 bit build on 64 eg 86_64 and will
it work with libtool and all. I have a solution but its very ugly!
--
Greetings, Brian
raja.sal...@iap-online.com writes:
In gcc, while instruction scheduling can it be possible to suspend the
scheduling for some instructions ? or
No. You can turn off instruction scheduling for the entire
compilation. You can use #pragma GCC optimize to turn scheduling off
for a specific
Piotr Wyderski piotr.wyder...@gmail.com writes:
The PE header walker is able to
dump PE sections,
but they have strange, numeric names, e.g.:
sec[5]: name = /4
That strange numeric name is used when the section name is more than 8
characters long. The value after the '/' is an offset into
* Ian Lance Taylor:
Your argument here seems to be that linking against libgcc makes a
program be covered by the definition of GCC in the runtime library
license.
Right. Why do you think this would not be the case? libgcc is part
of GCC, so a program linking to libgcc is a derivative work
* Ian Lance Taylor:
After the e-mail flurry, here is my personal summary of the issues
regarding the GCC Runtime Library Exception
(http://www.gnu.org/licenses/gcc-exception.html).
Thanks!
One way to resolve this might be to say that a compilation process
is Eligible so long as the
On Mon, Feb 02, 2009 at 02:00:33PM -0800, Florian Weimer wrote:
* Ian Lance Taylor:
After the e-mail flurry, here is my personal summary of the issues
regarding the GCC Runtime Library Exception
(http://www.gnu.org/licenses/gcc-exception.html).
Thanks!
One way to resolve this
I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI.
I cleaned up the formatting and added syntax coloring where
appropriate. I also changed the API to reflect the comments so far,
making it easier to register many callbacks at once while preserving
the ability to register callbacks
2009/2/2 Sean Callanan spy...@cs.sunysb.edu:
I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI.
Is there a reason for not using just -plugin=? What is with the -f*?
Cheers,
Manuel.
Benjamin,
On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:
It's possible for the plugin to implement every possible dlsym entry
point
and then farm the calls out to each individual script pass
internally, but
since GCC is already going to have to maintain a list of callbacks,
it seems
Eric Christopher echri...@gmail.com writes:
So my question is whether the saving in the size of the debug info with
-msym32 is really worth the trouble here or should we just start generating
64-bit addresses with -msym32?
Generating 64-bit addresses would be fine with me FWIW. I'm not sure
Hi,
In gcc, while instruction scheduling can it be possible to suspend the
scheduling for some instructions ? or
Is there a way to make the instruction has to allocate to run without
using the scheduler for particular instruction ?
Currently there is RTL template in machine description
Michael Meissner wrote:
I am just starting to think about adding OpenCL support into future versions
of
GCC, as it looks like a useful way of programming highly parallel type
systems,
particularly with hetrogeneous processors. At this point, I am wondering what
kind of interest people
Hi,
Gcc doesn't follow x86-64 psABI when passing and returing
union with long double:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
Gcc converts X87UP to SSE if X87UP is not preceded by X87.
I don't believe x86-64 psABI calls for it. I think psABI should
be updated with:
Index:
Sean Callanan wrote:
Benjamin,
On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:
It's possible for the plugin to implement every possible dlsym entry
point
and then farm the calls out to each individual script pass
internally, but
since GCC is already going to have to maintain a list of
On Mon, Feb 2, 2009 at 19:34, Taras Glek tg...@mozilla.com wrote:
Regarding versions: I think it's crazy to be passing a version in every
single function call. The plugin should check the gcc version it is being
loaded into on startup and bail if it doesn't match.
Agreed. Let's start with
Taras,
On Feb 2, 2009, at 7:34 PM, Taras Glek wrote:
Regarding versions: I think it's crazy to be passing a version in
every single function call. The plugin should check the gcc version
it is being loaded into on startup and bail if it doesn't match.
Since you and Diego seem to be of one
On Mon, 2 Feb 2009, Taras Glek wrote:
Regarding versions: I think it's crazy to be passing a version in every single
function call. The plugin should check the gcc version it is being loaded
into on startup and bail if it doesn't match.
I agree with checking once at startup, but that should
Joseph S. Myers wrote:
I agree with checking once at startup, but that should be GCC's job, not
the plugin's.
Yes.
The plugin should export the exact version string and
target triplet (and maybe configure options) of the compiler it was built
to be plugged into (the configure macros /
Dear Ian,
Thanks the reply.
Is there a way to make the instruction has to allocate to run without
using the scheduler for particular instruction ?
I don't understand the question.
The target we are using supports parallel instruction execution, Max 7.
For one cycle, one instruction packet
On Feb 2, 2009, at 9:15 PM, Mark Mitchell wrote:
Unless we have a lot more stability in plugin API than I expect we're
actually going to have at first, I suggest we check something like the
md5sum of the GCC binary itself. (Yes, I see the recursive problem in
building such a binary.) The
--- Comment #16 from bonzini at gnu dot org 2009-02-02 08:26 ---
Subject: Re: [4.2/4.3 Regression] NULL pointers
always considered distinct by PTA, even with -fno-delete-null-pointer-checks
rguenth at gcc dot gnu dot org wrote:
--- Comment #15 from rguenth at gcc dot gnu dot org
--- Comment #19 from pluto at agmk dot net 2009-02-02 08:55 ---
(In reply to comment #16)
Subject: Bug 38503
Author: rguenth
Date: Tue Jan 27 10:42:59 2009
New Revision: 143700
this patch doesn't fix testcase that i found yesterday.
i found another testcase for
I find that I can not print local variables (none that is) if I use 4.4 for
compiling CP2K, while it goes fine with 4.3.
Reproducing requires these steps:
wget http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz
tar -xzvf CP2K_2008_12_03.tgz
cd CP2K_2008_12_03/
#
# change FCFLAGS to read
--- Comment #1 from jv244 at cam dot ac dot uk 2009-02-02 08:59 ---
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure
--prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,fortran
--disable-multilib
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #10 from jzb2 at aexorsyst dot com 2009-02-02 09:31 ---
I can confirm this is a real problem. I have hit this exact same bug on
gcc-4.2.2. However, one difference in my setup is that I _do_ have
libstdc++.so available as part of my cross toolchain, with the result the
--- Comment #9 from jan dot kratochvil at redhat dot com 2009-02-02 13:48
---
Confirming it is a GDB bug, DW_TAG_module is completely ignored by
dwarf2read.c.
Older GCCs did not support module namespaces so it may look as a regression.
I hope to patch it soon although I have no such
--
Summary: alignment for unsigned short a[1
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2009-02-02
14:50 ---
This code:
unsigned short a[1];
void test()
{
int i;
for (i = 0; i 1; ++i) a[i] = 5;
}
will be vectorized with -O3 -march=core2 to this:
.L2:
movdqa %xmm0, a(%eax)
addl
I am trying to cross-compile flac 1.2.1 (from
http://downloads.sourceforge.net/flac/) for an ARM processor. The toolchain I
am using is based on a pretty recent buildroot snapshot (20090130).
Here's the output of gcc -v:
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with:
--- Comment #1 from s dot neumann at phase-zero dot de 2009-02-02 16:08
---
Created an attachment (id=17228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17228action=view)
preprocessed file that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39076
--- Comment #11 from jzb2 at aexorsyst dot com 2009-02-02 16:26 ---
Well, I answered my own question, sort of...
In my /usr/bin/libtool, in the CXX tag section, I have
postdeps=-lstdc++ -lm -lgcc_s -lc -lgcc_s
so voila, that's where it comes from, probably.
So this issue can now be
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2009-02-02
16:42 ---
(In reply to comment #2)
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
Are the casts actually
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-02 16:46
---
I'll see if it helps bash.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
We expand __builtin___clear_cache() to a 'synci' instruction on ISA_HAS_SYNCI
systems, which invalidates the icache only on the local CPU.
On an SMP system, the caches on all CPUs should be invalidated. To achieve
this we need to drop back to the old way of doing things by using the cache
flush
This command produces dependencies for several source files and write them to
the standard output:
gcc -M -MM file1.c file2.c file3.c
Problem appears when I try to save them to file using -MF option:
gcc -M -MM -MF makefile.dep file1.c file2.c file3.c
In this case gcc write dependencies for
The following block of code appears to produce an un-needed memcpy on both
Intel and PowerPC platforms. There is no aliasing or side-effect that I can
think of that could possibly force such copying to occur -- the problem seems
to be that gcc is not aware of the lifetime of large structures kept
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-02 13:24 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39073
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-02-02 18:26 ---
This looks like it happens on FreeBSD 7.1 as well:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00142.html
Any news on what is going on here?
Please note that i386-bsd is a primary platform for a release, as
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
if the solution of x includes ANYTHING we fail to add the solution of y to all
variables. Testcase (fails on a-i branch):
int i;
void __attribute__((noinline))
foo(long b, long q)
{
int *y;
int **a = y, **x;
int ***p;
if (b)
p = (int ***)q;
else
p = a;
x = *p;
*x = i;
*y
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-02 09:36 ---
Jakub, do you have an idea? This might be a side effect of one of your DWARF
patches.
Reduced test case:
module m
contains
subroutine a()
integer :: i
--- Comment #1 from jason at gcc dot gnu dot org 2009-02-02 18:38 ---
Subject: Bug 39054
Author: jason
Date: Mon Feb 2 18:38:10 2009
New Revision: 143876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143876
Log:
PR c++/39054
* parser.c
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 18:38 ---
Fixed in 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from aaw at gcc dot gnu dot org 2009-02-02 19:13 ---
There were problems with my original patch (Sadly, I don't recall the
details.). I haven't looked at this in a while and am unlikely to do so soon.
If someone else wants to look at this, please feel free to do so.
--- Comment #60 from pthaugen at gcc dot gnu dot org 2009-02-02 19:16
---
I tried leslie3d on PPC. The alias-improvements branch does indeed seem to fix
the issue. The version of leslie3d built with the alias-improvements branch is
about 10% faster than a version built with trunk, and
--- Comment #3 from dberlin at gcc dot gnu dot org 2009-02-02 19:42 ---
Eyeballing this, I think y should not end up empty anyway.
Shouldn't it have i in it's points-to set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39074
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-02 19:57 ---
Subject: Bug 39054
Author: jason
Date: Mon Feb 2 19:57:29 2009
New Revision: 143879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143879
Log:
PR c++/39054
* parser.c
--- Comment #24 from amylaar at gcc dot gnu dot org 2009-02-02 20:02
---
(In reply to comment #22)
If you post a patch to add the option to enable/disable partial-PRE I will
happily review and approve it for 4.4.
I experimented using Seteven Bosscher's patch as a starting point and
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-02-02 20:10 ---
Subject: Bug 38263
Author: ghazi
Date: Mon Feb 2 20:10:04 2009
New Revision: 143880
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143880
Log:
PR testsuite/38263
* gcc.dg/ipa/ipacost-2.c: Add
--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-02 09:51 ---
The generated unwind info looks good to me, so it is likely a gdb issue.
[58]module
name m
decl_file1
decl_line1
--- Comment #74 from jason at gcc dot gnu dot org 2009-02-02 20:27 ---
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard proposed in the initial bug
report; it is inappropriate for library headers to redefine
--- Comment #5 from cnstar9988 at gmail dot com 2009-02-02 13:19 ---
ping 4.3.4, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38957
--- Comment #76 from paolo dot carlini at oracle dot com 2009-02-02 21:11
---
Ok, let's wait a couple of days and, assuming there are no objections, I
volunteer to implement that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-02 10:39
---
Subject: Bug 38937
Author: rguenth
Date: Mon Feb 2 10:39:12 2009
New Revision: 143864
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143864
Log:
2009-02-02 Richard Guenther rguent...@suse.de
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-02 13:23 ---
Subject: Bug 39058
Author: jakub
Date: Mon Feb 2 13:23:43 2009
New Revision: 143867
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143867
Log:
PR inline-asm/39058
* recog.h (asm_operand_ok):
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-02-02 10:23
---
Same issue. Only possible fix is to not apply TBAA pruning to escaped
symbols, which will - well - basically disable TBAA. Testcase:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
--- Comment #75 from mark at codesourcery dot com 2009-02-02 20:29 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
fall back on the simpler solution that Howard
--- Comment #2 from dj at redhat dot com 2009-02-02 21:52 ---
You should put the new code in a #ifdef HAVE_STDINT and use the old code
otherwise. Else, any platforms without stdint.h would not compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:53 ---
The ABI does not guarantee alignment bigger than 2 for the external array. The
vectorizer adjusts the alignment for the internal one.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jv244 at cam dot ac dot uk 2009-02-02 09:49 ---
(In reply to comment #3)
thanks for the reduced testcase... will help :-)
Hmm, maybe this is only a gdb bug / missing feature.
just as a note, I tried gdb 6.8 and it failed as well.
--
--- Comment #46 from mmitchel at gcc dot gnu dot org 2009-02-02 22:00
---
As I understand it, the complaint here is that GCC_EXEC_PREFIX being set
affects HOSTCC, when HOSTCC is itself some other GCC.
But, we have to make sure that the newly built compiler searches the right
--- Comment #6 from jv244 at cam dot ac dot uk 2009-02-02 11:09 ---
(In reply to comment #5)
The generated unwind info looks good to me, so it is likely a gdb issue.
1) how does one get this generated unwind info (I'd like to see what is
different from 4.3)?
2) Do you see a way to
--- Comment #2 from falk at debian dot org 2009-02-02 19:02 ---
No problem with the trunk, but it's still there in the 4.3 branch.
Here's a test case. Requires -funroll-loops -Os, no problem with any other -O,
or without -funroll-loops, curiously.
int f(int x, int y) {
int bytes
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-02 14:03 ---
We could for example warn for
/* { dg-do compile } */
/* { dg-options -O -Wuninitialized } */
int i;
int __attribute((const,noinline))
foo (int **p)
{
return i;
}
int bar(int *q)
{
int *p;
*q = 0;
int j =
x86-64 psABI says:
The 64-bit mantissa of arguments of type {long double
belongs to class X87, the 16-bit exponent plus 6 bytes of padding
belongs to class X87UP.
...
If one of the classes is X87, X87UP, COMPLEX\_X87 class,
MEMORY is used as class.
But I got
[...@gnu-6 avx-abi]$ cat u4.i
--- Comment #8 from jv244 at cam dot ac dot uk 2009-02-02 12:14 ---
(In reply to comment #7)
2) report this to gdb and help them fix it.
OK, I've at least been able to add a PR for this in the gdb bugzilla:
http://sourceware.org/bugzilla/show_bug.cgi?id=9806
--
--- Comment #1 from s dot gesemann at gmail dot com 2009-02-02 15:18
---
This is probably just another manifestation of the same bug (#36744)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39050
--- Comment #11 from sje at cup dot hp dot com 2009-02-02 16:27 ---
Has anyone tested the patch in comment #9. I didn't test it with bash but I
did test it with Python (PR 38292) because I was looking at that bug and it
seemed to fix the problem.
--
sje at cup dot hp dot com
--- Comment #1 from comer352l at googlemail dot com 2009-02-02 16:22
---
Created an attachment (id=17229)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17229action=view)
Preprocessed file (created with gcc4.3.2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-02 11:18 ---
I think this depends on whether we want as an exception allow this or not.
If not, e.g.:
--- typeck2.c.jj22009-01-13 18:32:14.0 +0100
+++ typeck2.c2009-02-02 12:15:58.0 +0100
@@ -789,7 +789,8 @@
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-02 10:24 ---
Nice testcase from PR38503:
inline void *operator new (__SIZE_TYPE__, void *__p) throw() { return __p; }
struct Y {
Y() {}
int i;
};
struct X {
X() {}
void construct(const Y y)
{
new (m_data[0])
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-02 14:07 ---
Created an attachment (id=17227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17227action=view)
patch to warn about uninitialized pointer dereferences
This patch causes a warning for both testcases, the
--- Comment #3 from sezeroz at gmail dot com 2009-02-02 22:59 ---
(In reply to comment #2)
You should put the new code in a #ifdef HAVE_STDINT and use the old code
otherwise. Else, any platforms without stdint.h would not compile.
I would do that and it would be easy, but then one
--- Comment #4 from bje at gcc dot gnu dot org 2009-02-02 23:03 ---
Subject: Bug 39034
Author: bje
Date: Mon Feb 2 23:03:20 2009
New Revision: 143884
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143884
Log:
PR c/39034
* gcc.dg/dfp/pr39034.c: New test.
Added:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-02 14:55 ---
Err, it seems at least the x86_64 ABI guarantees alignment of 16 bytes for
arrays bigger than 16 bytes (including variable length arrays).
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-02 09:45 ---
Hmm, maybe this is only a gdb bug / missing feature.
$ gfortran-4.4 -O0 -g aaa.f90
$ idbc a.out
Intel(R) Debugger for applications running on Intel(R) 64, Version 11.1 Beta,
Build [1.2097.2.21]
[...]
(idb) b 6
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-02 10:19
---
Ok Mark, agreed, thanks. For the moment, I'm not going to work on this one and
I'm unassigning myself in order not to prevent anyone else quicker than me...
--
paolo dot carlini at oracle dot com changed:
Source file:
file test.c
===
#define __NR_close 2
#define CLOBBER_LIST memory, cc, r11, r12, r13, r14, r15, rbx
#define MY_SYSCALL_1(ARG)
\
__extension__ ((
--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-02 11:57 ---
1) eu-readelf -w info. If you don't have elfutils, binutils readelf -wi
generates similar output, though without the indentation, so it is harder to
find out the parent/child/sibling relation between consecutive
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-02 19:02 ---
Jakub's patch looks fine to me.
Benjamin, does you have an opinion about initializer-lists and complex? I
guess the library complex class will accept { real, imag } naturally because it
has a suitable constructor.
--- Comment #12 from hubicka at gcc dot gnu dot org 2009-02-02 16:35
---
try_inline should not recurse when edge is already inlined. The following
patch should fix the problem, I will benchmark it tonight
Index: ipa-inline.c
The example attached is a simple data-container-class. The data is stored as
Qt4-QStringLists.
Everything was fine with gcc 4.1 (330KB). 4.2 already caused a significant
increase. With 4.3, the binary size increased enormously again (6.7MB !).
When I disable GCSE-optimization using the additional
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-02 10:06 ---
I think the bug is in check_asm_operands/asm_operand_ok.
The latter has:
case '0': case '1': case '2': case '3': case '4':
case '5': case '6': case '7': case '8': case '9':
/* For best
--- Comment #1 from ro at gcc dot gnu dot org 2009-02-02 23:43 ---
It turns out that there are two problems here:
* If you invoke cc1 conftest.c (i.e. without -quiet), you get the ICE from the
assertion failure in c-decl.c:6225:
/* This is the earliest point at which we might know
--- Comment #14 from av1474 at comtv dot ru 2009-02-02 23:44 ---
(In reply to comment #8)
Please provide a preprocessed reduced testcase as similar to the original as
possible.
I think this is not only predicated PHI but our representation of loops may
also have something to do.
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-02-02 23:46
---
Looks indeed like a duplicate.
I can reproduce the bug with GCC 4.4-20090123, but not with GCC 4.4-20090131.
*** This bug has been marked as a duplicate of 38926 ***
--
reichelt at gcc dot gnu dot org
--- Comment #11 from reichelt at gcc dot gnu dot org 2009-02-02 23:46
---
*** Bug 39017 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from manu at gcc dot gnu dot org 2009-02-03 00:27 ---
(In reply to comment #14)
I'm not sure whether following warrants a new bug entry so doing it here,
sorry,
if it was inappropriate.
That is a different case. This PR is about loops. Your case is about
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-02-03
02:02 ---
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -
D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -i
--- Comment #4 from schaub-johannes at web dot de 2009-02-03 02:02 ---
Yes, sorry for not mentioning it. I also think the code is valid. In the link
to stackoverflow.com, where i answered that guys question, i gave reasons why i
think so. Next time i will put what i think about that
appears to be similar to reported bug against 4.3.2
--
Summary: stage 3 libgfortran build fails
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo:
--- Comment #1 from tony_eckert at umsl dot edu 2009-02-03 04:33 ---
appears similar to bug 37865, but without --enable-intermodule.
Only departure from defaults is --prefix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39083
Sent from my iPhone
On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from tony_eckert at umsl dot edu 2009-02-03
04:33 ---
appears similar to bug 37865, but without --enable-intermodule.
Only departure from defaults is
--- Comment #2 from pinskia at gmail dot com 2009-02-03 04:35 ---
Subject: Re: stage 3 libgfortran build fails
Sent from my iPhone
On Feb 2, 2009, at 8:33 PM, tony_eckert at umsl dot edu
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from tony_eckert at umsl dot edu
1 - 100 of 102 matches
Mail list logo