--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-22 06:48 ---
Both
character*(*) foo
character(*) foo
are supported by gfortran. At the moment I cannot imagine a program which works
with the latter and fails with the former. If you have a complete (short!)
example, we
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/543dbbd5a3cb5fce
Jerry, could you check whether Richard Maine's concerns are correct or not? NAG
f95 and g95 write everything in one line; g95 has also a trailing comma, NAG
does not. (ifort 11beta and sunf95 don't
--- Comment #4 from manu at gcc dot gnu dot org 2008-07-22 07:20 ---
Closing as invalid then.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from r dot emrich at de dot tecosim dot com 2008-07-22
07:53 ---
(In reply to comment #5)
For me it is working today
I don't Know if it's related but today (rev. 138048) I get the following on
x86_64-unknown-linux-gnu:
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-22 08:30 ---
This is caused by
static const unsigned int READ_CHUNK = 4096;
and, further down,
n = (base READ_CHUNK) ? base : READ_CHUNK;
where base is a gfc_offset (a signed quantity).
The unsigned is unnecessary.
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-22 09:01 ---
10.10.2 Namelist output
The form of the output produced is the same as that required for input, except
for the forms of real, character, and logical values. The name in the output is
in upper case. With the
the command is :
gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes -mpreferred-stack-boundary=2 -I..
if change -O2 to -O1 , ICE will dispear .
what's wrong ?
--
Summary: ICE when gcc 4.4.0-20080722 compiles glibc 2.6.1/stdio
--- Comment #1 from linuxl4 at sohu dot com 2008-07-22 09:23 ---
Created an attachment (id=15937)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15937action=view)
printf_size.i
gcc printf_size.c -c -std=gnu99 -O2 -fgnu89-inline -Winline -Wwrite-strings
-Wstrict-prototypes
Component|tree-optimization |middle-end
Keywords||ice-on-valid-code
Known to work||4.3.1
Summary|ICE when gcc 4.4.0-20080722 |[4.4 Regression] ICE in
|compiles
--- Comment #6 from manu at gcc dot gnu dot org 2008-07-22 09:46 ---
Subject: Bug 28079
Author: manu
Date: Tue Jul 22 09:45:58 2008
New Revision: 138049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138049
Log:
2008-07-22 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR 28079
--- Comment #7 from manu at gcc dot gnu dot org 2008-07-22 09:48 ---
Fixed in GCC 4.4
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 09:50 ---
Better summary to find duplicates.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-07-22 09:56 ---
No reply for a long time. Old version of GCC. Closing as INVALID.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from manu at gcc dot gnu dot org 2008-07-22 09:59 ---
Not working on this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-22 10:27 ---
Subject: Bug 36890
Author: tkoenig
Date: Tue Jul 22 10:27:10 2008
New Revision: 138050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138050
Log:
2008-07-22 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-22 10:29 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dorit at gcc dot gnu dot org 2008-07-22 10:39 ---
(In reply to comment #1)
One problem is vectorizable_conversion. Is there a way to support
V4DF/V4DI - D4SI/V4SF
V8SI - V8SF
With the current framework, the only way to support
V8SI - V8SF
is to implement the
Trying to compile the following program:
typedef void (*fptr)();
fptr zeroptr = 0;
templatetypename T, fptr F struct foo { };
templatetypename T struct fooT,zeroptr { };
void f() { }
fooint,f m_foo;
I get the message:
test.cpp:6: internal compiler error: in unify, at cp/pt.c:13401
Please submit
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-22 11:48
---
Te be clear, this is ICE on invalid
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-22 11:58 ---
Related to PR 32972 (optimizing cshift the way that other
array intrinsics have been done will cure this).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ro at gcc dot gnu dot org 2008-07-22 12:05 ---
Jan, did you have a chance to take a look? Your patch breaks Tru64 UNIX
bootstrap
since almost 4 months.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-22 12:11 ---
Analogously for:
integer foo(size([x]))
real x
As ifort writes:
error #6279: A specification expression object must be a dummy argument, a
COMMON block object, or an object accessible through host or use
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-22 12:30 ---
(In reply to comment #1)
Proposed patch passed regression test on i686-pc-linux-gnu..
Patch is approved (or obvious and simple, whatever you prefer :-)
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #3 from jhuddleston at hughes dot net 2008-07-22 13:17 ---
Created an attachment (id=15938)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15938action=view)
zip container with two files: C++ and GFORTRAN
burnus at gcc dot gnu dot org requested a small sample set
The attached test case is causing a spurious dependency violation message from
the assembler. The problem seems to be that the assembler is clearing all qp
mutex relations after a call, but the compiler does not emit .pred.rel.mutex
after them.
$ gcc -O2 -c -save-temps xdisp.c
xdisp.s: Assembler
--- Comment #1 from schwab at suse dot de 2008-07-22 13:34 ---
Created an attachment (id=15939)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15939action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36898
--- Comment #2 from schwab at suse dot de 2008-07-22 13:35 ---
Created an attachment (id=15940)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15940action=view)
Assembler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36898
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-22 13:44
---
*** Bug 36896 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2008-07-22 13:44 ---
*** This bug has been marked as a duplicate of 36450 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Small example:
==
#include iostream
#include locale
using namespace std;
int main()
{
locale::global(locale());
wcout.imbue(locale());
wcout Hello world! ðÒÉ×ÅÔ ÍÉÒ! endl;
return 0;
}
--- Comment #1 from mironov dot ivan at gmail dot com 2008-07-22 14:55
---
Created an attachment (id=15941)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15941action=view)
Preprocessed source (utf-8)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36899
--- Comment #1 from oliver dot regenfelder at gmx dot at 2008-07-22 15:32
---
Created an attachment (id=15942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15942action=view)
preprozessor output for the file triggering the bug
--
A small c++ program causes this ICE if optimization level is 1 ore above
[my_computer]$ g++ -v -save-temps -O3 compiler_bug.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared
--- Comment #4 from bonzini at gnu dot org 2008-07-22 15:48 ---
i had a patch to expand pow at the tree level, but it conflicted with fold
(which consistently tried to rebuild pow function calls). the outcome might be
better now that we have PAREN_EXPR, though.
--
bonzini at gnu
From PR35637 but this is a general issue of the diagnostic machinery.
The problem is: -pedantic no warning, -pedantic-errors gives an
error.
Explanation: The pedantic warning is in a system header, so it doesn't get
emitted. When using -pedantic-errors, it is an error, and errors are always
--- Comment #1 from manu at gcc dot gnu dot org 2008-07-22 16:30 ---
One testcase could use #include_next in a system header and compile with just
-pedantic-errors. This should be silent but it currently emits an error.
Another testcase could be just:
static int sc = INT_MAX + 1;
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-07-22 16:47
---
I will check on this later tonight or this week. I have wondered about that
comma myself.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from domob at gcc dot gnu dot org 2008-07-22 17:06 ---
Subject: Bug 29835
Author: domob
Date: Tue Jul 22 17:05:55 2008
New Revision: 138063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138063
Log:
2008-07-22 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-22 17:09
---
Really, there isn't much we can do here: according to the standard
(27.6.2.5.4/4) each char is widened *individually* (via out.widen), and some of
the chars in the character-literal at issue (not belonging to
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-22 17:11 ---
The message locus for constant-string is not yet perfect, but the effort to
benefit ratio in this case is probably rather bad, so I mark this as fixed.
In my commit, I changed the Unexpected element error to include
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-22 17:29
---
Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
suggestions for a fix.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-22 17:47 ---
I will check on this later tonight or this week. I have wondered about that
comma myself.
Thanks! I believe the comma should be valid, even though it is superfluous and
looks wrong. Thus it were nice if one could
--- Comment #3 from manu at gcc dot gnu dot org 2008-07-22 18:07 ---
(In reply to comment #2)
Thanks a lot Manuel! Maybe I will even be able to come to this, thanks to your
suggestions for a fix.
I think there is a problem with my suggestion: -pedantic-errors does not only
affect
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-22 18:25 ---
@jakub: I confirm that doing:
if (!DECL_CONTEXT (decl))
{
DECL_CONTEXT (decl) = current_function_decl;
}
at the beginning of one_static_initialization_or_destruction() allows the
compilation to not
On Linux/x86-64, gcc 4.3/4.4 give:
[EMAIL PROTECTED] gcc]$ cat /tmp/y.c
/*
* compile w/:
* gcc -Wall -Werror -fno-strict-aliasing -O2 -c foo.c
*/
typedef unsigned char __u8;
typedef unsigned short __u16;
static inline void * foo(
void * to, const void * from, int n)
{
switch ( n )
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-22 20:50 ---
This happens because the warning happens very early in the compiler so it does
not know that the case5 is not going to be used. I think the warning is
correct and not really bogus if you take that into account.
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-22 21:13 ---
This regression is introduced by revision 120898:
http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00603.html
The simplified testcase:
---
typedef unsigned char __u8;
typedef unsigned short __u16;
static inline unsigned
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-22 21:18 ---
The warning is very fragile: if the buffer in main() is not static then
there is no failure; is the size is passed as a constant there is no error.
Not really, if you read my comment, you will understand why
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-22 21:26
---
Out of curiosity: if this kind of code appears in a system header, is #pragma
GCC system_header able to suppress the warning? Of course I'm asking because
this is the most annoying feature of PR 36633 (which
--- Comment #5 from hjl dot tools at gmail dot com 2008-07-22 21:29 ---
It is a regression since the same correct code no longer compiles
with -Werror -Wall after upgrading from gcc 4.1/4.2 to 4.3.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #6 from hjl dot tools at gmail dot com 2008-07-22 21:30 ---
(In reply to comment #4)
Out of curiosity: if this kind of code appears in a system header, is #pragma
GCC system_header able to suppress the warning? Of course I'm asking because
this is the most annoying
--- Comment #7 from paolo dot carlini at oracle dot com 2008-07-22 21:32
---
(In reply to comment #6)
It comes from an application.
This doesn't answer my question.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #8 from hjl dot tools at gmail dot com 2008-07-22 21:42 ---
(In reply to comment #7)
(In reply to comment #6)
It comes from an application.
This doesn't answer my question.
I said It comes from an application. It isn't from system header file.
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-07-22 21:43
---
I think someone needs to kick the hell out of boost for making crappy code. I
am going to remove the regression marker for now because it is definitely a bit
weird what boost is doing and not normal for real
--- Comment #13 from lothar at tradescape dot biz 2008-07-22 21:48 ---
(In reply to comment #11)
From an application perspective it is still a regression, as it works happily
with gcc 4.2.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36861
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-07-22 21:52
---
(In reply to comment #13)
(In reply to comment #11)
From an application perspective it is still a regression, as it works happily
with gcc 4.2.3
Yes but it is boost's fault that boost tries to be smart about
--- Comment #15 from lothar at tradescape dot biz 2008-07-22 22:01 ---
What I am worried about is that if it is not marked as a regression nobody
cares to fix it although it breaks a real application that works with gcc
4.3.2.
If you have any insights how to improve the boost intrusive
--- Comment #9 from paolo dot carlini at oracle dot com 2008-07-22 22:53
---
I said It comes from an application. It isn't from system header file.
Yes, and that doesn't answer my question. I asked if the pragma is able to
suppress a warning triggered by your kind of snippet, IF,
--- Comment #13 from fmuldoo at me dot lsu dot edu 2008-07-22 22:54 ---
Subject: Re: Namelist I/O error: Bogus Cannot match
namelist object
Great, and thanks very much. I'm very glad you found it as it is the
only thing preventing me from using gfortran with my code. This is
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-22 23:40 ---
This is most likely fixed on the trunk already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-22 23:42 ---
(In reply to comment #2)
This is most likely fixed on the trunk already.
4.3.x also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36900
For AVR the following test fail. Probably since the day they were created.
For AVR there are no vectypes so they all fail message test
I don't know if these should be skipped as invalid or there is some significant
issue that warrant XFAIL.
FAIL: gcc.dg/tree-ssa/gen-vect-11.c
--- Comment #10 from hjl dot tools at gmail dot com 2008-07-23 01:04
---
(In reply to comment #9)
I said It comes from an application. It isn't from system header file.
Yes, and that doesn't answer my question. I asked if the pragma is able to
suppress a warning triggered by your
--- Comment #11 from paolo dot carlini at oracle dot com 2008-07-23 01:16
---
Thanks. Actually, I think the experiment would be more meaningful if you could
put also the equivalent of your main (a calling function, that is) inside the
header, because in your testcase the warning is
--- Comment #12 from hjl dot tools at gmail dot com 2008-07-23 01:23
---
(In reply to comment #11)
Thanks. Actually, I think the experiment would be more meaningful if you could
put also the equivalent of your main (a calling function, that is) inside the
header, because in your
--- Comment #13 from paolo dot carlini at oracle dot com 2008-07-23 01:28
---
You see, as I feared: this class of warnings coming from the middle-end is
especially nasty, because cannot be suppressed by any normal means.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
Take the following testcase:
#include altivec.h
#define xprint_vec(type) void x##type(vector type v) { }
xprint_vec(float);
This used to work in 4.3 and before but does not currently. The problem here
was introduced when the context sensitive keyword support was added.
--
Summary:
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-07-23 01:39
---
I have reviewed our code.
First, we reject the internal unit for namelist when using -std=f95.
$ gfc -std=f95 pr36895.f90
pr36895.f90:4.8:
write(line,nml=stuff)
1
Error: Fortran 2003: Internal file
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36904
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-23 01:55 ---
Hmm, I think the sign/zero extension is needed.
Even doing:
void fred(unsigned short in, unsigned short *out1)
{
int i;
for (i=0;i100;i++)
out1[i+1] = out1[i]*in;
}
--- CUT ---
We will get a zero
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-23 02:01 ---
for the loop on the trunk.
I think the trunk improved fold somewhere along the way, because the 4.3 I have
from January has the extra sign extension.
We will get a zero extension in the assembly (on
Take:
void fred(unsigned short in, unsigned short *out1)
{
__SIZE_TYPE__ i;
for (i=0;i100;i++)
out1[i+1] = in;
}
For PPC we currently generate:
.L2:
addi 9,9,1
slwi 0,9,1
sthx 3,4,0
bdnz .L2
But if change the code just so slightly to:
void
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-23 02:10 ---
(In reply to comment #2)
Also IV-opts is messing up anyways, it should have done out+1 as the base
instead of out, blah.
Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36905 .
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-23 02:16 ---
In fact this is one case where the old loop.c gets it correct :(.
4.1.1 with IV-opts off:
.L2:
sth 3,0(9)
addi 9,9,2
bdnz .L2
Which means I can declare this as a regression from 3.4.x.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-23 03:03 ---
I have a patch, I still have to check complex, I think it is ok because we have
expanded the division by the time we ran LIM.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-07-23 04:30
---
Subject: Bug 36852
Author: jvdelisle
Date: Wed Jul 23 04:29:15 2008
New Revision: 138072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138072
Log:
2008-07-22 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-07-23 04:37
---
Subject: Bug 36852
Author: jvdelisle
Date: Wed Jul 23 04:36:54 2008
New Revision: 138073
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=138073
Log:
2008-07-22 Jerry DeLisle [EMAIL PROTECTED]
PR
77 matches
Mail list logo
