--- Comment #9 from janus at gcc dot gnu dot org 2009-04-07 07:25 ---
Subject: Bug 38920
Author: janus
Date: Tue Apr 7 07:24:37 2009
New Revision: 145651
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145651
Log:
2009-04-07 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #10 from janus at gcc dot gnu dot org 2009-04-07 07:32 ---
Fixed with r145651 (I messed up the PR number in the ChangeLog entry, though).
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2009-04-07 07:34 ---
Oops. The commit in comment #9 was actually for PR38290, but I accidentally
messed up the PR number in the ChangeLog. Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 07:55 ---
(In reply to comment #2)
It'd be nice to know if -fno-tree-reassoc helped here.
Yes that solves the problem. I tried for -O[123s] (x86 and avr).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
With option -fdollar-ok the compiler does not recognize symbols that start with
$
test case:
program test
a$a = 12
$a = 12! error
end
I currently have a lot of legacy code with identifiers starting with $.
--
Summary: dollar sign in entities is
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-07 08:42 ---
Confirmed. Checked 4.3.4 and 4.5.0, both complain about '$a'.
Question is, if this is allowed at all. In comparison: digits are allowed in
function names, but not as the first character; 'FUNCTION f3()' is valid,
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 08:51
---
Fixed for 4.4.0 too. Thanks Jason.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from anickol at yahoo dot com 2009-04-07 08:59 ---
As I already said, I have code, being compiled with MS Fortran, that has
a lot of variable names starting with $. MS Fortran allows it.
My personal opinion is that the Fortran compiler's primary use is support
of the
--- Comment #11 from singler at gcc dot gnu dot org 2009-04-07 09:09
---
I found a shorter solution: Just parametrize equal_to with const T instead of
T. Better?
In general, passing the element to find as const ref is the safest we can do,
isn't it? AFAIK the other option is to not
--- Comment #12 from singler at gcc dot gnu dot org 2009-04-07 09:10
---
Created an attachment (id=17598)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17598action=view)
Patch differently parametrizing equal_to.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-07 09:12 ---
Question is, if this is allowed at all. In comparison: digits are allowed in
function names, but not as the first character; 'FUNCTION f3()' is valid,
'FUNCTION 3f()' is not.
My fortran book says:
names must
--- Comment #2 from wvangulik at xs4all dot nl 2009-04-07 09:51 ---
The problem is it uses R22 as loop counter and as the shift counter. I could
not (yet) reproduce the problem in a smaller example.
This could be the same problem as:
--- Comment #15 from janus at gcc dot gnu dot org 2009-04-07 11:40 ---
Reopening.
proc_decl_13.f90 produces a segfault when compiled with -g.
Backtrace:
#0 0x00f4bee1 in htab_hash_string (p=0x0) at
/home/jweil/gcc45/trunk/libiberty/hashtab.c:812
#1 0x005ff979 in
--- Comment #17 from jakub at gcc dot gnu dot org 2009-04-07 12:11 ---
All !DECL_IGNORED_P VAR_DECLs should have DECL_SOURCE_LOCATION set to something
other than UNKNOWN_LOCATION. So, either the FE forgot to set it, or it didn't
set DECL_IGNORED_P flag when it should.
--
--- Comment #2 from rguenther at suse dot de 2009-04-07 12:14 ---
Subject: Re: Local statics not promoted to
const
On Tue, 7 Apr 2009, hubicka at ucw dot cz wrote:
--- Comment #1 from hubicka at ucw dot cz 2009-04-07 11:44 ---
Subject: Re: New: Local statics not
-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap
--disable-multilib
Thread model: posix
gcc version 4.5.0 20090407 (experimental) (GCC)
bash-4.0$ pwd
/home/user/d/vim7.2
bash-4.0$ make
Starting make in the src directory.
If there are problems, cd to the src directory
--- Comment #16 from janus at gcc dot gnu dot org 2009-04-07 11:43 ---
(In reply to comment #15)
proc_decl_13.f90 produces a segfault when compiled with -g.
Sorry. Of course I'm talking about proc_ptr_13.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
--- Comment #2 from abhinav dot dubey at hcl dot in 2009-04-07 10:39
---
(In reply to comment #0)
tring to compile batch libraries with make commang but geeting an error
$ make -f retek.mk retek rms resa 21 | tee libretek.log
cc -DNDEBUG -I. -I/data/rmsdb/rms/oracle/lib/src
tring to compile batch libraries with make commang but geeting an error
$ make -f retek.mk retek rms resa 21 | tee libretek.log
cc -DNDEBUG -I. -I/data/rmsdb/rms/oracle/lib/src
-I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public
-I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/public
--- Comment #4 from abhinav dot dubey at hcl dot in 2009-04-07 11:46
---
(In reply to comment #3)
Please help me in solving this issue also...
Your Makefile expects Sun CC and you're using GCC.
There should not be any difference as i directed cc to gcc
$ cc -v
Reading specs from
--- Comment #1 from hubicka at ucw dot cz 2009-04-07 11:44 ---
Subject: Re: New: Local statics not promoted to const
ipa-reference definitly is supposed to do this transform. I will debug
why it does not in this testcase.
Honza
--
--- Comment #18 from janus at gcc dot gnu dot org 2009-04-07 12:41 ---
Patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 145652)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -1015,10
For
int foo(void)
{
static int blah = 1;
return blah;
}
we should be able to promote blah to TREE_READONLY during ipa-reference (or
local analysis) if blah does not have its address taken and is not written
to in the function body.
This occurs for example in 189.lucas via
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-07 10:42
---
Please help me in solving this issue also...
Your Makefile expects Sun CC and you're using GCC.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2009-04-07 09:23 ---
from error.c(error_print)
00470 case 'u':
00471 arg[pos].type = TYPE_UINTEGER;
00472
00473 case 'l':
00474 c = *format++;
00475 if (c == 'u')
00476
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-07 10:18 ---
Note that '$a' is also rejected by g77.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-07 10:08
---
also try to compile by gcc comman ... the famous hello word program..
$ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o
$ gcc -c abhi.o abhi.c
gcc: abhi.o: linker input file unused because linking not done
..
When trying to build on Sparc/Sun-Solaris 2.8 with cc command from SUN Forte
6.2, we have compilation error because of assignation between const and non
const variables.
I have patched the source code with problem (2 files) in order to compile it.
The patch file is joined with this bug report to
--- Comment #1 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:03
---
Created an attachment (id=17599)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17599action=view)
Modofed source files in order to compile on Sun/Solaris 2.8 with forte 6.2 C
compiler
--
typedef struct {
float vertexAttrib[16][4];
float vertexAttribPre[16][4];
float rasterAttrib[16][4];
float rasterAttribPre[16][4];
} CRCurrentState;
void crStateCurrentInit(CRCurrentState *c)
{
unsigned int i;
for (i = 0; i 16; i++)
{
(c-vertexAttribPre[i])[0] =
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-07 13:13
---
This Bugzilla is for *GCC*, which has nothing to do with the Sun compiler.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--8--
#include functional
int fn(long, float) {
return 0;
}
int main(int argc, char *argv[]) {
typedef std::result_ofdecltype(fn)::type type;
return 0;
}
--8--
$ g++ -std=c++0x testcase.cpp
In file included from
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 13:19
---
Note that *most* of the facilities in functional are still following the TR1
specifications, thus, in general, do not expect conformance to the latest C++0x
draft (or file a DR for each unimplemented behavior
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-07 13:20 ---
But the patch is against gcc and we support building with other host compilers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-07 13:20 ---
We need preprocessed source to reproduce the bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 13:22
---
Ah, by *compile* they mean *building* GCC iself ;) Ok, then this PR should be
tweaked quite a bit (C++?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
--- Comment #5 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:25
---
Yes, but building GCC (as said) with Sun compiler (or other) has to do with
GCC.
(In reply to comment #2)
This Bugzilla is for *GCC*, which has nothing to do with the Sun compiler.
--
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 13:26 ---
(In reply to comment #2)
The problem is it uses R22 as loop counter and as the shift counter. I could
not (yet) reproduce the problem in a smaller example.
This is my minimal test case:
static uint16_t
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 13:28
---
Yes, but please fix your report: the issue has nothing to do with c++, I guess.
Also Host / Target / Build should likely be just sparc-sun-solaris2.8, no?
--
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:29
---
There should not be any difference as i directed cc to gcc
Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you
need to use Sun CC.
--
ebotcazou at gcc dot gnu dot org changed:
--- Comment #1 from bonzini at gnu dot org 2009-04-07 13:42 ---
More info from Solaris bug # 6323525:
if (number_of_cores() 2) then don't have bug
if (family == 0xf Model 0x40) then have bug
if (rdmsr(MSR_BU_CFG/*0xC0011023*/) 2) then bug is masked
See also
--- Comment #7 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:35
---
(In reply to comment #6)
Yes, but please fix your report: the issue has nothing to do with c++, I
guess.
Also Host / Target / Build should likely be just sparc-sun-solaris2.8, no?
I don't know if it is
--- Comment #5 from burnus at gcc dot gnu dot org 2009-04-07 13:43 ---
Many compilers support $ signs as extension (ISO standard Fortran does not).
However, only a few support a leading $ sign. One of the questions which
immediately come up, which data type is $foo (implicit typing).
I
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:38
---
Thanks a lot , Is there any workaround for this problem,Becouse SunCC compiler
is paid.
You need to read the documentation of the software you're trying to build and
see whether GCC is supported; if so, follow
The code shown below works nicely when compiled with -O2 or -O2 -g.
However, it fails when compiled with -g, but only for std::complexfloat. For
the other types it works well. Valgrind gives piles of uninitialized value
errors.
The same results are obtained when building on other Linux platforms.
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 13:54
---
Explain what do you mean by fails.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
From
http://code.google.com/p/google-perftools/source/browse/trunk/src/base/atomicops-internals-x86.h
bool has_amd_lock_mb_bug; // Processor has AMD memory-barrier bug; do lfence
// after acquire compare-and-swap.
...
inline Atomic32
--- Comment #6 from abhinav dot dubey at hcl dot in 2009-04-07 13:34
---
(In reply to comment #5)
There should not be any difference as i directed cc to gcc
Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you
need to use Sun CC.
Thanks a lot , Is there any
--- Comment #2 from diepen at astron dot nl 2009-04-07 14:03 ---
The output does not show the correct results. It looks as if the imaginary part
of the complex number in the bind2nd object is incorrect. When debugging the
bind2nd object was constructed correctly, but when used in
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-04-07 14:05
---
(In reply to comment #1)
Note that *most* of the facilities in functional are still following the TR1
specifications, thus, in general, do not expect conformance to the latest
C++0x
draft (or file a DR
Hi, I'am one of the lead developers from Linux Verification Center
(http://www.linuxtesting.org/) at ISPRAS in Russia. Last several years we make
instruments for linux testing along with the Linux Foundation
(http://linuxfoundation.org/) under the LSB-Infrastructure project. Some our
instruments
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:11
---
Are you *really* sure the simplified testcase was supposed to work per the TR1
specifications? The author of thar code is Doug Gregor, and it never did in
GCC.
--
--- Comment #1 from susanin at ispras dot ru 2009-04-07 14:13 ---
Created an attachment (id=17600)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17600action=view)
This patch add some absent function attributes to the tree-dump
--
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:15
---
I'm looking at 3.4/3 in n1836, and my answer is *no*.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:17
---
Yes, you are right. Apparently some sort of miscompilation. The problem does
not happen when using the C++ runtime + a different C++ compiler, by the way.
Let's look further into it... The other possibility is
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:23
---
Richard, can I have your opinion about this? Thanks in advance!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Hi everyone
The following code cannot pass compilation by g++ v4.3.2.
#include functional
#include algorithm
#include iostream
#include string
#include memory
#include vector
using namespace std;
class test
{
public:
void func(int i) { wcout i L: test\n; }
};
namespace
{
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-04-07 14:31
---
So it is a purely C++0x bug, as you indicated in your first reply.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 14:33
---
Current mainline is fine. I can reproduce on x86_64-linux with 4_3-branch and
4_4-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 14:34
---
Yes, a purely unimplemented C++0x feature.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-07 14:45
---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-04-07 14:45
---
I think you have the syntax wrong, if you want to know the return type of a
function type (or function pointer, or function reference) you need to say:
result_ofint (*(long, float))(long ,float)::type
what
--- Comment #2 from axel-freyn at gmx dot de 2009-04-07 14:45 ---
Created an attachment (id=17601)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17601action=view)
shorter testcase
testcase sufficient for ICE on gcc version 4.3.2 (Debian 4.3.2-1.1), Target:
x86_64-linux-gnu
--
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-07 14:46 ---
(In reply to comment #2)
As I already said, I have code, being compiled with MS Fortran, that has
a lot of variable names starting with $. MS Fortran allows it.
My personal opinion is that the Fortran compiler's
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 14:47
---
Yes, that would work, we even have testcases for it. But what about C++0x,
Jonathan? Seems strange that only that more convoluted syntax is right...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-04-07 14:51
---
This is not a bug in C++0x either. The spec is:
Given an rvalue fn of type Fn and values t1, t2, ..., tN of types T1, T2, ...,
TN in ArgTypes, respectively,
the type member is the result type of the expression
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-07 14:51 ---
The expected output is
10 10
10 10
(10,0) (10,0)
(10,0) (10,0)
correct? With -O0 I get
10 10
10 10
(nan,nan) (nan,nan)
(10,0) (10,0)
while for -m32 it is ok. So it appears only the float variant is affected?
--- Comment #7 from kargl at gcc dot gnu dot org 2009-04-07 14:54 ---
(In reply to comment #5)
Many compilers support $ signs as extension (ISO standard Fortran does not).
However, only a few support a leading $ sign. One of the questions which
immediately come up, which data type is
--- Comment #2 from bonzini at gnu dot org 2009-04-07 15:02 ---
I cannot see any better alternative, but I'll point out that saying
wrong-code is not exact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 15:08
---
Well, *cannot* be still an issue exactly in these terms, because there are no
log2* functions any more in the code...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
--- Comment #3 from hubicka at ucw dot cz 2009-04-07 15:14 ---
Subject: Re: Local statics not promoted to const
I think it only adjusts global statics.
This is why I originally implemented varpool to have both local and
global static alike, so it should not.
Well, time to debug it
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18
---
*** Bug 39635 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18
---
This looks like a duplicate of bug #39386.
*** This bug has been marked as a duplicate of 39386 ***
--
eric dot weddington at atmel dot com changed:
What|Removed
--- Comment #5 from eric dot weddington at atmel dot com 2009-04-07 15:23
---
Adding additional version numbers in the known-to-fail field from comment in
duplicate bug #39635. Still waiting to hear if bug is present in 4.4.
--
eric dot weddington at atmel dot com changed:
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-07 15:29 ---
Minor data point (-O1 -g):
movss 4(%rbx), %xmm3
movss (%rbx), %xmm2
movss (%rsp), %xmm1
movss 4(%rsp), %xmm0
call__mulsc3
Breakpoint 1, 0x77667990 in
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 15:32
---
Ok, give me a few minutes, I'm going to dig a bit further...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
Note: This enhancement request (in my opinion) is related with the compiler
frontend (of C++ and probably also C) and can be applied to all platforms.
Given a .cpp file (3 lines below only, nothing else);
int main()
{
int* p = new foo;
}
When tried to compile gives the following error:
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 15:37
---
FWIW, the EDG C++ front-end issues a very similar error message ;)
39681.C(3): error: expected a type specifier
int* p = new foo;
^
--
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-04-07 15:40
---
See what I wrote at http://gcc.gnu.org/ml/libstdc++/2008-09/msg00124.html under
point 3)
You want this:
typename std::result_of decltype(traitsT::restore) (S*) ::type
Paolo, let's close this.
--
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-04-07 15:42
---
(In reply to comment #12)
typename std::result_of decltype(traitsT::restore) (S*) ::type
Oops, that should be S not S*
It's not perfect, but for this case std::result_of works if you get the syntax
right :)
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-07 15:44 ---
Wait - it's ok.
class binder2nd
: public unary_functiontypename _Operation::first_argument_type,
typename _Operation::result_type
{
protected:
_Operation op;
typename
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 15:45
---
Agreed ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-07 15:45
---
It seems to be an ABI mismatch in the backend somehow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-04-07 15:46
---
Created an attachment (id=17603)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17603action=view)
preprocessed testcase with bind2nd marked noinline
Testcase, look at the compiled piece for the call to
--- Comment #15 from piotr dot wyderski at gmail dot com 2009-04-07 15:47
---
Subject: Re: std::result_of doesn't work
jwakely dot gcc at gmail dot com gcc-bugzi...@gcc.gnu.org:
You want this:
typename std::result_of decltype(traitsT::restore) (S*) ::type
Thank you! :-)
Paolo,
--- Comment #12 from paolo dot carlini at oracle dot com 2009-04-07 15:48
---
You are too fast ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-04-07 15:57
---
The intel compiler generates
..___tag_value__ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_.69:
#165.5
movq (%rsi), %rax #167.53
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-07 16:04
---
With a small testcase it works:
struct Y {};
struct X {
Y y;
float real;
float imag;
};
struct X __attribute__((noinline))
foo (float *p)
{
struct X x;
x.real = p[0];
x.imag = p[1];
return x;
}
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-07 16:05
---
So maybe it's a C++ FE issue after all ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-07 16:24
---
Sorry for the noise, forgot that we don't care any more about 4_1 and 4_2 ;)
Anyway, the issue is apparently *very* old...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #19 from janus at gcc dot gnu dot org 2009-04-07 16:24 ---
Subject: Bug 38152
Author: janus
Date: Tue Apr 7 16:24:31 2009
New Revision: 145692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145692
Log:
2009-04-07 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #17 from paolo dot carlini at oracle dot com 2009-04-07 16:44
---
I guess I'm going to reduce the big one with 'delta', if you have special
advice about that, just let me know...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
--- Comment #7 from info dot gnu at rt-labs dot com 2009-04-07 16:52
---
*** Bug 39663 has been marked as a duplicate of this bug. ***
--
info dot gnu at rt-labs dot com changed:
What|Removed |Added
--- Comment #4 from info dot gnu at rt-labs dot com 2009-04-07 16:52
---
You're right, I tried both examples you mentioned, i'll point this to #35466
that seems to point out the problem you described about.
*** This bug has been marked as a duplicate of 35466 ***
--
info dot gnu
/opt/gcc-4.3.3/bin/gfortran -ffixed-line-length-0 -g-c
-I/Volumes/Users/bmayer/Desktop/download/netcdf-4.0/f90 driver.F90
driver.F90:170.25:
call write_input(crm_input_test.nc, lchnk, 1, icol, plev2, ps, pmid,
1
Warning: Character length of actual argument
--- Comment #25 from jason at gcc dot gnu dot org 2009-04-07 17:49 ---
Subject: Bug 25185
Author: jason
Date: Tue Apr 7 17:48:52 2009
New Revision: 145697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145697
Log:
PR c++/25185
* c-common.h, c-common.c: Add
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-07 17:51 ---
Could you please attach a (ideally) minimal testcase that reproduces the error?
Thanks.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-07 18:28 ---
this dump file is only supposed to be used to debug gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
1 - 100 of 133 matches
Mail list logo
