Adriaan van Os [EMAIL PROTECTED] wrote:
and people are
responsible for fixing all front ends when they do backend changes.
I don't believe that, they would just say, oh, it is broken or oh,
it is not a primary language or whatever excuse.
You probably don't follow GCC development enough.
Jeffrey A Law writes:
On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
Jeffrey A Law writes:
On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
On irc today we were discussing handling 'this' in gcj. We can add an
attribute to the argument to mark it as
On Fri, 2006-03-31 at 09:55 +0100, Andrew Haley wrote:
Well, it's not just functionss but also global variables. AFAICS
there are three sources of data: args, retvals, and globals. And
there are quite a few of these globals we can usefully tag as known
never to be null.
Seems to me the same
Setting TREE_OVERFLOW here sounds like the bug.
Well, it's the standard semantics of the middle-end, nothing more:
/* A subroutine of fold_convert_const handling conversions of an
INTEGER_CST to another integer type. */
static tree
fold_convert_const_int_from_int (tree type, tree arg1)
{
Hello,
I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails
with:
echo timestamp s-gtype
/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc
-B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/
-B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/
On 03/31/06 04:08, Jeffrey A Law wrote:
Then we just need to make VRP not be so quick to ignore statements
with virtual operands (ie, the same problem we need to solve if
VRP is going to be able to use non-null attributes on function
return values).
Certainly. The approach I had sketched
It would take a massive target-specific backend hack to make that
happen, as GCC currently only supports flat address spaces. ;-)
Rémy Saissy wrote:
Hi everybody,
I'm looking for gcc support of x86-32 segment registers but the only information
I've found about it is in this old thread:
On irc today we were discussing handling 'this' in gcj. We can add an
attribute to the argument to mark it as non-null... but strangely
there doesn't seem to be a way to mark other local variables as
known-non-null -- a curious deficiency.
It seems to me that for other locals that the
Hi,
I was trying to convert the gcc C-Gimple form to the internal AST
representation used in our research compiler. I was able to transform most
of the nodes of the GIMPLE tree but was not able to find out a way to
retrieve the global declarations from the GIMPLE tree. For example is there
a way
On 3/30/06, Adriaan van Os [EMAIL PROTECTED] wrote:
the problem is not regular testing.
Then waht is the problem with the daily maintenance you mention? Maybe
there are other ways to make life easier for the gpc folks if you
would be more specific about the problems you apparently have.
and
Hello,
I've checkouted todays sources from trunk and I can confirm that the same
failure also happens there.
Cheers,
Karel
On Fri, 31 Mar 2006, Karel Gardas wrote:
Hello,
I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails
with:
echo timestamp s-gtype
GCC reports an error for this snippet:
int main()
{
foo:
int x;
}
foo.c:4: error: expected expression before 'int'
... but not this snippet:
int main()
{
foo:
(void)0;
int x;
}
Is this expected behaviour? At the very least, it seems like an
unusual distinction.
Please
Shaun Jackman [EMAIL PROTECTED] writes:
GCC reports an error for this snippet:
int main()
{
foo:
int x;
}
foo.c:4: error: expected expression before 'int'
The C standard only allows labels to occur before statements. A
declaration is not a statement.
Andreas.
--
Andreas
PR26763 is
int try (int *a)
{
return a + -1 a;
}
int main(void)
{
int bla[100];
if (try (bla + 50))
abort ();
return 0;
}
now, this looks like a perfectly valid testcase which pointer_int_sum
makes questionable, because it produces
a + -4B a
which has an overflowing pointer
Hello,
I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails
with:
echo timestamp s-gtype
/home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing
sentinel in function call
This usually means NULL is defined as 0 instead of (void*)0.
-- Pinski
Snapshot gcc-4.1-20060331 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060331/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Diego Novillo wrote:
On 03/30/06 03:32, Adriaan van Os wrote:
Still, I would like to create a GNU Pascal branch for gcc. This will be
a central place where to keep the compiler updated with
I don't think this is a good idea. You are either part of the compiler
or you aren't. Front ends
You know, I've always wondered why there wasn't a lisp-family front end
for GCC, the roots of GNU and RMS being where they are (and didn't RMS
promise way back when to make lisp suitable for unix systems
programming?). I'm just not connected enough to the lisp world to know
the answer I
I successfully built and installed GCC 4.0.3 on Slackware 10.2.
Bootstrapping info:
1. Output of srcdir/config.guess:
i686-pc-linux-gnu
2. Output of gcc -v:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-src/gcc-4.0.3/configure
Thread model: posix
gcc version 4.0.3
--- Comment #3 from falk at debian dot org 2006-03-31 08:40 ---
Confirmed, also present in 4.2.0 20060218
Test case:
struct LongDouble {
char ld[16];
};
struct DynAny {
virtual void insert_longdouble(LongDouble value) = 0;
};
struct TAO_DynCommon : public virtual DynAny {
--- Comment #39 from ebotcazou at gcc dot gnu dot org 2006-03-31 09:53
---
I've also been poking at MPFR. There are apparently 10 or more patches now
for
2.2.0, that may resolve the issues, too. I'll look at that. I've rebuilt it,
and ran the check area for mpfr, and 115/117
Won't build on Mingw. You are probably aware of it. I started the build with
GCC 4.0.2 on Mingw.
[EMAIL PROTECTED] /mingw/gcc-4.1.0
$ make
make[1]: Entering directory `/mingw/gcc-4.1.0'
make[2]: Entering directory `/mingw/gcc-4.1.0/host-i686-pc-mingw32/zlib'
true AR_FLAGS=rc CC_FOR_BUILD=gcc
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2006-03-31 10:54
---
This is the build with GMP 4.1.3 and MPFR 2.2.0:
gax% gcc/xgcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: /home/eric/svn/gcc-4_0-branch/configure
--- Comment #2 from toon at moene dot indiv dot nluug dot nl 2006-03-31
11:24 ---
Could you retry this with gfortran 4.1 (now that it is out) ?
Thanks.
--
toon at moene dot indiv dot nluug dot nl changed:
What|Removed |Added
--- Comment #6 from aph at gcc dot gnu dot org 2006-03-31 11:43 ---
Subject: Bug 26858
Author: aph
Date: Fri Mar 31 11:43:43 2006
New Revision: 112574
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112574
Log:
2006-03-30 Andrew Haley [EMAIL PROTECTED]
PR java/26858
--- Comment #7 from aph at gcc dot gnu dot org 2006-03-31 13:05 ---
Subject: Bug 26858
Author: aph
Date: Fri Mar 31 13:05:32 2006
New Revision: 112575
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112575
Log:
2006-03-30 Andrew Haley [EMAIL PROTECTED]
PR java/26858
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-03-31 13:51 ---
Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work because
of PR 18058 (although there is a patch posted for that PR). Also bootstrap
with GCC 2.x or 3.x isn't quite right since I tried 3.4.x
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-31 13:55
---
The original testcase does not crash anymore, but changing the
inline bool f1(char* p, char* q, int) { return p ? p : q; }
to
inline bool f1(char* p, char* q, const int) { return p ? p : q; }
makes the
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-31 13:57
---
Created an attachment (id=11173)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11173action=view)
testcase
Testcase according to comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26771
--- Comment #2 from dir at lanl dot gov 2006-03-31 13:59 ---
There was a discussion of how to do it on some websites. I thought that they
just configured gfortran and gcc a liitle different, but I guess that I will
have to go back and look at the details.
--
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:05
---
Confirmed on Solaris 7, 8 and 9, everything is fine on Solaris 10.
Three functions are missing:
conftest.cc:75: error: '::wcstold' has not been declared
conftest.cc:76: error: '::wcstoll' has not been
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:09
---
Of the 3 workarounds in comment #17, bootstrap with Sun cc doesn't work
because of PR 18058 (although there is a patch posted for that PR). Also
bootstrap with GCC 2.x or 3.x isn't quite right since I tried
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-03-31 14:24
---
Probably a duplicate of PR26197.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-03-31 14:29 ---
(In reply to comment #20)
It's the wrong PR, this one is for pre-4.2, the 3 workarounds work.
The problem is minor for pre-4.2. The blocker PR for 4.2 is PR other/26507.
Huh? The third comment in 26507 (by you I
--- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:36
---
Huh? The third comment in 26507 (by you I might add) agrees that PR 26507 and
this one are the same problem. We should close one as a dup of the other.
I precisely chose not to close either because of their
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2006-03-31 14:44
---
My hope is that this PR will get more attention. We can't IMHO release 4.2
with this problem still there, and it was filed in October.
Oh, and feel free to take a stab at it. :-) Part of the problem is that
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-31 15:01
---
I'm about to post a fix.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04 ---
Breakpoint 1, make_decl_rtl (decl=0x40148880) at ../../gcc/gcc/varasm.c:968
968 gcc_assert (TREE_CODE (decl) != TYPE_DECL
(gdb) list
963 || TREE_PUBLIC (decl)
964 ||
compile trivial program with
g++ -c -O1 ice.cxx
I'll append a machince-readable copy of the test case...
==
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
--- Comment #1 from apl at alum dot mit dot edu 2006-03-31 15:32 ---
Created an attachment (id=11174)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11174action=view)
test case causing ICE
g++ -c -O1 ice.cxx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-31
15:34 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #4 from danglin at gcc dot gnu dot org 2006-03-31 15:04
---
Breakpoint 1, make_decl_rtl
The following c++ program compiles without error even though it crosses an
initialization. I only noticed this problem on g++ 3.4.4, 3.4.5. Versions
before and after 3.4 appear to be okay.
int g()
{
return 0;
}
int main()
{
goto L1;
int i=g();
L1:;
}
--
Summary:
--- Comment #1 from gary dot lazer at yahoo dot com 2006-03-31 16:10
---
more info: i686, intel dual xeon 2 GHz processors, dell precision 530
g++ output:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.5/specs
Configured with: ../configure --prefix=/usr
The following testcase crashes the compiler when compiled with -fipa-pta:
==
struct A
{
int i, j;
};
A foo(A);
templateint A bar(A a) { return foo(a); }
void baz()
{
bar0(A());
}
==
bug.cc: In function 'void
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #7 from hjl at gcc dot gnu dot org 2006-03-31 17:36 ---
Subject: Bug 25741
Author: hjl
Date: Fri Mar 31 17:36:00 2006
New Revision: 112583
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112583
Log:
contrib/regression/
2006-03-31 H.J. Lu [EMAIL PROTECTED]
--- Comment #8 from hjl at gcc dot gnu dot org 2006-03-31 17:42 ---
Subject: Bug 25741
Author: hjl
Date: Fri Mar 31 17:42:06 2006
New Revision: 112584
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112584
Log:
2006-03-31 H.J. Lu [EMAIL PROTECTED]
PR testsuite/25741
gcc currently generates duplicate debug information for enums declared in
namespaces.
Compile this C++ code with -g:
namespace { enum x { i = 1 }; }
x y;
In the .s file, I see this:
.uleb128 0x3
.string x
.byte 0x4
.byte 0x1
.byte 0x1
.byte
--- Comment #12 from zerocool at modemsoft dot it 2006-03-31 18:14 ---
Finally i produce the information that you ask me with the your precious
indication and that is :
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
Compile this C++ code with -g
enum x { i = 1 };
class c {
static const x beg = i;
};
void bar () { }
Looking at the .s output and the readelf --debug-dump output will show that
there is no debug info for x or beg. This is as expected: they are not used by
any actual code, so there is no need
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-31 18:58 ---
The patch to 4.1 will be committed tomorrow.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:11 ---
Confirmed, a litte more reduced testcase:
typedef unsigned long long U64;
typedef unsigned short U16;
typedef unsigned char U8;
U16 m_rh;
U8 m_gN_eQ;
void f()
{
U16 m_;
m_gN_eQ = ((m_rh) ? 0x1ULL
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-31 19:13 ---
*** This bug has been marked as a duplicate of 20721 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-31 19:13
---
*** Bug 26962 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 19:59 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 20:05 ---
This looks very related to PR 14167.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26965
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26847
Hello,
I've compiled 4.2.0 GCC on OpenBSD 3.9-current. I've configured it with:
/home/karel/svn/gcc/trunk/configure
--prefix=/home/karel/usr/local/gcc-trunk-20060331 --enable-shared
--enable-threads --enable-languages=c++ --disable-checking --disable-nls
the problem is that resulting C
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-31 21:12 ---
I believe c-common.c:pointer_int_sum is wrong in relying on pointer overflow
during conversion of the integer offset to an unsigned pointer. I'm sending
a patch that fixes this for comments.
--
--- Comment #23 from tkoenig at gcc dot gnu dot org 2006-03-31 21:13
---
Subject: Bug 19303
Author: tkoenig
Date: Fri Mar 31 21:13:46 2006
New Revision: 112590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112590
Log:
PR fortran/19303
Backport from mainline
--- Comment #24 from tkoenig at gcc dot gnu dot org 2006-03-31 21:24
---
Fixed on 4.1. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 21:38 ---
Hmm, these functions should be weak and should not be visible.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.1.1 4.0.4 4.2.0
Target Milestone|4.2.0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26936
Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different
order? Is there something unstable in the PRE algorithm?
No, we just call fold on the expressions we build, and whatever it gives
us, we use :)
--- Comment #3 from dberlin at gcc dot gnu dot org 2006-03-31 22:41 ---
Subject: Re: [4.1/4.2 Regression] -ftree-ch
generates worse code
Compare pretmp.28_49 with pretmp.32_11, why are the arguments in a different
order? Is there something unstable in the PRE algorithm?
Still trying to get more info, but here is what I have.
Trying to build HDF5 1.7.52 on Fedora Core 5 i386 with gcc-4.1.0-3 (also seem
to see it with gcc-4.1.0-4 from rawhide).
The Dataspaces (h5s) test segfaults.
I've tracked it down to the following code in H5Dio.c:2263-2270 (in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-31 23:14 ---
Can you try first without -fstack-protector. If that does not work, try with
-fno-strict-aliasing added to see if maybe there is an aliasing issue.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-31 23:26 ---
I wrote a little script to print the amount of time taken for each
line of 'make' output.
This tends to confirm that installing the headers is very slow.
One other difference from 'make install-exec' is that the
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-31 23:30 ---
Is there a reasonable way to detect good failures versus bad failures here?
We definitely want to ignore cases where gcj-dbtool fails due to things
like not having mmap available.
Perhaps the thing to do is let it
--- Comment #2 from orion at cora dot nwra dot com 2006-03-31 23:32 ---
Compiled using 4.1.0 with the old 4.0.2 (FC4) flags (no -fstack-protector and
--param=ssp-buffer-size=4) with no effect.
Added -fno-strict-aliasing with no effect (at least for this, I've got a type
conversion
--- Comment #3 from orion at cora dot nwra dot com 2006-03-31 23:34 ---
Sorry, my browser seems to have changed components...
--
orion at cora dot nwra dot com changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2006-04-01 00:04 ---
Subject: Bug 25358
Author: kargl
Date: Sat Apr 1 00:04:46 2006
New Revision: 112594
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112594
Log:
2006-03-31 Asher Langton [EMAIL PROTECTED]
PR
(((1L) 1) 1)))
fastmap[j] = 1;
}
}
}
}
gcc version 4.2.0 20060331 (experimental)
gcc -O3 -ftree-vectorize ruby.c -c
ruby.x.i: In function ruby_re_compile_fastmap:
ruby.x.i:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed
This short section of code when compiled with:
g++ -g -O3 -Wformat=2 bug.cpp
complains
{{{
/usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++locale.h:
In function `int std::__convert_from_v(char*, int, const char*, _Tv,
__locale_struct* const, int)
--- Comment #6 from kargl at gcc dot gnu dot org 2006-04-01 00:07 ---
Subject: Bug 25358
Author: kargl
Date: Sat Apr 1 00:07:03 2006
New Revision: 112595
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112595
Log:
2006-03-31 Asher Langton [EMAIL PROTECTED]
PR
--- Comment #7 from kargl at gcc dot gnu dot org 2006-04-01 00:12 ---
Fixed on 4.1 and trunk.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from myles at peakstreaminc dot com 2006-04-01 00:14 ---
Created an attachment (id=11177)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11177action=view)
code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #2 from myles at peakstreaminc dot com 2006-04-01 00:19 ---
g++ -O2 -Wformat=2 works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #8 from kargl at gcc dot gnu dot org 2006-04-01 00:26 ---
Forgot to add the target milestone.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 ---
The warning is a true warning in that libstdc++ code contains:
const int __ret = std::snprintf(__out, __size, __fmt, __prec, __v);
But I don't know if there is a way of fixing this unless making
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-01 00:40 ---
(In reply to comment #3)
__convert_from_v out of line (which could slow down the compiler anyways).
s/compiler/program/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26970
--- Comment #3 from lucier at math dot purdue dot edu 2006-04-01 00:45
---
Subject: Re: Can't compile a 64-bit gcc
OK, I'll try to give a bit more data and make a more intelligent
comment.
I tried to configure and build mainline with this command:
/bin/rm -rf *; env CC='gcc
--- Comment #4 from lucier at math dot purdue dot edu 2006-04-01 00:48
---
Subject: Re: Can't compile a 64-bit gcc
On Mar 31, 2006, at 6:45 PM, lucier at math dot purdue dot edu wrote:
So it appears that configure in 4.1.0 realizes that the libiconv on
powerpc-darwin-8.5.0 is not
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-01 00:52 ---
Confirmed, reduced testcase:
void
ruby_re_compile_fastmap (char *fastmap, int options)
{
int j;
for (j = 0; j (1 8); j++)
{
if (j != '\n' || (options 4))
fastmap[j] = 1;
}
}
-
you can
--- Comment #13 from rmathew at gcc dot gnu dot org 2006-04-01 07:57
---
As you can see from the backtrace, the problem is in gcc/java/jcf-io.c at
line number 394 where we make a call to scandir(). I'm not an alpha-linux
hacker, but I see that there's scandir64 and dirent64 and it
88 matches
Mail list logo
