--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-08-16 06:11
---
Subject: Bug 35863
Author: jvdelisle
Date: Sat Aug 16 03:42:54 2008
New Revision: 139148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139148
Log:
2008-08-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-08-16 06:11
---
Subject: Bug 35863
Author: jvdelisle
Date: Sat Aug 16 03:42:54 2008
New Revision: 139148
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139148
Log:
2008-08-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-08-16 06:11
---
Subject: Bug 35863
Author: jvdelisle
Date: Sat Aug 16 03:38:31 2008
New Revision: 139147
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139147
Log:
2008-08-15 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-08-15 23:52 ---
On the trunk we get:
lis 11,[EMAIL PROTECTED]
la 9,[EMAIL PROTECTED](11)
lwz 0,[EMAIL PROTECTED](11)
cmpwi 7,0,0
bne 7,.L6
li 0,1344
li 3,1344
stw 0,4(9
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-15 21:26 ---
The gimplifier is inlining the value of MOUSE_reset_colors for some reason ...
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
file test.c:
--
enum stdcolor_enum {
black,blue, green, cyan,
red, magenta, brown, lightgray,
darkgray, lightblue,lightgreen, lightcyan,
lightred, lightmagenta, yellow, white
};
union mouse_color_union {
struct mou
--- Comment #16 from paolo dot carlini at oracle dot com 2008-08-15 20:36
---
No news, Manuel, still unsuppressed by the pragma
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #6 from jakub at gcc dot gnu dot org 2008-08-15 20:19 ---
*** Bug 37133 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2008-08-15 20:19 ---
Yes, this is a dup of PR29635. Solving PR29635 really means handling these
all.
*** This bug has been marked as a duplicate of 29635 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from manu at gcc dot gnu dot org 2008-08-15 20:18 ---
GCC system_headers should suppress this warning now, doesn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36902
--- Comment #6 from manu at gcc dot gnu dot org 2008-08-15 20:16 ---
(In reply to comment #5)
> Created an attachment (id=16074)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16074&action=view) [edit]
> third fix candidate
>
> This patch tries another approach.
Patches go to [EMA
--- Comment #14 from manu at gcc dot gnu dot org 2008-08-15 20:11 ---
(In reply to comment #13)
> 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.
What location is being passed to that warnin
http://dwarfstd.org/Dwarf3.pdf
"3.3 Subroutine and Entry Point Entries"
For
subroutine test()
entry etry()
end subroutine test
there is no DW_TAG_entry_point created.
Expected: As ifort has:
-
<1><1eb>: Abbrev Number: 4 (DW_TAG_subprogram)
<1ec> DW_AT_dec
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-15 19:49 ---
I think to some extend this is a dup of bug 29635.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37133
http://dwarfstd.org/Dwarf3.pdf
See: "3.2 Module, Namespace and Importing Entries"
* DW_TAG_module
* DW_TAG_imported_declaration (for renamed items, only: tag)
* DW_TAG_imported_module
Example (from Dwarf3, note there a ":" is missing):
module A
integer X, Y, Z
end module
module B
use A
end m
http://dwarfstd.org/Dwarf3.pdf
"4.3 Namelist Entries"
"A namelist is represented by a debugging information entry with the tag
DW_TAG_namelist. If the namelist itself has a name, the namelist entry has a
DW_AT_name attribute, whose value is a null-terminated string containing the
namelistÂ’s name
Ouch.
This is a factor of 20 for this simple test case on my computer.
$ cat foo.f90
program main
real, dimension(3,3) :: a,b,c
call random_number(a)
call random_number(b)
do i=1,10**8
c = matmul(a,b)
a(1,1) = a(1,1) + b(1,1) - c(1,1)
end do
print *,c
end program main
$ gfort
--- Comment #3 from kargl at gcc dot gnu dot org 2008-08-15 18:59 ---
(In reply to comment #2)
> (In reply to comment #1)
>
> Is there a Fortran 77 compatible work-around that will do what this program
> was
> doing (i.e.: write out a mixed set of 4 byte integers and 8 byte floats to a
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-15 18:29 ---
Created an attachment (id=16077)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16077&action=view)
gcc44-pr29635.patch
Initial patch, which generates DW_TAG_module in the compilation unit that
defines
the module
--- Comment #1 from paolo dot carlini at oracle dot com 2008-08-15 17:26
---
I don't see anything wrong with the code in __final_insertion_sort, thus this
is indeed, in my opinion, a bogus warning emitted by the compiler. Seems
related to PR 36902.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from regehr at cs dot utah dot edu 2008-08-15 17:20 ---
(In reply to comment #2)
> Probably a dup of PR36548.
>
But PR36548 seemed to be about overflow whereas this one doesn't appear to have
any overflows.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37125
--- Comment #2 from huwaldtj at saic dot com 2008-08-15 16:58 ---
(In reply to comment #1)
Is there a Fortran 77 compatible work-around that will do what this program was
doing (i.e.: write out a mixed set of 4 byte integers and 8 byte floats to a
binary file with a specific format sinc
--- Comment #1 from kargl at gcc dot gnu dot org 2008-08-15 16:53 ---
(In reply to comment #0)
> It appears that gfortran does not interpret recl=1 the way many historic
> compilers, including g77, did. So, this bug report is to request that recl=1
> be interpreted to mean that the com
Given:
#include
class Id {
public:
Id();
Id( const Id & );
operator int() const;
int id;
};
int get_int();
int main()
{
struct SideVertexBuffer {
enum { max_vertices = 4 };
Id node_id[ max_vertices ] ;
int processor ;
};
SideVertexBuffer entry;
int num_side_vert = get_int(
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-15 14:37 ---
Probably a dup of PR36548.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-15 14:32 ---
This somehow looks familiar. Also happens on the 4.3 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
In porting legacy Fortran 77 code to gfortran, I encountered an issue that can
be boiled down and reproduced with the following code:
INTEGER*4 HDRPOS,CURPOS
OPEN(UNIT= 9,FILE='fort.9',ACCESS='DIRECT', STATUS='NEW',
& FORM='UNFORMATTED',RECL=1)
INQUIRE(UNIT=9, NE
27 matches
Mail list logo
