--- Comment #8 from julian1844 at yahoo dot com 2009-04-30 06:38 ---
(In reply to comment #7)
ok, mingw should be linking against libpthreads with -fopenmp (it should also
be linking against libgomp also)
I don't think libgomp has been ported to mingw yet.
I wonder if the source
--- Comment #8 from ruben at tapir dot caltech dot edu 2009-04-30 07:33
---
In my considered opinion, the need to support these functions has little to do
with efficiency or with convenience. It has more to do with accuracy and
symmetries; relations such as sind(30)=0.5, cosd(90)=0.0,
--- Comment #9 from ruben at tapir dot caltech dot edu 2009-04-30 07:38
---
Someone suggested multiplying or dividing the argument by a factor.
That does not do - the floating point precision achieved would be insufficient.
Someone complains about the names of these functions. I
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-30 07:51 ---
These functions will *not* be implemented, period.
And even if they would be implemented, they'd internally just return
sin(arg*180/pi) co. The compiler and the runtime library don't actually
calculate sin/cos
--- Comment #2 from jan dot kratochvil at redhat dot com 2009-04-30 07:52
---
Please close it as DUPLICATE of PR debug/35463.
--
jan dot kratochvil at redhat dot com changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
--- Comment #4 from espindola at google dot com 2009-04-30 08:07 ---
Probably fixed on 146998.
Andrew Pinski, we cannot use a shared library for this. The idea is for the
plugin to remember what gcc version it was compiled for. A shared library can
change after the fact.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 09:02 ---
Can you try with a later version of the compiler (in the set of released
versions) 4.3.4 , 4.4.0 or trunk and report back ?
Don't get this failure with arm-eabi configurations.
--
ramana at gcc dot gnu dot org
--- Comment #16 from jakub at gcc dot gnu dot org 2009-04-30 09:07 ---
Created an attachment (id=17783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17783action=view)
gcc45-pr39942.patch
Patch that attempts to take into account .p2align directives that are emitted
for (some)
--- Comment #10 from pault at gcc dot gnu dot org 2009-04-30 09:52 ---
(In reply to comment #9)
(In reply to comment #8)
I have remote access to the machine now. Having trouble with gcc build. Not
forgotton.
I remember our admin talking about needing an updated ld to be able to
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
Subject: Bug 38571
Author: ramana
Date: Thu Apr 30 10:04:52 2009
New Revision: 147000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147000
Log:
Fix PR target/38571
Modified:
trunk/gcc/ChangeLog
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
This is now fixed with r147000
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
--- Comment #5 from joseph at codesourcery dot com 2009-04-30 10:09 ---
Subject: Re: [4.5 Regression] ./plugin-version.h:11:
error: 'gcc_version' defined but not used
On Thu, 30 Apr 2009, pinskia at gcc dot gnu dot org wrote:
Really I think plugin support is flawed. There should
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-30 10:10 ---
Can you try with a compiler of more recent vintage and report back.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-04-30 10:18 ---
Can you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Create a default configuration that honours big endian ARM by default. PR31938
refers to this.
--
Summary: Support big endian ARM by default.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:25 ---
If there is a request to support a big endian default configuration for ARM,
there should be a separate enhancement request for that. Given this, I'd close
this bug as being invalid. I've filed PR39975 for this
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:30 ---
Not sure if this is related to PR31849 as well.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-04-30
10:31 ---
It is working with 4.3.3, so it seems to have been silently fixed somewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36689
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-30 10:37 ---
For 4.3 try if -fno-tree-sra fixes the failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38696
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 10:39 ---
We need more information on what the exact problem is with the code generated.
Could you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The following code snippet produces a bogus warning when compiled with
-O2 -Wall on trunk:
bug.cc: In function 'void
_Z41__static_initialization_and_destruction_0ii.clone.0()':
bug.cc:3: warning: array subscript is below array bounds
bug.cc:3: warning: array subscript is below array bounds
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 09:27 ---
Seems to work today on gcc50 with gcc 4.4.0 and trunk on the simulator .I don't
see these failures in recent testresults on gcc-testresults@ from the
auto-tester at gcc50.
--
ramana at gcc dot gnu dot org
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-30 11:29 ---
gcc 3.4 is no longer supported. Marking this as WONTFIX.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39974
--- Comment #5 from dominiq at lps dot ens dot fr 2009-04-30 11:25 ---
Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this?
No! Still fails at revision 146999.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29336
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-04-30
12:44 ---
Closing, works with 4.3.3
--
dennis dot wassel at googlemail dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 ---
*** This bug has been marked as a duplicate of 35463 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-30 12:46 ---
*** Bug 35462 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-30 13:00 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-30 13:02 ---
Revision 146817:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html
may be the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-30 13:05 ---
I think this has been fixed by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=146137
http://gcc.gnu.org/viewcvs?root=gccview=revrev=146290
http://gcc.gnu.org/viewcvs?root=gccview=revrev=146897
on the trunk.
--
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from bonzini at gnu dot org 2009-04-30 14:56 ---
Fails after PRE.
Reduced testcase requiring just a jc1 executable (assuming gcc is built in a
subdirectory of the toplevel, i.e. ../configure):
./jc1 ../../libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
--- Comment #7 from bonzini at gnu dot org 2009-04-30 14:56 ---
Ah, I didn't bootstrap so jc1 cannot be miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #2 from jb at gcc dot gnu dot org 2009-04-30 15:12 ---
Subject: Bug 39667
Author: jb
Date: Thu Apr 30 15:12:37 2009
New Revision: 147004
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147004
Log:
Fix PR libfortran/39667
Modified:
trunk/gcc/testsuite/ChangeLog
anonymous struct on:
g++ (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3)
and gives DW_TAG_structure_type DW_AT_name type27 on:
g++ (GCC) 4.5.0 20090430 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35463
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-04-30 16:09 ---
Subject: Re: gfortran support for non-standard sind,cosd and friends
intrinsics
On Thu, Apr 30, 2009 at 07:38:31AM -, ruben at tapir dot caltech dot edu
wrote:
--- Comment #9 from
--- Comment #2 from gustcr at yahoo dot com dot ar 2009-04-30 16:24 ---
(In reply to comment #1)
Change Severity to normal. Fortran bugs are never major.
AFAIK, there will be no further releases from the gcc-4.1.x branch,
so it is highly unlikely that this bug will be fixed.
We have a hot spot on sixtrack in a function called thin6d.
Such loop is generated by the old (pre-146817) gcc as a single BB, thus the
only way inside that loop is by executing instructions until we fall into that
code.
The post-146817 gcc breaks that loop in two BB's, such that we can actually
--- Comment #12 from janis at gcc dot gnu dot org 2009-04-30 16:30 ---
In comment #10 I meant that the tests in gcc.c-torture/execute now pass for
powerpc64-linux with -m32 and -m64, and that the 3 tests in gcc.target/powerpc
listed in comment #7 still fail for powerpc64-linux with
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-30 16:32 ---
Revision 146817 is the cause. It is reproducible with test data, -i test.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
16:33 ---
This is already in 4.4, but we would like to add additional checks on 4.5 that
would be risky to have on 4.4 (since it was almost being released). I have the
additional patch and will attach it soon.
--- Comment #3 from kargl at gcc dot gnu dot org 2009-04-30 16:35 ---
(In reply to comment #2)
(In reply to comment #1)
Change Severity to normal. Fortran bugs are never major.
AFAIK, there will be no further releases from the gcc-4.1.x branch,
so it is highly unlikely that
The 32 bit PA build broke with version 146817. The failure can be reproduced
by compiling the included test program. The failure is:
x.c: In function '__fixtfdi':
x.c:9: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6825
Please submit a full bug report,
with preprocessed source
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #16 from pault at gcc dot gnu dot org 2009-04-30 17:03 ---
module m
type t
integer :: i,j
end type t
interface assignment (=)
module procedure i_to_t
end interface
contains
elemental subroutine i_to_t (p, q)
type(t), intent(out) :: p
integer,
if [ x-fPIC != x ]; then \
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/arm-none-linux-gnueabi/bin/ -c
-DHAVE_CONFIG_H -g -O2 -I/home/dave/opt/gnu/include -I.
-I../../gcc/libiberty/../include -W -Wall
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 17:27 ---
See the same error on hppa-unknown-linux-gnu:
libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/gfortran
-B/home/dave/gnu/gcc
/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dave/o
hi,
i'm currently testing gcc-4.4.1-20090427 on my large c++ codebase.
the application uses threads, contains over 100+ shared components
and the tested debug build (-O0 -g2 -fpic) needs over 2GB of disk space,
so creating reduced testcase at this point isn't trivial thing.
i've observed that
--- Comment #4 from janis at gcc dot gnu dot org 2009-04-30 17:48 ---
Subject: Bug 39776
Author: janis
Date: Thu Apr 30 17:48:03 2009
New Revision: 147010
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147010
Log:
PR testsuite/39776
* g++.dg/ext/altivec-15.C:
--- Comment #5 from janis at gcc dot gnu dot org 2009-04-30 17:53 ---
Subject: Bug 39776
Author: janis
Date: Thu Apr 30 17:53:23 2009
New Revision: 147011
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147011
Log:
PR testsuite/39776
* g++.dg/ext/altivec-15.C:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-30 17:55 ---
Interesting. I Knew about a PIC failure on arm but I the backtrace was
different, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 .
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-30 17:59 ---
Seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29209 which seems
like it was worked around in 4.3 and 4.4 but exposed again with the SSA expand
patch.
--
pinskia at gcc dot gnu dot org changed:
I will attach the preprocessed source code. I think the code is valid but I am
not sure of that after using delta to cut it down as far as I could.
x.cc:40: internal compiler error: tree check: accessed elt 3 of tree_vec with 2
elts in tsubst, at cp/pt.c:9249
Please submit a full bug report,
--- Comment #1 from sje at cup dot hp dot com 2009-04-30 18:41 ---
Created an attachment (id=17784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17784action=view)
Preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39980
--- Comment #3 from jv244 at cam dot ac dot uk 2009-04-30 18:48 ---
a bug in the code that is triggered by the option. closing as invalid.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Scenario1A: When class X inherits from A, B, and C; and A and C are empty
classes, then gcc properly creates X such that: sizeof(X) == sizeof(B)
Scenario1B: When class X inherits from A and B; and A is an empty class, then
gcc properly creates X such that: sizeof(X) == sizeof(B)
Scenario2A:
--- Comment #1 from navinkumar+bugs at gmail dot com 2009-04-30 18:54
---
Created an attachment (id=17785)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17785action=view)
demonstrates scenarios when zero-size base class optimization fails
compile with flag: -std=c++0x
--
--- Comment #2 from navinkumar+bugs at gmail dot com 2009-04-30 18:57
---
Tested with 2 versions of GCC, same behavior;
Version #1
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /1123/scratch/gcc4.4.0/src/configure
--prefix=/1123/software/gcc4.4.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:01 ---
I think GCC is doing the correct thing here as there is no padding to put
_2_emptyB in. And this is not a zero-size base class optimization but rather
padding filling class optimization.
Have you read the IA64
--- Comment #4 from navinkumar+bugs at gmail dot com 2009-04-30 19:22
---
Since std::is_empty_2_emptyB::value std::is_empty_2_emptyA::value (as
verified by the static assertions), GCC should not treat _2_emptyB differently
from _2_emptyA when computing the structure's layout. The
This problem originates in peren_c++. The test (Sec13/3_1_3/P13290.C)
exercising the following clause: ISO/IEC 14882:1998, 13.3.1.3.
(When a user-defined conversion is invoked to convert an
assignment-expression to a type cv T, where T is a class type,
a constructor of T is considered a
--- Comment #1 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
19:29 ---
ASM code for the bad loop
.L145:
fmul 10,8,13
fmul 5,8,0
addis 3,4,0xffe5
lfd 22,8(7)
addi 7,4,8
lfd 6,9472(3)
fmadd 10,9,0,10
fmsub
--- Comment #5 from sergei_lus at yahoo dot com 2009-04-30 19:32 ---
Please close this issue. I think the real problem is in libc, not in the
compiler. (test passes with -fno-threadsafe-statics). Thank you for support.
--
sergei_lus at yahoo dot com changed:
What
--- Comment #2 from luisgpm at linux dot vnet dot ibm dot com 2009-04-30
19:38 ---
Created an attachment (id=17786)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17786action=view)
Last tree pass for the bad code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
--- Comment #1 from danglin at gcc dot gnu dot org 2009-04-30 19:47 ---
Still present in 4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-30 19:51 ---
bb 45:
# crkveuk_lsm.686_3635 = PHI crkveuk_lsm.686_517(44)
# cikve_lsm.685_3640 = PHI cikve_lsm.685_528(44)
# crkveuk_lsm.686_3564 = PHI crkveuk_lsm.686_517(44)
Interesting, I wonder if that causes expand
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-30 20:17 ---
I am not sure if it is related. Revision 146817 miscompiled 465.tonto in
SPEC CPU 2006 on Linux/ia32 with
-O3 -msse2 -mfpmath=sse -ffast-math -funroll-loops -m32
The resulting tonto binary generated the wrong
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30
20:57 ---
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o test.exe
That command works
version 4.5.0 20090430 (experimental) [trunk revision 147009] (GCC)
--
Summary: ICE: type mismatch in address expression
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-30 21:07 ---
I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision
146999.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Component|target |libgomp
Target Milestone|---
--- Comment #9 from bonzini at gnu dot org 2009-04-30 21:10 ---
Subject: Re: [4.5 Regression] Bootstrap failure in libjava on
i686-apple-darwin9
I successfully bootstrapped libjava on powerpc-apple-darwin9 at revision
146999.
Interesting, can you try the command-line I
Test gcc.dg/vect/ggc-pr37574.c started failing on powerpc64-linux with -m32 or
-m64 with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=146888
r146888 | rguenth | 2009-04-28 12:16:22 + (Tue, 28 Apr 2009)
with the following options to cc1, which are used in the testsuite:
--- Comment #4 from sje at gcc dot gnu dot org 2009-04-30 21:43 ---
Subject: Bug 39579
Author: sje
Date: Thu Apr 30 21:43:21 2009
New Revision: 147018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147018
Log:
PR middle-end/39579
* gcc.dg/vect/vect-35.c: XFAIL for
--- Comment #13 from meissner at gcc dot gnu dot org 2009-04-30 22:00
---
Subject: Bug 39955
Author: meissner
Date: Thu Apr 30 21:59:49 2009
New Revision: 147021
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147021
Log:
fix for PR 39955
Modified:
trunk/gcc/ChangeLog
The warning printed with -Wignored-qualifiers (warning: type qualifiers
ignored on function return type) seems to be lying. The const on a functions
return type is not actually ignored, as can be demonstrated using typeof(). I
think that the warning should be right and the typeof() behavior
--- Comment #4 from gustcr at yahoo dot com dot ar 2009-05-01 00:10 ---
(In reply to comment #3)
I couldn't find any other gmp or mpfr in the system.
Also tried using the system's ld and as (both version 2.11.2) but the same
error pops up (see below).
Using ps ax I checked that the
Consider the following test case:
program defallocatable
implicit none
! Demonstrate structure constructors with default initialization
! and allocatable arrays. (Unspecified in F2003, initialized to
! unallocated in F2008.)
type mytype_t
integer, allocatable :: data(:)
end type
88 matches
Mail list logo
