--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #2 from dan at math dot uiuc dot edu 2008-01-07 00:20 ---
Well, if you were right, then gnu99 and gnu89 would have the same behavior, but
they don't:
indigo% gcc -c -std=gnu99 foo.c
indigo% nm foo.o
T _f
0008 T _main
indigo% gcc -c -std=gnu89 foo.c
indigo% nm fo
--- Comment #3 from dan at math dot uiuc dot edu 2008-01-07 00:21 ---
PS: it could be a bug inserted by Apple...
--
dan at math dot uiuc dot edu changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-07 00:28 ---
> Use nm filename.o to see that a global symbol f has been declared, but it
>shouldn't be.
Yes it should, that is what it should do for C99/GNU99.
>PS: it could be a bug inserted by Apple...
Well no, Apple just f
--- Comment #25 from gdr at cs dot tamu dot edu 2008-01-07 00:38 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatibl
--- Comment #26 from mark at codesourcery dot com 2008-01-07 01:16 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> I would not bet money that nobody is not using it. However, that
> somebody
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-07 01:32
---
I mean 2008-01-06 snapshot of course, duh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34698
This is introduced in last 24 hours because 2007-01-06 snapshot was ok,
Executing on host:
/var/pisi/gcc-4.3_pre20080107-32/work/gcc-4.3-20080107/build/gcc/testsuite/gfortran/../../gfortran
-B/var/pisi/gcc-4.3_pre20080107-32/work
/gcc-4.3-20080107/build/gcc/testsuite/gfortran/../../
/var/pisi/gcc-
--- Comment #5 from dan at math dot uiuc dot edu 2008-01-07 01:43 ---
Thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34697
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-07 01:46
---
I can confirm this bug. We know where this was introduced. It is probably a
latent bug and occurs only with invalid code. It is being worked.
--
jvdelisle at gcc dot gnu dot org changed:
What
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-07 02:53
---
Subject: Bug 34659
Author: jvdelisle
Date: Mon Jan 7 02:53:04 2008
New Revision: 131371
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131371
Log:
2008-01-06 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-01-07 03:17
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
St
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/
xxx/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/xxx/gnu/gcc/gcc/gcc/testsuite/
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 -w -O0
-L/xxx/gn
u/gcc/objdir/hppa1.1-hp-hpux10.20/./libgfortran/.libs
-L
--- Comment #7 from hjl at lucon dot org 2008-01-07 04:57 ---
gfc_undo_symbols has
for (p = changed_syms; p; p = q)
{
q = p->tlink;
if (p->new)
{
/* Symbol was new. */
delete_symtree (&p->ns->sym_root, p->name);
p->refs-
Consider the following code, compiled with the latest gcc built from sources,
with the -std=c++0x flag:
#include
struct S
{
S() {}
S(S &s) { std::cout << "L-value ref" << std::endl; }
S(S &&s) { std::cout << "R-value ref" << std::endl; }
};
S source() { static S s; return s; }
int m
--- Comment #27 from gdr at cs dot tamu dot edu 2008-01-07 06:54 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #26 from mark at codesourcery dot com
--- Comment #28 from gdr at cs dot tamu dot edu 2008-01-07 06:57 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Imagine that you're a user. You read about GNU __compl
--- Comment #29 from gdr at cs dot tamu dot edu 2008-01-07 07:09 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
"complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| > We have no plan of how those new constructors will in
--- Comment #30 from mark at codesourcery dot com 2008-01-07 07:44 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | Is it conceivable that ISO C++ will ever add a
> | complex::complex(int) co
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-07 07:48 ---
*** This bug has been marked as a duplicate of 33375 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from mark at codesourcery dot com 2008-01-07 07:48 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> But, as that hypothetical user, I would not have any ground to be unhappy.
>
--- Comment #8 from burnus at gcc dot gnu dot org 2008-01-07 07:48 ---
*** Bug 34698 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
101 - 122 of 122 matches
Mail list logo
