Andrew Haley wrote:
Yuri Pudgorodsky writes:
We can say something like:
In GNU C, you may cast a function pointer of one type to a function
pointer of another type. If you use a function pointer to call a
function, and the dynamic type of the function pointed to by the
The SC has appointed Ben Elliston as maintainer of the Decimal
Floating-Point components of the compiler, including relevant portions
of the front ends, libraries, etc.
Ben, please update MAINTAINERS to reflect your expanded role.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650)
I have been trying to figure out when the pattern vec_extract is
invoked. I understand it is invoked from extract_bit_field but I
don't see how it can be invoked. For both SSE and altivec I have
tried the following code (which I thought would cause vec_extract
pattern to be called) but on both,
Andrew Pinski wrote:
I have been trying to figure out when the pattern vec_extract is
invoked. I understand it is invoked from extract_bit_field but I
don't see how it can be invoked. For both SSE and altivec I have
tried the following code (which I thought would cause vec_extract
pattern to
On Jul 12, 2006, at 10:04 AM, Tristan Wibberley wrote:
This isn't type visibility. Shared objects don't export types
they export symbols. The types are defined in headers and are
thus known to exist - no visibility attributes will or should
change that.
Actually in C++, they are
On Jul 11, 2006, at 10:58 AM, Benjamin Kosnik wrote:
I don't know what to do about the ICE: it looks like Mike has a patch.
My patch to fix this isn't at all obvious that it is correct to me.
There are no signs that it will be reviewed anytime soon, so, I'd say
please revert the patch
As was discussed at the summit, we'd like to get rid of global language
callbacks so that we can
safely inline from different source languages.
AFAICS, this can be archived by using the space occupied by the
lang_flags to store a language
tag in each tree node.
I.e., while the frontend does
Hi Ulrich.
Few months ago I has analyzed PR19636 (avr specific bug) and found
that it's a reload related problem. I has started the thread
http://gcc.gnu.org/ml/gcc/2006-02/msg00213.html but nobody commented the
problem.
Can you comment the problem as reload maintainer ?
Denis.
My patch to fix this isn't at all obvious that it is correct to me.
There are no signs that it will be reviewed anytime soon,
That's because you've buried it in an SOS message about bootstrap
breaking.
Please post your patch on gcc-patches with a sane and descriptive
subject, and put also
Benjamin Kosnik writes:
My patch to fix this isn't at all obvious that it is correct to me.
There are no signs that it will be reviewed anytime soon,
Benjamin That's because you've buried it in an SOS message about bootstrap
Benjamin breaking.
Benjamin Please post your patch on
On 7/12/06, Joern RENNECKE [EMAIL PROTECTED] wrote:
As was discussed at the summit, we'd like to get rid of global language
callbacks so that we can
safely inline from different source languages.
AFAICS, this can be archived by using the space occupied by the
lang_flags to store a language
tag
I don't understand what you are exactly trying to do, but I guess you
want to virtualize the lang-hooks? The proper way to get rid of them
is to encode the information they provide in the IL, not to encode the
source language in the trees.
I strongly agree and was going to say so in response
Andrew Pinski wrote:
I have been trying to figure out when the pattern vec_extract is
invoked.
I looked at this when I worked on the mips simd support. In
config/mips/mips-ps-3d.md I wrote
;; ??? This is only generated if we perform a vector operation that has
to be
;; emulated. There is
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client
I'm taking the wiki down for a few days because
1. It's getting attacked again, and the current software doesn't make
fixing this easy.
2. I'm currently not at home, and have a lot of meetings, so i probably
won't finish converting it until i get back home. :)
Sorry about this.
--Dan
Richard Kenner wrote on 07/12/06 14:33:
I don't understand what you are exactly trying to do, but I guess you
want to virtualize the lang-hooks? The proper way to get rid of them
is to encode the information they provide in the IL, not to encode the
source language in the trees.
I strongly
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
No, that's why we need programmer provided attributes. The programmer says:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass them back in later
and
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
the client code needs to know about the existence of this type so
it can get pointers and references to instances and pass them back
in later and maybe be able to call virtual member functions and
access non-static members by putting it
Tristan Wibberley [EMAIL PROTECTED] writes:
| Daniel Jacobowitz wrote:
| On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
| If the programmer had intended that the type should appear to not
| exist. it wouldn't be defined in a header #include-able by client
| code. The
|
Daniel Jacobowitz [EMAIL PROTECTED] writes:
[...]
| I just don't get it. Why should it matter whether a member function is
| virtual or not in order to be able to call it from outside this shared
| object? Either you can access the public members of the class, or you
| can't. Being able to
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client
Mike Stump wrote:
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass them back in
later and maybe be able to call virtual member functions and access
non-static
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
| The programmer says:
|
| the client code needs to know about the existence of this type so it
| can get pointers and references to instances and pass them back in
| later and maybe be able to call virtual member functions
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
No, that's why we need programmer provided attributes. The programmer says:
the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass
(copying your mail to the gcc mailing list again)
Benjamin Smedberg wrote:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
The way I was thinking about it, if a type has hidden visibility, we
can't refer to it from outside its object. Thus, it
Jason Merrill wrote:
OK, you've convinced me that the compiler shouldn't override or complain
about explicit visibility attributes. Do you have a problem with
implicit propagation of visibility in the absence of an attribute?
Specifically:
Do you agree with implicitly giving template
Well, I agree with what you said about your example, but it's not what
I am meaning. See below.
Ian Lance Taylor wrote:
Rodney M. Bates [EMAIL PROTECTED] writes:
I don't understand this. A pointer to anywhere in an activation record
(or even outside it, if outside by a fixed offset) allows
Tristan Wibberley [EMAIL PROTECTED] writes:
| Mike Stump wrote:
| On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| the client code needs to know about the existence of this type so
| it can get pointers and references to instances and pass them back
| in later and maybe be able to
Tristan Wibberley [EMAIL PROTECTED] writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
| Since C++ doesn't have a notion of module a
| class that the
Benjamin Smedberg wrote:
Jason Merrill wrote:
Do you agree with implicitly giving template instantiations the
minimum visibility of the template and arguments unless explicitly
overridden?
This is not what I would naturally expect, coming from a
dllimport/export mindset, but I don't think
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
| Mike Stump wrote:
| On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| the client code needs to know about the existence of this type so
| it can get pointers and references to instances and pass them back
| in
Jason Merrill [EMAIL PROTECTED] writes:
[...]
| | - I don't recall suggesting that
| | multiple types with the same name should be able to exist.
| then you have to consider that suggestion and come with an answer.
|
| I don't see why. The point is that visibility is orthogonal to
|
On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
So, -concretely- what happens to a class S (e.g. associated type info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units, with say hidden visibility?
Well, there are
Joe Buck [EMAIL PROTECTED] writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| So, -concretely- what happens to a class S (e.g. associated type info object
| address, address of member functions, etc.) with external linkage,
| defined in multiple translation units,
Gabriel Dos Reis wrote:
Jason Merrill [EMAIL PROTECTED] writes:
So, -concretely- what happens to a class S (e.g. associated type info object
address, address of member functions, etc.) with external linkage,
defined in multiple translation units, with say hidden visibility?
If it has hidden
Gabriel Dos Reis wrote:
Joe Buck [EMAIL PROTECTED] writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| So, -concretely- what happens to a class S (e.g. associated type info object
| address, address of member functions, etc.) with external linkage,
| defined in
Gabriel Dos Reis wrote:
Tristan Wibberley [EMAIL PROTECTED] writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
vtables happen to just work with
Jim Wilson [EMAIL PROTECTED] writes:
Andrew Pinski wrote:
I have been trying to figure out when the pattern vec_extract is
invoked.
I looked at this when I worked on the mips simd support. In
config/mips/mips-ps-3d.md I wrote
;; ??? This is only generated if we perform a vector
Tristan Wibberley [EMAIL PROTECTED] writes:
But I think it is important that there are three places where
visibility is a factor (as a concept of being able to see things
rather than the attribute).
I think it would help if you wrote down the rules for the visibility
attributes as applied to
This is repost of my slightly earlier post, with a critical and
confusing misstatement corrected.
Well, I agree with what you said about your example, but it's not what
I am meaning. See below.
Ian Lance Taylor wrote:
Rodney M. Bates [EMAIL PROTECTED] writes:
I don't understand this. A
Daniel Jacobowitz wrote:
I just don't get it. Why should it matter whether a member function is
virtual or not in order to be able to call it from outside this shared
object? Either you can access the public members of the class, or you
can't. Being able to access some of them and get link
--- Comment #3 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-12 06:30 ---
Created an attachment (id=11863)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11863action=view)
mpif.h (from MPICH)
This file alone is not going to be able to reproduce this bug.
Can you
--- Comment #25 from richard at codesourcery dot com 2006-07-12 06:32
---
Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0
worked.
pcarlini at suse dot de [EMAIL PROTECTED] writes:
Thanks Rainer and Eric. Then, since we have a workaround in place for
the
--- Comment #13 from mmitchel at gcc dot gnu dot org 2006-07-12 07:22
---
Subject: Bug 28016
Author: mmitchel
Date: Wed Jul 12 07:22:47 2006
New Revision: 115365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115365
Log:
PR c++/28016
* decl.c (cp_finsh_decl): Do
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-07-12 07:23
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following snippet
write(*,100) 0.9
write(*,100) 0.99
write(*,100) 0.999
write(*,100) 0.
write(*,100) 0.9
write(*,100) 0.99
100 format((f3.0))
end
with gcc-gfortran-4.1.1-1.fc5, I get as output
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-12 08:16 ---
Fixed in 3.4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Program1:
with Ada.Text_IO; use Ada.Text_IO;
procedure Main is
task Task1 is
entry Stop;
end Task1;
task body Task1 is
begin
accept Stop;
end Task1;
begin
Put_Line ( Please wait... );
Delay 3.0;
abort Task1;
Put_Line ( Task Task1 Aborted! );
end main;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-12 08:56 ---
0.9 in Fortran is 0.9f in C.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-07-12 09:25
---
Subject: Bug 28187
Author: rguenth
Date: Wed Jul 12 09:25:40 2006
New Revision: 115366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115366
Log:
2006-07-12 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-07-12 09:26
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
/usr/bin/gcc-3.4 -mmmx -msse -Winline --param inline-unit-growth=1
--param large-function-growth=1 -O3 -mtune=pentium4 -march=i686
-fomit-frame-pointer -floop-optimize2 -funroll-loops -ftracer -MT
libfbmmx_la-fbmmx.lo -MD -MP -MF .deps/libfbmmx_la-fbmmx.Tpo -c fbmmx.i -fPIC
-DPIC -o
--- Comment #1 from rainer-gccbugzilla at 7val dot com 2006-07-12 10:09
---
Created an attachment (id=11864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11864action=view)
preprocessed source file that causes the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-07-12 10:53 ---
Works for me with 3.4.0 to 3.4.6.
/space/rguenther/install/gcc-3.4.0/bin/gcc -mmmx -msse -Winline --param
inline-unit-growth=1 --param large-function-growth=1 -O3
-mtune=pentium4 -march=i686
--- Comment #7 from mnylund at emtrion dot de 2006-07-12 11:17 ---
Here's a workaround for the bug (gcc-3.4.4 qt-3.3.6):
- build with -O1 is ok
- build with -O2 leads to ICE
- build with -O2 -fno-schedule-insns2 is OK
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22250
--- Comment #3 from rainer-gccbugzilla at 7val dot com 2006-07-12 11:26
---
Yes, it fails with the preprocessed file that I attached. I also tried a
apt-get install --reinstall gcc-3.4 gcc-3.4-base to make sure that the gcc
installation isn't corrupt. Omitting -ftracer stops the error
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-07-12
11:54 ---
Tobias,
I am so glad to see that somebody is passing components of derived type arrays;
I bust myself to make that work! Anyway, I partially broke it with a recent
patch - sorry.
Reduced testcase:
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-12 12:25 ---
please report the output from the compiler if you specify -v as additional
argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28356
--- Comment #26 from multix at gmail dot com 2006-07-12 12:27 ---
I have 6.5.17 too.
I would propose to either improve the autodetect features or point out that
flag in the atchitecture specific page so that other users won't ask.
I'm available for testing on my box. I Think I have
--- Comment #27 from pcarlini at suse dot de 2006-07-12 12:29 ---
(In reply to comment #26)
I have 6.5.17 too.
... or point out that
flag in the atchitecture specific page so that other users won't ask.
That makes sense. Can you prepare a patch? Thanks in advance.
--
--- Comment #4 from multix at gmail dot com 2006-07-12 12:32 ---
I already configured using --with-gnu-as but not with --with-gnu-ld.
Possibly the two options need to be specified together, that is the gnu
assembler needs the gnu linker?
--
--- Comment #5 from rainer-gccbugzilla at 7val dot com 2006-07-12 12:44
---
debianSarge tiffany:/tmp$ cat ./x
/usr/bin/gcc-3.4 -v -mmmx -msse -Winline --param inline-unit-growth=1
--param large-function-growth=1 -O3 -mtune=pentium4 -march=i686
-fomit-frame-pointer
i.e. the attached test case with
gcc (GCC) 4.1.1 20060629 (Red Hat 4.1.1-6) and
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
gives...
New-Style Correct: const 0xbfdb3d2c, unconst 0xbfdb3d2c
Old-Style Correct: const 0xbfdb3d2c, unconst 0xbfdb3d2c
Old-Style Incorrect: const 0xbfdb3d2c,
--- Comment #1 from caolanm at redhat dot com 2006-07-12 12:51 ---
Created an attachment (id=11865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11865action=view)
demo source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28357
Full version string:
g++-4.1 (GCC) 4.1.2 20060708 (prerelease) (Ubuntu 4.1.1-8ubuntu1)
Same problem exists in Debian 'etch'.
The error message after the location of the crash is:
/usr/include/boost/spirit/core/composite/actions.hpp:106: internal compiler
error: in expand_expr_addr_expr_1, at
--- Comment #2 from jakub at gcc dot gnu dot org 2006-07-12 13:02 ---
Works with 3.4.6 and 3.2.3, reproduced on mainline.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from peter dot soetens at fmtc dot be 2006-07-12 13:05
---
Created an attachment (id=11866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11866action=view)
Compressed (bzip2) preprocessed file
After unzipping, compile this file using:
$ g++-4.1 -c attachment.ii
--- Comment #5 from mrs at gcc dot gnu dot org 2006-07-12 13:12 ---
Subject: Bug 28280
Author: mrs
Date: Wed Jul 12 13:12:08 2006
New Revision: 115369
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115369
Log:
PR c/28280
* c-parser.c (c_parser_typeof_specifier):
--- Comment #6 from mrs at apple dot com 2006-07-12 13:13 ---
I have checked in a fix for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-12 13:36 ---
I cannot reproduce this with any FSF release of the 3.4 series. This must be a
Debian specific bug - please report with them.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from bryce at gcc dot gnu dot org 2006-07-12 13:56 ---
Subject: Bug 28352
Author: bryce
Date: Wed Jul 12 13:56:25 2006
New Revision: 115370
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115370
Log:
2006-07-12 Bryce McKinlay [EMAIL PROTECTED]
PR
--- Comment #4 from mckinlay at redhat dot com 2006-07-12 13:59 ---
I've committed a patch which fixes the off by one error seen with
ecj-produced bytecode. The missing line number issue is a different bug. It
seems that gcj -C simply does not generate any debug info for the snafu
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-07-12 14:08
---
Even shorter (valid) testcase:
=
templatetypename struct A
{
static const bool i = true;
templatebool = i struct B {};
B b;
};
--- Comment #5 from patchapp at dberlin dot org 2006-07-12 14:15 ---
Subject: Bug number PR other/28251
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00517.html
--
--- Comment #9 from paul dot richard dot thomas at cea dot fr 2006-07-12
14:20 ---
Created an attachment (id=11867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11867action=view)
For discussion, perusal and testing: a beta-release of the TR15581 patch
This patch represents some
--- Comment #10 from paul dot richard dot thomas at cea dot fr 2006-07-12
14:23 ---
Bother! Forget the last test - it is an old, incorrect version. I will post
the right one tonight.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
fastjar contains the following security problem:
When a JAR archive is extracted with filenames with ../ inside, it can
extract files outside of the current directory (a so called directory
traversal).
Unconspicious users unpacking such files could overwrite their own files,
or even system files
--- Comment #1 from marcus at jet dot franken dot de 2006-07-12 14:50
---
Created an attachment (id=11868)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11868action=view)
cups.jar
sample file with ../ paths inside.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #2 from marcus at jet dot franken dot de 2006-07-12 14:54
---
Created an attachment (id=11869)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11869action=view)
fix.patch
i would propose this patch to fix this problem.
--
--- Comment #12 from reichelt at gcc dot gnu dot org 2006-07-12 15:03
---
Reduced (from PR 28219) testcase:
=
templateint struct A
{
enum { a, b = a };
void foo(Ab);
};
=
bug.h:4: internal compiler error: tree check:
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-12 15:08 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:11
---
Subject: Bug 28163
Author: fxcoudert
Date: Wed Jul 12 15:11:11 2006
New Revision: 115372
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115372
Log:
PR fortran/28163
* trans-expr.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-12 15:14 ---
Created an attachment (id=11870)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11870action=view)
different fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:17
---
Fixed on 4.2
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:19
---
Confirmed, then, if there's a patch already :)
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-12 15:19 ---
I have applied the 2nd fix to the upstream (savannah) fastjar CVS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-07-12 15:21
---
Confirmed, and not target-specific. I'll look into it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-07-12 15:45
---
Fails since GCC 4.1.0 for me.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
I get an undefined reference error with a recent gcc 4.2 when linking to a
class whose header contains an additional namespace that is references from
that class. This is a very recent error. It started to occur between 20060626
and 20060709.
(sid)1690:[EMAIL PROTECTED]: ~/src/t] make
rm -f *.o
--- Comment #28 from paolo at gcc dot gnu dot org 2006-07-12 16:03 ---
Subject: Bug 27878
Author: paolo
Date: Wed Jul 12 16:02:46 2006
New Revision: 115374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115374
Log:
2006-07-12 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from drow at gcc dot gnu dot org 2006-07-12 16:08 ---
(In reply to comment #3)
Is it OK to add (set_attr can_delay no) for tls_get_tp_mode
definition?
I think so, with suitable comment. Some future MIPS architecture may provide a
register for this, in which case the
--- Comment #29 from paolo at gcc dot gnu dot org 2006-07-12 16:10 ---
Subject: Bug 27878
Author: paolo
Date: Wed Jul 12 16:10:12 2006
New Revision: 115375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115375
Log:
2006-07-12 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #30 from ro at techfak dot uni-bielefeld dot de 2006-07-12
16:11 ---
Subject: Re: GCC 4.1.1 build fails on mips-sgi-irix6.5 (libstdc++)/GCC 4.1.0
worked.
multix at gmail dot com writes:
I'm available for testing on my box. I Think I have access to a 6.5.4 box
too...
--- Comment #31 from pcarlini at suse dot de 2006-07-12 16:11 ---
Doc patch committed to mainline and 4_1-branch.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-12 16:14
---
With little modifications one can trigger all sorts of behaviour:
ICEs in different places and accepts-invalid bugs.
*** This bug has been marked as a duplicate of 24791 ***
--
reichelt at gcc dot gnu dot
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-07-12 16:14
---
*** Bug 28316 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-07-12 16:39 ---
FX
I couldn't do the confirmation from the lab!
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28353
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-07-12 16:39
---
Here's a testcase that crashes even at -O0 since GCC 4.1.0:
===
templateint struct A
{
A() {}
};
A0 a;
template A0::A() {}
===
As Wolfgang already mentioned:
if you do something like this:
char *buffer;
int i;
buffer = (char *) malloc (sizeof (struct something) * 1024);
for (i=0; i 1024;i++)
memcpy (buffer + i * sizeof (struct something),i;sizeof (int));
then when i == 255 there is no data stored in buffer. I mean i can read out the
correct
--- Comment #1 from tbm at cyrius dot com 2006-07-12 16:51 ---
This was caused by:
r115086 | jason | 2006-06-30 03:15:56 +0200 (Fri, 30 Jun 2006) | 58 lines
--
tbm at cyrius dot com changed:
What|Removed |Added
1 - 100 of 159 matches
Mail list logo
