--- Comment #2 from jb at gcc dot gnu dot org 2005-11-17 08:26 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01271.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24909
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-11-17 09:40
---
The compiler already crashes with "g++ -O -finline-functions -g",
i.e. without explicitly specifying -fno-unit-at-a-time.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jb at gcc dot gnu dot org 2005-11-17 10:00 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01277.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24862
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-17 10:02
---
Here's a shorter testcase without templates:
==
void foo()
{
#pragma omp parallel
{
int i, N;
#pragma omp for schedule (dynamic)
for (i=0; ihttp://gcc.gn
--- Comment #3 from saurabh dot verma at codito dot com 2005-11-17 10:05
---
Adding myself to CC list, as the offending patch was given by me
--
saurabh dot verma at codito dot com changed:
What|Removed |Added
-
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-17 10:39
---
Confirmed.
The following code snippet causes an ICE since 2.95.3
with the exception of 4.0.0 - 4.0.2:
==
template struct A
{
static int i;
A() { ++i; }
};
template int A<0
--- Comment #6 from reichelt at gcc dot gnu dot org 2005-11-17 11:08
---
The following testcase crashes since GCC 2.95.3 except 3.1 and 3.2:
===
template struct A
{
A() : T(0) {}
};
A a;
===
The error message with GCC 3.2 wa
--- Comment #2 from guerby at gcc dot gnu dot org 2005-11-17 11:13 ---
Subject: Bug 24857
Author: guerby
Date: Thu Nov 17 11:13:18 2005
New Revision: 107116
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107116
Log:
2005-11-17 Laurent GUERBY <[EMAIL PROTECTED]>
PR ada
--- Comment #14 from reichelt at gcc dot gnu dot org 2005-11-17 11:24
---
This is not really a regression, since evn with 2.95.3 we get an ICE
(with --enable-checking):
bug.cc: In function `int main()':
bug.cc:4: converting to `void' from `int'
bug.cc:4: void value not ignored as it ou
--- Comment #18 from rguenth at gcc dot gnu dot org 2005-11-17 11:35
---
Subject: Bug 24851
Author: rguenth
Date: Thu Nov 17 11:35:00 2005
New Revision: 107117
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107117
Log:
2005-11-16 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #19 from rguenth at gcc dot gnu dot org 2005-11-17 11:36
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-11-17 11:42 ---
So I guess being able to hunt it confirms it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-11-17 11:47 ---
Btw., this also happens on armv4l compiling NX:
gcc -c -O3 -fsigned-char -I. -I../../exports/include/freetype2
-I../../extras/freetype2/src-I../../extras/freetype2/src/base
-I../../extras/freetype
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-17 11:59
---
Here's a sightly simpler testcase.
If I remove the copy-ctor from A, I get the failure from PR24606.
=
template void foo(F f)
{
f();
}
struct A
{
A();
A(const A
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-11-17 12:04
---
I think this is a duplicate of PR 24602.
The only difference is the missing copy-ctor here.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rakdver at gcc dot gnu dot org 2005-11-17 12:33 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #22 from thebohemian at gmx dot net 2005-11-17 12:39 ---
Created an attachment (id=10262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10262&action=view)
lazy linking - part 2
This is the same patch as above but corrects the behavior in case that the
static field of a
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-11-17 12:45
---
It looks like the simplify-rtx patch is not really the cause of the problem,
it simply exposes a pre-existing bug in combine and/or flow.
Before combine, we have a situation that looks like (simplified):
insn 8
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:47
---
Subject: Bug 24892
Author: fxcoudert
Date: Thu Nov 17 12:46:57 2005
New Revision: 107119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107119
Log:
PR fortran/24892
* io/io.h (unit_access)
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2005-11-17 12:51
---
Subject: Bug 20811
Author: fxcoudert
Date: Thu Nov 17 12:51:41 2005
New Revision: 107120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107120
Log:
PR fortran/20811
* scanner.c (gfc_open_i
--- Comment #34 from rakdver at gcc dot gnu dot org 2005-11-17 13:35
---
It behaves somewhat erratically on SPEC2000 (it increases the overall score,
but there are some significant regressions). And, it also causes us to produce
worse code for this testcase at the moment, due to a miss
--- Comment #23 from aph at gcc dot gnu dot org 2005-11-17 13:46 ---
mm, I was wrong about static fields.
The problem is that a JV_CONSTANT_Fieldref constant pool entry points to a
JV_CONSTANT_Class, and at the present time we attempt to resolve that
JV_CONSTANT_Class reference at link
--- Comment #8 from pcarlini at suse dot de 2005-11-17 13:50 ---
I have got additional evidence that __sync_fetch_and_add does not work
correctly. If, for example, in this code, stressed in the testcase
12658_thread-1.cc, and using atomic operations:
const locale&
locale::operator
--- Comment #8 from mark at gcc dot gnu dot org 2005-11-17 14:03 ---
Subject: Bug 23183
Author: mark
Date: Thu Nov 17 14:03:22 2005
New Revision: 107121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107121
Log:
2005-11-17 Mark Wielaard <[EMAIL PROTECTED]>
* java/text/
--- Comment #3 from andreast at gcc dot gnu dot org 2005-11-17 14:37
---
Unfortunately it does not werk :(
I found this message in the libtool archive:
http://lists.gnu.org/archive/html/libtool-patches/2004-08/msg2.html
Currently we have this 'whole_archive_flag_spec='-all_load $
--- Comment #35 from rakdver at gcc dot gnu dot org 2005-11-17 15:09
---
Created an attachment (id=10263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10263&action=view)
Patch
After some playing with fold, I arrived to the following patch, that almost
works. With the patch, the
--- Comment #2 from charlet at gcc dot gnu dot org 2005-11-17 15:15 ---
Works fine on mainline as of today.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:16 ---
Not a frontend bug. P3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
C
--- Comment #3 from charlet at gcc dot gnu dot org 2005-11-17 15:17 ---
Closing.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #7 from rguenth at gcc dot gnu dot org 2005-11-17 15:17 ---
Not a fortran frontend bug, but IVOPTs one. P3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dje at watson dot ibm dot com 2005-11-17 15:17 ---
Subject: Re: [4.0 Regression] Python miscompilation - TOC reload
"Reliably" is the wrong word. The patch will fix the problem reliably for
the default case; it will not fix it for a particular set of options.
The
--- Comment #1 from charlet at gcc dot gnu dot org 2005-11-17 15:23 ---
The minimum requirement is not out of date.
There has indeed always been a different requirement for cross compilers
where you need to first have a native compiler using the exact same
version, and that should indee
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-17 15:23
---
Giovanni's example now compiles on mainline and the 4.0 branch
due to Mark's patch for PR 23789:
==
template struct A {};
template void foo(A) {}
void bar()
{
m68k-elf build fails building libiberty/regex.c.
Reduced testcase below:
void foo(void);
void
bar (unsigned char *p)
{
int j;
j = *(p) ;
j += ((signed char) (*p) ) << 8;
if (j)
foo();
}
Compiled with m68-elf-gcc -O2 gives
test.c:10: error: insn does not satisfy its constraints:
(ins
--- Comment #1 from joel at gcc dot gnu dot org 2005-11-17 15:36 ---
Also fails building m68k-rtems4.7.
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-17 16:26 ---
Confirmed with r107118.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24912
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-17 16:31 ---
I think I understand why these fail. The issue comes down to
PCC_BITFIELD_TYPE_MATTERS and ms style bitfields, we don't emulate them yet in
libobjc with the new config directory should help fix this.
--
pinskia
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
--- 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
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 #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
--- 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
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 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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|major
Component|c |target
--
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
--- 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
[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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
--
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
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: 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
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"
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)
--- 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
--- 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:06 ---
*** Bug 24921 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
--- 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:11 ---
*** This bug has been marked as a duplicate of 24919 ***
--
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 #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:16 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
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:26 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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.
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 #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
1 - 100 of 137 matches
Mail list logo
