--- 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=gcc&view=rev&rev=120145
Log:
2006-12-21 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- 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 de
--- 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 chang
--
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 09:20:
--- 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:
unit size
align 8 symtab
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 sourc
--- 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
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 integ
--- 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=gcc&view=rev&rev=120147
Log:
2006-12-22 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optim
--- 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 include
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=gcc&view=rev&rev=120151
Log:
2006-12-22 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR mi
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=12833&action=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=12836&action=view)
complet error message x86_64 suse linux 10.1
in case it may help, here is the list of
conflicting fi
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
#inc
--- 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::_Expr > >,
bool>' to 'long int' for argument '1' to 'long int __builtin_expect(long int,
long int)'
--
http://gcc.gnu.org/bugzilla/show_
--- 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=gcc&view=rev&rev=120155
Log:
2006-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- 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=gcc&view=rev&rev=120155
Log:
2006-12-22 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
#include
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 http://gcc.gnu.org/bugs.html
--- 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 built
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |target
GCC build triplet||mips-sgi-irix6
--- 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
--
http://gcc.gnu.o
31 matches
Mail list logo
