--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:19
---
If you add a third argument to the constructor, don't you somehow have to
add the old constructor with its two-argument signature to the library to
allow old programs to link against the new library?
How wo
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
20:21 ---
Subject: Bug 23419
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 20:21:34
Modified files:
libgfortran: Change
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:26
---
(In reply to comment #7)
> If you add a third argument to the constructor, don't you somehow have to
> add the old constructor with its two-argument signature to the library to
> allow old programs to link agains
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:39
---
Actually, __normal_iterator is what std::string uses for it's iterator class, so
we could be in trouble.
On the note of removing enable_if, my only other thought is something like:
template
then change th
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:45
---
(In reply to comment #9)
> Actually, __normal_iterator is what std::string uses for it's iterator class,
> so we could be in trouble.
As long as no user code expects instantiations of members of __normal_iterator
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
20:48 ---
Works just fine on the mainline.
--
What|Removed |Added
Known to work|3.3.2 3.4.4
--- Additional Comments From chris at bubblescope dot net 2005-09-07 20:51
---
I just tried adding a template parameter, and it does break things unfortunatly.
In an "old" file define something like:
void f(vector::iterator v) {..}
and then try to call it from a file that includes the
--- Additional Comments From bangerth at dealii dot org 2005-09-07 20:55
---
What I had meant was liba.so containing an explicit specialization of
std::vector and libb.so using it while being compiled with
-fno-implicit-instantiations (or whatever the correct name for that
flag was)
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07
20:58 ---
Even with the committed patch, there is still something wrong
on i686:
$ cat compl.f
program main
complex (kind=10) a, b
integer(kind=1), dimension(32) :: ea, eb
equivalence (ea, a)
--- Additional Comments From pcarlini at suse dot de 2005-09-07 20:58
---
(In reply to comment #11)
> I just tried adding a template parameter,
You mean, to the __normal_iterator class itself? That does not work, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:04
---
(In reply to comment #12)
> What I had meant was liba.so containing an explicit specialization of
> std::vector and libb.so using it while being compiled with
> -fno-implicit-instantiations (or whatever the cor
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-07 21:07
---
The code in mem*.[ch] is much messier than I originally thought. There are
lots of casts in assignments of pointer variables. The macros in mem00.h
starting with Unit_Size, which are used in both lvalues and
--- Additional Comments From chris at bubblescope dot net 2005-09-07 21:07
---
Actually for inline functions, even with -fno-implicit-templates,
instansiations are still generated (I can
kind of see why. You could argue they shouldn't be, but they are)
--
http://gcc.gnu.org/bugzill
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:08 ---
Subject: Bug 20848
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 21:08:24
Modified files:
gcc/fortran: ChangeLog symbol.c
gcc/tests
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
21:11 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:19 ---
Subject: Bug 20848
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 21:19:21
Modified files:
gcc/fortran: Change
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-09-07
21:20 ---
Fixed on mainline and 4.0.
--
What|Removed |Added
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:25 ---
Subject: Bug 23262
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 21:25:40
Modified files:
libgfortran: ChangeLog acinclude.m4 config.h.in co
--- Additional Comments From bangerth at dealii dot org 2005-09-07 21:27
---
I guess then there is no danger involved.
BTW, I'm not one of the corporate folks, so I have few problems with
breaking ABI compatibility :-) I was just too fast raising a point that
in the end didn't turn
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
21:32 ---
Subject: Bug 23262
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 21:31:57
Modified files:
libgfortran: Change
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07
21:33 ---
Patch commited, bug fixed.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 23261 depends on bug 23262, which changed state.
Bug 23262 Summary: [mingw32] rewind truncates file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23262
What|Old Value |New Value
--- Additional Comments From pcarlini at suse dot de 2005-09-07 21:36
---
(In reply to comment #16)
> I guess then there is no danger involved.
Yeah! ;)
> BTW, I'm not one of the corporate folks, so I have few problems with
> breaking ABI compatibility :-) I was just too fast raising
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-07 22:05 ---
It seems that expand generates different insns in 4.0 and 4.1 for the comparison
in question:
4.0 generates: (from .00.expand)
(insn 15 13 16 1 (set (reg/f:SI 62)
(mem/s/f:SI (plus:SI (re
--- Additional Comments From bangerth at dealii dot org 2005-09-07 22:40
---
Yea, but I guess I'll leave this to you guys, that sounds too complicated
for me. I'll just stick my head out every once in a while and try to find
a loophope in your reasoning and to invent ways to show that
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-07 22:43 ---
Subject: Re: __gnat_is_absolute_path: Segmentation fault
> Do you still see the problem ?
This is fixed.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22285
--- Additional Comments From danglin at gcc dot gnu dot org 2005-09-07
22:45 ---
No longer occurs.
--
What|Removed |Added
Status|UNCONFIRMED |RES
There is an internal error in gcc when following code is compiled with -O2 -c
options.
=
typedef float floatvect2 __attribute__((mode(V2DF)));
typedef union
{
floatvect2 vector;
double f[2];
}resfloatvect2;
void tempf(double *x, double *y)
{
floatvect2 temp
--- Additional Comments From raj dot khem at gmail dot com 2005-09-07
23:15 ---
I think it needs backporting this particular patch from Richard to 3.4 branch
submitted for bug #12133
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-07-09 10:06:03
--
What|Removed |Added
Summary|[3.3/3.4 regression] [arm] |[3.4 regression] [arm] ICE
|ICE in change_address_1, at |in change_address_1, at
In particular, describe in the detail all the allowed and disallowed changes to
the library headers (vs library proper, .so and .a): see the audit trail of
libstdc++/23767 for some examples.
--
Summary: Improve abi.html
Product: gcc
Version: 4.1.0
Stat
The following compiled with -m32 -O2 -S
void badFunc (int size)
{
char temp[size];
temp[size-1] = '\0';
};
gives
badFunc:
mflr 0
stwu 1,-16(1)
stw 0,20(1)
addi 0,3,30
lwz 9,0(1)
mr 11,1
stw 31,12(1)
mr 31,1
rlwinm 0,0,0
--
What|Removed |Added
Known to fail||4.0.2 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23774
--- Additional Comments From normbograham at yahoo dot com 2005-09-08
01:43 ---
Ed:
I also have the same problem, but a little thought gives you a good work-
around. First a little background. There is a function that calls main.
This is the last function on the stack you can quer
On a i686 platform, the example below is miscompiled with -O1.
I expect this program to print -0.96. Here's what it actually does:
$ g++ -O1 -o y y.cc
$ ./y
-1.288766
$ g++ -o y y.cc
$ ./y
-0.96
$
The value that the optimized version prints is actually different
on each run of the program
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:35
---
>From the log, this was a gdb bug.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-08 02:42
---
A more severe example is gdb.base/call-ar-st.c wherein the local static variable
"double_array" is not put to the debug info at all. Not even its name as in the
example here.
--
http://gcc.gnu.org/bugzilla/
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-08
03:07 ---
I think this is a good idea. I don't think we need a switch; this should just
be the default. We also need a documentation update to mention this. And, I
think the default ICE_EXIT_CODE shold be "2", unl
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org |dot au
Status|UNCONFIRME
--
What|Removed |Added
CC||fang at csl dot cornell dot
||edu
http://gcc.gnu.org/bugzilla/s
--- Additional Comments From csm at gnu dot org 2005-09-08 05:49 ---
Confirmed. The doFinal methods should leave 'state' as-is, as the reporter
suggests. It is up to CipherSpi
subclasses to reset themselves when their 'engineDoFinal' methods are called.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08
05:52 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-08
06:52 ---
Subject: Bug 23760
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-08 06:52:04
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gfor
101 - 144 of 144 matches
Mail list logo
