--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-01-25 07:41
---
Fixed on 4.1 and 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-01-25 07:37
---
It's again the combiner:
26.life1:
(insn 21 19 22 2 (set (subreg:SI (reg:DI 64 [ D.654 ]) 0)
(const_int 1 [0x1])) 34 {*movsi_1} (insn_list:REG_DEP_TRUE 73 (nil))
(nil))
(insn 22 21 23 2 (set (stric
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-01-25 07:30
---
I don't see this problem any more. Was this fixed? Is the default record
length an issue any more? Can we close this PR? I wonder if the fix to P25835
fixed this? If so I propose we close this unless it is re
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-01-25 07:05
---
> Jan, I have verified that turn on x86_partial_reg_stall:
>
> const int x86_partial_reg_stall = m_PPRO;
>
> fixes those 2 failures. That is why only -mtune=pentiumpro passes those
> 2 tests.
Confirmed.
--
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC|law at gcc dot gnu dot org |
AssignedTo|unassigned at gcc dot gnu |law at gcc dot gnu
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-25 06:46
---
Fortran is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-01-25 06:46
---
This is certainly not a P1 for 4.1. If it's a bug (it probably is, but I still
want to think about it more), it's a minor one, in the grand scheme of things.
--
mmitchel at gcc dot gnu dot org changed:
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-25 06:43
---
Ada is not release critical; P5.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-25 06:33
---
P2, invalid code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25875
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-25 06:32
---
This is going to be hard to fix. We have two choices: either re-parse the
decl-specifiers after we know the class in which the function is being defined,
or (better) substitute into the function return type at tha
bash-3.00$ cat z1.c
int foo(void);
void bar(void) { (unsigned int)foo(); }
bash-3.00$ vi z1.c
bash-3.00$ /usr/local/gcc-4.1-branch/bin/gcc -c z1.c -Wall -O2
z1.c: In function bar:
z1.c:1: warning: value computed is not used
bash-3.00$ /usr/local/gcc-4.1-branch/bin/gcc -v
Using built-in specs.
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-01-25 06:30
---
We need to fix this.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-25 06:27
---
I think it's fine to change S390 for 4.1, if we change PowerPC. In fact, I
think S390 is less risk than PowerPC, since it is used by fewer people.
I'm watching the patches on the GCC list for PowerPC, but it look
Tested on gcc 4.0.2 20050808 and gcc 4.0.3 20051013
I don't know if this is a bug or a feature : this code, also
compiled without optimization, doesn't check if the address of
the variable is zero.
extern unsigned long int __spm_addr;
int main(void)
{
return &__spm_addr ? __spm_addr + 1 : -
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-01-25 04:44
---
To remind me, I should enable g++.dg/abi/key1.C on *-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-25 04:39
---
Found the problem and a way to fix it. The problem is that the key function
needs to be changed to the arm-eabi way and not the IA64 C++ ABI way.
See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02645.html for t
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-25 04:07
---
I might need some C++ help on this one but I think this is valid as the virtual
function is marked as inline so it is vague but can that be a key function?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-25 03:58
---
Or maybe not. More likely the TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-25 03:51
---
Caused by:
(machopic_select_section): Return the selected section rather than
emitting assembly code. Replace the static function table with
inline conditional expressions. Update the test
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-25 03:40 ---
Subject: Re: [3.4/4.0/4.1] [DR 392] Reference binding and explicit copy
constructors
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #11)
| > | Did you read comment 3?
| >
| > Yes. I
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-25 03:40
---
Before the breakage:
.globl __ZTV1f
.weak_definition __ZTV1f
.section __DATA,__const_coal,coalesced
After:
.globl __ZTV1f
.const_data
We are doing two things wrong, not mar
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-25 03:34
---
Actually DR 152 clarifies that this is invalid code. as Per 8.5/12 this is
copy-initialization.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #14 from gdr at gcc dot gnu dot org 2006-01-25 03:28 ---
DR 391, not 392. My typo.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Sever
--- Comment #13 from hhinnant at apple dot com 2006-01-25 03:24 ---
(In reply to comment #11)
> | Did you read comment 3?
>
> Yes. Is your claim that whether the copy constructor is converting or
> not does not matter?
No. My suspicion is that there is a 99.99% chance that EDG is c
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2006-01-25 02:41:25 |2006-01-25 03
--- Comment #12 from gdr at cs dot tamu dot edu 2006-01-25 03:20 ---
Subject: Re: [3.4/4.0/4.1 Regression] [DR 152] Reference binding and explicit
copy constructors
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| So this really just DR 152
No!
DR 152 is about what hap
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-25 03:09 ---
Subject: Re: [3.4/4.0/4.1] [DR 391] Reference binding and explicit copy
constructors
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #9 from hhinnant at apple dot com 2006-01-25 02:54 -
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-25 03:03
---
So this really just DR 152 and has nothing to do with DR 391 except misleading
us. DR 152 is TR1 so it is part of the standard, therefor this is still a
regression and should be marked as normal severity.
--
p
--- Comment #9 from hhinnant at apple dot com 2006-01-25 02:54 ---
(In reply to comment #8)
> Changing to request for enhancement. The requested behaviour is a change
> in th working paper. Existing behaviour is what is required by the standard
> (even when it can be argued that checki
--- Comment #8 from gdr at gcc dot gnu dot org 2006-01-25 02:41 ---
Changing to request for enhancement. The requested behaviour is a change
in th working paper. Existing behaviour is what is required by the standard
(even when it can be argued that checking for something that is elide
--- Comment #7 from gdr at cs dot tamu dot edu 2006-01-25 02:38 ---
Subject: Re: [3.4/4.0/4.1 Regression] [DR 391] Reference binding and explicit
copy constructors
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #4)
| > before you declare something
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-25 02:14
---
Fails in "20051210".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #6 from hhinnant at apple dot com 2006-01-25 02:05 ---
At the risk of continuing off-topic...
Thank you Andrew for your continuing prompt and high quality work. It is a
very valuable service and I've never had any complaints with the way you
provide it. Good Job and Thank
Greetings!
Is this bug still in the GCC 4.x releases? (See messages below.)
Or has it been fixed in the GCC 4.x releases?
Thanks,
Eric.
> -Original Message-
> From: Bob Friesenhahn [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 24, 2006 6:51 PM
> To: Eric Lemings
> Cc: 'libtool@gn
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-25 01:55 ---
(In reply to comment #4)
> before you declare something as a regression, please make sure you do
> understand the real issues. When you don't fully understand, please
> leave it alone and help somewhere else. Thank
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-01-25 01:39
---
Subject: Bug 25835
Author: jvdelisle
Date: Wed Jan 25 01:39:45 2006
New Revision: 110202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110202
Log:
2006-01-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from gdr at cs dot tamu dot edu 2006-01-25 01:32 ---
Subject: Re: [3.4/4.0/4.1 Regression] [DR 391] Reference binding and explicit
copy constructors
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I am going to mark this a regression but not confirm it be
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-01-25 01:29
---
Subject: Bug 25835
Author: jvdelisle
Date: Wed Jan 25 01:29:14 2006
New Revision: 110201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110201
Log:
2006-01-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-01-25 01:19
---
Subject: Bug 25835
Author: jvdelisle
Date: Wed Jan 25 01:19:11 2006
New Revision: 110200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110200
Log:
2006-01-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-25 01:10
---
Nathan sorry for CCing you (that was accident).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-01-25 01:10
---
Once again Dale, Thanks a million! er uh two and a half million!
I will commit to 4.2 tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25835
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-25 01:06
---
It was broken in "20051217". so only two weeks now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #5 from roger at eyesopen dot com 2006-01-25 01:05 ---
I'm testing the following patch...
Index: combine.c
===
*** combine.c (revision 109912)
--- combine.c (working copy)
*** try_combine (rtx i3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-25 00:53 ---
First since you are getting your compilers from redhat, you should talk to them
first.
But second gfortran does not have this limit as far as I know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25953
Hello:
This my help request is related with the solution that the GNU site provides
for the large file unit numbers problem (please refer to
http://gcc.gnu.org/onlinedocs/gcc-3.4.1/g77/Large-File-Unit-Numbers.html#Large%20File%20Unit%20Numbers)
So this is my problem:
I recently updated my PC with
--- Comment #5 from daney at gcc dot gnu dot org 2006-01-25 00:47 ---
Fixed now.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Example:
int toto() {
int a=0;
#pragma omp single
{
for (int i=0; i<10; ++i)
a += i;
}
return a;
}
int main() { return toto(); }
Even though we don't support openmp currently, this should not ICE.
--
--- Comment #4 from daney at gcc dot gnu dot org 2006-01-25 00:42 ---
Subject: Bug 25816
Author: daney
Date: Wed Jan 25 00:42:17 2006
New Revision: 110199
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110199
Log:
PR java/25816
* configure.ac (enable_tls): New en
--- Comment #3 from daney at gcc dot gnu dot org 2006-01-25 00:11 ---
Subject: Bug 25816
Author: daney
Date: Wed Jan 25 00:11:41 2006
New Revision: 110190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110190
Log:
PR java/25816
* configure.ac (enable_tls): New en
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-25 00:04
---
It worked in "20051203".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #7 from ayers at gcc dot gnu dot org 2006-01-24 23:49 ---
Fixed by replacing strncpy with memcpy and insuring the new strings are '\0'
termintated.
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from stevenj at alum dot mit dot edu 2006-01-24 23:41
---
The documentation apparently still needs to be fixed, as it currently (as of
20060117) says:
"To generate the final exectuable, the runtime library @code{libgomp} must be
linked in using @option{-lgomp}."
--
--- Comment #6 from ayers at gcc dot gnu dot org 2006-01-24 23:37 ---
Subject: Bug 9751
Author: ayers
Date: Tue Jan 24 23:37:24 2006
New Revision: 110187
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110187
Log:
2006-01-24 David Ayers <[EMAIL PROTECTED]>
PR libobjc/9
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 23:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #23 from pcarlini at suse dot de 2006-01-24 23:14 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #22 from paolo at gcc dot gnu dot org 2006-01-24 23:12 ---
Subject: Bug 25649
Author: paolo
Date: Tue Jan 24 23:12:26 2006
New Revision: 110186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110186
Log:
2006-01-24 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
Compiling the following code results in a compile error:
PROGRAM loc_1
CONTAINS
SUBROUTINE f (x)
INTEGER, DIMENSION(*) :: x
INTEGER :: address
address=LOC(x)
END SUBROUTINE f
END PROGRAM loc_1
The error produced by gfortran is:
[aardschokker:fms/trunk/ob
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-01-24 23:09 ---
(In reply to comment #2)
> It seems condjump_equiv_p (info, false) returns false because
> f1->dest and f2->dest are forwarder blocks:
This means that they have to have been forwarder blocks to forwarder blocks
orig
--- Comment #3 from fche at redhat dot com 2006-01-24 22:54 ---
With today's svn snapshot on x86, nptl, test case works ok.
If you can reproduce a crash, it would be useful to first amend the test case
to keep a log of malloc/free operations.
--
fche at redhat dot com changed:
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-24 22:53
---
It was broken before "20051231". So we are done to a month.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #3 from hhinnant at apple dot com 2006-01-24 22:51 ---
More information:
I now believe I unknowingly misled when I surmized that EDG had implemented cwg
391. If you declare the copy ctor private in the example, EDG rejects g(X())
based on accessibility. Rather I am now sur
--- Comment #6 from law at redhat dot com 2006-01-24 22:50 ---
Subject: Re: [4.2 Regression] ICE on ACATS cxac004 in
Tree-VRP
On Tue, 2006-01-24 at 22:15 +, laurent at guerby dot net wrote:
>
> --- Comment #5 from laurent at guerby dot net 2006-01-24 22:15 ---
> c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-24 22:48 ---
I am going to mark this a regression but not confirm it because I don't
understand this issue fully and this seems like someone else who knows better
about this should do that.
CCing Mark as he did the change for PR
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #21 from pcarlini at suse dot de 2006-01-24 22:45 ---
Ok, let's move the concerned inserters and extractors out of line, for the sake
of warning consistency. The performance loss seems bearable.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 22:38 ---
I am going to mark this depending on PR 12226 for a second since that is the PR
12226 which made promoted this change.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
Consider:
struct X {
X();
explicit X(const X&);
};
void f(X);
void g(const X&);
int main()
{
X x;
f(x);
f(X());
g(x);
g(X());
}
We currently give errors for f(x), f(X()) and g(X()), but not g(x). This is
not quite the behavior of EDG which allows g(X()).
--- Comment #5 from laurent at guerby dot net 2006-01-24 22:15 ---
c99004a randomly fails PR21317, unrelated to your fix, so go ahead :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25900
--- Comment #4 from law at redhat dot com 2006-01-24 22:12 ---
Subject: Re: [4.2 Regression] ACATS ICE cxac0004 in
set_value_range, at tree-vrp.c:161 on x86-linux
On Sat, 2006-01-21 at 21:00 +, pinskia at gcc dot gnu dot org wrote:
Weird.
I've got a little hack to reject t
--- Comment #5 from ayers at gcc dot gnu dot org 2006-01-24 22:00 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jan 24 22:00:26 2006
New Revision: 110183
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110183
Log:
2006-01-24 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-01-24 22:00
---
Now also fixed ion the 4.0 branch and the 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ayers at gcc dot gnu dot org 2006-01-24 21:57 ---
Subject: Bug 13946
Author: ayers
Date: Tue Jan 24 21:57:22 2006
New Revision: 110182
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110182
Log:
2006-01-24 David Ayers <[EMAIL PROTECTED]>
PR libobjc/
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-01-24 21:45
---
Subject: Bug 25552
Author: reichelt
Date: Tue Jan 24 21:44:57 2006
New Revision: 110181
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110181
Log:
PR c++/25552
* parser.c (cp_parser_unquali
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-01-24 21:39
---
Subject: Bug 25552
Author: reichelt
Date: Tue Jan 24 21:38:56 2006
New Revision: 110180
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110180
Log:
PR c++/25552
* parser.c (cp_parser_unquali
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-01-24 21:37
---
Recategorizing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Compo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-24 21:22 ---
It is even worse when opening two of these :) (or even five).
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
In some places the IO library simply assumes that the IO request is 'small
enough', and happily allocates a buffer big enough for the request to be
handled in one go. Unformatted IO already uses sread()/swrite() which bypasses
buffering if the request is bigger than the buffer size. However, this h
--- Comment #10 from schnetter at aei dot mpg dot de 2006-01-24 21:09
---
Yes, I am able to compile the code with that version:
$ ~/gcc/bin/g++ --version
g++ (GCC) 4.2.0 20051129 (experimental)
$ ~/gcc/bin/g++ -o lamtest *.ii -L/sw/lib -llammpio -llammpi++ -lmpi -llam
--
http://g
--- Comment #17 from rth at gcc dot gnu dot org 2006-01-24 21:07 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from rth at gcc dot gnu dot org 2006-01-24 21:06 ---
Subject: Bug 25259
Author: rth
Date: Tue Jan 24 21:06:07 2006
New Revision: 110179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110179
Log:
PR libgomp/25259
* configure.ac: Use GCC_HEADER_STDI
--- Comment #11 from trt at acm dot org 2006-01-24 20:33 ---
HP liked this warning suggestion. It will be in their next compiler release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-24 20:28 ---
Just to clarify with "gcc (GCC) 4.2.0 20051129", you were able to compile the
example you gave in comment #2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-24 20:20 ---
Hmm, this testcase works correctly on x86_64-linux-gnu, in that the vtable is
marked as weak.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-24 20:14 ---
Reduced testcase:
file1.cc:
class f
{
virtual void g();
};
inline void f::g()
{}
int sub(void)
{}
file2.cc:
class f
{
virtual void g();
};
inline void f::g()
{}
int main(void)
{}
--
Now why does this work
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-24 20:04 ---
Trying to reduce this failure. (I can reproduce it on today's compiler).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908
--- Comment #6 from mark at detrick dot com 2006-01-24 19:02 ---
Platform: SunOS hassium 5.10 Generic_118822-26 sun4u sparc SUNW,Ultra-60
GCC package: gcc-4.0.2.tar.bz2
Configure command from the gcc directory:
gcc-4.0.2/configure \
--with-gnu-as \
--with-as=/usr/local/bin/as \
--with-g
--- Comment #5 from mark at detrick dot com 2006-01-24 18:58 ---
Created an attachment (id=10725)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10725&action=view)
gcc java compile failure - screen output
Everything up to the point in this output worked fine.
Solaris 10 with Sun U
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-01-24 18:43
---
Working on it, it's the combiner.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-24 18:38
---
(In reply to comment #18)
> (In reply to comment #17)
> > I now see how the other PR caused this bug, we now inline "operator >>".
>
> Which means compiling with 4.2, you cannot use a 4.1's libstdc++ so we have an
--- Comment #19 from pcarlini at suse dot de 2006-01-24 18:38 ---
Indeed, as I said already, it's only by *chance* that the warning was not
emitted before, because the logic of the library has not changed and in fact,
**cannot** be changed. Really, if we want something ""better"", either
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-24 18:35
---
(In reply to comment #17)
> I now see how the other PR caused this bug, we now inline "operator >>".
Which means compiling with 4.2, you cannot use a 4.1's libstdc++ so we have an
ABI incompatibility now too.
--
--- Comment #5 from samuel dot thibault at ens-lyon dot org 2006-01-24
18:35 ---
But still an unpleasant behavior :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24745
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-24 18:34
---
I now see how the other PR caused this bug, we now inline "operator >>".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25649
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-24 18:32
---
The guess this bug is invalid then. If the standard is not sane, then this is
actually not a bug.
But then again libstdc++ can be a little saner in the case I gave for comment
#9. That is all I am asking for rea
--- Comment #15 from pcarlini at suse dot de 2006-01-24 18:28 ---
Andrew, do you understand that, according to the standard, the library
**cannot** touch that argument if the extraction fails?!? It is 22.2.2.1.2/11.
Do whatever you like, invent a new __attribute__((uninitialized)), file
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-01-24 18:27
---
(In reply to comment #12)
> Andrew, please stop saying stupid things. If you can support your claims with
> the library chapters of the standards, ok, otherwise please spend time on
> something else.
What does the
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-24 18:24
---
Lets look at the final IR:
_M_extract (&cin, &__l);
this.90 = (struct basic_ios > *) &cin;
D.31548 = this.90 + *(long int *) (cin._vptr.basic_istream + -24);
__a.59 = (int) D.31548->D.24021._M_streambuf_sta
--- Comment #12 from pcarlini at suse dot de 2006-01-24 18:21 ---
Andrew, please stop saying stupid things. If you can support your claims with
the library chapters of the standards, ok, otherwise please spend time on
something else.
--
pcarlini at suse dot de changed:
Wh
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-24 18:19
---
(In reply to comment #10)
> I suppose changing the component to libstc++ was a mistake... Irrespective of
> whether the compiler want or not to suppress this warning (in my opinion, it
> should not) the logic in th
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-24
17:39 ---
Subject: Re: [4.2 Regression] Build failure: undefined symbol __floatunsitf
> Has this all been fixed now?
This change fixes the problem on hppa*-*-hpux*:
2005-12-04 John David Anglin <[EMAIL PROTECTE
1 - 100 of 172 matches
Mail list logo
