--- Comment #11 from jakub at gcc dot gnu dot org 2008-02-27 09:09 ---
Subject: Bug 35368
Author: jakub
Date: Wed Feb 27 09:09:05 2008
New Revision: 132704
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132704
Log:
PR c++/35368
* rtti.c: Include c-pragma.h.
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-27 09:00 ---
This just needs someone with the time and willingness to implement it.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Minimal example program:
#include
#include
template< typename T > struct A;
template< typename T, typename U > struct A< std::pair< T, U > >
{
static void f()
{
std::cout << __PRETTY_FUNCTION__ << std::endl;
}
};
int main()
{
A< std::pair< int, int > >::f();
}
Output of __PRETTY
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-27 09:50 ---
Subject: Bug 34971
Author: rguenth
Date: Wed Feb 27 09:50:04 2008
New Revision: 132706
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132706
Log:
2008-02-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-27 09:35 ---
It uses the names as in the std::pair template declaration, so you could argue
this is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35387
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-27 09:31 ---
Fixed on 4.3/4.4, I believe the problem can't be reproduced on earlier branches
unless you have hjl's patch backported.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #12 from jakub at gcc dot gnu dot org 2008-02-27 09:27 ---
Subject: Bug 35368
Author: jakub
Date: Wed Feb 27 09:26:24 2008
New Revision: 132705
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132705
Log:
PR c++/35368
* rtti.c: Include c-pragma.h.
--- Comment #1 from eres at il dot ibm dot com 2008-02-27 10:03 ---
Same error was received on powerpc64-linux, trunk r132684
configured with:
--with-cpu=default32 --enable-checking --enable-bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
--- Comment #2 from uriah at mobiletornado dot com 2008-02-27 09:41 ---
Subject: RE: -MT generates a target string too long
over two lines
Hello,
Actually I've encountered an error with Microsoft nmake... I've tried to
reproduce it with make, but it seemed to work OK.
It still seems t
--- Comment #3 from thomas dot orgis at awi dot de 2008-02-27 10:12 ---
Well, that's good to hear that this is already fixed.
Though it may be nit-picky to note that there isn't a 4.3 gfortran binary
package on the page you pointed out but only 4.2 and trunk (4.4) ;-)
I'll see when the s
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 09:50 ---
I'll apply this for 4.3.1 as well.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Trying to compile 447.dealII benchmark from SPEC CPU 2006 v 1.0 in an Alpha
machine I get the following error:
g++ -v -save-temps -c -o vector.long_double.o -DSPEC_CPU -DNDEBUG -Iinclude
-DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3 -O3 -static -mcpu=ev6 -mtune=ev6
-D__V40_OBJ_COMPAT -DCOMPAT_4
--- Comment #1 from dario at unizar dot es 2008-02-27 10:24 ---
Created an attachment (id=15235)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15235&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35388
There is something wrong with the norm() in STL to get the norm2 of complex
numbers.
Suppose we have complex x(8,1), the norm of x should be 8*8 + 1*1 = 65,
but norm(x) returns 64, which is incorrect.
If we do complex x(8,1), there is no problem, norm(x) does return 65.
The issue is not limited
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-27 10:35
---
Actually, after looking more in depth at the front-end code, we do a fairly
good job of supporting the use of f2c calling conventions for Fortran 95 code
(it's mainly handled by the use of sym->attr.always_explici
--- Comment #2 from dario at unizar dot es 2008-02-27 10:25 ---
Created an attachment (id=15236)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15236&action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35388
the preprocessed file:
unsigned
foo (int n)
{
return ~((unsigned)~n);
}
The above code is compiled to:
;; Function foo (foo)
;; enabled by -tree-original
{
return (unsigned int) ~n;
}
This should be "return (unsigned int) n".
--
Summary: ~~n != n in some cases
Produ
--- Comment #2 from sam at gcc dot gnu dot org 2008-02-27 11:57 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #4 from sam at gcc dot gnu dot org 2008-02-27 12:13 ---
Subject: Bug 22255
Author: sam
Date: Wed Feb 27 12:12:14 2008
New Revision: 132708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132708
Log:
gcc/ada/
PR ada/22255
* s-fileio.adb (Reset): Do
--- Comment #1 from takeshi dot mouri dot net at green dot ocn dot ne dot
jp 2008-02-27 11:53 ---
The regression is located at revision 129128.
--
takeshi dot mouri dot net at green dot ocn dot ne dot jp changed:
What|Removed |Added
--
--- Comment #5 from sam at gcc dot gnu dot org 2008-02-27 12:13 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #1 from sam at gcc dot gnu dot org 2008-02-27 11:54 ---
Subject: Bug 34799
Author: sam
Date: Wed Feb 27 11:53:55 2008
New Revision: 132707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132707
Log:
gcc/ada/
PR ada/34799
* sem_ch13.adb (Analyze_Rec
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #2 from d dot frey at gmx dot de 2008-02-27 12:02 ---
I understand where the names come from, but that doesn't make the message
correct. Consider the specialization in the example program to use <_T2,_T1>
(note the reversed order) and an instantiation with , the resulting
mes
--- Comment #12 from manu at gcc dot gnu dot org 2008-02-27 12:34 ---
Patches for older branches have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01357.html
I hope they are useful and don't break anything ;-)
If there is nothing else to do in this PR, I will close it
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-27 12:43 ---
This works for me. Please provide a testcase that fails.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-27 12:36 ---
extern void abort (void);
unsigned int foo (int n)
{
return ~((unsigned int)~n);
}
int main()
{
if (foo(0) != 0)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|R
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-27 12:32 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 12:32 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 12:43 ---
I used:
#include
#include
#include
int main()
{
std::complex x(8, 1);
std::cout << std::norm(x) << std::endl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-27 13:00 ---
Confirmed. This is a diagnostics bug. (And perhaps a duplicate).
Thanks for the report. If you would like to contribute a patch, please read
http://gcc.gnu.org/contribute.html
--
manu at gcc dot gnu dot org change
--- Comment #14 from manu at gcc dot gnu dot org 2008-02-27 13:42 ---
(In reply to comment #13)
> Thanks a lot for taking the time to write a patch for this. I do have one
> question: if I'm reading the patch correctly, this postpones warnings about
> unrecognised options not just for -W
cd /localbuild/icewm-1.2.35/src/
g++ -fpermissive -Wall -Wpointer-arith -Wconversion -Wwrite-strings -Winline
-Woverloaded-virtual -W -fno-exceptions -fno-rtti -g -O2 -DHAVE_CONFIG_H
-DLIBDIR='"/usr/local/share/icewm"' -DCFGDIR='"/etc/icewm"'
-DLOCDIR='"/usr/local/share/locale"' -DKDEDIR='""' -DPA
$ gcc -V 4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure linux gnu
Thread model: posix
gcc version 4.3.0 20080219 (prerelease) [gcc-4_3-branch revision 132456]
(Debian 4.3-20080219-1)
$ gcc -V 4.3 fs.i -funsigned-char -Os -Wall -S -o fs.S
fs.i: In function DOS
--- Comment #2 from T dot Mittelstaedt at cadenas dot de 2008-02-27 13:05
---
gcc 4.1 compiles this file.
[EMAIL PROTECTED]:/localbuild/icewm-1.2.35/src$ /usr/X11R6/bin/gcc-4.1 -v
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.1.2/specs
Target: x86_64-linux-gnu
Configured with: ../
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-27 13:23 ---
This looks like a dup of PR31899 which was fixed for 4.2.3. Please re-open if
that is not the case.
*** This bug has been marked as a duplicate of 31899 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-27 13:18 ---
Subject: Bug 25290
Author: rguenth
Date: Wed Feb 27 13:17:17 2008
New Revision: 132710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132710
Log:
2008-02-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #13 from pmaydell at chiark dot greenend dot org dot uk
2008-02-27 13:32 ---
Thanks a lot for taking the time to write a patch for this. I do have one
question: if I'm reading the patch correctly, this postpones warnings about
unrecognised options not just for -Wno-* but als
--- Comment #1 from T dot Mittelstaedt at cadenas dot de 2008-02-27 13:01
---
Created an attachment (id=15237)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15237&action=view)
preprocessed source stripped of system includes via uninclude
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from revitale at gcc dot gnu dot org 2008-02-27 13:28
---
Subject: Bug 34999
Author: revitale
Date: Wed Feb 27 13:27:56 2008
New Revision: 132711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132711
Log:
Fix PR rtl-optimization/34999
Added:
trunk/gcc/testsu
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-27 13:23
---
*** Bug 35391 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-27 14:14 ---
Fixed for 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-27 14:13 ---
Subject: Bug 35390
Author: rguenth
Date: Wed Feb 27 14:12:33 2008
New Revision: 132712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132712
Log:
2008-02-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-27 14:13 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.3.0
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-27 14:15 ---
Fi-xed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-27 14:13 ---
Subject: Bug 34971
Author: rguenth
Date: Wed Feb 27 14:12:33 2008
New Revision: 132712
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132712
Log:
2008-02-27 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-27 14:32
---
Subject: Bug 33387
Author: fxcoudert
Date: Wed Feb 27 14:32:02 2008
New Revision: 132713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132713
Log:
PR fortran/33387
* trans.h: Remove prot
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-02-27 14:33
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Dear G++ developers,
*PLATFORM*
GCC 4.2.3, Intel Core 1 (32 bit), Kubuntu 8.04-alpha (Debian-based).
*DESCRIPTION OF THE PROBLEM*
When using nested templates such as
A, z>, t>, u>
the optimizer seems to give up some useful optimizations when the depth is
greater than 17.
I know that the C++ st
--- Comment #1 from jacob at math dot jussieu dot fr 2008-02-27 14:48
---
Created an attachment (id=15238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15238&action=view)
test case referred to in first post
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35393
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2008-02-27 14:51
---
There's more to it... using the "result" syntax for the function makes it fail
even with my patch:
function f(a) result(res)
implicit none
real(8), intent(in) :: a(:)
complex(8) :: res
res = cmplx(sum(a)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 15:19 ---
You probably hit some inliner size limits which are not connected to
-ftemplate-depth-20. (That option should never change code generation).
g++ 4.3.0 seems to work like a charm btw. With g++ 4.2 you can use
__att
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-27 15:59 ---
I tested on a x86_64 host where possibly all the string operations are
inlined (try -minline-all-stringops). Indeed, flatten only inlines all
functions
where the body is available -- a warning is possibly not wanted
--- Comment #3 from jacob at math dot jussieu dot fr 2008-02-27 15:49
---
Thank you for the quick reply. I'm glad to hear that it's fixed and much
improved in 4.3.
I tried what you said about __attribute__((flatten)) (I copied and pasted your
code) and that didn't change the performanc
--- Comment #5 from jacob at math dot jussieu dot fr 2008-02-27 16:22
---
Oh sure, I hadn't thought about that, but it makes perfect sense to not
"flatten" callees whose body source code is not available.
I tried g++-4.3 and confirm that it is much faster and doesn't suffer from that
b
--- Comment #2 from charles dot w dot lambert at gmail dot com 2008-02-27
16:32 ---
I can confirm this bug against gcc 4.2.3 and gcc 4.3.0 on os x (10.5.2).
Apparently apple has changed the way that putenv is handled. From the `man 3
getenv` page i quote:
"COMPATIBILITY
putenv() n
--- Comment #34 from jacob at math dot jussieu dot fr 2008-02-27 16:36
---
I retried today with
g++-4.3 (Ubuntu 4.3-20080126-1ubuntu1) 4.3.0 20080126 (experimental) [trunk
revision 131874]
and my benchmark ran in 25s compared to 20s with g++-4.2.3.
So there is certainly a lot of impr
--- Comment #35 from pinskia at gcc dot gnu dot org 2008-02-27 16:43
---
We get:
:
m__valuem_I_lsm.28 = 1.0e+0 - m__valuem_I_lsm.28;
ivtmp.30 = ivtmp.30 + 1;
if (ivtmp.30 != 1)
goto ;
else
goto ;
or:
L2:
addl$1, %eax
movapd %xmm1, %xmm2
--- Comment #21 from bangerth at dealii dot org 2008-02-27 16:52 ---
Can someone check which of the testcases now work and separate
those that don't into PRs of their own? This PR has become
a bit confusing.
W.
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #36 from jacob at math dot jussieu dot fr 2008-02-27 16:58
---
That's great; from the assembly code I take it that you are referring tothe
last benchmark.cpp; I was referring to the first one. Again, my 4.3 is one
month old so maybe things have further improved since.
--
--- Comment #37 from bonzini at gnu dot org 2008-02-27 17:05 ---
Subject: Re: [4.3/4.4 Regression] Revision 119502 causes
significantly slower results with 4.3/4.4 compared to 4.2
jacob at math dot jussieu dot fr wrote:
> --- Comment #36 from jacob at math dot jussieu dot fr 2008
--- Comment #58 from uros at gcc dot gnu dot org 2008-02-27 17:30 ---
Subject: Bug 25477
Author: uros
Date: Wed Feb 27 17:29:58 2008
New Revision: 132723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132723
Log:
PR target/25477
* config/darwin-ppc-ldouble-patch.
--- Comment #59 from ubizjak at gmail dot com 2008-02-27 17:32 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|NEW
I think recent versions of g++ (4.*, for example, but not 3.4.4) go too far
performing C++ template instantiation. Mind you, this is only a guess, and you
guys will know better.
Here's the problem case. The code shown below should (in my opinion) compile
properly as is but should not compile when
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-27
17:49 ---
Subject: Re: Cannot bootstrap Ada with host gnatmake-4.2
> --- Comment #2 from charles dot w dot lambert at gmail dot com
> 2008-02-27 16:32 ---
> I can confirm this bug against gcc 4.2.3 and gcc
--- Comment #1 from daney at gcc dot gnu dot org 2008-02-27 18:05 ---
Subject: Bug 34409
Author: daney
Date: Wed Feb 27 18:04:49 2008
New Revision: 132725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132725
Log:
PR target/34409
* config/mips/iris.h (MIPS_DEBUGG
--- Comment #2 from daney at gcc dot gnu dot org 2008-02-27 18:08 ---
Fixed on the trunk.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #7 from daney at gcc dot gnu dot org 2008-02-27 18:11 ---
Unassigning as I am not working on this.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from charles dot w dot lambert at gmail dot com 2008-02-27
18:16 ---
I agree, what flags can be used to determine when to use it?
I used
...
#elif (defined (__vxworks) && defined (__RTP__)) \
|| (defined (__i386__) && (__APPLE__))
setenv (name, value, 1);
#else
...
--- Comment #5 from charles dot w dot lambert at gmail dot com 2008-02-27
18:20 ---
I also forgot to add that changing to
...
#elif (defined (__vxworks) && defined (__RTP__)) \
|| defined (__APPLE__)
setenv (name, value, 1);
#else
...
would involve changing
...
putenv (expressio
The following test case should be diagnosed as an error. This is because the
type definition (e.g, X_t) is private, but the entity defined with it (abc) is
public.
module xyzzy
implicit none
private
type X_t
real :: y
real :: z
end type
private :: X_t
type(X_t), parameter,
--- Comment #1 from w6ws at earthlink dot net 2008-02-27 18:30 ---
Add keywords
--
w6ws at earthlink dot net changed:
What|Removed |Added
Keywords|
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-27 18:32 ---
This isn't a regression: 3.3 has this issue, and 2.95 (which does not have
-MT) has this issue when you use
123456789a123456789b123456789c123456789d123456789e123456789f123456789g123.c
as source file name.
The online
--- Comment #4 from rwild at gcc dot gnu dot org 2008-02-27 18:35 ---
(In reply to comment #3)
> This isn't a regression: 3.3 has this issue, and 2.95 (which does not have
> -MT) has this issue when you use
> 123456789a123456789b123456789c123456789d123456789e123456789f123456789g123.c
>
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from ywei at qualcomm dot com 2008-02-27 20:13 ---
Subject: RE: error in norm() of STL
I did additional test based your test code. You are right that norm()
seems to be fine. The problem happens when I try to cast the return
double value of norm() to unsigned long long (
--- Comment #4 from pluto at agmk dot net 2008-02-27 20:30 ---
Subject: Re: error in norm() of STL
On Wednesday 27 of February 2008 21:13:13 ywei at qualcomm dot com wrote:
> --- Comment #3 from ywei at qualcomm dot com 2008-02-27 20:13 ---
> Subject: RE: error in norm() of S
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-27 20:38 ---
This is just the non bug with respect of percussion.
See http://gcc.gnu.org/bugs.html#nonbugs_general
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #103 from pinskia at gcc dot gnu dot org 2008-02-27 20:38
---
*** Bug 35389 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-27 21:02
---
Two more remarks on that: ASINH, ACOSH and ATANH need to accept COMPLEX
arguments. Some other functions also should be extended that way (ASIN, ACOS...
and probably many more).
Also, one very annoying feature: BE
--- Comment #60 from dominiq at lps dot ens dot fr 2008-02-27 21:26 ---
(In reply to comment #53)
> Oops, sorry, fixed by rev. 132621.
Now I get:
XPASS: gfortran.dg/large_real_kind_3.F90 -O0 (test for excess errors)
FAIL: gfortran.dg/large_real_kind_3.F90 -O0 execution test
XPASS:
--- Comment #61 from bonzini at gnu dot org 2008-02-27 21:32 ---
Subject: Re: builtin functions should use $LDBL128 suffix
on darwin when appropriate
I think it depends on the version of mpfr that you have installed?
> Also I don't understand why there is a test for "excess errors".
--- Comment #104 from ywei at qualcomm dot com 2008-02-27 21:41 ---
Subject: RE: optimized code gives strange floating point results
Not sure this is the same issues as 323. All three numbers, 8, 1 and 65,
should be able to represented in IEEE 754 floating-point format exactly
without
--- Comment #5 from rwild at gcc dot gnu dot org 2008-02-27 21:43 ---
Subject: Bug 35379
Author: rwild
Date: Wed Feb 27 21:42:23 2008
New Revision: 132727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132727
Log:
libcpp:
PR preprocessor/35379
* mkdeps.c (deps_wr
--- Comment #6 from rwild at gcc dot gnu dot org 2008-02-27 21:53 ---
Fixed in 4.4.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
e i
[EMAIL PROTECTED]:~/work/test/foo$
/home/frey/work/svn/gcc/host-i686-pc-linux-gnu/gcc/g++ --version
g++ (GCC) 4.4.0 20080227 (experimental)
[snip]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35387
--- Comment #62 from fxcoudert at gcc dot gnu dot org 2008-02-27 22:28
---
That new testcase fails under Darwin at -O0 (because of a faulty libm) and
passes with optimization turned on (because the middle-end is very clever). So,
there two solutions are: either have 1 FAIL (-O0) and the
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-02-27 22:45 ---
This is most likely a dup of bug 99.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35387
--- Comment #63 from dominiq at lps dot ens dot fr 2008-02-27 22:52 ---
(In reply to comment #62)
I have nothing against FAIL (I am not fond of XFAIL that in my opinion hide the
problem). I reported the failures because I understood that they were not
expected. If now they will, it fine
--- Comment #6 from gnu_andrew at member dot fsf dot org 2008-02-27 23:00
---
The new structure is committed. As StringBuilder is final, we will have to
clone AbstractStringBuilder in the gnu.classpath package. This is not too
problematic, as we don't expect the internal class to need
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-28
01:41 ---
Subject: Re: Cannot bootstrap Ada with host gnatmake-4.2
> but i know that is most likely not the correct fix. If someone could verify
> that setenv copies the input buffer on all versions of OS X then it
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-28 04:59
---
Yes, of course we just bumped to 4.4 a few days ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35381
configured with ../gcc-4.3-20080208/configure --enable-languages=c,c++,java
The same issue was also observed on i686-pc-linux x86-64 platforms.
>Description:
when an assignment to a variable is followed by 'cmpxchg' on the
variable, there exists a dependency between the two state
--- Comment #1 from kimwooyoung at gmail dot com 2008-02-28 06:35 ---
Created an attachment (id=15240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15240&action=view)
a test file to re-produce the issue
to reproduce the issue, compile it with 'g++ -O2 '
--
http://gcc.gnu.org
--- Comment #32 from uros at gcc dot gnu dot org 2008-02-28 07:09 ---
Subject: Bug 24685
Author: uros
Date: Thu Feb 28 07:08:51 2008
New Revision: 132737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132737
Log:
PR target/25477
* gcc/config/darwin-protos.h: Add
--- Comment #64 from uros at gcc dot gnu dot org 2008-02-28 07:09 ---
Subject: Bug 25477
Author: uros
Date: Thu Feb 28 07:08:51 2008
New Revision: 132737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132737
Log:
PR target/25477
* gcc/config/darwin-protos.h: Add
96 matches
Mail list logo
