--- Comment #1 from dann at godzilla dot ics dot uci dot edu 2005-10-05
05:13 ---
Created an attachment (id=9889)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9889&action=view)
preprocessed code for this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24209
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-10-05 05:13
---
: Search converges between 2002-07-14-trunk (#81) and 2002-07-21-trunk (#82).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
4.1 selects a strange instruction to put in the delay slot of a bl,a
instruction because in the non-taken case the same instruction will be executed
anyway...
-O2 code for 4.1
PointToRowCol:
save%sp, -112, %sp
sethi %hi(term), %g1
ld [%g1+%lo(term)], %l2
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-05 05:05 ---
: Search converges between 2003-07-11-trunk (#291) and 2003-07-12-trunk (#292).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22180
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-05 05:03 ---
: Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446).
: Search converges between 2004-02-02-3.4 (#1) and 2004-03-01-3.4 (#2).
Hmm, this was introduced after 3.4 branched.
--
pinskia at
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-05 04:59 ---
I think there is a patch on Apple's branch but from what I heard is that it
causes huge compile time issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-05 04:56 ---
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23307
--- Comment #20 from pinskia at gcc dot gnu dot org 2005-10-05 00:55
---
Created an attachment (id=9888)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9888&action=view)
The fix which needs to be tested
Sorry about the name of the patch but I really hate reload, Oh and this is the
--- Comment #24 from pinskia at gcc dot gnu dot org 2005-10-05 00:54
---
Created an attachment (id=9887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9887&action=view)
Patch which fixes the reduced testcase
Sorry about the name of the patch but reload is the worst code I have ev
--- Comment #6 from hjl at lucon dot org 2005-10-05 00:37 ---
I used libstdc++ as an example to show that it isn't unreasonable to have
.o files compiled with and without -fffunction-sections. Besides, on my system
there is a libstdc++.a. We can just use something like
#define HOT_TEXT_
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-05 00:08 ---
(In reply to comment #0)
> On a somewhat scary note, compiling without -ftime-report speeds up the
> compilation from 0:11.95 to 0:04.39. This leads me to believe that the
> -ftime-report numbers can't be trusted ve
--- Comment #4 from pcarlini at suse dot de 2005-10-05 00:07 ---
PS: in case -buffered- cin is needed, a call:
std::ios::sync_with_stdio(false);
can be added before any I/O takes place (thus renouncing to char-by-char sync
with "C" stdio, however).
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from sabre at nondot dot org 2005-10-05 00:03 ---
Created an attachment (id=9886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9886&action=view)
Large C++ file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24208
--- Comment #3 from pcarlini at suse dot de 2005-10-05 00:02 ---
Indeed, not a bug. Really, we cannot do better than the default behavior (0)
for the default, sync-ed, cin, cout & co, because of the issue explained in
detail in libstdc++/12077: the fix removed the non-trivial showmanyc
Here's a case where the C++ front-end is still slow, despite the great
improvements in GCC 4. This is preprocessed with Apple's 4.x compiler.
From, 'g++ IC.ii -ftime-report -O0 -o /dev/null -S', I get:
parser: 1.84 (27%) usr 1.48 (29%) sys 3.22 (27%) wall
name lookup
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 23:46 ---
Paolo could you comment on this. This looks like PR 7744.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-04 23:42 ---
I don't think this is a bug at least reading the standard, there is nothing as
far as I can see says that in_avail will ever return any but 0 for cin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24206
The best description comes from an email by Richard Maine.
http://gcc.gnu.org/ml/fortran/2005-10/msg00073.html
Consider the following code:
module a
implicit none
real b
end module a
module c
use a
implicit none
private
contains
subroutine d
namelist /e/ b
The following code when run always returns 0 for in_avail()
To reproduce, just compile the following code with g++ with no commandline
switches and run the resulting binary.
#include
using namespace std;
int main () {
streamsize size;
char ch;
streambuf * pbuf;
pbuf = cin.rdbuf();
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-04 23:14 ---
(In reply to comment #4)
> A library may be compiled with -ffunction-sections. It doesn't mean that all
> codes linked against that library have to use -ffunction-sections. For
> example,
> libstdc++ is compiled wit
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-04 23:13 ---
In file t.f90:5
use tpsalie_analysis
1
Fatal Error: Can't open module file 'tpsalie_analysis.mod' for reading at (1):
No such file or directory
In file t.f90:3066
use precision_con
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 23:05 ---
Hmm, I think this is related to PR 15167.
This worked with "4.0.0 20050225" and "3.5.0 20040909".
Though it failed with "3.4.0 20040116" and 3.4.0 release and the current
mainline.
I am going to mark this currentl
--- Comment #4 from hjl at lucon dot org 2005-10-04 22:58 ---
A library may be compiled with -ffunction-sections. It doesn't mean that all
codes linked against that library have to use -ffunction-sections. For example,
libstdc++ is compiled with -ffunction-sections. Do I have to use it f
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-04 22:53 ---
Fixed already in 3.4.4.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 22:50 ---
This is 3.4 only regression, I have to look to see if I can reproduce it using
a newer 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-04 22:41 ---
(In reply to comment #2)
> The problem is with -ffunction-sections, we may put a very big cold function
> in
> the .text.hot section and a very hot function in the .text.unlikely section.
> It
> defeats the whole p
--- Comment #2 from hjl at lucon dot org 2005-10-04 22:36 ---
The problem is with -ffunction-sections, we may put a very big cold function in
the .text.hot section and a very hot function in the .text.unlikely section. It
defeats the whole purpose of .text.hot/.text.unlikely.
--
hjl
--- Comment #3 from jsberg at bnl dot gov 2005-10-04 22:35 ---
$ gfortran4 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.2/configure --prefix=/opt/gcc-4.0.2
--program-suffix=4 --enable-threads --with-arch=pentium4 --with-tune=pentium4
--enable-__cxa_atexi
--- Comment #2 from jsberg at bnl dot gov 2005-10-04 22:34 ---
Created an attachment (id=9885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9885&action=view)
Small change from previous, this one doesn't ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24204
--- Comment #1 from jsberg at bnl dot gov 2005-10-04 22:33 ---
Created an attachment (id=9884)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9884&action=view)
The source file that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24204
Sorry, Fortran 90 isn't my gig; can't tell you much more. Code follows.
--
Summary: ICE (segfault)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unass
--- Comment #3 from janis187 at us dot ibm dot com 2005-10-04 22:23 ---
It looks like it was fixed on mainline by this patch from mmitchel:
http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01218.html
It's hard to be sure because there are build failures at that time for
powerpc-linux.
--
--- Comment #1 from peterson at austin dot ibm dot com 2005-10-04 22:20
---
Created an attachment (id=9883)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9883&action=view)
Output of -v -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24203
gcc with -O2 computes an expression incorrectly. gcc -O1 computes
it correctly. The core expression is the following function:
uint64 Function2(void)
{
uint64 value;
value = 0;
value |= 0x0040;
value |= 0x8000ULL;
value |= 0x1000ULL;
if (gui) va
--- Comment #1 from debian-gcc at lists dot debian dot org 2005-10-04
21:59 ---
Created an attachment (id=9882)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9882&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[ forwarded from http://bugs.debian.org/bug=330857 ]
unpacking the attached tarball and cpp -I.. -I. test.c gives:
% cpp -I.. -I. test.c
# 1 "test.c"
# 0 ""
# 1 ""
# 1 "test.c"
# 1 "../tao/ORB.h" 1
# 1 "../tao/Sequence_T.h" 1
# 1 "../tao/Sequence.h" 1
# 1 "../tao/Sequence_T.h" 1
# 4 "../tao/S
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-04 21:52 ---
I don't see why this is really a problem. It only effects the gcing sections,
it just means you are not going to remove those functions when used with other
functions which are in the hold/cold section.
--
pinsk
We have
#define HOT_TEXT_SECTION_NAME ".text.hot"
#define UNLIKELY_EXECUTED_TEXT_SECTION_NAME ".text.unlikely"
There is a little potential for confusion, for example suppose we have a very
hot function with the unlikely name of "unlikely" or a very cold function
called "hot". With -ffunction-sect
--- Comment #9 from anthony dot ajw at gmail dot com 2005-10-04 21:43
---
The name following "t." must be the name of a member of either T, or one of its
base classes.
t.template f can only refer to a global template f if it is then followed
by a nested name specifier (e.g. t.template
--- Comment #43 from mark at codesourcery dot com 2005-10-04 21:14 ---
Subject: Re: [4.1 Regression] push_fields_onto_fieldstack
calculates offset incorrectly
jason at redhat dot com wrote:
> I was suggesting that instead of making the complete type and base type
> essentially copie
--- Comment #42 from jason at redhat dot com 2005-10-04 21:05 ---
Subject: Re: [4.1 Regression] push_fields_onto_fieldstack
calculates offset incorrectly
mark at codesourcery dot com wrote:
> So, I guess maybe we agree on the right plan. In particular:
>
> 1. When we see "T*" or "T&
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 21:01 ---
*** Bug 24200 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 2005-10-04 21:01 ---
*** This bug has been marked as a duplicate of 23797 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
[ forwarded from http://bugs.debian.org/325545 ]
This ill-formed code makes g++ ICE:
template struct foo;
template<>
struct foo<0>
{
typedef int t;
};
int main()
{
1 << typename foo<0>::t(42);
}
--
Summary: Error recovery problem after spurious "typename"
Product:
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 20:57 ---
Broken
: Search converges between 2003-04-22-trunk (#236) and 2003-05-04-trunk (#237).
Changed ICE, also ICEd all the time even without -g -frepo:
: Search converges between 2004-07-29-trunk (#498) and 2004-07-30-tr
--- Comment #4 from pcarlini at suse dot de 2005-10-04 20:53 ---
(In reply to comment #3)
> Is there any specific reason that _GLIBCXX_FULLY_DYNAMIC_STRING is not defined
> on Cygwin ?
Not having really looked into this issue, the reason is however obvious: the
use of _S_empty_rep_stora
--- Comment #21 from michael dot meissner at amd dot com 2005-10-04 20:46
---
Subject: RE: variable rotate and long long rotate
should be better optimized
Sorry, I got mixed up as to who the original poster was.
SSE2 is harder to use because it deals with 128 bit items instead of 64
--- Comment #1 from debian-gcc at lists dot debian dot org 2005-10-04
20:43 ---
Created an attachment (id=9881)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9881&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24199
[ forwarded from http://bugs.debian.org/328467 ]
Attached test case segfaults with -frepo -g. Problem not present in 4.0 or 4.1.
--
Summary: Segfault with -frepo -g
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
--- Comment #20 from ak at muc dot de 2005-10-04 20:39 ---
Newer linux does that of course, although not always in older releases.
But even in user space it's not a good idea to use SSE2 unless you really need
it because it increases the cost of the context switch and costs an exception
--- Comment #19 from michael dot meissner at amd dot com 2005-10-04 20:35
---
Subject: RE: variable rotate and long long rotate
should be better optimized
I almost forgot, kernels should be using -mno-mmx and -mno-sse as a
matter of course (or -msoft-float). I first ran into this pr
--- Comment #18 from michael dot meissner at amd dot com 2005-10-04 20:32
---
Subject: RE: variable rotate and long long rotate
should be better optimized
Yep, all valid points. So I don't think it should be done by default.
But I suspect the original poster's application may be wel
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #17 from ak at muc dot de 2005-10-04 20:20 ---
The code now looks fine to me thanks
I would prefer if it didn't generate SSE2/MMX code because that would be a
problem for kernels. Also in many x86 implementations moving things between
normal integer registers and SIMD regist
Many dg-do compile tests, added when libstdc++/2020 was fixed, are using the
class gnu_char_type as a character type. But this is buggy, because characters
are PODs and PODs cannot have user defined constructors because are aggregate
(8.5.1/1, 9/4). Maybe better removing completely the duplicated g
--- Comment #16 from michael dot meissner at amd dot com 2005-10-04 20:06
---
Created an attachment (id=9880)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9880&action=view)
Respin of 17886 patch to match new tree contents
This patch is meant to apply on top of Mark's changes, bu
--- Comment #15 from cvs-commit at gcc dot gnu dot org 2005-10-04 20:05
---
Subject: Bug 23125
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-04 20:05:15
Modified files:
gcc: ChangeLog c-dec
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-10-04 20:03
---
Fixed on both the mainline and 4.0 branches.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from michael dot meissner at amd dot com 2005-10-04 19:51
---
Note, Mark's patch as applied to the tree has a minor typo in it. The rotrdi3
define_expand uses (rotate:DI ...) instead of (rotatert:DI ...). It doesn't
matter in practice, since the generator function is n
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-10-04 19:49
---
Need to retest, I was compiling with a bad version of 4.1 which causes us to
fail with some varargs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-04 19:44 ---
(In reply to comment #6)
> I know it is in the gnat1 front-end but I really don't want to do the dumps
> for
> that :(.
I figured out how to fix the problem but to me it seems like a front-end bug in
that it does n
--- Comment #13 from cvs-commit at gcc dot gnu dot org 2005-10-04 19:41
---
Subject: Bug 21975
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-04 19:41:47
Modified files:
gcc: ChangeLog c-dec
--- Comment #24 from cvs-commit at gcc dot gnu dot org 2005-10-04 19:41
---
Subject: Bug 22052
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-10-04 19:41:47
Modified files:
gcc: ChangeLog c-dec
--- Comment #23 from pinskia at gcc dot gnu dot org 2005-10-04 19:41
---
Fixed the correct way in 4.0.3 which does not expose PR 23104.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-04 19:29 ---
I will try to update the patch tomorrow and submit it again for 4.1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-04 19:29
---
(In reply to comment #10)
> I stoped working on this a while back.
Well right after powerpc-darwin stoped bootstrapping Ada.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18692
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-04 19:28
---
I stoped working on this a while back.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ptsekov at gmx dot net 2005-10-04 19:28 ---
Is there any specific reason that _GLIBCXX_FULLY_DYNAMIC_STRING is not defined
on Cygwin ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--
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=23606
--- Comment #9 from dje at watson dot ibm dot com 2005-10-04 19:24 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
I bootstrap GCC every day without seeing this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-04 19:20 ---
My debugging sessions for this got bogged down, but I ran into a mainline fix
for this problem while investigating something else:
http://gcc.gnu.org/ml/gcc-cvs/2004-05/msg00133.html
I'm testing a backport of tha
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-04 19:17
---
I am not going to try to fix a reload bug, sorry.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from pinskia at gcc dot gnu dot org 2005-10-04 19:14
---
Reload is adding the REG_LABEL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
--- Comment #8 from h dot m dot brand at xs4all dot nl 2005-10-04 19:13
---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
On 4 Oct 2005 15:00:17 -, "dje at watson dot ibm dot com"
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #7 from dje at watson dot ibm dot com
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 19:10 ---
Maybe it is better just to support shared (dynamic) Libraries on win32 too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #1 from gerrit at gcc dot gnu dot org 2005-10-04 19:08 ---
Created an attachment (id=9877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9877&action=view)
Testcase which demostrates the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
Hello,
I noticed the following problem while porting an internal C++ application
from linux to Cygwin. If a std::string instance created in one module
(exe or dll) is passed to another say as an argument of a function call,
the program crashes or hangs. I did debug for a while and it turned
out th
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-10-04 19:07
---
The backtrace:
#1 0x008d8fc8 in make_edges (min=0x2c73cb8, max=0x2c694d0, update_p=1) at
../../gcc/cfgbuild.c:350
#2 0x008da32c in find_many_sub_basic_blocks (blocks=0x1e01200) at
../../gcc/cfgbuild.c:763
#3 0x0
--- Comment #14 from michael dot meissner at amd dot com 2005-10-04 18:59
---
Created an attachment (id=9876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9876&action=view)
Patch for x86 double word shifts
This patch fixes the bug from the x86 side of things instead of from the
When emit_input_reload_insns has an oldequiv that is different from old,
it re-computes the reload pattern icode used for secondary reloads.
It checks the predicate of operand 0 against the relod register, something
md.texi says doesn't happen and it clears icode for a mismatch. Instead it
should
--- Comment #23 from pinskia at gcc dot gnu dot org 2005-10-04 18:35
---
Created an attachment (id=9874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9874&action=view)
New patch which takes into the suggesstion from RTH
The new patch, it is simplier and actually fixes the real b
--- Comment #11 from ian at airs dot com 2005-10-04 18:18 ---
Fixed on mainline.
--
ian at airs dot com changed:
What|Removed |Added
Known to work|2.95.3
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-04 18:17 ---
Confirmed, reduced testcase:
void g (__int128_t *dest, long dstride, long rank)
{
long n;
for (n = 0; n < rank; n++)
dest[n * dstride] = 1;
}
So TImode is fully supported on ia64.
--
pinskia at gcc dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-04 18:09 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-04 18:06
---
Subject: Bug 13726
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-10-04 18:06:20
Modified files:
gcc: ChangeLog c-ppoutput.c
gcc/testsuite : C
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-04 17:29 ---
Even though it is a latent bug, this causes a build failure, therefor it is a
considered a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from kargl at gcc dot gnu dot org 2005-10-04 17:06 ---
(In reply to comment #3)
> Patch posted.
>
Ok for mainline and 4.0. Note, please cross post Fortran patches
to fortran@ mailinglist.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24176
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-04 16:54
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #12 from bonzini at gcc dot gnu dot org 2005-10-04 16:53
---
C and middle-end part was approved; I'd rather wait for C++ approval too before
committing it, because committing the approved parts will reintroduce a C++
regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #9 from cvs-commit at gcc dot gnu dot org 2005-10-04 16:16
---
Subject: Bug 19382
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]2005-10-04 16:16:10
Modified files:
gcc: ChangeLog builtin
--- Comment #8 from cvs-commit at gcc dot gnu dot org 2005-10-04 16:14
---
Subject: Bug 19382
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]2005-10-04 16:14:52
Modified files:
gcc: ChangeLog builtins.c
Log message:
PR a
--- Comment #11 from hidden_peak at mail dot ru 2005-10-04 15:55 ---
Sometimes test run fine fror me too, but (the same build and same evironment!)
sometimes not. This like depends upon garbage... Well, as expected---call of
dtor of died object.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #10 from hidden_peak at mail dot ru 2005-10-04 15:49 ---
Like my.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24189
--- Comment #1 from schwab at suse dot de 2005-10-04 15:46 ---
Created an attachment (id=9873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9873&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
Compiling libgfortran results in this ICE:
../../../libgfortran/generated/maxloc0_16_i4.c: In function
‘maxloc0_16_i4’:
../../../libgfortran/generated/maxloc0_16_i4.c:154: error: unrecognizable insn:
(insn 592 591 593 22 ../../../libgfortran/generated/maxloc0_16_i4.c:107 (set
(mem:DI (post_modify:
--- Comment #11 from pcarlini at suse dot de 2005-10-04 15:44 ---
The DR is now [Ready] and we can implement its straightforward resolution.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #41 from mark at codesourcery dot com 2005-10-04 15:28 ---
Subject: Re: [4.1 Regression] push_fields_onto_fieldstack
calculates offset incorrectly
rguenth at gcc dot gnu dot org wrote:
> --- Comment #40 from rguenth at gcc dot gnu dot org 2005-10-04 15:12
> ---
>
--- Comment #40 from rguenth at gcc dot gnu dot org 2005-10-04 15:12
---
(In reply to comment #38)
> As a 4.1 kludge, i can make the points-to analyzer do what it does for unions,
> which is to glob everything to a single variable for those classes where it
> has
> found two fields it
--- Comment #2 from menzel at ls6 dot cs dot uni-dortmund dot de
2005-10-04 15:10 ---
(In reply to comment #1)
> I think this only effects 4.0.x.
Yes, I tried version 3.4.4, 4.0.0 and 4.0.2 of the compiler.
No Problem with 3.4.4, while 4.0.0 and 4.0.2 fail.
--
http://gcc.gnu.org/b
--- Comment #7 from dje at watson dot ibm dot com 2005-10-04 15:00 ---
Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04
> h dot m dot brand at xs4all dot nl writes:
h> Next step is to upgrade vac-6.0.0.11 to vac-7.0.0.3
You said that you are bootstrapping with GCC
1 - 100 of 158 matches
Mail list logo
