http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
Summary: [4.6 Regression][OOP] Segfault with TBP
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455
--- Comment #13 from Tobias Burnus 2011-02-01
08:50:39 UTC ---
(In reply to comment #12)
> "valgrind ./a.out" shows:
That seems to be a valgrind bug; even a simple Fortran program consisting of
"end" causes the problem.
The crash with comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #9 from Iain Sandoe 2011-02-01 09:08:53
UTC ---
Jack,
The linkage of libs (with trunk darwin.h) is like this:
libgcc_ext.dylib ---> exports our additional symbols (ONLY)**
libSystem > contains the annotated system symbols.
**
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46990
--- Comment #7 from Tobias Burnus 2011-02-01
09:26:52 UTC ---
A variant is
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/dad37643dd8cd0c6
where the defined assignment has:
elemental subroutine assign (a, b)
class(ba
cp2k.sopt.ltrans1.s -v
GNU GIMPLE (GCC) version 4.6.0 20110201 (experimental) [trunk revision 169466]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110201 (experimental) [trunk revision
169466], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456
--- Comment #10 from Mikael Pettersson 2011-02-01
09:40:18 UTC ---
Your test case requires using binaries without sources on Win32.
You can:
1. Try a newer gcc, preferably 4.5.2. Your pre-4.3.0 development snapshot is
ancient and likely to con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #1 from Joost VandeVondele
2011-02-01 09:42:12 UTC ---
gzipped testcase (2.7Mb) downloadable from
http://www.pci.uzh.ch/vandevondele/tmp/cp2k.sopt.ltrans1.o.gz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Summary: Wrong output for small absolute values with F editing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541
--- Comment #11 from Richard Guenther 2011-02-01
09:47:26 UTC ---
Author: rguenth
Date: Tue Feb 1 09:47:21 2011
New Revision: 169468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169468
Log:
2011-02-01 Richard Guenther
PR tree-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568
Summary: Name lookup: different behavior 4.1.2 / 4.5.0
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
--- Comment #6 from Mikael Pettersson 2011-02-01
10:11:52 UTC ---
The bug started to occur at r140501:
Author: pinskia
Date: Fri Sep 19 22:24:06 2008
New Revision: 140501
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140501
Log:
2008-09
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540
Richard Earnshaw changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
Summary: gfortran does not detect that the parameters for
passing a partial string to a subroutine are
incorrect.
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47560
Paolo Carlini changed:
What|Removed |Added
CC||bkoz at redhat dot com
--- Comment #1 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541
Jakub Jelinek changed:
What|Removed |Added
Known to work||4.4.4, 4.6.0
Summary|[4.5/4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47557
--- Comment #1 from Richard Guenther 2011-02-01
11:17:53 UTC ---
I think the current behavior is correct.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47570
Summary: "one() >= 0" isn't constexpr for unsigned int, yet ==
and > is.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541
--- Comment #13 from Richard Guenther 2011-02-01
11:27:07 UTC ---
Author: rguenth
Date: Tue Feb 1 11:27:04 2011
New Revision: 169472
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169472
Log:
2011-02-01 Richard Guenther
PR tree-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122
--- Comment #16 from Zdenek Dvorak 2011-02-01
11:27:13 UTC ---
(In reply to comment #15)
> Ah, the reason why pr19210-* fail is that those loops have non-const/pure call
> in it. So, while single_exit (loop) == exit, loop_only_exit_p (loop, exit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47541
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #2 from Tobias Burnus 2011-02-01
11:33:33 UTC ---
A bit unrelated to the reported problem, but I wonder whether the
coarray/coindexed part is already correctly checked for:
"If the actual argument is a coindexed scalar, the correspon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #13 from Richard Guenther 2011-02-01
11:35:08 UTC ---
It's unfortunate that graphite inserts arrays of size 1 instead of scalar
(memory) vars. Otherwise update-address-taken would just re-write those
into SSA after going out-of-graph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #14 from Richard Guenther 2011-02-01
11:45:44 UTC ---
Noting that pass_graphite_transforms lacks any verifier calls, the following
would enable the cleanup (in case scalar vars would have been used).
Index: gcc/tree-ssa-loop.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
--- Comment #4 from Richard Guenther 2011-02-01
11:50:39 UTC ---
Sounds similar to other reports that build on i?86 without -msse and
a target attribute that enables some more SSE features.
Try with -msse, if that works this is invalid (and a du
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46692
--- Comment #3 from Sebastien Bourdeauducq
2011-02-01 11:52:15 UTC ---
Author: lekernel
Date: Tue Feb 1 11:52:12 2011
New Revision: 169473
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169473
Log:
PR gcc/46692
* config/lm32/t-lm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #2 from Richard Guenther 2011-02-01
11:53:09 UTC ---
I think we need source code (LTO bytecode isn't really portable).
It looks like that vuse is somehow bogus - mind posting the output of
(gdb) call debug_tree (vuse)
at that point
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46692
Sebastien Bourdeauducq changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #3 from Joost VandeVondele
2011-02-01 12:04:46 UTC ---
(In reply to comment #2)
> I think we need source code (LTO bytecode isn't really portable).
oops... that's building CP2K. Let me see if I can reproduce this with this
night's ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
Richard Guenther changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #5 from Joost VandeVondele
2011-02-01 12:23:35 UTC ---
(In reply to comment #4)
> That's indeed invalid - it should be an SSA name. This means some
> earlier pass messed up (or PRE itself). The bug shouldn't depend
> on LTO (apart f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #6 from Joost VandeVondele
2011-02-01 12:29:36 UTC ---
to reproduce from sources
wget http://www.pci.uzh.ch/vandevondele/tmp/cp2k.tgz
tar -xzvf cp2k.tgz
cd cp2k/makefiles
make -j ARCH=gfortran-test24 VERSION=sopt
this assumes that y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
Jakub Jelinek changed:
What|Removed |Added
Summary|internal compiler error in |[4.6 Regression] internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #2 from Richard Guenther 2011-02-01
12:53:41 UTC ---
Program received signal SIGINT, Interrupt.
tree_code_size (code=POLYNOMIAL_CHREC)
at /space/rguenther/src/svn/trunk/gcc/tree.c:737
737 }
(gdb) up
#1 0x00c3d049 in m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456
--- Comment #11 from steve.reinke at iws dot fraunhofer.de 2011-02-01 13:14:23
UTC ---
Hi,
I din't found a gcj version 4.5 build for windows.
That's why I tried to use this version.
Do you know where I can get anywhere such a windows build?
Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #10 from Iain Sandoe 2011-02-01 13:25:31
UTC ---
two more minor points.
1/ the trunk lib specs do the same as gcc-4.2.1(apple local)
2/ there are no exported symbols for 10.6 in /usr/lib/libgcc_s.10.5.dylib (they
are all $add$os10.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #3 from Richard Guenther 2011-02-01
13:41:25 UTC ---
With --param scev-max-expr-size=20 (the 4.5 default) trunk uses 300MB ram,
with 21 it uses 580MB with 22 1.2GB, with 23 2.2GB, ... so it indeed
grows exponential (as designed). Bum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926
Tony Poppleton changed:
What|Removed |Added
Last reconfirmed|2008-12-28 06:57:47 |2011-02-01 13:13
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47567
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #11 from Jack Howarth 2011-02-01
13:51:52 UTC ---
Created attachment 23195
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23195
build log for xplor-nih 2.2.7 under gcc trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #12 from Jack Howarth 2011-02-01
13:53:18 UTC ---
Created attachment 23196
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23196
otool -L output for xplor-nih binaries
e --x-libraries=/usr/X11R6/lib
--enable-languages=c,c++,fortran --enable-cloog-backend=legacy
Thread model: posix
gcc version 4.6.0 20110201 (experimental) (GCC)
[frodo:~/xplor-nih-2.27] howarth% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456
--- Comment #12 from Mikael Pettersson 2011-02-01
14:12:12 UTC ---
(In reply to comment #11)
> Hi,
>
> I din't found a gcj version 4.5 build for windows.
> That's why I tried to use this version.
>
> Do you know where I can get anywhere such a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
rtran/intrinsics/time_1.h:211: undefined reference
to `clock_gettime'
collect2: ld returned 1 exit status
This bug is specific to the following build:
http://gfortran.org/download/i686/gfortran-4.6-20110201-linux-i686.tar.gz
Is it due to Patch 81226?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47456
--- Comment #13 from steve.reinke at iws dot fraunhofer.de 2011-02-01 14:28:43
UTC ---
Created attachment 23197
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23197
the src file for the jar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572
Summary: [OOP] Invalid: Allocatable polymorphic with init
expression.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #4 from Richard Guenther 2011-02-01
14:36:04 UTC ---
Author: rguenth
Date: Tue Feb 1 14:36:00 2011
New Revision: 169478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169478
Log:
2011-02-01 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
Richard Guenther changed:
What|Removed |Added
Known to work||4.6.0
Summary|[4.4/4.6 Regr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #14 from Iain Sandoe 2011-02-01 14:37:39
UTC ---
the difference caused by including a reference to "/usr/libgcc_s.xxx" is to
allow a libgcc_s appearing in a DYLD_LIBRARY_PATH (or a fallback path in the
compiler's list) to over-ride ..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
--- Comment #6 from Jakub Jelinek 2011-02-01
14:40:50 UTC ---
Created attachment 23198
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23198
gcc46-pr47564.patch
Ugh, this is ugly.
The problem is that tree_rest_of_compilation calls init_emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47573
Summary: [trans-mem] ICE in invoke_set_current_function_hook
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47547
--- Comment #5 from hjl at gcc dot gnu.org 2011-02-01
14:42:16 UTC ---
Author: hjl
Date: Tue Feb 1 14:42:08 2011
New Revision: 169479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169479
Log:
Check HOST_BIT_BUCKET when settting dump bas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47547
H.J. Lu changed:
What|Removed |Added
Target Milestone|4.6.0 |4.5.3
Summary|[4.5/4.6 Regression] W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #6 from Tony Poppleton 2011-02-01
14:45:28 UTC ---
Out of interest, could this parameter of 20 be automatically tuned based on the
available RAM?
For systems with a lot of RAM, it might make sense to increase the parameter
above 20 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #7 from Richard Guenther 2011-02-01
14:46:56 UTC ---
Hm, you are using -O0 for the compile and -O3 ... for the link step? Should
work in theory, but of course isn't tested thoroughly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
--- Comment #7 from rguenther at suse dot de
2011-02-01 14:48:15 UTC ---
On Tue, 1 Feb 2011, tony.poppleton at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47555
>
> --- Comment #6 from Tony Poppleton
> 2011-02-01 14:45:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #8 from Joost VandeVondele
2011-02-01 14:53:44 UTC ---
(In reply to comment #7)
> Hm, you are using -O0 for the compile and -O3 ... for the link step? Should
> work in theory, but of course isn't tested thoroughly.
Right :-) I'm try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
--- Comment #3 from Tobias Burnus 2011-02-01
14:54:10 UTC ---
(In reply to comment #2)
> Draft patch:
> + || gfc_expr_attr (actual).pointer
That check won't work as "foo(1)" is never a pointer while "foo" might be a
pointer; thus, o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
--- Comment #3 from janus at gcc dot gnu.org 2011-02-01 14:59:45 UTC ---
Author: janus
Date: Tue Feb 1 14:59:40 2011
New Revision: 169480
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169480
Log:
2011-02-01 Janus Weil
PR fortran/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47565
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #2 from Janne Blomqvist 2011-02-01 15:08:13
UTC ---
On Linux/Glibc libgfortran is built with _GNU_SOURCE, which according to the
glibc manual is a superset of all kinds of
_POSIX_C_SOURCE=[latest_supported_standard]
XOPEN_SOURCE=[late
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #15 from Jack Howarth 2011-02-01
15:11:51 UTC ---
DYLD_LIBRARY_PATH is unset when xplor is started. Also remember that your test
case in comment 9 is insufficient to reproduce the behavior of xplor-nih. The
code calling the unwinder s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568
Jonathan Wakely changed:
What|Removed |Added
Known to work||4.4.5
--- Comment #2 from Jonathan Wake
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47569
Tobias Burnus changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47568
--- Comment #3 from Matwey V. Kornilov
2011-02-01 15:24:30 UTC ---
Thanks. What is its bugid? I didn't find something similar and then I filled
this ticket. Probably I looked through not careful enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #16 from Iain Sandoe 2011-02-01 15:26:15
UTC ---
(In reply to comment #15)
> Perhaps r163267 is fragile to certain combination of linker flags (like
> -flat_namespace)?
"fragile" LOL...
man ld:
-flat_namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #4 from Michael Richmond
2011-02-01 15:27:19 UTC ---
(In reply to comment #2)
> OP, what does "ldd /path/to/libgfortran.so.3" say?
linux-gate.so.1 => (0xe000)
libm.so.6 => /lib/libm.so.6 (0xb772b000)
libc.so.6 => /li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #5 from Tobias Burnus 2011-02-01
15:29:50 UTC ---
For the symbols defined in librt, cf.
http://refspecs.freestandards.org/LSB_4.0.0/LSB-Core-generic/LSB-Core-generic/librt.html
Regarding http://gcc.gnu.org/ml/fortran/2011-01/msg00326
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #10 from Richard Guenther 2011-02-01
15:40:30 UTC ---
Testcase:
/* { dg-lto-do run } */
/* { dg-extra-ld-options "-O2 -ffast-math" } */
double cabs(_Complex double);
double __attribute__((used))
foo (_Complex double x, int b)
{
if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47564
--- Comment #7 from Jakub Jelinek 2011-02-01
15:47:07 UTC ---
Following works by not doing target_reinit once tree_rest_of_compilation calls
init_function_start, until final.
--- function.c.jj 2011-01-25 18:40:08.0 +0100
+++ function.c 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #17 from Iain Sandoe 2011-02-01 15:50:44
UTC ---
I guess you could make the requirement to link libSystem before (and after)
libgcc_ext explicit like this:
Index: gcc/config/darwin10.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #6 from Janne Blomqvist 2011-02-01 15:50:52
UTC ---
(In reply to comment #3)
> clock_gettime is defined in librt, so if libgfortran started using librt
> symbols, it needs to a) link against it dynamically for libgfortran.so
Yes, tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47572
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47566
--- Comment #11 from Joost VandeVondele
2011-02-01 15:52:42 UTC ---
(In reply to comment #9)
> In file included from :425:0:
> /tmp/cp2k/makefiles/../src/realspace_grid_types.F: In function
> 'rs_pw_transfer_replicated':
> /tmp/cp2k/makefiles/../
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #18 from Iain Sandoe 2011-02-01 15:57:30
UTC ---
(In reply to comment #17)
> I guess you could make the requirement to link libSystem before (and after)
> libgcc_ext explicit like this:
you would also need to ensure that libSystem wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47558
--- Comment #19 from Jack Howarth 2011-02-01
15:59:30 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
>
>
> > Perhaps r163267 is fragile to certain combination of linker flags (like
> > -flat_namespace)?
>
> "fragile" LOL...
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
Janne Blomqvist changed:
What|Removed |Added
Target|i686-pc-linux-gnu |
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #8 from Tobias Burnus 2011-02-01
16:08:10 UTC ---
(In reply to comment #6)
> > clock_gettime is defined in librt, so if libgfortran started using librt
> > symbols, it needs to a) link against it dynamically for libgfortran.so
>
> Ye
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #9 from Jakub Jelinek 2011-02-01
16:13:24 UTC ---
How many fortran users actually need to more precise DATE_AND_TIME though?
Bringing in -lpthread (as dependency of -lrt) certainly has some extra
overhead, e.g. everything that uses gt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559
--- Comment #2 from Richard Guenther 2011-02-01
16:16:04 UTC ---
Author: rguenth
Date: Tue Feb 1 16:15:56 2011
New Revision: 169487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169487
Log:
2011-02-01 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574
Summary: internal compiler error: in build2_stat, at
tree.c:3795
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47559
Richard Guenther changed:
What|Removed |Added
Keywords|wrong-code |
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #10 from Michael Richmond
2011-02-01 16:18:49 UTC ---
(In reply to comment #7)
> As a workaround for the reporter, dynamic linking works fine.
When I use "gfortran -Bdynamic call_date_and_time.f90" I get the same error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47574
Martin Losch changed:
What|Removed |Added
Attachment #23200|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571
--- Comment #11 from Janne Blomqvist 2011-02-01
16:20:06 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > > clock_gettime is defined in librt, so if libgfortran started using librt
> > > symbols, it needs to a) link against it dyna
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47575
Summary: store-motion removes global stores from endless loops
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47575
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
1 - 100 of 208 matches
Mail list logo
