--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de
2006-12-19 07:45 ---
Hi!
Indeed! I can build again with 'revision 120002'.
Thanks!
Philippe
--
P dot Schaffnit at access dot rwth-aachen dot de changed:
What|Removed |Added
-
--- Comment #2 from seongbae dot park at gmail dot com 2006-12-19 06:58
---
Yes, it looks like duplicate, although PR 15369 is against 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30257
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-19 06:50 ---
I have seen this bug before somewhere like maybe PR 15369.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30257
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-12-19 06:36
---
Subject: Bug 30145
Author: jvdelisle
Date: Tue Dec 19 06:36:26 2006
New Revision: 120044
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120044
Log:
2006-12-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-12-19 06:35
---
Subject: Bug 30145
Author: jvdelisle
Date: Tue Dec 19 06:35:04 2006
New Revision: 120043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120043
Log:
2006-12-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-12-19 06:32
---
Subject: Bug 30200
Author: jvdelisle
Date: Tue Dec 19 06:32:09 2006
New Revision: 120042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120042
Log:
2006-12-18 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-12-19 06:29
---
Subject: Bug 30200
Author: jvdelisle
Date: Tue Dec 19 06:28:47 2006
New Revision: 120041
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120041
Log:
2006-12-18 Jerry DeLisle <[EMAIL PROTECTED]>
For a given input:
1 class A {
2int a;
3 public:
4A(int i) { a = i * i; }
5
6virtual void func(void);
7 };
8
9 const A a1(1);
10
11 void func(void)
12 {
13 }
When compiled with -fprofile-arcs -ftest-coverage,
the gcn
It works not as it says.
I think it's a bug.
Why not let it does as it introduced?
--
Summary: -Wall
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned
--- Comment #28 from sayle at gcc dot gnu dot org 2006-12-19 04:17 ---
Subject: Bug 29302
Author: sayle
Date: Tue Dec 19 04:17:11 2006
New Revision: 120040
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120040
Log:
2006-12-18 Roger Sayle <[EMAIL PROTECTED]>
Eric Ch
--- Comment #7 from whaley at cs dot utsa dot edu 2006-12-19 00:31 ---
>Depends on what you mean by fixable by the programmer because most people don't
know anything about precusion issues.
Most people don't know programming at all, so I guess you are suggesting that
errors that are f
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-18 23:02 ---
>I cannot, of course, force you to admit it, but 323 is a bug fixable by the
> programmer, and this one is not.
Depends on what you mean by fixable by the programmer because most people don't
know anything about pr
--- Comment #5 from whaley at cs dot utsa dot edu 2006-12-18 22:14 ---
I cannot, of course, force you to admit it, but 323 is a bug fixable by the
programmer, and this one is not. The other requires a lot of work in the
compiler, and this does not. So, viewing them as the same can be d
--- Comment #86 from pinskia at gcc dot gnu dot org 2006-12-18 22:04
---
*** Bug 30255 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 22:04 ---
The problem with register spilling and what PR 323 is talking about is all the
same issue really, it is just exposed differently.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu
--- Comment #30 from pertusus at free dot fr 2006-12-18 21:39 ---
(In reply to comment #29)
> getarg intrinsic which was in g77 also seems to be unimplemented?
>
Sorry, it is implemented. What has changed with regard with g77 is that
the associated symbol isn't along getarg_ anymore. I
--- Comment #3 from whaley at cs dot utsa dot edu 2006-12-18 21:16 ---
BTW, in case it isn't obvious, here's the fix that I typically use for problems
like bug 323 that I cannot when it is gcc itself that is unpredictably spilling
the computation:
void test(double x, double y)
{
const
--- Comment #5 from iano at apple dot com 2006-12-18 20:52 ---
I will nominate the following as a test case. It should compile without
errors:
for each affected arch:
gcc test_case.c
gcc test_case.c -maltivec
gcc test_case.c -faltivec
gcc test_case.c -maltivec -DINCLUDE_HEADER
test_
--- Comment #2 from whaley at cs dot utsa dot edu 2006-12-18 20:43 ---
Hi,
While it may be decided not to fix this problem, this is not a duplicate of bug
323, and so it should be closed for another reason if you want to ignore it.
323 has a problem because of the function call, where
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 20:25 ---
(In reply to comment #3)
> C++ standard §11.4 (Friends) ¶7:
>
> "A name nominated by a friend declaration shall be accessible in the scope of
> the class containing the friend declaration. The meaning of the friend
--- Comment #4 from iano at apple dot com 2006-12-18 20:24 ---
A gcc test case that verfies behavior in this area would drive conformance by
external vendors like IBM.
Unfortunately, it is not clear that GCC even has an approved method for
determining if the PIM is active.
--
ht
--- Comment #85 from pinskia at gcc dot gnu dot org 2006-12-18 20:16
---
*** Bug 30255 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 20:16 ---
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from friedman at splode dot com 2006-12-18 20:14 ---
I think the -ffriend-injection option should be the default as it conforms to
the ISO standard. Please reopen.
C++ standard §11.4 (Friends) ¶7:
"A name nominated by a friend declaration shall be accessible in the scop
Hi,
I am aware that gcc attempts to avoid any reordering of floating-piont
operations by default, as this leads to slightly different answers on different
runs. There appears to be a similar problem on the x87, where from my
assembly-diving, I believe I've established that when a register spill i
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-18 20:07 ---
One more point to all this issues if you do configure GCC with --with-cpu=cell
or --with-cpu=970, etc. or use -mcpu=cell, -mcpu=970, -maltivec is enabled by
default.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 20:06 ---
> 3) Fix __APPLE_ALTIVEC__ so that is is defined in some predicable manner that
> can be used for this purpose. Perhaps all you need here is a verification
> test
> case. The problem case appears to be the Cell / L
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 20:04 ---
-faltivec does not exist on any PPC target except for darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30254
It is possible with most compilers use the __VEC__ symbol to indicate that the
AltiVec C Programming Interface is available. GCC has taken a different track.
It is possible to have __VEC__ defined (-maltivec) without the C Programming
Interface operational (altivec.h has not been included.)
It i
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 19:04 ---
Hmm,
typedef typed_slot_rep typed_slot;
typed_slot *typed_rep = static_cast(rep);
return (typed_rep->functor_)();
This code could violate C++ aliasing rules.
--
http://gcc.gnu.org/bugzil
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-18 19:02 ---
Reduced testcase:
struct xpv {
int xpv_cur;
};
bool m_all_methods;
void f(bool a)
{
m_all_methods = ( a ? (({struct xpv *nxpv = 0;(nxpv->xpv_cur > 1 ); }) ? 1 :
0) :1);
}
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 18:54 ---
Reducing ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
--- Comment #2 from nathan at gcc dot gnu dot org 2006-12-18 18:37 ---
patch here. http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01260.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28966
--- Comment #1 from nathan at gcc dot gnu dot org 2006-12-18 18:36 ---
*** Bug 29248 has been marked as a duplicate of this bug. ***
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from nathan at gcc dot gnu dot org 2006-12-18 18:36 ---
this is really a duplicate of 28966. Like vxworks has an unconditional 128 bit
stack alignment, unlike other targets where it is only 128bit when altivec
comes into play.
*** This bug has been marked as a duplicate
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Target Milestone|--- |4.2.0
http:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 17:46 ---
This is not a bug. Friends don't interject.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dcb314 at hotmail dot com 2006-12-18 17:10 ---
Created an attachment (id=12826)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12826&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30253
--- Comment #1 from fang at csl dot cornell dot edu 2006-12-18 17:07
---
ARM-style friend-injection of names into the parent namespaces has been removed
since gcc-4.1, as noted in:
http://gcc.gnu.org/gcc-4.1/changes.html
You should add a forward declaration "class Bar;" before decla
I just tried to compile Suse Linux package yast2-perl-bindings-2.14.0-11
with the new GNU C++ compiler version 3.2 snapshot 20061216.
Here is an extract from the build log
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./include -I/usr/include/YaST2
-DY2LOG=\"Perl\" -DMODULEDIR=\"/usr/share/YaST2/modules\"
--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2006-12-18
15:57 ---
Created an attachment (id=12825)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12825&action=view)
preprocessed and somewhat reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
gcc miscompiles this testcase (reduced from rtorrent) since r111639, compile
with -O1 -fstrict-aliasing:
#include
#include
static long dummy;
struct A
{
static void *foo (void *p) { return p; }
typedef sigc::slot C;
C bar();
};
A::C A::bar ()
{
return sigc::bind (sigc::ptr_fun (&A::f
We should use MPFR to evaluate the c99 bessel functions. However we have to
wait until MPFR implements a suitable interface as described here:
http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/TODO?root=mpfr&rev=3448&r1=3446&r2=3448
--
Summary: Evaluate bessel functions at com
--- Comment #35 from ghazi at gcc dot gnu dot org 2006-12-18 14:53 ---
Mine, obviously.
Almost done, targetted to gcc-4.3.
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
-
We should use MPFR to evaluate c99 lgamma function (and the common extension
function gamma). However we have to wait until MPFR implements a suitable
interface as described here:
http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/TODO?root=mpfr&rev=4214&r1=4205&r2=4214
--
Summ
program struct
REAL , POINTER :: RD(:,:) =>NULL()
ALLOCATE(RD(10,10))
Compile with gfortran -g struct.f90
The Dwarf output for RD leads to:
<1><10d>: Abbrev Number: 5 (DW_TAG_pointer_type)
DW_AT_byte_size : 4
-- there should be a type in there (there is with
The following code compiles under gcc-3.3 and earlier versions, but not under
versions of gcc 4 up to and including gcc-4.0.3 (and possibly later).
class Foo
{
public:
// This should act as a forward declaration of class Bar
friend class Bar;
Foo( Bar *b ) { bar = b; }
--- Comment #2 from sb7206 at gmail dot com 2006-12-18 11:16 ---
The workaround is ok for me (but is it the expected behavior?).
Best regards,
Serge
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30246
--- Comment #6 from gdr at cs dot tamu dot edu 2006-12-18 10:58 ---
Subject: Re: -O2 generates bad code
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| > then it can only be postive
|
| Plausible, but I don't think so.
In that case, you might want to read the C++ standard
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-12-18 10:41 ---
(In reply to comment #4)
> That patch was already approved:
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01982.html
Because of the elapsed time since the posting of the patch,
I did a fresh bootstrap. However lib
--- Comment #5 from ismail at pardus dot org dot tr 2006-12-18 10:39
---
I tried to follow http://gcc.gnu.org/bugs.html#need . Anything else I should
provide?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30247
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 10:26 ---
There is no obvious what is wrong from the tree dumps.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from gdr at cs dot tamu dot edu 2006-12-18 10:16 ---
Subject: Re: New: -O2 generates bad code
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| I compiled the following C++ code on a x86_64 machine
| without optimisation.
|
| #include
|
| int
| main()
| {
|
--- Comment #3 from ismail at pardus dot org dot tr 2006-12-18 10:15
---
Valgrinding the crashing mplayer shows:
==5836== Invalid read of size 1
==5836==at 0x401E776: strlen
(in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==5836==by 0x4B4049E: fprintf (in /lib/libc-2.3.
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| I compiled the following C++ code on a x86_64 machine
| without optimisation.
|
| #include
|
| int
| main()
| {
| long long n = 1;
|
| cout << sizeof( n) << endl;
| for (int i = 0; i < 100; ++i)
| {
|
--- Comment #2 from ismail at pardus dot org dot tr 2006-12-18 10:11
---
Created an attachment (id=12824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12824&action=view)
mp_msg.c compiled with -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30247
--- Comment #1 from ismail at pardus dot org dot tr 2006-12-18 10:10
---
Created an attachment (id=12823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12823&action=view)
mp_msg.c compiled with -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30247
gcc 4.2 branch and gcc 4.3 SVN snapshot seems to miscompile MPlayer's mp_msg.c
resulting in a crash. gcc 3.4.6 is ok. During compilation no warning is issued.
Gcc tested is :
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/cartman/gcc_4.2
--enable-c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 10:09 ---
What is happening is that -ggdb3 does not enable -dD for the preprocessor.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-18 10:04 ---
This feature is now part of the "fortran-experiments" branch, available at:
svn://gcc.gnu.org/svn/gcc/branches/fortran-experiments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
Hello,
Objects generated using '-ggdb3' are different if the compilation process is
split in 2 steps (preprocessing and then compilation) or not.
The issue can be reproduced for the following 'main.c' code using the commands
'gcc -ggdb3 -c main.c' and 'gcc -ggdb3 -c main.c -E > main.i; gcc
-ggdb3
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 09:59 ---
(In reply to comment #3)
> (In reply to comment #1)
> > then it can only be postive
>
> Plausible, but I don't think so.
Again signed type overflow is undefined by the C standard so it can do
anything.
So in this
--- Comment #3 from dcb314 at hotmail dot com 2006-12-18 09:53 ---
(In reply to comment #1)
> then it can only be postive
Plausible, but I don't think so.
The executed code displays a negative number after about
64 iterations, then displays about thirty zeros.
There is one set bit in
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 09:44 ---
Oh you can use -fwrapv if you want signed type overflow to be defined as
wrapping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-18 09:39 ---
No, this is undefined code.
since n is a signed type, and the starting n is 1 and it is only multiplied by
2, then it can only be postive and never equal to 0 because overflow for signed
types is undefined.
--
pi
I compiled the following C++ code on a x86_64 machine
without optimisation.
#include
int
main()
{
long long n = 1;
cout << sizeof( n) << endl;
for (int i = 0; i < 100; ++i)
{
cout << n << ' ' << (float) n << '\n';
n *= 2;
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-12-18 09:33
---
*** Bug 30244 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 2006-12-18 09:33 ---
*** This bug has been marked as a duplicate of 29922 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from dcb314 at hotmail dot com 2006-12-18 09:31 ---
Created an attachment (id=12822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12822&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30244
I just tried to compile the attached code with
the snapshot 4.3-20061216 C compiler.
The compiler said
[EMAIL PROTECTED]:~/gnu/20061216/bugs> ~/gnu/20061216/results/bin/gcc -c -O2
bug27.c
bug27.c: In function 'conf':
bug27.c:4452: internal compiler error: in insert_into_preds_of_block, at
tree-s
--- Comment #4 from dcb314 at hotmail dot com 2006-12-18 09:28 ---
(In reply to comment #3)
> I tried it out and it is still broken.
I have more detail.
I finally managed to get a working compiler
by removing all of the following flags from the
configure line
--disable-multilib
--with
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2006-12-18
08:55 ---
Appears to be fixed by:
2006-12-12 Daniel Berlin <[EMAIL PROTECTED]>
* tree-ssa-structalias.c (handle_ptr_arith): Return false when we
can't handle the pointer arithmetic.
--
belys
--- Comment #4 from dfranke at gcc dot gnu dot org 2006-12-18 08:20 ---
Ups, I didn't check with -pedantic or the -std options.
Since others treat it as an error, I think, a warning in -std=gnu should be the
very least.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
73 matches
Mail list logo
