--- Comment #10 from angry-kasyan at narod dot ru 2009-01-13 08:12 ---
(In reply to comment #9)
(In reply to comment #8)
still unfixed?
Please provide a compilable self-contained testcase.
Danny
Here is compilable testcase:
## begin df.cpp
__attribute__((dllimport)) int
--- Comment #19 from steven at gcc dot gnu dot org 2009-01-13 08:19 ---
Joern, nobody is forcing you to follow the crowd if you think the crowd is
going in the wrong direction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-01-13 08:41 ---
From:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00197.html
Looking at the __signbitl issue first. HPPA is the only platform that wants to
export this. Let's try to figure out why.
I see this in
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-01-13 08:42 ---
Created an attachment (id=17082)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17082action=view)
patch for hppa check-abi fail
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33485
--- Comment #8 from bkoz at gcc dot gnu dot org 2009-01-13 08:43 ---
Created an attachment (id=17083)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17083action=view)
check abi fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
--- Comment #5 from rguenther at suse dot de 2009-01-13 08:55 ---
Subject: Re: [4.4 Regression] Missed FRE because
of VIEW_CONVERT_EXPR
On Tue, 13 Jan 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 01:09
---
We
--- Comment #1 from jakub at gcc dot gnu dot org 2009-01-13 09:03 ---
Seems cp_walk_subtrees doesn't handle REINTERPRET_CAST_EXPR, so
check_for_bare_parameter_packs doesn't detect them. Just handling this the
same
as CAST_EXPR seems to fix this testcase.
--
jakub at gcc dot gnu dot
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-13 09:29 ---
I think the best solution is to explore the possibility of lowering the call
to what it will look like in the end - pass return values of variable size
by reference. Hopefully all targets will end up doing this ;)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-13 09:33 ---
Or, can we make that invalid GNU C please? ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 09:51 ---
It should be ok with -fnon-call-exceptions.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-01-13 10:02 ---
Created an attachment (id=17084)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17084action=view)
shiny
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-01-13 10:06 ---
(From update of attachment 17082)
mistaken, part of 32666
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from frikkie at zitera dot co dot za 2009-01-13 10:12
---
Created an attachment (id=17085)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17085action=view)
patch_for_volatile_bitfields_gcc400.tgz
The following patches help to honour the container type of the
--- Comment #13 from frikkie at zitera dot co dot za 2009-01-13 10:42
---
Please note: The patch was for GCC 4.4.0, not GCC 4.0.0 as mentioned in the
previous post.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
(There is another issue with constant folding, which Steve wants to fix.)
The following program compiles with NAG f95/g95/ifort and prints T F. With
gfortran 4.3 and 4.4 it crashes (with 4.1/4.2 it
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-01-13 11:03
---
Smaller testcase for the possible libstdc++ / C++ FE issue, build with
-O2 -finline-functions -Wstrict-aliasing -Wsystem-headers
#include set
class test
{
test();
void bar(int ci);
std::setint foo;
};
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
print *, (-2.0)**2.0
end
is invalid. gfortran should print a diagnostic for -std=f95/f2003/f2008 as NAG
f95 does:
Error: Negative floating-point value raised to a real power
Fortran 2003 in the
the following code shows a performance regression from gcc-4.2 to gcc-4.3 and
4.4 (20090111) on an intel core2 using the x86_64 architecture:
void bench_1(float * out, float * in, float f, unsigned int n)
{
n /= 4;
__m128 scalar = _mm_set_ps1(f);
do
{
__m128 arg =
--- Comment #4 from pkeller at globalphasing dot com 2009-01-13 11:26
---
Thanks for confirming the problem. I know that what I did isn't particularly
portable (although it would be fine on the systems that I work with). I vaguely
remember something about setenv not being available on
On Jan 13, 2009, at 3:08 AM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0f1d7da66fa015c2
print *, (-2.0)**2.0
end
is invalid. gfortran should print a diagnostic for -std=f95/f2003/
f2008 as
--- Comment #1 from pinskia at gmail dot com 2009-01-13 11:28 ---
Subject: Re: New: Diagnose and treat (-2.0)**2.0 properly
On Jan 13, 2009, at 3:08 AM, burnus at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
Found at:
the following two functions are equivalent, adding a scalar to a vector, using
a manual loop unrolling of 8 (2 sse vectors).
the first function serializes the operation, while the second function
interleaves the instructions for two operations:
void bench_3(float * out, float * in, float f,
--- Comment #3 from dominiq at lps dot ens dot fr 2009-01-13 11:37 ---
- Mathematica:
-2^2 = 4, -2.0^2.0 = -4.0
2.0^1.9 = -3.73213 --- probably -2.0^1.9!
Apparently Mathematica parse -2.0^a as -(2.0^a). (-2.0)^1.9 gives 3.54947-
1.15329 I. I don't know if the fortran
--- Comment #2 from dominiq at lps dot ens dot fr 2009-01-13 11:30 ---
The question is whether one needs to reject it completely or only with
-std=f95.
I vote for only with -std=f95 with may be a warning otherwise. I think it is
a legitimate optimization to replace A**B by A**I
--- Comment #15 from laurent at guerby dot net 2009-01-13 12:05 ---
Add URL of gcc-patches discussion
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00409.html
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-01-13 12:14
---
There is only a conditional path through the program that violates aliasing
rules,
likely never executed. We do not detect this fact because of a points-to
solver
issue, PR38826.
--
rguenth at gcc dot gnu dot
The following testcase emits a strict-aliasing warning because the points-to
result for p is wrong. It should be pt_anything, but instead the read from
s.q is considered a non-pointer variable (we do not have constraints for all
implicitly taken addresses by passing s to the function call).
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 12:34 ---
It is interesting to see how taking the address of s.q makes it a pointer
variable. The fundamental issue seems to be that eliminating non-pointers
and their edges conflicts with field-sensitive analysis.
Consider
--- Comment #5 from joseph at codesourcery dot com 2009-01-13 12:52 ---
Subject: Re: [4.2/4.3/4.4 regression] ICE with nested
function
Does standard Ada allow something like this? If so, there's not much
point making it invalid GNU C.
--
--- Comment #4 from rwild at gcc dot gnu dot org 2009-01-13 13:05 ---
(In reply to comment #3)
for ac_var in `(set) 21 |
sed -n 's/^ac_env_\([a-zA-Z_0-9]*\)_set=.*/\1/p'`; do
That happens much earlier than the posted errors.
Thomas, please print the full name of the
--- Comment #2 from rwild at gcc dot gnu dot org 2009-01-13 13:10 ---
Relinking in itself is not a bug. You can avoid it on some systems
(but likely not on yours) with --enable-fast-install.
On some systems it is simply necessary.
If there is a specific problem you have with the
--- Comment #20 from amylaar at gcc dot gnu dot org 2009-01-13 14:00
---
(In reply to comment #19)
Joern, nobody is forcing you to follow the crowd if you think the crowd is
going in the wrong direction.
I have evidence that the direction is wrong. I added a new option to disable
--- Comment #21 from amylaar at gcc dot gnu dot org 2009-01-13 14:11
---
(In reply to comment #20)
office: 1.39% worse
Actually, this is the EEMBC version with bezier01, where the entire benchmark
gets optized away and thus tiny changes in the cost of the set-up code make
--- Comment #22 from rguenther at suse dot de 2009-01-13 14:29 ---
Subject: Re: TreeSSA-PRE load after store missed
optimization
On Tue, 13 Jan 2009, amylaar at gcc dot gnu dot org wrote:
--- Comment #21 from amylaar at gcc dot gnu dot org 2009-01-13 14:11
---
(In reply
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-13 14:37 ---
In fact, field-sensitive points-to analysis is probably not improving things
anyway - a testcase where it does is certainly welcome! - simply due to the
fact that the points-to analysis would need to be more clever
--- Comment #7 from rob1weld at aol dot com 2009-01-13 14:38 ---
Let me clarify the accuracy of my meaning:
When I said: Down in family is not cross compiling. I meant for the purposes
of being able to execute 'target' code on the 'host', 'build' or 'target'
platform (as when
--- Comment #2 from rob1weld at aol dot com 2009-01-13 14:44 ---
(In reply to comment #1)
fixincludes is already registered as PR 25470.
And really PR 3415 is the original bug for it.
*** This bug has been marked as a duplicate of 3415 ***
Hehe ...
Only a few years old.
--
--- Comment #4 from rob1weld at aol dot com 2009-01-13 14:53 ---
(In reply to comment #3)
Coverage builds should not be bootstrapped.
Profiled bootstrap means build stage1 with no opts and then stage2 with
generating the profiling data and then build some target libraries (not all
--- Comment #8 from rob1weld at aol dot com 2009-01-13 14:58 ---
(In reply to comment #7)
Nobody builds using --enable-intermodule, it uses too much memory in general
anyways so closing as won't fix.
We can fix it by reopening this bug and removing --enable-intermodule .
It is
--- Comment #23 from amylaar at gcc dot gnu dot org 2009-01-13 14:58
---
(In reply to comment #22)
If you post a patch to add the option to enable/disable partial-PRE I will
happily review and approve it for 4.4.
I'd be happy to post the patch, but we (ARC) are still waiting for the
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 15:07 ---
I don't see how this changes could cause more branch misses. If you do the
same .palign for the 4.4 code does the regression vanish? I would suspect
that the loop-stream detector catches one but not the other form
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-13 15:08 ---
Try -frename-registers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38825
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-13 15:09 ---
Reopening a bug doesn't fix anything. Patches do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38788
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-13 15:15 ---
Note that your testcase has moved the load _mm_load_ps(in+4); before the
store _mm_store_ps(out, result); which the compiler cannot do itself because
they may alias.
--
--- Comment #7 from rob1weld at aol dot com 2009-01-13 15:17 ---
(In reply to comment #6)
You should not be bootstrapping a --enable-coverage=noopt build, you should
only need to build stage1 gcc.
I only typed make.
If I set --enable-coverage=noopt it should build correctly when I
--- Comment #2 from rob1weld at aol dot com 2009-01-13 15:19 ---
(In reply to comment #1)
Well you don't understand any of these options it seems.
First --enable-coverage=nopt does nothing except changes the CFLAGS really.
There is nothing in the toplevel makefile or configure which
--- Comment #3 from tim at klingt dot org 2009-01-13 15:26 ---
(In reply to comment #1)
Try -frename-registers.
i forgot to mention: the binaries are compiled with -O3 -mfpmath=sse -msse
(4.2, 4.3 and 4.4).
-frename-registers is enabled by -O3
(In reply to comment #2)
Note that
--- Comment #3 from rob1weld at aol dot com 2009-01-13 15:26 ---
(In reply to comment #2)
*** Bug 38746 has been marked as a duplicate of this bug. ***
I think the Bugs in 38746 are more serious (and against the Trunk) than these
discards qualifiers warnings and the ever annoying
--- Comment #4 from spop at gcc dot gnu dot org 2009-01-13 15:33 ---
Subject: Bug 38786
Author: spop
Date: Tue Jan 13 15:33:13 2009
New Revision: 143341
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143341
Log:
2009-01-13 Sebastian Pop sebastian@amd.com
PR
--- Comment #22 from jakub at gcc dot gnu dot org 2009-01-13 15:37 ---
Created an attachment (id=17086)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17086action=view)
gcc44-pr38245.patch
Updated patch (tested with the new testcase on i386/x86_64 and eyeballed
for ppc{,64},
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-13 15:44 ---
-frename-registers does make a difference for me,
.L2:
movaps %xmm0, %xmm2
movaps %xmm0, %xmm1
addps (%rsi,%rax), %xmm2
movaps %xmm2, (%rdi,%rax)
addps 16(%rsi,%rax),
--- Comment #14 from frikkie at zitera dot co dot za 2009-01-13 15:51
---
Created an attachment (id=17087)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17087action=view)
GCC 4.3.2 patch for volatile bitfields
The following patches help to honour the container type of the
--- Comment #6 from frikkie at zitera dot co dot za 2009-01-13 15:56
---
Good day,
I've submitted patches to bug report 23623
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623)
that corrects the behavior described in this bug report.
There are patches for GCC 4.3.2 and GCC 4.4.0.
I originally found this problem when trying to compile a Java package written
by the Universität Stuttgart's institute IKR. I was using Debian's gcj
package, version 4.3.2-2, but can likewise reproduce this using SVN trunk, as
well as Debian's 4.2.4-4 package.
I completely reduced the test case
--- Comment #5 from tim at klingt dot org 2009-01-13 16:08 ---
(In reply to comment #4)
-frename-registers does make a difference for me,
i can reproduce it, however, -frename-registers is supposed to be enabled by
-O3:
t...@thinkpad:~/workspace/nova-server.git$
--- Comment #2 from tim at klingt dot org 2009-01-13 16:22 ---
(In reply to comment #1)
I don't see how this changes could cause more branch misses. If you do the
same .palign for the 4.4 code does the regression vanish? I would suspect
that the loop-stream detector catches one but
I'm compiling the attached source and inspecting symbols in it:
g++-4.3 -v -save-temps -Wall -Wextra -O2 -fno-inline-small-functions
mylib.cpp -c -o mylib.o
nm mylib.o | c++filt | grep 'serialize'
With -O2 -fno-inline-small-functions (as above), nm gives (as expected):
W void
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-13 16:33 ---
The problem is the following in arith.c:
if (op == INTRINSIC_POWER op2-ts.type != BT_INTEGER)
goto runtime;
Thus it is only run-time evaluated. gfc_arith_power deals so far only with
--- Comment #4 from burnus at gcc dot gnu dot org 2009-01-13 16:35 ---
I wonder whether this should be fixed together with PR 38823.
Currently, (x)**(non-integer) is never be simplified at compile time - and the
simplification would be an obvious place to do the checking.
--
--- Comment #1 from ronan dot lehy at probayes dot com 2009-01-13 16:35
---
Created an attachment (id=17088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17088action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-01-13 16:37 ---
Yes, the alias sets are not properly transfered to RTL:
;; MEM[base: out, index: ivtmp.58] = result;
(insn 22 21 0 /usr/lib64/gcc/x86_64-suse-linux/4.4/include/xmmintrin.h:951 (set
(mem:V4SF (plus:DI (reg/v/f:DI
--- Comment #2 from ronan dot lehy at probayes dot com 2009-01-13 16:39
---
(In reply to comment #1)
Created an attachment (id=17088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17088action=view)
I had to trim a bit the source to be make the preprocessed source fit into 1000
--- Comment #7 from joseph at codesourcery dot com 2009-01-13 16:39 ---
Subject: Re: Incorrect memory access type used used in accessing
bitfields
On Tue, 13 Jan 2009, frikkie at zitera dot co dot za wrote:
I've submitted patches to bug report 23623
--- Comment #3 from ronan dot lehy at probayes dot com 2009-01-13 16:42
---
Created an attachment (id=17089)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17089action=view)
Original source (#includes Boost headers).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
--- Comment #10 from dodji at gcc dot gnu dot org 2009-01-13 16:50 ---
Subject: Re: [4.2/4.3/4.4 Regression] template parameter does
not hide class name
jakub at gcc dot gnu dot org a écrit :
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-12 23:00 ---
The 4.3
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-13 17:18 ---
As the asserts aren't on the trunk, this isn't really a regression, we've been
emitting bogus unwind info in these cases (and many more than now) before as
well.
--
jakub at gcc dot gnu dot org changed:
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-13 17:49 ---
Closing.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Compiling the following program gives the error:
Error: Type 'y_c' at (1) is a parameter to the BIND(C) procedure 'wrapper' but
is not C interoperable because derived type 'ty_c' is not C interoperable
It works if one moves the TYPE declaration up. It also works with the
SUBROUTINE is not
--- Comment #4 from jakub at gcc dot gnu dot org 2009-01-13 18:07 ---
Simplified testcase:
extern int bar (void);
volatile int g;
int
foo (void)
{
int a = 1 = bar ();
if ((1 9223372036854775807LL - a 1 - a ? : 1 + a) 1)
return g;
return 0;
}
--
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-13 18:12 ---
Subject: Bug 38795
Author: jakub
Date: Tue Jan 13 18:11:50 2009
New Revision: 143351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143351
Log:
PR c++/38795
* tree.c (cp_walk_subtrees): Handle
--- Comment #3 from jakub at gcc dot gnu dot org 2009-01-13 18:12 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
I would like to see a new gfortran extension added so that the Variable Format
Expression I/O capability will be available with gfortran as it is on many
commercial compilers. Such a capability was once proposed as an addition to
the Fortran 95 standard but was not accepted for some reason.
--
--- Comment #3 from dberlin at gcc dot gnu dot org 2009-01-13 18:42 ---
Subject: Re: points-to result wrong for reads
from call-clobbered vars
Interesting.
I have emailed some others for their thoughts.
One way to eliminate this bug would be to mark the entire structure as
On Jan 13, 2009, at 8:03 AM, tschwinge at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
I originally found this problem when trying to compile a Java
package written
by the Universität Stuttgart's institute IKR. I was using Debian's
gcj
package, version 4.3.2-2, but can likewise
--- Comment #1 from pinskia at gmail dot com 2009-01-13 19:22 ---
Subject: Re: New: gcj emitting incorrect code
On Jan 13, 2009, at 8:03 AM, tschwinge at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
I originally found this problem when trying to compile a Java
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2009-01-13 19:43 ---
Subject: Re: New: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:08:40AM -, burnus at gcc dot gnu dot org wrote:
Fortran 2003 in the second sentence of the second
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2009-01-13 19:44 ---
Subject: Re: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:28:05AM -, pinskia at gmail dot com wrote:
-2.0^1.9 will be a complex number. Maybe we can define it as
--- Comment #7 from domob at gcc dot gnu dot org 2009-01-13 19:47 ---
Created an attachment (id=17090)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17090action=view)
Another test case
This seems to be yet another test triggering this ICE.
--
Hi,
I compiled BLAS and LAPACK with the gfortran compiler of the graphite
branch such that I could test the CP2K benchmark. On my laptop, that
is an amd64-linux, make test passes with the gfortran compiler from
the graphite branch. However I'm not able to run the test that you
reported failing:
--- Comment #28 from sebpop at gmail dot com 2009-01-13 19:52 ---
Subject: Re: [graphite] several ICEs with CP2K (summary)
Hi,
I compiled BLAS and LAPACK with the gfortran compiler of the graphite
branch such that I could test the CP2K benchmark. On my laptop, that
is an
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2009-01-13 19:55 ---
Subject: Re: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:30:40AM -, dominiq at lps dot ens dot fr wrote:
--- Comment #2 from dominiq at lps dot ens dot fr
The attached program gives an ICE:
bash-3.2# gfortran-dev reduced.f03
reduced.f03: In function 'mysql_library_shutdown':
reduced.f03:24: internal compiler error: in bitmap_first_set_bit, at
bitmap.c:770
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2009-01-13 19:58 ---
Subject: Re: Diagnose and treat (-2.0)**2.0 properly
On Tue, Jan 13, 2009 at 11:37:25AM -, dominiq at lps dot ens dot fr wrote:
--- Comment #3 from dominiq at lps dot ens dot fr
--- Comment #9 from mikael at gcc dot gnu dot org 2009-01-13 20:08 ---
(In reply to comment #2)
I think it is
a legitimate optimization to replace A**B by A**I (with I=B) when B is known
to
be an integer, hence to accept negative values for A in this case.
You can use A**I
--- Comment #1 from domob at gcc dot gnu dot org 2009-01-13 19:56 ---
Created an attachment (id=17091)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17091action=view)
Test case
This is the program ICE'ing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38831
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-13 20:31 ---
Needed for legacy code; internal I/O allows the same (and more powerful) albeit
a bit lengthier.
Cf. http://gcc.gnu.org/ml/fortran/2009-01/msg00167.html
and
--- Comment #29 from jv244 at cam dot ac dot uk 2009-01-13 20:33 ---
(In reply to comment #28)
the graphite branch. However I'm not able to run the test that you
reported failing:
./cp2k.sopt canonical.inp
CP2K: The specified file canonical.inp can not be opened, it does not
Running the test program from the attached tarfile
produces the expected output:
shared_lib/testuser export LD_LIBRARY_PATH=../installed_lib
shared_lib/testuser ./appl_main
Here is appl_main, now calling Pkg.Proc ...
Pkg.Proc: X is 2
Here is appl_main, back from calling Pkg.Proc: end of program.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-13 20:37 ---
Can you see if the normal eclipse compiler that comes with the eclipse IDE has
the same issue, and maybe report it to them if so?
GCJ no longer includes a source compiler, we use the eclipse compiler (this was
done
--- Comment #1 from oliver dot kellogg at eads dot com 2009-01-13 20:39
---
Created an attachment (id=17092)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17092action=view)
source code and makefiles for the test application
Usage:
$ tar xvzf gnat-shared_lib.tgz
$ cd shared_lib
$
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-13 20:39 ---
The single CC user is modified, then those changes are reverted, but
unfortunately they aren't reverted by putting back the old content, but instead
tweaking the new comparison with PUT_CODE.
SUBST (*cc_use,
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-01-13 20:39 ---
Other circumstances include co-processing. You want to compile for your
favorite hardware, Xbox or PSP
HEHE, funny you mentioned the PSP, you know that I work for Sony on their GCC
for PS3 compilers. So I cross
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-13 20:43 ---
serialize with an empty body is a pure function so it will be can be optimized
away without any effects. I don't see the issue here really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-01-13 20:46 ---
Also since it is not explicitly instatinated, the template does not need to be
in the object file really.
Can you give a better example of why do you think this is wrong besides a nm
testcase? It might be due to
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-13 20:46 ---
This is a dup of PR 20618, which was closed as WONTFIX at the time.
The semantics of variable formats are very tricky (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618#c1 ),
so this is hard to get right.
--
--- Comment #5 from thomas dot jourdan at gmail dot com 2009-01-13 20:50
---
Created an attachment (id=17093)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17093action=view)
Configure and build log
This patch contains the full build log of the cross tool chain.
--
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-13 20:57 ---
Created an attachment (id=17094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17094action=view)
gcc44-pr38774.patch
Patch I'm going to bootstrap/regtest. Fixes the testcase on both i686-linux
and x86_64-linux.
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-01-13 20:59 ---
(In reply to comment #6)
Created an attachment (id=17094)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17094action=view) [edit]
gcc44-pr38774.patch
Patch I'm going to bootstrap/regtest. Fixes the
1 - 100 of 124 matches
Mail list logo
