Access to private types in a class from another instantiated template class is
not getting the expected "type is private" error from gcc compiler.
$gcc -c -v inp4.cpp
Using built-in specs.
Target: hppa1.1-hp-hpux11.11
Configured with: /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/configure
--host=hppa1.1-hp-hpu
--- Comment #2 from simon at pushface dot org 2009-04-29 06:00 ---
(In reply to comment #1)
> The Ada make files don't use GNU libtool to build the shared libraries.
GNAT Pro 6.2.1 on Darwin uses -rpath/@rpath, presumably AdaCore will fold this
in at a future date.
--
http://gcc.gn
--- Comment #2 from bkoz at gcc dot gnu dot org 2009-04-29 05:12 ---
Subject: Bug 39868
Author: bkoz
Date: Wed Apr 29 05:12:00 2009
New Revision: 146923
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146923
Log:
2009-04-28 Benjamin Kosnik
PR libstdc++/39868
*
--- Comment #11 from bonzini at gnu dot org 2009-04-29 05:09 ---
Subject: Re: [4.5 regression] Revision 146874 breaks %z on
x87 insns
> The right thing is just to document them.
Agreed. But the question is whether to break %z and all but one
person reckon it would be actuall
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 04:35 ---
You need to link in the object file which also contains Preprocess. This bug
reporting system is not really for getting basic C++ help which you can get via
the newsgroup comp.lang.c++.
--
http://gcc.gnu.org/bu
--- Comment #2 from nilesh dot barange at gmail dot com 2009-04-29 04:24
---
(In reply to comment #1)
> This means you don't have any definition of Preprocess or any other of the
> functions mentioned above.
>
Following is my code...
#include
#include
#include
#include "domain.h"
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-04-29 04:06
---
Also, we need to consider taking F2003 9.10 at face value. Notice the use of
the word "attempt":
"An end-of-file condition occurs in the following cases:
(1) When an endfile record is encountered during the re
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-04-29 03:38
---
Notice what gfortran does with this modified from the original test case:
read(str,'(i1)') a
./a.out
0
Here we properly pad as expected. Now, the subtlety here is: should we provide
positioning in
--- Comment #3 from bergner at gcc dot gnu dot org 2009-04-29 02:14 ---
Michael, did you configure with --enable-decimal-float? I can never remember
whether that is enabled by default for powerpc64-linux or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39955
--- Comment #31 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-29
01:03 ---
Subject: Re: [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++
exported
> Also, libstdc++.so is definitely not the right home for __signbitl symbol, so
> we definitely shouldn't allow any n
--- Comment #2 from janis at gcc dot gnu dot org 2009-04-29 00:49 ---
The patch from Andreas doesn't make a difference for the struct-layout-1 tests.
Here are test results from earlier today:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg03009.html
There are lots of regressions i
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-29 00:43 ---
(In reply to comment #7)
> How does gimple handle
>
> typedef int foo __attribute__ ((aligned(1)));
The C/C++ front-end ignores the aligned here but does not mention that to you.
That is a different issue though,
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 00:42 ---
This code:
---
void *memcpy(void *dest, const void *src, __SIZE_TYPE__ n);
struct timeval {
long tv_sec;
};
typedef struct timeval packed __attribute__((aligned(1)));
struct outdata {
long align;
ch
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-29 00:33 ---
(In reply to comment #6)
> Andrew is right. There is no "known" alignment (or misalignment) as far
> as the gimple code is concerned, only the natural alignment:
>
> send_probe (struct outdata * outdata, struct tim
--- Comment #1 from matz at gcc dot gnu dot org 2009-04-29 00:23 ---
I tested powerpc64-linux a few minutes ago (r146824) and it doesn't show
these errors. I have Andreas Krebbels patch applied, though, and it might
really make a difference. See
http://gcc.gnu.org/ml/gcc-patches/2009-0
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from matz at gcc dot gnu dot org 2009-04-29 00:17 ---
Andrew is right. There is no "known" alignment (or misalignment) as far
as the gimple code is concerned, only the natural alignment:
send_probe (struct outdata * outdata, struct timeval * tp)
{
struct timeval * D.12
Most of the struct-layout-1 tests started failing on
powerpc64-unknown-linux-gnu with this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=146817
r146817 | matz | 2009-04-26 19:35:04 + (Sun, 26 Apr 2009)
Here's a minimized testcase that demonstrates the failure:
struct S301
{
_Decim
--- Comment #30 from jakub at gcc dot gnu dot org 2009-04-28 23:59 ---
Also, libstdc++.so is definitely not the right home for __signbitl symbol, so
we definitely shouldn't allow any newly linked program to use symbol from that
library. If __signbitl is ever needed (prove it), then it b
--- Comment #29 from jakub at gcc dot gnu dot org 2009-04-28 23:56 ---
The glibc macro AFAIK does:
# define signbit(x) \
(sizeof (x) == sizeof (float)\
? __signbitf (x)\
--- Comment #10 from jakub at gcc dot gnu dot org 2009-04-28 23:51 ---
I disagree, while the modifiers are perhaps undocumented, there is tons of
software in the wild that uses them heavily (I don't know about %z, but many
other modifiers) and breaking that all would be a terrible idea.
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-28 23:48 ---
(In reply to comment #3)
> Indeed. We likely fold the memcpy, but that should better preserve the
> known alignment.
What known alignment?
The alignment of the type is known to be the same alignment as long inside
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-28 23:43 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from anmol at freescale dot com 2009-04-28 23:43 ---
I verified with native GCC on target: powerpc-unknown-linux-gnu on:
gcc version 4.5.0 20090423 (experimental) [trunk revision 146648] (GCC)
gcc version 4.4.1 20090424 (prerelease) [gcc-4_4-branch revision 146746] (G
--- Comment #34 from pinskia at gcc dot gnu dot org 2009-04-28 23:43
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-28 23:42 ---
*** Bug 39691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-28 23:42 ---
*** This bug has been marked as a duplicate of 14482 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from hp at gcc dot gnu dot org 2009-04-28 23:41 ---
Thanks, kind-of verified; build now breaks at the "original" site again. :]
This could be the last comment on this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39938
--- Comment #21 from pinskia at gcc dot gnu dot org 2009-04-28 23:41
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 23:28 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 23:24 ---
The Ada make files don't use GNU libtool to build the shared libraries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39336
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 23:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-28 23:11 ---
/* This was a conditional expression but it triggered a bug in
Sun C 5.5. */
if (subtract_p)
temp = double_int_neg (b->data);
else
temp = b->data;
/* This was a conditional expression but it tr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|bootstrap |target
GCC ta
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-04-28 22:50
---
(In reply to comment #12)
> Maybe there's some significant difference between the behaviour of
> mips16_gp_pseudo_reg() and require_pic_register() which causes this, or maybe
> MIPS is broken too?
Hmm,
ARM uses em
--- Comment #12 from jules at gcc dot gnu dot org 2009-04-28 22:31 ---
FYI: the above patch seems to have caused ARM Linux (cross) builds to break,
e.g.:
/scratch/julian/arm-mainline/src/gcc-mainline/libgcc/../gcc/config/arm/unwind-arm.c:589:
internal compiler error: Segmentation fault
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-28 22:19 ---
Works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compon
--- Comment #4 from ubizjak at gmail dot com 2009-04-28 22:16 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-28 22:14 ---
Your libpthreads is doing something wrong.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39897
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39898
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 22:11 ---
This means you don't have any definition of Preprocess or any other of the
functions mentioned above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-28 22:04 ---
Indeed. We likely fold the memcpy, but that should better preserve the
known alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-28 21:59 ---
(In reply to comment #1)
> I think this testcase is invalid really:
> memcpy(&outdata->tv, tp, sizeof outdata->tv);
>
> tv is packed and taking the address of a packed entry is not really a valid
> thing.
>
I
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-28 21:54 ---
I think this testcase is invalid really:
memcpy(&outdata->tv, tp, sizeof outdata->tv);
tv is packed and taking the address of a packed entry is not really a valid
thing.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #10 from ubizjak at gmail dot com 2009-04-28 21:53 ---
Actually, alignment is from ix86_avoid_jump_misspredicts, where:
/* Look for all minimal intervals of instructions containing 4 jumps.
The intervals are bounded by START and INSN. NBYTES is the total
size of
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-28 21:52 ---
So that explains it, Use -Os or attribute cold if you want NOPs to be gone.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
On Linux/ia64, revision 146820 gave
Apr 26 20:44:03 gnu-12 kernel: pr26565.exe(23460): unaligned access to
0x6e31, ip=0x46d0
Apr 26 20:44:03 gnu-12 kernel: pr26565.exe(23472): unaligned access to
0x6e71, ip=0x46d0
Apr 26 20:44:03 gnu-12 kernel: pr265
--- Comment #8 from ubizjak at gmail dot com 2009-04-28 21:47 ---
>From config/i386/i386.c:
/* AMD Athlon works faster
when RET is not destination of conditional jump or directly preceded
by other jump instruction. We avoid the penalty by inserting NOP just
before the RET inst
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39932
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-04-28 21:42 ---
Ok, so one issue with the verifier is that it doesn't distinguish between
lvalues and rvalues when verifying verify_types_in_gimple_reference. I will
fix this.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from anmol at freescale dot com 2009-04-28 21:38 ---
I tried reproducing on trunk and on gcc-4_4-branch; GCC does not loop forever:
gcc version 4.5.0 20090423 (experimental) [trunk revision 146648] (GCC)
--
--- Comment #7 from rguenther at suse dot de 2009-04-28 21:35 ---
Subject: Re: [4.5 Regression] Revision 146831 caused
many test failures
On Tue, 28 Apr 2009, sje at cup dot hp dot com wrote:
> --- Comment #6 from sje at cup dot hp dot com 2009-04-28 21:25 ---
> ;; Function
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-04-28 21:32
---
This should work now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-28 21:30
---
Subject: Bug 39938
Author: ebotcazou
Date: Tue Apr 28 21:29:58 2009
New Revision: 146915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146915
Log:
PR rtl-optimization/39938
* resource.c (
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-28 21:27 ---
We need to update SSA form after FRE as we now notice the cast to
entry_func (with noreturn attribute, thus no VDEF) was invalid (and
thus we add a VDEF).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39941
--- Comment #6 from sje at cup dot hp dot com 2009-04-28 21:25 ---
;; Function foo (foo)
foo ()
{
vector float D.2002;
vector float D.2001;
vector float D.2000;
vector float D.1999;
vector float D.1998;
vector float D.1997;
v4sf value.1;
v4sf value.0;
:
value.0_2 = val
--- Comment #6 from vvv at ru dot ru 2009-04-28 21:18 ---
Let's compile file test.c
//#file test.c
extern int F(int m);
void func(int x)
{
int u = F(x);
while (u)
u = F(u)*3+1;
}
# gcc -o t.out test.c -c -O2
# objdump -d t.out
t.out: file format e
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-28 21:18 ---
(In reply to comment #3)
> There error I get on cc.c-torture/execute/20050604-1.c and
> gcc.dg/torture/pr21817-1.c with optimization level 1 or greater is:
>
> x.c:6: error: invalid expression for min lvalue
> D.200
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-28 21:24 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-28 21:23 ---
4.1.2 produces:
.L4:
addq$8, %rsp
.p2align 4,,2
ret
While the trunk produces:
.L1:
addq$8, %rsp
.p2align 4,,2
.p2align 3
ret
--
http://gcc.gnu.org
--- Comment #5 from rguenther at suse dot de 2009-04-28 21:21 ---
Subject: Re: [4.5 Regression] Revision 146831 caused
many test failures
On Tue, 28 Apr 2009, pinskia at gcc dot gnu dot org wrote:
> (In reply to comment #3)
> > There error I get on cc.c-torture/execute/20050604-1.c a
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-28 21:17 ---
Reduced testcase. Fails at -O1.
typedef void (*entry_func) (void) __attribute__ ((noreturn));
extern entry_func entry_addr;
static void bsd_boot_entry (void)
{
stop ();
}
void bsd_boot (void)
{
entry_addr =
--- Comment #3 from sje at cup dot hp dot com 2009-04-28 21:10 ---
There error I get on cc.c-torture/execute/20050604-1.c and
gcc.dg/torture/pr21817-1.c with optimization level 1 or greater is:
x.c:6: error: invalid expression for min lvalue
D.2000_6 = BIT_FIELD_REF <{ 1.0e+9, 1.0e+9, 1
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-28 21:09 ---
Confirmed.
#1 0x084a7d71 in execute_todo (flags=7)
at /home/richard/src/trunk/gcc/passes.c:1031
1031gcc_assert (flags & TODO_update_ssa_any);
(gdb)
#2 0x084a8772 in execute_one_pass (pass=0x8d26100)
--- Comment #5 from jingyu at gcc dot gnu dot org 2009-04-28 20:58 ---
Patch was committed to trunk and branch 4.4.
--
jingyu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jingyu at gcc dot gnu dot org 2009-04-28 20:57 ---
Subject: Bug 39790
Author: jingyu
Date: Tue Apr 28 20:57:42 2009
New Revision: 146914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146914
Log:
Backport from mainline.
PR testsuite/39790
--- Comment #28 from carlos at codesourcery dot com 2009-04-28 20:57
---
Exporting a non-default versioned symbol is useless since new programs won't be
able to link against that definition.
Did 4.2/4.3 export a global default symbol for __signbitl?
If we did export a global default s
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-28 20:47 ---
FWIW I agree. Relying on undocumented behavior is as invalid as any other
invalid asm that happened to work in the past.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39949
--- Comment #3 from jingyu at gcc dot gnu dot org 2009-04-28 20:39 ---
Subject: Bug 39790
Author: jingyu
Date: Tue Apr 28 20:39:11 2009
New Revision: 146913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146913
Log:
PR testsuite/39790
* lib/target-supports.exp (c
--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-28 20:38 ---
Works for me on (powerpc|i686)-apple-darwin9 gfortran 4.2.3, 4.3.3, 4.4.0, and
trunk.
You should update your gfortran to at least 4.3.3 (4.2 is no longer supported).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-28 20:04
---
(In reply to comment #10)
> (In reply to comment #9)
> > Is this one of those bugs that only trigger on -fPIC?
> >
I opened PR 39952 for this.
--
hjl dot tools at gmail dot com changed:
What|R
This compilation problem prevents SPECmpi benchmark 115.fds4 (file read.f) from
compiling with gfortran. Here is an example of the problem:
% cat read.f
MODULE READ
CONTAINS
SUBROUTINE READ_SPRK
OPEN(95,FILE='dat',FORM='FORMATTED',STATUS='OL
gcc.dg/compat/struct-layout-1_generate.c generates some tests
randomly. Not all possible combinations are tested. The test
T(2456,double a;struct{int * c;}b[];,F(2456,a,-85022.609375,131929.593750))
from PR 39903 was never generated on Linux/x86-64. As the result,
PR 39903 regression wasn't detec
--- Comment #9 from mdorey at bluearc dot com 2009-04-28 20:00 ---
(In reply to comment #1)
> Because a null pointer constant is an integral constant expression, thus the
> warning is wrong.
Are all integral constant expressions necessarily implicitly convertible to all
integer types?
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-28 19:44
---
> This makes sense to me as a possible explanation, but my response would be
> to turn variable tracking on even at -O0.
This was experimented, but this generates bloated and inferior debugging infor
mation for t
--- Comment #8 from bonzini at gnu dot org 2009-04-28 19:33 ---
Subject: Re: [4.5 regression] Revision 146874 breaks %z on
x87 insns
> If I had told you that we had had several internal applications
> which use %z on x87 since 1998, would it make a difference?
Maybe no, but i
--- Comment #7 from burnus at gcc dot gnu dot org 2009-04-28 19:25 ---
(In reply to comment #6)
> may be interested to RTFM and specially:
>
> -fno-automatic
> -fmax-stack-var-size=n
Well, -fopenmp implies -frecursive and thus the use of the stack. If a function
can never be called in s
After installing GCC:
$ ls -l $PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach
lrwxr-xr-x 1 locallocal 25 Apr 28 14:22
$PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/include-fixed/mach ->
root/usr/sys/include/mach
$ ls -l
$PREFIX/lib/gcc/alphaev56-dec-osf4.0g/4.4.0/inclu
--- Comment #2 from jdraper at super dot org 2009-04-28 18:24 ---
(In reply to comment #1)
> IIRC at -O0, variable tracking is not enabled so it only produces single
> locations.
>
This makes sense to me as a possible explanation, but my response would be to
turn variable tracking on e
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-28 18:23 ---
Considering this is all undocumened no.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-28 18:22 ---
(In reply to comment #3)
> H.J., please do not make up testcases and tell us who was actually using %z
> for
> x87 as of March 31st, 2009.
>
If I had told you that we had had several internal applications
which us
--- Comment #5 from bonzini at gnu dot org 2009-04-28 18:14 ---
... to mark as waiting.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIR
--- Comment #4 from bonzini at gnu dot org 2009-04-28 18:13 ---
reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
__unix__ macro is not predefined with gcc/g++ on AIX platform. Should it be
predefined on this platform for portability?
--
Summary: __unix__ macro is not predefined on AIX platform (C and
C++)
Product: gcc
Version: 3.3.4
Status:
--- Comment #13 from bonzini at gnu dot org 2009-04-28 18:12 ---
*** Bug 39949 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from bonzini at gnu dot org 2009-04-28 18:12 ---
H.J., please do not make up testcases and tell us who was actually using %z for
x87 as of March 31st, 2009.
Otherwise, this bug has the same level of seriousness as the one I'm closing it
as duplicate of.
*** This bug has
--- Comment #5 from ubizjak at gmail dot com 2009-04-28 17:37 ---
Unfortunately, all code snippets and dumps are of no use. Please see
http://gcc.gnu.org/bugs.html for the reason why.
As an exercise, please compile *standalone* _preprocessed_ source you will
create with -S added to your
--- Comment #4 from vvv at ru dot ru 2009-04-28 17:15 ---
Created an attachment (id=1)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=1&action=view)
Simple example from Linux
See two functons:
static void pre_schedule_rt
static void switched_from_rt
--
http://gcc.gnu.o
--- Comment #3 from vvv at ru dot ru 2009-04-28 17:10 ---
Additional examples from Linux Kernel 2.6.29.1:
(Note: conditional statement at the end of all fuctions!)
=
linux/drivers/video/console/bitblit.c
void fbcon_set_bitops(struct fbcon_ops *ops)
{
ops->bmove
--- Comment #2 from vvv at ru dot ru 2009-04-28 17:04 ---
Created an attachment (id=17776)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17776&action=view)
Source file from Linx Kernel 2.6.29.1
See static void set_blitting_type
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #43 from pinskia at gcc dot gnu dot org 2009-04-28 16:51
---
*** Bug 39948 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-28 16:51 ---
*** This bug has been marked as a duplicate of 57 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-28 16:45 ---
None of x86 insn modifiers are documented and %z comments in gcc
source codes on 4.3/4.4 branches are simply incorrect. %z has been
working on x87 insns since day 1 on gcc.gnu.org back to 1992. Why
do we have to brea
--- Comment #1 from ubizjak at gmail dot com 2009-04-28 16:39 ---
Wontfix, the code uses undocumented operand modifier.
--
ubizjak at gmail dot com changed:
What|Removed |Added
---
Revision 146874:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01518.html
breaks %z on x87 insns:
[...@gnu-16 float-1]$ cat foo.c
#define fp_to_int(func,ftype,itype) \
itype \
__attribute__((noinline)) \
func (ftype value) \
{ \
itype res; \
__asm__ __volatile__ ("fistp%z0 %0" : "=m" (res) : "t"
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-28 16:31 ---
Fixed with r146905. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-28 16:27 ---
Subject: Bug 39946
Author: janus
Date: Tue Apr 28 16:27:27 2009
New Revision: 146905
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146905
Log:
2009-04-28 Janus Weil
PR fortran/39946
* reso
1 - 100 of 166 matches
Mail list logo
