--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 06:19 ---
First this is a very bogus warning.
Second this is caused by SRA and BIT_FIELD_REF:
D.1509.x = 0;
D.1509.y = 0;
s.p = D.1509;
D.1511_10 = BIT_FIELD_REF ;
D.1512_12 = D.1511_10 != 0;
s.i = D.1512_12;
D.1
--- Comment #8 from jason at redhat dot com 2005-11-18 06:15 ---
Subject: Re: visibility attributes on namespace scope
bkoz at gcc dot gnu dot org wrote:
> What do you mean, "less or equal visibility to their enclosing scope?"
Where default > protected > hidden > internal, if a class
--- Comment #13 from amodra at bigpond dot net dot au 2005-11-18 06:05
---
Fixed
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Status|NEW
--- Comment #12 from amodra at gcc dot gnu dot org 2005-11-18 05:55 ---
Subject: Bug 24779
Author: amodra
Date: Fri Nov 18 05:55:16 2005
New Revision: 107160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107160
Log:
PR target/24779
Backport 2005-03-13 David Ede
Consider this code:
struct p {
short x, y;
};
struct s {
int i;
struct p p;
};
struct s f()
{
struct s s;
s.p = (struct p){};
s.i = (s.p.x || s.p.y);
return s;
}
When compiled with gcc -Wall -O -c, it reports:
t.c: In function 'f':
t.c:14:
--- Comment #3 from rth at gcc dot gnu dot org 2005-11-18 05:42 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rth at gcc dot gnu dot org 2005-11-18 05:39 ---
Subject: Bug 24845
Author: rth
Date: Fri Nov 18 05:39:12 2005
New Revision: 107159
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107159
Log:
PR 24845
gcc/
* gcc.c (link_gomp_spec): New.
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 05:34 ---
Actually it has nothing to do with makefile missing dependencies.
The problem comes in for include directories for gfortran changed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 04:56 ---
Confirmed, a regression from 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 04:01 ---
Confirmed. Testing the other branches now for regressions.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
(in mainline) compile the below with -O. A patch follows which I'm fairly
sure is right, but I will not be able to run a test cycle until Nov 30. I'll
do it then if nobody else has.
$ld/gcc/gccs.fsf.obj/gcc/xgcc -B $ld/gcc/gccs.fsf.obj/gcc/ -O 4347034.c
4347034.c: In function 'main':
4347034.c:
--- Comment #4 from danglin at gcc dot gnu dot org 2005-11-18 03:22 ---
Subject: Bug 24348
Author: danglin
Date: Fri Nov 18 03:22:18 2005
New Revision: 107157
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107157
Log:
PR target/24348
* config.gcc (hppa*-*-hpux*):
Joel C. Kampfer wrote:
perl /usr/home/joelk/ftp/gcc-4.0.2/fastjar/../contrib/texi2pod.pl -D fastjar
fastjar.pod
So it is perl that is failing? There is probably not much we can do
about that. What perl version do you have? If it is an old one, you
should consider upgrading perl. An alter
--- Comment #1 from tkho at ucla dot edu 2005-11-18 02:35 ---
Created an attachment (id=10273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10273&action=view)
shift/mask long long testcase
Here is a rough instruction-count comparison for f() compiled at -O2,
march=pentiumpro betw
Qianli Zhang wrote:
> Sorry to bother you. Recently I met with a problem in strtof, a sample
> program is like:
Compile with -Wall, and you get a warning saying that the return type of
strtof is unknown, and the program fails.
Compile with -Wall -std=c99 and you get no warning and the progra
shift/mask operations on long long like (x << 8) | ((y >> 48) & 0xffull) could
be further optimized for x86. Please see comments in the attached test case
(posted earlier in PR 17886).
--
Summary: long long shift/mask operations should be better
optimized
--- Comment #5 from hp at gcc dot gnu dot org 2005-11-18 02:03 ---
I have a patch under test. However, with and without that patch, *and* with
and without r106804 (only with-with and without-without combinations tested),
I still get with r107118 when building libgfortran:
/home/hp/comb
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-18 01:31
---
Subject: Re: New: Trivial static const objects should go to .rodata
"msharov at hotmail dot com" <[EMAIL PROTECTED]> writes:
| With the object being initialized at runtime as if it mattered. Because the
| v
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-18 00:57 ---
Confirmed, very related to PR 4131.
First this is not a trivial static const object as there is no trivial
constructure here.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-18 00:55
---
*** Bug 22575 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-18 00:55 ---
This is a dup of bug 4131.
*** This bug has been marked as a duplicate of 4131 ***
*** This bug has been marked as a duplicate of 4131 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-18 00:51 ---
Reopening this bug since it is the correct one to keep open.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2005-11-18 00:47
---
This is near stuff I am working on so I will work it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-18 00:46 ---
There is another PR about this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24928
If a class has a trivial constructor that can be completely inlined and
consists of simply initializing member variables, then static const instances
of this class can be initialized at compile time and placed into .rodata. This
would be the same behaviour that C has for static const structs and ar
--- Comment #7 from bkoz at gcc dot gnu dot org 2005-11-17 23:53 ---
What do you mean, "less or equal visibility to their enclosing scope?"
My meta-goal is to try and give namespace and class scope visibilty attributes
similar meanings. Do you think this is worthwhile, possible, and do
--- Comment #14 from bkoz at gcc dot gnu dot org 2005-11-17 23:41 ---
> I think nesting _6 within std makes sense in the abstract as well, as it
> is properly part of the standard library space, not a separate entity.
Sounds sane to me.
> The debug mode headers will need to be modifie
--- Comment #11 from amodra at bigpond dot net dot au 2005-11-17 23:38
---
Re comment #8, regression tests passed on powerpc64-linux and powerpc-linux,
with just one regression for ppc64, gcc.c-torture/execute/20020720-1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
--- Comment #10 from amodra at bigpond dot net dot au 2005-11-17 23:13
---
Yes, I must have been looking at the wrong set of dumps. On mainline, the
problem of sched1 not seeing a potential mem access via r2 for a fp constant
load only happens now if you compile with -funsafe-math-opti
--- Comment #4 from hp at gcc dot gnu dot org 2005-11-17 22:59 ---
Reload is middle-end, not rtl-optimization.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2005-11-17 22:55 ---
Why do the examples want to have a namespace (or class) with default visibility
nested within one with hidden visibility? The other way around makes sense,
but this seems nonsensical. It seems to me that nested scope
--- Comment #5 from andreast at gcc dot gnu dot org 2005-11-17 22:54
---
would this snippet be ok?
Index: ltcf-c.sh
===
--- ltcf-c.sh (revision 107140)
+++ ltcf-c.sh (working copy)
@@ -419,7 +419,7 @@
hardcode_di
--- Comment #1 from amodra at bigpond dot net dot au 2005-11-17 22:42
---
My bootstrap failed last night in the same place. It was make -j1 too.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #13 from jason at redhat dot com 2005-11-17 22:39 ---
Subject: Re: versioning weak symbols in libstdc++
I think nesting _6 within std makes sense in the abstract as well, as it
is properly part of the standard library space, not a separate entity.
The debug mode headers w
--- Comment #4 from geoffk at gcc dot gnu dot org 2005-11-17 22:35 ---
It's certainly wrong to be using -all-load unless you're also using -r.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from bkoz at gcc dot gnu dot org 2005-11-17 22:15 ---
Here you go Jason. Actually, it looks like I have a complete archive of most
parts of this discussion, the related material, code samples, issues, etc. If
you would like, I will tar it up and put it in this pr. Or, if
Makefile in libgfortran has
selected_int_kind.lo: intrinsics/selected_int_kind.f90
$(LIBTOOL) --mode=compile $(FC) $(AM_FCFLAGS) $(FCFLAGS) -c -o
selected_int_kind.lo `test -f 'intrinsics/selected_int_kind.f90' || echo
'$(srcdir)/'`intrinsics/selected_int_kind.f90
But it doesn't depend on
--- Comment #11 from bkoz at gcc dot gnu dot org 2005-11-17 21:54 ---
Created an attachment (id=10272)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10272&action=view)
Outline for Kona presentation
I cannot believe I found this stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #10 from bkoz at gcc dot gnu dot org 2005-11-17 21:53 ---
Created an attachment (id=10271)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10271&action=view)
Kona paper, as revised but not in post-Kona mailing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #8 from vsxo at hotmail dot com 2005-11-17 21:52 ---
Of course, G4 and G5 are marketing names for *FreeScale* 74xx and IBM ppc970xx
cpus respectively. These are listed under the values that can be given to -mcpu
et al, but I can't find them in the list of cpus given under -mp
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 21:48 ---
Confirmed, I should note that anonymous structs are extensions.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-17 21:43 ---
(In reply to comment #6)
> The documentation is vague in that the G4 nor the G5 are mentioned among the
> Motorola and IBM processors listed in the description of these arguments.
That is because G4 and G5 are marke
When declaring an anonymous union inside a class,
any variable from an anonymous struct contained in the union is accessible
like a public member, regardless of the access level of the enclosing union.
Bug does only occur when struct and union are BOTH anonymous.
The following sample code, which
--- Comment #11 from andreast at gcc dot gnu dot org 2005-11-17 21:30
---
Adding -I. to FC in the Makefile of libgfortran makes my compile happy again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20811
--- Comment #6 from vsxo at hotmail dot com 2005-11-17 21:26 ---
Sure, sure. But -mcpu=970 -mno-altivec makes sense: it just causes the SIMD
unit to be unused. -mcpu=G3 -maltivec does not make sense. I don't agree that
it should be possible to override the explicitly selected architectur
--- Comment #8 from aldyh at gcc dot gnu dot org 2005-11-17 21:15 ---
See previous comment.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #7 from aldyh at gcc dot gnu dot org 2005-11-17 21:12 ---
We used to allow this, but have now made the warning stricter. This behavior
was done deliberately. See:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html
As is explained in the thread, you can modify the mac
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-17 21:10 ---
That was from:
http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options
And:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-17 21:08 ---
And this is documented already:
If you wish to set an individual option to a particular value, you may specify
it after the -mcpu option, like `-mcpu=970 -mno-altivec'.
--
pinskia at gcc dot gnu dot org changed
--- Comment #3 from vsxo at hotmail dot com 2005-11-17 21:06 ---
> This is not an undocemented behavior.
The documentation did not change since 4.0.0, yet the behaviour did. I
wonder if the previous behaviour also was not undocumented?
> First it is documented that later options sho
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2005-11-17 21:05
---
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01311.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-11-17 21:03
---
Subject: Bug 22333
Author: ebotcazou
Date: Thu Nov 17 21:03:50 2005
New Revision: 107134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107134
Log:
PR ada/22333
* trans.c (gnat_gimplify_e
--- Comment #2 from rearnsha at gcc dot gnu dot org 2005-11-17 20:55
---
The compiler is trying to reload the Maverick register into a VFP register.
But there are no VFP registers on the ep9312!
Testing a fix.
--
rearnsha at gcc dot gnu dot org changed:
What|Remove
--- Comment #10 from andreast at gcc dot gnu dot org 2005-11-17 20:51
---
After this patch libgfortran fails to build on darwin-ppc.
it does not find the selected_int_kind.inc in the libgfortran objdir when
building libgfortran. (selected_int_kind.f90 compilation)
Reverting the patch
--- Comment #9 from gdr at integrable-solutions dot net 2005-11-17 20:46
---
Subject: Re: versioning weak symbols in libstdc++
"jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This code, like the testcase for c++/16021, works fine if the implementation
| namespace is nest
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-17 20:31 ---
Confirmed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugs
--- Comment #3 from ray at ultramarine dot com 2005-11-17 20:28 ---
Subject: Re: GFORTRAN input and carriage returns
On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13
> ---
> First can you t
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
The C++ front end makes pedwarns into errors by default (unless -fpermissive).
However, this only applies to front end pedwarns and not to preprocessor ones,
as the preprocessor has its own pedantic_errors setting which is changed by an
explicit -pedantic-errors option but doesn't default to 1 for
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 ---
First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos
file?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:11 ---
*** Bug 24918 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:11 ---
*** This bug has been marked as a duplicate of 24919 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:10 ---
Actually this has already been fixed for 4.0.3 at least:
open ios0
read ios3
buf 1 2 -77 -77
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:06 ---
*** Bug 24921 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:06 ---
*** This bug has been marked as a duplicate of 24923 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 20:05 ---
Count is already in ecx so why should GCC move again count to the ecx register.
Your inline-asm does not tell GCC that ecx is touched which is why GCC is
removing the move.
--
pinskia at gcc dot gnu dot org chan
The following has a problem
integer buf(200),ios
buf(1) = -77
buf(2) = -77
open(10,file='cow',access='DIRECT',recl=100,iostat=ios)
print *,' open ios ',ios
read(10,rec=1,iostat=ios) buf
print *,' read ios ',ios
print *,' buf 1 2 ',buf(1),buf(2)
I found that when I compile this code with -O2:
#include
#define bit_swap(v, count, res) \
do {\
asm volatile ( \
"1: sarb %1\n" \
" rclb %0\n"
--
Summary: iostat on read
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ray at ultramarine dot
When reading a "dos" file, gfortran returns two records for each line
in the file: the real record and a null one. In other words it is treating
the carriage return as a newline instead of the pair carriage return/newline
as the newline.
Here is an example:
integer ios
character buf*(
--
Summary: GFORTRAN input and carriage returns
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
Compilation of the following program TEST.f fails:
PROGRAM HEX_TEST
INTEGER(4) MASK
MASK = 'c0'X
END
~ $ gfortran -c TEST.f
In file TEST.f:5
MASK = 'c0'X
1
Error: Unclassifiable statement at (1)
whereas the following code compiles correctly:
PROGRAM HEX_TEST
INTEGER(4) MASK
MASK
--- Comment #8 from jason at gcc dot gnu dot org 2005-11-17 19:01 ---
The nesting also means you don't need the reciprocal using-directive which you
added to avoid the problem from 16021.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
--- Comment #7 from jason at gcc dot gnu dot org 2005-11-17 18:57 ---
Here's a reduced testcase:
namespace N { }
namespace std
{
using namespace N __attribute__ ((strong));
}
namespace N
{
using namespace std;
template
struct A
{
void f();
};
}
namespace std
{
template
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-17 18:34 ---
(In reply to comment #6)
> (In reply to comment #5)
> > the point of the bug submitter was to have them documented in cpp(1).
> But they are documented in the info page:
I should point out the web page is generated
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:34
---
(In reply to comment #5)
> As far as OpenBSD is concerned, this bug is not important: neither 3.7,
> nor 3.8, nor -current are affected.
Well, if nobody is interested in this, closing accordingly.
--
fxcouder
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-17 18:33 ---
(In reply to comment #5)
> the point of the bug submitter was to have them documented in cpp(1).
But they are documented in the info page:
Predefined Macros
* Standard Predefined Macros::
* Common Predefined Macros
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:31
---
*** Bug 21995 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-17 18:31
---
This bug is a duplicate of PR 24384, which is fixed on 4.1 but not on 4.1. See
comment #3 in PR 24384 for details.
*** This bug has been marked as a duplicate of 24384 ***
--
fxcoudert at gcc dot gnu dot org
--- Comment #5 from debian-gcc at lists dot debian dot org 2005-11-17
18:26 ---
(In reply to comment #2)
> They are documented:
> http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
the point of the bug submitter was to have them documented in cpp(1).
Matthias
--
ht
--- Comment #13 from jason at gcc dot gnu dot org 2005-11-17 18:14 ---
It also works if NS is nested within std, as in the example in the GCC
documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16021
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-17 18:05 ---
And have been since 3.1:
http://gcc.gnu.org/onlinedocs/gcc-3.1/cpp/Common-Predefined-Macros.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-17 18:04 ---
Since they are documented, I am going to close this as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 18:03 ---
They are documented:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24916
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 18:02 ---
The C front-end defines these.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from joel at gcc dot gnu dot org 2005-11-17 17:59 ---
Created an attachment (id=10265)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10265&action=view)
Preprocessed file that produces ICE
This is the command line which produces the ICE. I changed -c to -E to produc
[forwarded from http://bugs.debian.org/339495]
you can see[1] that cpp supports -O, -O[1-9], -Os options, and these options
are meaningful (defining macros). but this is not documented in man page[2] and
info[3].
[1]
$ cpp -dM /dev/null | grep OPT
$ cpp -dM -O /dev/null | grep OPT
#define __OPTIM
--- Comment #4 from mckinlay at redhat dot com 2005-11-17 17:38 ---
I'm curious whether other Java implementations do this - my guess is no, since
some of these locks are mandated by the spec (during class initialization, for
example), so it seems that denial-of-service attacks would alw
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24915
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|major
Component|c |target
--- Comment #12 from dwarak dot rajagopal at amd dot com 2005-11-17 17:30
---
(In reply to comment #9)
> (In reply to comment #8)
> > I got the same ICE with one of the SPEC2006 candidate benchmarks on
> > x86_64-linux-gnu.
>
> Was this before or after my fix for PR 18157 went in? Bec
template
struct is_int
{
static const bool value = false;
};
template <>
struct is_int
{
static const bool value = true;
};
template
struct enable_if
{};
template
struct enable_if
{ typedef T type; };
class test
{
public:
template
typename enable_if::value>::type func(T x)
{}
--- Comment #12 from jason at gcc dot gnu dot org 2005-11-17 17:18 ---
The testcase compiles fine if you add
using namespace std;
within namespace NS. I'm not sure whether or not this should be implied by the
strong using.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16021
--- Comment #1 from nekkar at libero dot it 2005-11-17 17:12 ---
Created an attachment (id=10264)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10264&action=view)
Preprocessed source
Just to be clear, the gcc-4_0-branch was updated today, after the last fix to
bug http://gcc.gnu.o
model: posix
gcc version 4.0.3 20051117 (prerelease)
/tmp/build/gcc/cc1 -quiet -v -I. -I. -I../../gcc-4_0-branch/gcc
-I../../gcc-4_0-branch/gcc/. -I../../gcc-4_0-branch/gcc/../include
-I../../gcc-4_0-branch/gcc/../libcpp/include -iprefix
/tmp/build/gcc/../lib/gcc/armv4l-unknown-linux-gnu/4.0.3/ -isystem
/
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 16:56 ---
This is not an undocemented behavior. First it is documented that later
options should override the earlier ones. Second this is an expected change.
Third you should have reported this to Apple first since you are
The G4 PowerPC processor does not support the (full) GPOPT instruction
set that can be activated with -mpowerpc-gpopt. The documentation is not
explicitly clear on which (current) processors support this instruction set -
or any of the other additional/extended/optional sets like those se
1 - 100 of 137 matches
Mail list logo
