--- Additional Comments From acct4290 at dedion dot com 2005-04-14 22:14
---
Created an attachment (id=8636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8636&action=view)
Preprocessed (.i) file for test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21033
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25
---
*** This bug has been marked as a duplicate of 19435 ***
--
What|Removed |Added
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-14 22:25
---
*** Bug 21033 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
Hi,
I was in the process of translating a program written in f77 into f90 when this
bug occurred. All I did was to add parameters to a function ; these parameters
must correspond to the dimensions of arrays, as I want to allocate memory to
them dynamically.
I declared my arrays like:
real
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-14 22:35 ---
Created an attachment (id=8637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8637&action=view)
Assembler file generated using the -save-temps option
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:01
---
Created an attachment (id=8638)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8638&action=view)
patch
--
What|Removed |Added
The comments in basic_string.h above std::basic_string::compare(...) and
therefore the Doxygen-generated documentation do not correctly describe the
behaviour of the compare() member function.
In all cases, the comments describe compare() as comparing strings by length
first, and calling traits::c
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:02
---
A comment in the patch says "Tested on i686-pc-linux-gnu", but
it just means that it will have been tested by the time I post this patch. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-14 23:07
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01668.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-14
23:33 ---
Could you attach the .f90 file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-14
23:37 ---
Subject: Bug 14311
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-14 23:37:47
Modified files:
gcc: ChangeLog builtin-types.def builtins.
Description of problem:
gcj ICEs compiling Azureus 2.2.0.2 to native code.
Version-Release number of selected component (if applicable):
gcc-java-4.0.0-0.42 from RedHat Fedora Core Development
How reproducible:
Always
Steps to Reproduce:
1. Download and unpack Azureus 2.2.0.2 from
http://azureu
I tried to build gcc-4.0.0-20050410 (RC1) and got the following error:
/usr/local/bin/gcc -maix64 -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition-DHAVE_CONFIG_H -o cc1 \
c-parse.o c-lan
On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote:
I tried to build gcc-4.0.0-20050410 (RC1) and got the following error:
BOOT_CFLAGS="-O9 -maix64" CFLAGS="-O9 -maix64" CXXFLAGS="-O9 -maix64"
LIBCFLAGS="-g -O9 -maix64" LIBCXXFLAGS="-g -O9 -maix64
-fno-implicit-templates"
nohup /u
--- Additional Comments From pinskia at physics dot uc dot edu 2005-04-15
00:49 ---
Subject: Re: New: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On Apr 14, 2005, at 8:45 PM, ltg at zes dot uni-bremen dot de wrote:
> I tried to build gcc-4.0.0-20050410 (RC1) and got the following
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
00:51 ---
Also what gcc are you starting with?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21037
In:
void foo() {
int i;
int j;
int k;
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `void foo()':
foo.cc:5: error: expected `}' at end of input
The disgnostic should show the line number of the unmatched opener "{". Finding
mismatched brackets can be a real pain in l
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15
01:08 ---
Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On 15-Apr-2005 pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
> 00:51
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
01:29 ---
Subject: Bug 21021
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 01:29:44
Modified files:
gcc: ChangeLog tree-vrp.c
gcc/tes
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 01:31
---
Just checked in a workaround patch.
For a real fix, keep an eye on PR 21024.
--
What|Removed |Added
---
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
02:32 ---
Subject: Re: [PR middle-end/20739] lvalue cond-expr gimplification may crash on
cv-qual diffs
On Apr 14, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Bootstrap and regtest pased on amd64-linux-gnu, a
-BEGIN PGP SIGNED MESSAGE-
I ran into an interesting bug when attempting to add imlib2 to a program that
uses GLUT. The program would compile/link fine, but segfault when the
imlib_load_image() call was made. (initial call to imlib)
The fix?
change:
int time;
to:
//int time;
the time integ
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
02:40 ---
> Hmm? VRP is automatically enabled at -O2 and higher.
But it doesn't run unless we find some ASSERT_EXPR, and if all we have is a
simple loop, no such ASSERT_EXPR is introduced.
--
http://gcc.gnu.org/b
--- Additional Comments From matz at suse dot de 2005-04-15 02:40 ---
We see this error in blender. I was able to reduce it quite a bit to this:
struct IMG_Rect {
virtual inline int getWidth() const;
virtual inline bool isEmpty() const;
virtual int getVisibility(int) const;
};
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
03:09 ---
Subject: Bug 20739
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 03:09:51
Modified files:
gcc: ChangeLog gimplify.c
gcc/tes
--- Additional Comments From matz at suse dot de 2005-04-15 03:16 ---
One strange thing is, that the call to getWidth() in B is already in .generic:
if (retval.1)
{
getWidth (&i_bnds);
}
while the call to getWidth() in isEmpty() (which is inlined later into
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
03:31 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 12, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote:
> I still like your fallbacks, that by trying harder we perform better
> o
On Apr 14, 2005, at 10:32 PM, Jay Summet wrote:
-BEGIN PGP SIGNED MESSAGE-
I ran into an interesting bug when attempting to add imlib2 to a
program that
uses GLUT. The program would compile/link fine, but segfault when the
imlib_load_image() call was made. (initial call to imlib)
The fix
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-15 04:05
---
Testing the obvious fix.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
04:05 ---
I don't know if it would useful or not. Take the following:
void g(); void h();
void f()
{
//. say about 100 lines
if (a) {
//. say about 100 lines
//. say about 100 lines
}
well you
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-15
05:07 ---
Subject: Re: Intrinisc function SPREAD is broken
>
>
>This appears to fix the benchmark in question.
>
>
>
I believe that reshape needs the same/similar fix.
Is ret->data = NULL guaranteed for temporarie
--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-15
05:25 ---
Subject: RE: [4.0 RC1] Bootstrap failure (ld: TOC overflow)
On 15-Apr-2005 pinskia at physics dot uc dot edu wrote:
>
> It is already done for BOOT_LDFLAGS.
OK. I configured now with:
BOOT_LDFLAGS="-
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:29
---
A::foo_ is not template-dependent, so it is looked up and bound at the time
of template definition, not at instantiation time. Because template-dependent
base classes are not visible at the time, the access is
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:31
---
The unqualified name Foo is looked up within the class hierarchy, and finds
the name of the base class.
W.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-15
05:36 ---
Hmm, all of the testcases listed here work on the mainline.
--
What|Removed |Added
Know
--- Additional Comments From bangerth at dealii dot org 2005-04-15 05:36
---
It may also very well be the case that the shown opening brace isn't the
one that is unmatched, but that you forgot to close a block somewhere in
the middle.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-15
05:44 ---
Subject: Bug 21004
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-15 05:43:57
Modified files:
gcc: ChangeLog convert.c builtins.c
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-15
05:56 ---
Subject: [PR tree-optimization/21029, RFC] harmful chrec type conversions
I started out by handling the specific case that the Ada front-end
triggers, reduced to function f() in the attached testcase. Later
--- Additional Comments From igodard at pacbell dot net 2005-04-15 06:04
---
Yes, it's a design flaw of C that parens and bracked are so overloaded that the
compiler (or the human) can't tell if the problem is too many openers or not
enough closers. Still, every little bit helps :-)
Iva
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-15 06:09 ---
Sure.
Actually the main file is a .F file. The tgz I'm about to attach contain the
following files:
- main.F : main file
- guess.h params.h pinch_complet.h prec.h: included by the preprocessor
--- Additional Comments From nicolas dot girard at nerim dot net
2005-04-15 06:10 ---
Created an attachment (id=8639)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8639&action=view)
Source files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21034
This hits when compiling rrdtools, which creates a perl .xs module. It's
and autoconf package, and hence has a config.h. perl also has a config.h
used from it's headers (by doing a 'include "config.h"', so the one from the
perl include dir is used correctly), which has a multiple include guard
--- Additional Comments From matz at suse dot de 2005-04-15 06:21 ---
Created an attachment (id=8640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8640&action=view)
Tarball with the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21039
g++ reports: "gpp_bug.cpp:10: internal compiler error: Segmentation fault", on
both Gentoo Linux (gcc 3.3.5) and Solaris (gcc 3.3.2).
Full output of "g++ gpp_bug.cpp":
gpp_bug.cpp: In function `void func()':
gpp_bug.cpp:10: internal compiler error: Segmentation fault
Please submi
--- Additional Comments From matz at suse dot de 2005-04-15 06:51 ---
Perhaps due to the IPA infrastructure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
101 - 146 of 146 matches
Mail list logo
