--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-22 08:31 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-22 08:31 ---
Subject: Bug 30225
Author: pinskia
Date: Fri Dec 22 08:31:03 2006
New Revision: 120145
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120145
Log:
2006-12-21 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #3 from s__nakayama at infoseek dot jp 2006-12-22 08:39 ---
(In reply to comment #2)
When is the justification that we expect a value of 2? Bool in C++ is
a one-bit type and when you do x.x++ I would imagine that you overflow
the range of that type. The fact that you
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-22 08:45 ---
This is a very simple patch to fix this issue also:
-if (same_type_p (TREE_TYPE (arg), boolean_type_node))
+if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE)
--
pinskia at gcc dot gnu dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-09-24 17:04:36 |2006-12-22
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-22 09:24 ---
Actually I was wrong in saying this is an easy fix.
That part of the fix is still needed but there is another issue in that we are
getting the wrong type for the increment:
component_ref 0xb7d2a118
type
This bug has similarities with bug no 20811. For some reason the gfortran
compilier cannot locate a file when its absolute path is included. See below:
My operating system:
$ uname -a
Linux lylt0061.terma.com 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:31:29 EST 2006
i686 i686 i386 GNU/Linux
The
--- Comment #4 from tbm at cyrius dot com 2006-12-22 10:43 ---
What's the status of this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29682
test case
#include iostream
struct S
{
signed long l: 32;
};
void foo(long)
{
std::cout NG\n;
}
void foo(int)
{
std::cout OK\n;
}
int main()
{
S x = {1};
foo(x.l+0);
return 0;
}
result
$g++ a.c -o a; ./a
NG
According to ISO/IEC 14882 4.5 p3, type of `x.l+0' becomes int by
--- Comment #35 from bonzini at gnu dot org 2006-12-22 12:29 ---
Subject: Bug 29840
Author: bonzini
Date: Fri Dec 22 12:28:52 2006
New Revision: 120147
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120147
Log:
2006-12-22 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #36 from bonzini at gnu dot org 2006-12-22 12:52 ---
Should be fixed now (by inspection of the reduced test case). Patch committed
is at this URL:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01378.html
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-22 12:56 ---
Confirmed. I think the following patch should work. I'll take the bug next year
(if I don't forget). Otherwise, if someone wants to take it, feel free to do
so.
The problem is that only
for include_path in
A testcase provided by Eef van Beveren, notice the difference between the
handling of backslash in the format string and in the regular string:
[EMAIL PROTECTED]:~/src cat backslash.f
call wrt('\backslash')
call wrt('\\backslash')
write (*,100)
write (*,200)
stop
100
--- Comment #10 from manu at gcc dot gnu dot org 2006-12-22 15:54 ---
Subject: Bug 7651
Author: manu
Date: Fri Dec 22 15:54:05 2006
New Revision: 120151
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120151
Log:
2006-12-22 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
I have a friend sorting function defined in my class and the compiler complains
it has not been declared. It works perfectly on a i686-redhat-linux-gnu with
gcc 4.0.2.
The compiler has been installed from the RPM distributed with Fedora Core 5.
The command line used is the following:
g++
--- Comment #1 from antonio dot bulgheroni at gmail dot com 2006-12-22
16:27 ---
Created an attachment (id=12833)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12833action=view)
The intermediate temporary file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30279
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-22 17:10 ---
Please read:
http://gcc.gnu.org/gcc-4.1/changes.html
ARM-style name-injection of friend declarations is no longer the default. For
example:
struct S {
friend void f();
};
--- Comment #16 from Jean-pierre dot vial at wanadoo dot fr 2006-12-22
19:20 ---
Created an attachment (id=12836)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12836action=view)
complet error message x86_64 suse linux 10.1
in case it may help, here is the list of
conflicting
The (strictly speaking ill-formed) program below successfully compiles with
gcc 4.1.0 but fails with a SIGSEGV at runtime. I think it should either fail
to compile or, if it compiles because of a gcc extension, it should also run
successfully to completion.
$ cat u.cpp g++ u.cpp ./a.out
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-22 19:52 ---
What target is this one, all I get is:
t.cc:8: error: cannot convert 'std::_Exprstd::_UnClosstd::__logical_not,
std::_Expr, std::_UnClosstd::__logical_not, std::_Expr,
std::_BinClosstd::__equal_to, std::_ValArray,
--- Comment #2 from sebor at roguewave dot com 2006-12-22 20:22 ---
(In reply to comment #1)
This was gcc 4.1.0 on sparc-sun-solaris2.9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
--- Comment #7 from pault at gcc dot gnu dot org 2006-12-22 20:49 ---
Subject: Bug 30084
Author: pault
Date: Fri Dec 22 20:49:00 2006
New Revision: 120155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120155
Log:
2006-12-22 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #21 from pault at gcc dot gnu dot org 2006-12-22 20:49 ---
Subject: Bug 25818
Author: pault
Date: Fri Dec 22 20:49:00 2006
New Revision: 120155
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120155
Log:
2006-12-22 Paul Thomas [EMAIL PROTECTED]
PR
#include stdexcept
struct my_error : public std::runtime_error
{
my_error( std::string const );
};
template typename T
struct wrapper
{
template typename R
void add_method( R ( T::* )() const );
};
void test()
{
wrapper my_error ().add_method( my_error::what );
--- Comment #3 from pcarlini at suse dot de 2006-12-22 21:42 ---
Hi. In fact, I'm getting the same as Andrew on x86-linux, x86_64-linux and
powerpc-darwin. Seems a really weird target-dependent issue, I hope Eric can
help, a minimum of debugging, a backtrace (thanks in advance, anyway)
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-12-22 22:17
---
No SIGSEGV for me with 4.1.1:
gax% ./pr30280
Assertion failed: a == false, file pr30280.C, line 7
zsh: IOT instruction (core dumped) ./pr30280
Please provide the missing info as per
--- Comment #5 from sebor at roguewave dot com 2006-12-22 22:25 ---
Regardless of whether the program aborts with SIGSEGV or SIGABRT, the point is
that it should either not compile or it should run succesfully to completion.
Here's the output of g++ -v if it helps:
$ g++ -v
Using
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
GCC build triplet|
--- Comment #2 from dfranke at gcc dot gnu dot org 2006-12-22 22:49 ---
Documented in trunk.
Backport to 4.2 will follow soon.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2006-12-22 23:01 ---
Yes, the crazy thing is that apparently the snippet *compiles* only on
sparc-solaris (and shouldn't, of course).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
--- Comment #3 from patchapp at dberlin dot org 2006-12-23 03:00 ---
Subject: Bug number PR preprocessor/30001
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/2006-12/msg01602.html
--
31 matches
Mail list logo
