--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
21:51 ---
Namelookup happens before access checking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23904
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
21:53 ---
As I mentioned in comment 1, this is not a bug as namelookup comes before
access checking. This is
what the standard says.
--
What|Removed |Added
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-15
22:02 ---
Subject: Bug 16032
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-15 22:02:14
Modified files:
libjava: ChangeLog interpret.cc verify.cc defi
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-15
22:05 ---
Fix checked in
--
What|Removed |Added
Status|NEW |RESOLV
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-15
22:05 ---
Now we have again (?? appeared not too long ago) DOM taking all time and memory
threading 1 times repeating
if (__priority == 65535)
{
if (__initialize_p == 0)
{
__comp_dto
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-15 22:14
---
This changed with the following patch from geoffk:
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00723.html
--
What|Removed |Added
---
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
22:20 ---
I think the relevant part of the C++ standard here is [temp.inst] paragraph 5:
If the overload resolution process can determine the correct function to call
without instantiating a class
template definitio
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
22:34 ---
(In reply to comment #39)
> Another reason why spelling needs preserving (in addition to implementing #
> correctly) is for the constraints on duplicate macro definitions.
>
> #define foo \u00c1
> #define fo
The function is supposed to copy expressions from "src" to "dest", however, at
line 486 and 487:
dest->lower[i] = gfc_copy_expr (dest->lower[i]);
dest->upper[i] = gfc_copy_expr (dest->upper[i]);
"dest" are misused as the arguments in the parentheses. Both of them should be
"src", I th
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
22:36 ---
Fixed by:
2005-09-14 Christopher Faylor <[EMAIL PROTECTED]>
* pex-win32.c: Include "windows.h".
(backslashify): New function.
(fix_argv): Use backslashify to convert path to window
Line 422 in the file is a if-statement:
if (l_stride != NULL)
mpz_cdiv_q (X2, X2, r_stride->value.integer);
I am not clear about the functionality of "mpz_cdiv_q", but I think the
condition should be "r_stride != NULL" by looking at its surroundings and
complying to certain consistenc
pinskia at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
> 14:22 ---
> Small testcase:
> void f(int i)
> {
> switch (i)
> {
> case 1:
> struct a *b;
> }
> }
>
> But IIRC this is invalid code as variable defintion
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:50 ---
Subject: Re: switch and struct
pinskia at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-15
> 14:22 ---
> Small testcase:
> void f(int i)
>
geoffk at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 ---
> (In reply to comment #39)
> > Another reason why spelling needs preserving (in addition to implementing #
> > correctly) is for the constraints on duplicate macr
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:53 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
geoffk at gcc dot gnu dot org wrote:-
>
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 ---
> (In repl
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
22:53 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, geoffk at gcc dot gnu dot org wrote:
> --- Additional Comments From geoffk at gcc dot gnu dot org 2005-09-15
> 22:34 -
--- Additional Comments From neil at daikokuya dot co dot uk 2005-09-15
22:58 ---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
joseph at codesourcery dot com wrote:-
> I don't believe I said I'd file a DR unless I saw a defect. There is no
> defect because models A or C
--- Additional Comments From ppluzhnikov at charter dot net 2005-09-15
23:31 ---
The line '#0 ' causes trouble for other tools that work with
the output from 'gcc -E'; e.g. edgcpfe refuses to parse it:
$ gcc -E - < /dev/null > junk.i && edgcpfe --c junk.i
"", line 1: error: invalid lin
--- Additional Comments From joseph at codesourcery dot com 2005-09-15
23:37 ---
Subject: Re: UCNs not recognized in identifiers
(c++/c99)
On Thu, 15 Sep 2005, neil at daikokuya dot co dot uk wrote:
> > Yes, "spelling" is meant in terms of the source code characters.
> > The idea
--- Additional Comments From geoffk at geoffk dot org 2005-09-16 00:01
---
Subject: Re: UCNs not recognized in identifiers (c++/c99)
On 15/09/2005, at 3:53 PM, joseph at codesourcery dot com wrote:
> Yes, "spelling" is meant in terms of the source code characters.
> The idea is t
We noticed the function has no switch case for "BT_COMPLEX" by similarity check
against other functions such as "gfc_simplify_range" in the same file. I think
it's reasonable for a complex to have a radix. So one "case BT_COMPLEX:" may be
needed just after "case BT_REAL:" at line 2513. Could y
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:52 ---
I think this is a dup of bug 7088 but I cannot prove it for sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:53 ---
Fixed so closing.
--
What|Removed |Added
Status|UNCONFIRMED |RES
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-16 00:45
---
Test vect-97.c currently passes on ia64-linux and passed on alpha-dec-osf5.1b
on 20050805, and the submitter said it passes on ia64-hpux; this PR can
probably be closed.
--
http://gcc.gnu.org/bugzilla/show
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
00:58 ---
Fixed in 4.1.0 by:
2005-09-12 Ian Lance Taylor
PR g++/7874
* cp-tree.h (struct lang_decl_flags): Add hidden_friend_p
bitfield. Make dummy bitfield one bit smaller.
(DECL_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
01:03 ---
Fixed in 4.1.0.
--
What|Removed |Added
Status|NEW |RESOL
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
01:51 ---
Subject: Bug 23896
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 01:50:26
Modified files:
gcc/cp : ChangeLog pt.c
gcc/testsuite
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-16
01:54 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED|RESO
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
01:54 ---
Subject: Bug 23896
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-16 01:53:43
Modified files:
gcc/cp : Change
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:01
---
gfc_simplify_radix is used in intrinsic.c for simplification of the
RADIX intrinsic function. The standard defines RADIX for REAL and
INTEGER. See 13.14.84.
program mn
complex z
print*, radix(z)
end p
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
02:16 ---
Unassigning for now.
--
What|Removed |Added
AssignedTo|pinskia at gcc dot gnu dot |
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:34
---
I'm not sure what this function is really accomplishing. The
line "*dest = *src;" isn't copying src to dest. We simply
have set *dest to point to src. So, the for loop is a NOP.
Of course, I could be missi
Template subclasses do not find variables in their parent classes
Example code that should compile and does not:
template
class A {
protected:
S maxIt;
public:
A(S x) {maxIt = x;}
};
template
class B : public A {
public:
B(S d) : A(d) {
maxIt *= 2;
}
};
B f()
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
02:47 ---
Read http://gcc.gnu.org/gcc-3.4/changes.html
This is not a bug.
--
What|Removed |Added
--- Additional Comments From bauhaus at futureapps dot de 2005-09-16 03:11
---
looking at tests/res/string.h in the build area, it does lack \n at EOF,
so the message is correct. (All other files do have \n at EOF.)
inclhack.def:2004 has the following comment.
/* The string.h result is
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:14 ---
Resolved by patches to PR21875
--
What|Removed |Added
Status|NEW
--
Bug 19276 depends on bug 23379, which changed state.
Bug 23379 Summary: compiler segfault with internal write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23379
What|Old Value |New Value
--
Bug 23379 depends on bug 23364, which changed state.
Bug 23364 Summary: missing format reversion for internal write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23364
What|Old Value |New Value
--
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:20 ---
Fixed by patches to PR21875
--
What|Removed |Added
Status|NEW
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-09-16
03:24 ---
No more NIST failures
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:26 ---
This looks like a bug. However I don't agree with this analysis.
We should be applying the same transformation to both l and r.
Also, multiplying then dividing by the same value makes no sense.
--
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:26 ---
This looks like a bug. However I don't agree with this analysis.
We should be applying the same transformation to both l and r.
Also, multiplying then dividing by the same value makes no sense.
--- Additi
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-09-16
03:27 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From michel at colorado dot edu 2005-09-16 03:32
---
Subject: Re: Template subclasses do not find variables in
their parent classes
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
> 02:47
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:36 ---
(In reply to comment #2)
> No idea why that is. What's the logic behind this? Make my code twice as
> long?
The standard says this, did you read the page I gave? If not then I copied and
pasted what is r
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=270
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=457
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:40 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:40 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:41 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:42 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:42 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:43 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=603
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:44 ---
reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:45 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--
What|Removed |Added
Target Milestone|--- |3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=765
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:48 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:48 ---
Close as invalid.
--
What|Removed |Added
Status|REOPENED|RES
--
What|Removed |Added
Target Milestone|--- |3.0.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=857
--- Additional Comments From michel at colorado dot edu 2005-09-16 03:49
---
Subject: Re: Template subclasses do not find variables in
their parent classes
I read this. What I am questioning is the logic behind this. Isn't the
logic of template that if you were to replace the typenam
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:50 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:50 ---
Mark as invalid.
--
What|Removed |Added
Status|REOPENED|RESO
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:54 ---
Here is the "real" backtrace:
#0 0x00064374 in sarray_lazy_copy (oarr=0x0) at
/Users/pinskia/src/libobjc/gcc/libobjc/sarray.c:484
#1 0x000668d0 in __objc_install_dispatch_table_for_class (class=0x31034) a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
03:55 ---
The next runtime does:
objc: Both ./1.so and ./2.so have implementations of class Foo.
objc: Using implementation from ./2.so.
What do you think we should do, use the later one of the first or abort?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
04:24 ---
I am going to implement the next runtime behavior. The following code works
and is just like the code
in your testcase too but works with both runtimes:) :
#include
#include
#include
#ifdef __NEXT_RUN
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-16
04:26 ---
Actually my testcase works with the next runtime also but that might be because
it is picking the first
Foo and the one in 2.so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18764
We use some optimized XOR routines for software RAID. Unfortunately, the
compiler generated incorrect code when this was compiled for Redhat 7.3 +
2.4.24 (this is normally kernel code). I later found out that all versions of
gcc that I tested (up to FC4 - 4.0.0 20050519 (Red Hat 4.0.0-8)) had
--- Additional Comments From jeff at panasas dot com 2005-09-16 05:44
---
Created an attachment (id=9738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9738&action=view)
Xor test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
--- Additional Comments From skyhover at hotmail dot com 2005-09-16 05:45
---
Thanks for your information and clarification. I agree now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23907
--- Additional Comments From skyhover at hotmail dot com 2005-09-16 05:53
---
There are some similar code in function "gfc_copy_array_ref" at line 53-55.
There, "src" are kind of recursively copied into "dest".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23905
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-16
06:51 ---
Subject: Bug 23357
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-16 06:50:57
Modified files:
gcc/cp : ChangeLog cp-tree.def
Added files:
101 - 172 of 172 matches
Mail list logo
