The purpose of the attached code is to print out the internal representation of
some floating points. However, when compiling with optimizations turned on the
behaviour of the compiled program is not the expected one (i.e. the proper hex
representation is not printed out, but something else, here
--- Comment #1 from mail at sebastianbauer dot info 2007-03-21 07:14
---
Created an attachment (id=13240)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13240action=view)
The simple test source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
--- Comment #2 from mail at sebastianbauer dot info 2007-03-21 07:15
---
Created an attachment (id=13241)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13241action=view)
The output of the compiler invocation and the executable.
--
--- Comment #2 from christian dot joensson at gmail dot com 2007-03-21
08:37 ---
same thing on 4.2 RC1:
Executing on host: /usr/local/src/branch/objdir/gcc/testsuite/g++/../../g++
-B/\
usr/local/src/branch/objdir/gcc/testsuite/g++/../../ -nostdinc++
-I/usr/local/\
--- Comment #3 from mueller at gcc dot gnu dot org 2007-03-21 09:05 ---
both are caused by our well known offender -fivopts.
the problem why the existing workarounds don't work is because the adress is
first converted to unsigned int before +/- modification is done. the traversal
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-03-21 09:13
---
Yet another wrinkle found (with -fno-range-check and crazily large integers),
yet another patch: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01398.html
This one looks final to me, though :)
--
fxcoudert at
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-03-21 09:31
---
If I understand right the two patches do different things. Consider
the following example:
void X(void) {
void D(void) { D(); };
D();
}
The nested function is reachable, so
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-21 09:58 ---
This is related to PR29286, the C++ aliasing rules are disputedly different
from
the C ones. So at the moment you cannot implement an allocator in C++ (and in
C in general). That said, the proper way is to start a
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-21 09:59 ---
You are violating C aliasing rules. Use a union or memcpy to access the fp
value.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following program is taken from
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/fire.f90
The is_g95 check returns T for g95 and NAG f95 and F for ifort 9.1 and sunf95.
I believe it should return TRUE by the standard.
Running the program through valgrind shows:
==317== Invalid read of size 1
The following program compiles with NAG f95, g95 and ifort, but gfortran
writes:
interface1.f90:8.12:
test2(i:i) = achar(mod(i,32)+iachar('@'))
1
Error: Unclassifiable statement at (1)
This is possibly related to PR 31222. (If you mark it as duplicate, please
ensure that
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 10:49 ---
Please also check:
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface2.f90
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface3.f90
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/interface4.f90
The
I'm not completely sure that the following code is invalid, but I think it is.
Taken from:
http://home.comcast.net/%7Ekmbtib/Fortran_stuff/cyclic_specs1.f90
g95 prints:
Error: Circular specification in variable 'ouch' at (1)
NAG f95 compiles it without any warning/error, however. Running it
Hi.
I'm using the GCC compiler for PPC405 as delivered with Xilinx EDK 8.1.
The exact version is: powerpc-eabi-gcc (GCC) 3.4.1 ( Xilinx EDK 8.1.1
Build EDK_I.19.3 190106 )
I found a bug in the code generation.
My code is a serial receiver and uses an uninitialized uchar nData:
uchar nBits;
--- Comment #4 from tobi at gcc dot gnu dot org 2007-03-21 12:13 ---
(In reply to comment #3)
FX' suggestion may fail if dots turn out to be non-portable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31144
On 3/21/07, Informatica Tecnologia Dual [EMAIL PROTECTED] wrote:
Hi.
I'm using the GCC compiler for PPC405 as delivered with Xilinx EDK 8.1.
The exact version is: powerpc-eabi-gcc (GCC) 3.4.1 ( Xilinx EDK 8.1.1
Build EDK_I.19.3 190106 )
I found a bug in the code generation.
My code is a
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-21 14:00
---
(In reply to comment #4)
FX' suggestion may fail if dots turn out to be non-portable.
The GNU as documentation says: Symbol names begin with a letter or with one of
`._'. On most machines, you can also use $ in
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-03-21 14:11 ---
Brooks, maybe not.
Thread safety, in the context it was asked for, still needs to be proved.
Having mutexes within the code is fine to save the states from overwriting each
other (it is an unexpected serialisation
--- Comment #4 from mueller at gcc dot gnu dot org 2007-03-21 14:16 ---
Created an attachment (id=13242)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13242action=view)
patch
this is the patch I'm currently testing. would be nice if you could confirm
that this is also fixing your
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
Found by valgrind:
gfortran gfortran.dg/char_unpack_2.f90
valgrind a.out
==20842== Conditional jump or move depends on uninitialised value(s)
==20842==at 0x4ECB306: unpack_internal (unpack_generic.c:99)
==20842==by 0x4ECB6AA: _gfortran_unpack0_char (unpack_generic.c:233)
==20842==by
Found using valgrind:
gfortran gfortran.dg/backspace_5.f
valgrind ./a.out
==15340== Syscall param write(buf) points to uninitialised byte(s)
==15340==at 0x56000C0: __write_nocancel (in /lib64/libc-2.5.so)
==15340==by 0x4EBEE90: do_write (unix.c:336)
==15340==by 0x4EBEF31: fd_flush
Found by valgrind:
gfortran gfortran.dg/eoshift.f90
valgrind a.out
==20986== Conditional jump or move depends on uninitialised value(s)
==20986==at 0x4EC57D7: eoshift0 (eoshift0.c:115)
==20986==by 0x4EC5D0A: _gfortran_eoshift0_4 (eoshift0.c:251)
==20986==by 0x4009A7: MAIN__ (in
--- Comment #4 from ian at airs dot com 2007-03-21 14:39 ---
With current mainline, I get no warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo() { Foo f; }
but I do get a warning for this:
struct Foo { int i; } __attribute__ ((deprecated));
void foo() {
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-21 14:50
---
Created an attachment (id=13243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13243action=view)
Patch to fix the problem reported
This one is mine. Attached patch (regtested on i686-linux) fixes the
--- Comment #5 from jakub at gcc dot gnu dot org 2007-03-21 14:53 ---
obj-c++ bootstrap is actually where the warning triggered correctly, this
was on trunk checkout from yesterday and some tree codes were = 256,
while an array had just 256 entries and thus e.g.
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-21 14:54 ---
Behavior is different with today's mainline on i386-darwin.
Without optimization the first one gives an error further down the line, and
the other three pass:
1.f90:3: internal compiler error: in simplify_subreg, at
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-21 14:56 ---
gcc.c-torture/execute/920711-1.c has exactly the same issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-21 15:04 ---
I don't understand why it fails in the fourth case. The comparison it seems to
complain about is generated via
return build2 (NE_EXPR, boolean_type_node, decl,
fold_convert (TREE_TYPE (decl),
--- Comment #3 from jakub at gcc dot gnu dot org 2007-03-21 15:05 ---
Created an attachment (id=13244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13244action=view)
gcc43-pr31261.patch
Patch I'm testing ATM.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-21 15:12 ---
That should work, C++ mangles names to something like
_ZN9wikipedia7article8wikilinkC1ERKSs
NB your regexp is missing the underscore inside the second pair of brackets :-)
--
valgrind finds when compiling gfortran.dg/use_6.f90
the following unitinitalized variables:
==29473== Conditional jump or move depends on uninitialised value(s)
==29473==at 0x43DD76: read_module (module.c:733)
==29473==by 0x43E664: gfc_use_module (module.c:4201)
==29473==by 0x443DC7:
--- Comment #2 from pault at gcc dot gnu dot org 2007-03-21 15:22 ---
This fixes it
Index: gcc/fortran/trans-intrinsic.c
===
*** gcc/fortran/trans-intrinsic.c (revision 123059)
--- gcc/fortran/trans-intrinsic.c
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-21 15:23 ---
The problem seems to be that the expression is not folded at all. Calling
gfc_show_expr (e) right before the error message is printed in resolve.c:5618
prints
min[((-4) (5))]
--
tobi at gcc dot gnu dot org
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-21 15:36 ---
The recommended way is to post a message to gcc@gcc.gnu.org or
[EMAIL PROTECTED]
I'll follow your advice, but before I'ld like some feedback about what follows.
I have applied the following patch
---
--- Comment #13 from rth at gcc dot gnu dot org 2007-03-21 15:43 ---
We've fixed the wrong-code part.
Re-tagging the PR to reflect the optimization possibility.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rth at gcc dot gnu dot org 2007-03-21 15:47 ---
Subject: Bug 31245
Author: rth
Date: Wed Mar 21 15:46:46 2007
New Revision: 123110
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123110
Log:
PR target/31245
* config/i386/emmintrin.h (__m128i,
--- Comment #8 from dje at gcc dot gnu dot org 2007-03-21 15:49 ---
This is not a GCC bug. Binutils was updated to support AIX 4.3.3, but has not
been maintained, improved, or updated for AIX 5. It can do simple things, but
does not fully support more advanced features. For instance,
--- Comment #8 from rth at gcc dot gnu dot org 2007-03-21 15:50 ---
Subject: Bug 31245
Author: rth
Date: Wed Mar 21 15:50:01 2007
New Revision: 123111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123111
Log:
PR target/31245
* config/i386/emmintrin.h (__m128i,
--- Comment #9 from rth at gcc dot gnu dot org 2007-03-21 15:52 ---
Subject: Bug 31245
Author: rth
Date: Wed Mar 21 15:52:23 2007
New Revision: 123112
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123112
Log:
PR target/31245
* config/i386/emmintrin.h (__m128i,
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-03-21 15:57
---
It would be nice to know whether darwin does not implement cexp in an optimal
way (special casing zero real part and dispatching to a sincos equivalent for
the imaginary part) or if the issue is only a bad ABI for
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-21 16:09 ---
It would be nice to know whether darwin does not implement cexp in an optimal
way ...
I have forgotten to mention that I did some (quick) profiling: cexp seens
trivially implemented.
It calls sin, cos and exp +
--- Comment #7 from jima at cadence dot com 2007-03-21 16:13 ---
(In reply to comment #6)
... the proper way is to start a new object lifetime using placement new.
Are you referring only to internal operations in MyHeap::Malloc (in the demo
program), or do you mean that the overall
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2007-03-21
16:15 ---
The following program causes an infinite loop in gfortran, but not in other
fortrans.
PROGRAM do_index_in_call
DO i = 1, 1
CALL SUB(i)
ENDDO
END PROGRAM do_index_in_call
SUBROUTINE sub(i)
i = 2
END
--- Comment #11 from jakub at gcc dot gnu dot org 2007-03-21 16:16 ---
Richard, in http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00972.html
you said you'll look into it. The above mentioned patch (updated so that
it applies) is what I'm using in Fedora Core and RHEL gccs for almost a
The following program prints my login name when I run it with the command:
./a.out
but it prints only blanks when I run it with nohup:
nohup ./a.out
cat nohup.out
PROGRAM test_getlog
CHARACTER(LEN=8) :: cname
CALL GETLOG(cname)
PRINT *, cname
END
--
Summary: getlog returns blanks
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 16:49 ---
This works for me:
[EMAIL PROTECTED]:~$ nohup ./a.out
nohup: appending output to `nohup.out'
[EMAIL PROTECTED]:~$ !c
cat nohup.out
Hello
apinski
What OS are you running with?
--
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2007-03-21
16:59 ---
Subject: Re: getlog returns blanks when not run
from the command prompt
I am running SuSE Linux 10.2
At 12:49 PM 3/21/2007, you wrote:
--- Comment #1 from pinskia at gcc dot gnu dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:05 ---
new seems to be ok (should_write_tags=.true.) but new2 contains only garbage.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 17:13 ---
*** Bug 31211 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31200
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:13 ---
The following code is wrong, if cp_get_default_logger returns NULL.
struct cp_logger_type D.1364;
D.1364 = *cp_get_default_logger ();
cp_logger_log (D.1364);
*** This bug has been marked as a duplicate
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-21 17:15 ---
aad.f90: In function 'tricky':
aad.f90:24: internal compiler error: in gfc_get_symbol_decl, at
fortran/trans-decl.c:877
Compiles with NAG f95 and g95, ICEs with ifort and sunf95.
--
burnus at gcc dot gnu dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-21 17:27 ---
I can reproduce this. With g95 it shows also with nohup the login, whereas with
gfortran, sunf95 and ifort it does not.
gfortran calls: char *getlogin(void)
g95 calls: getpwuid(getuid())-pw_name
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-21 17:31 ---
The only thing I can think of this is really a glibc issue and/or a shell issue
as it works for me with debian.
Ok, I can reproduce it with bash on FC5 (I think it is FC5) but it works with
csh as the shell.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-21 17:34 ---
This is not a shell issue either, it is just csh/tcsh has nohup as a builtin
:).
Anyways this is a bug with coreutils.
coreutils 5.2.1's nohup works
coreutils 5.93's nohup does not.
You should report this bug to
2 local classes with same name and sharing methods with same signature
mismatch in calling methods depending on link order
fangorn:thierry% g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/thierry/gcc-4.0.4/configure
Thread model: posix
gcc version 4.0.4
--- Comment #1 from thierry dot galas at med dot ge dot com 2007-03-21
17:50 ---
Created an attachment (id=13245)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13245action=view)
very short code showing the issue in a tar file
--
--- Comment #2 from thierry dot galas at med dot ge dot com 2007-03-21
17:52 ---
samething with gcc :
version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31300
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-21 17:53 ---
They are not local, if you want to declare local classes to a file use an
anonymous namespace.
This code is invalid but no diagnostic is required by the C++ standard (it
violates the One definition rule).
--
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 18:02 ---
(In reply to comment #5)
Anyways this is a bug with coreutils.
coreutils 5.2.1's nohup works
coreutils 5.93's nohup does not.
You should report this bug to them.
I reported it now, cf.
--- Comment #4 from thierry dot galas at med dot ge dot com 2007-03-21
18:16 ---
Subject: Re: undetected class name clash
I agree , sure it is invalid ,(no mine at the root) but a diagnostic
would be nice
very difficult to decide people to use c++ , if this kind of issue is
not
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-21 18:26 ---
The only way to get a diagnostic is to output the class definition and even
then sometimes the detection could be wrong. ODR reporting is a hard problem
with most code.
--
--- Comment #4 from trt at acm dot org 2007-03-21 18:28 ---
I think this could be generalized to more operators, e.g.
(y | (x 7)) 7
^ (bitwise or, xor, multiply, ...)
This optimization could be for e M where e contains a subexpression of the
form t N which can
--- Comment #6 from thierry dot galas at med dot ge dot com 2007-03-21
18:33 ---
Subject: Re: undetected class name clash
Thanks for the anonymous namespace suggestion (I didn't know about it
before) ,
it is efficient and could be systematized at the scale of a large team.
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-21 19:07 ---
(In reply to comment #3)
The following program causes an infinite loop in gfortran, but not in other
fortrans.
The program is plainly invalid as one redefines the DO thus your Fortran
compiler is free to do what
The following program compiles with g95 and f95 in less than a second. gfortran
needs more than several minutes (until I lost patience).
I think gfortran does not enter an endless loop but tries to solve the h1
assignment explicitly. (At least is seems to do this with a much stripped down
--- Comment #8 from jima at cadence dot com 2007-03-21 20:58 ---
I tried using placement-new and explicit destructor calls to
delineate the lifetime of the allocator's internal class objects explicitly,
such that their lifetimes do not overlap with any references to the
same storage
--- Comment #10 from patchapp at dberlin dot org 2007-03-21 21:05 ---
Subject: Bug number PR 23572
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/2007-03/msg01437.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-21 21:45 ---
I bet this is a duplicate of another bug like say PR 20923.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31301
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 21:56 ---
*** This bug has been marked as a duplicate of 20923 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 21:56 ---
*** Bug 31301 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-21 22:31 ---
Richard Main wrote in
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5e91eb94c1ea71ec/
See Notes 15.29 and 15.23 for a (bried) explanation and
example of exactly this. I knoew this was an
The NCOPIES argument of REPEAT is not converted to the integer king the library
expects (kind=4), which can lead to segfaults. I changed that code recently, so
I'll fix it. I'll probably take this opportunity to have the front-end actually
emit an error if the NCOPIES argument is larger than a
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
No time to reduce this one, filing it so it doesn't get lost:
module cyclic
implicit none
contains
function ouch(x,y)
implicit character(len(ouch)) (x)
implicit character(len(x)+1) (y)
implicit character(len(y)-1) (o)
intent(in) x,y
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:10
---
I tried to see if it was a regression against g77, but it is not. Will not
backport to 4.2, and closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:13
---
Not a regression, so won't backport to 4.2. Closing as fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-03-22 00:22
---
(In reply to comment #3)
12.5.2.1 Function subprogram
If RESULT is not specified, the result variable is function- name and all
occurrences of the function name in execution-part statements are references
to
If you compile the attached code with optimization on a 4.1.x system it will
generate a store into a stack temporary in the middle of the loop that is never
used. If you compile the code with -DUSE_MACRO where it uses macros instead of
inline functions, it will generate the correct code without
--- Comment #1 from michael dot meissner at amd dot com 2007-03-22 00:38
---
Created an attachment (id=13248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13248action=view)
C++ source that shows the bug
This is the source that shows the bug.
--
--- Comment #2 from michael dot meissner at amd dot com 2007-03-22 00:39
---
Created an attachment (id=13249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13249action=view)
This is the assembly language with the extra store in it
--
--- Comment #3 from michael dot meissner at amd dot com 2007-03-22 00:40
---
Created an attachment (id=13250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13250action=view)
This is the good source compiled with -DUSE_MACRO
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31307
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-22 01:38 ---
Inline version:
r.dst[0].i = MEM[base: d];
D.6423 = r.dst[0].i;
D.6449 = __builtin_ia32_paddusb128 (VIEW_CONVERT_EXPR__v16qi(D.6423),
VIEW_CONVERT_EXPR__v16qi(D.6423));
r.dst[0].i =
subroutine X (A )
character(len=*), intent(inout) :: A(*)
character(len=len(a)) :: B
end subroutine X
fails:
In file test.f90:3
character(len=len(a)) :: B
1
Error: The upper bound in the last dimension must appear in the reference to
the assumed size array
Description:
Code includes two structures, a 6 byte struct of the following form:
struct 6bytes { char [2] ; char [4] }
and another that embeds this at the very end in the following form:
struct { bool ; bool ; 6bytes } ;f
compiler is generating code for assignment to the trailing 6byte
--- Comment #1 from peeterj at ca dot ibm dot com 2007-03-22 04:28 ---
Created an attachment (id=13251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13251action=view)
source code that demonstrates the code generation issue described.
--
--- Comment #7 from ebb9 at byu dot net 2007-03-22 04:46 ---
According to POSIX, The getlogin() function shall return a pointer to a
string containing the user name associated by the login activity with the
controlling terminal of the current process. The behavior of nohup was
hi
i found bug in g++ 4.1.2 - version included with new kubuntu fiesty.
to reproduce this bug i've created 3 simple files a.h, a.cpp and main.cpp
//a.h
#ifndef A_H
#define A_H
class A{
public:
void b(int c);
private:
int d;
};
#endif
//a.cpp
#include a.h
inline void A::b(int c)
{
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29941
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-22 06:39 ---
*** This bug has been marked as a duplicate of 29941 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-22 06:39 ---
*** Bug 31308 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
94 matches
Mail list logo
