[Bug ada/25573] New: Incorrect result returning constrained subtype (slice) with non-trivial return expression
The library PNG_IO fails during elaboration while performing some sanity checks
on its internal functions.
This was created on i386-redhat-linux-gnu (Centos 4)
I have boiled this down to a pretty simple test case that looks like the issue
happens when a function is returning a constrained subtype of an unconstrained
array and it is doing so when building the return value from an expression.
The following code should print abcd. Instead, it prints several garbage
characters.
with Text_IO;
with Interfaces; use Interfaces;
procedure Slice_Bug is
subtype Slice_Type is String(1 .. 4);
function identity(A : in Character) return Character is
begin
return a;
end identity;
function Get_Slice return Slice_Type is
begin
return identity('a') & identity('b') & identity('c') & identity('d');
end Get_Slice;
begin
Text_IO.Put_Line(Get_Slice);
end Slice_Bug;
Removing the constraint from the subtype makes this code work as expected.
Leaving the constraint in and doing a simple return "abcd" also works.
--
Summary: Incorrect result returning constrained subtype (slice)
with non-trivial return expression
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25573
[Bug ada/26306] Use of volatile array with bounds determined at run time.
--- Comment #4 from jeff at thecreems dot com 2006-10-20 16:56 --- I just did a fresh Gcc build today this no longer appears to be a problem URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 117904 Node Kind: directory Schedule: normal Last Changed Author: fxcoudert Last Changed Rev: 117904 Last Changed Date: 2006-10-20 07:52:56 -0400 (Fri, 20 Oct 2006) Properties Last Updated: 2006-10-20 09:33:34 -0400 (Fri, 20 Oct 2006) [EMAIL PROTECTED] mat_test]$ gcc -c scratch.adb [EMAIL PROTECTED] mat_test]$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26306
[Bug ada/24726] Gigi abort, Code=508
--- Comment #4 from jeff at thecreems dot com 2006-10-20 17:01 --- Seems fixed in trunk Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --disable-checking --enable-languages=c,fortran,ada --prefix=/home/jcreem/local Thread model: posix gcc version 4.2.0 20061020 (experimental) [EMAIL PROTECTED] bg]$ gcc -c elements-sets.adb [EMAIL PROTECTED] bg]$ -- jeff at thecreems dot com changed: What|Removed |Added CC||jeff at thecreems dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
[Bug ada/24079] Ada FE ICE on protected procedure with default argument (invalid?)
--- Comment #2 from jeff at thecreems dot com 2006-10-20 17:03 --- Still there in head gcc -c bug.adb +===GNAT BUG DETECTED==+ | 4.2.0 20061020 (experimental) (i686-pc-linux-gnu) Assert_Failure atree.adb:812 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24079
[Bug ada/29533] New: Ada fails to vectorize even trivial loops
While there might exist a case that can be vectorized, a few of the simple cases that should be easy that I have tried are not able to be vectorized. For example, the following package compare_lang is type the_range is range 0 .. 100; type My_Array is array (the_range) of Float; a, b, c : my_array; procedure do_compare; end compare_lang; package body compare_lang is procedure do_compare is begin for JJJ in the_range loop a(jjj) := b(jjj) * c(jjj); end loop; end do_compare; end compare_lang; gcc -c -O3 -gnatp -march=pentium4 -mfpmath=sse -msse3 -ftree-vectorize -ftree-vectorizer-verbose=5 compare_lang.adb compare_lang.adb:5: note: not vectorized: complicated access pattern. compare_lang.adb:3: note: vectorized 0 loops in function. Obviously similar structures C vectorize fine. -- Summary: Ada fails to vectorize even trivial loops Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at thecreems dot com GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29533
[Bug ada/22601] New: GNAT Command lists many commands as available that are not
Typing the command "gnat" results in the following output (note this is Centos
4.1 but I am pretty sure this is not target specific) :
GNAT 3.4.3 20050227 (Red Hat 3.4.3-22.1) Copyright 1996-2004 Free Software Found
ation, Inc.
List of available commands
GNAT BIND gnatbind
GNAT CHOP gnatchop
GNAT CLEAN gnatclean
GNAT COMPILEgnatmake -f -u -c
GNAT ELIM gnatelim
GNAT FIND gnatfind
GNAT KRUNCH gnatkr
GNAT LINK gnatlink
GNAT LIST gnatls
GNAT MAKE gnatmake
GNAT NAME gnatname
GNAT PREPROCESS gnatprep
GNAT PRETTY gnatpp
GNAT STUB gnatstub
GNAT XREF gnatxref
Commands FIND, LIST, PRETTY, STUB and XREF accept project file switches -vPx, -P
prj and -Xnam=val
Some of the commands that are listed as available commands are not really
available:
%gnat elim
Couldn't locate gnatelim
%gnat pretty
Couldn't locate gnatpp
%gnat stub
Couldn't locate gnatstub
I think these are only available with the pro distribution of GNAT.
Seems to still be the case in HEAD right now too (with possible addition of the
sub command metric).
Perhaps gnatcmd.adb should be updated so that it looks at some other file that
is already branched between the FSF sources and ACT and tailor the output to
only include those commands that are actually expected to be present.
--
Summary: GNAT Command lists many commands as available that are
not
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22601
[Bug ada/34117] Please enable range checks by default (-gnato)
--- Comment #1 from jeff at thecreems dot com 2007-11-16 14:27 --- Seems like a good idea. Since we often say that correctness should come before performance when it comes to optimization, it has always seemed odd to me that performance was the default mode of operation. We can complain all we want that users should read the manual before they start using the compiler but the fact is they don't and probably never will. I do wonder if perhaps a new flag that just disables range checking to get the 'old' behavior would be warranted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117
[Bug ada/29543] New: Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
I understand comparing very very small benchmarks like this can be misleading
but I believe I've looked at this enough to have a sense that it is
demonstrating a basic truth and not a narrow performance issue.
The test case that has been attached shows a FORTRAN and Ada program that are
equivalent (within their matrix multiply loop). The Ada one runs about 2x
slower with about 3x the number of machine instructions in the inner loop.
(Note that running with Ada run time checks disabled).
I dumped the optimized trees (as the original tree of the Ada version was
difficult to read because of the node types not being known to the pretty
printer). The Ada tree is certainly a mess compared to the FORTRAN version.
The core of the FORTRAN code looks like
do I = 1,N
do J = 1,N
sum = 0.0
do R = 1,N
sum = sum + A(I,R)*B(R,J)
end do
C(I,J) = sum
end do
end do
With the resulting optimized tree fragment (of the inner most loop) being
:;
sum = MEM[base: (real4 *) ivtmp.97] * MEM[base: (real4 *) pretmp.81, index:
(real4 *) ivtmp.161 + (real4 *) ivtmp.94, step: 4B, offset: 4B] + sum;
ivtmp.94 = ivtmp.94 + 1;
ivtmp.97 = ivtmp.97 + ivtmp.157;
if (ivtmp.94 == () D.1273) goto ; else goto ;
While the core of the Ada code looks like:
for I in A'range(1) loop
for J in A'range(2) loop
Sum := 0.0;
for R in A'range(2) loop
Sum := Sum + A(I,R)*B(R,J);
end loop;
C(I,J) := Sum;
end loop;
end loop;
With the resulting optimized tree fragment of the inner most loop being :
:;
D.2370 = (*D.2277)[pretmp.627]{lb: tst_array__L_3__T16b___L sz: pretmp.709 *
4}[() r]{lb: tst_array__L_4__T17b___L sz: 4};
:
temp.721 = D.2344->LB0;
:
temp.720 = D.2344->UB1;
:
temp.719 = D.2344->LB1;
:
j.73 = () j;
D.2373 = (*D.2298)[() r]{lb: temp.721 sz: MAX_EXPR <(temp.720 +
1 - temp.719) * 4, 0> + 3 & -4}[j.73]{lb: temp.719 sz: 4};
:
D.2374 = D.2370 * D.2373;
:
sum = D.2374 + sum;
:
if (r == tst_array__L_4__T17b___U) goto ; else goto ;
:;
r = r + 1;
goto ();
Now, I'll be the first to admit that I know very little about the innards of
compiler technology but that tree looks like a horrible mess. It is no wonder
the resulting assembly is such a mess.
I am attaching a tar file that has the complete source for the Ada and the
FORTRAN version.
--
Summary: Ada produces substantially slower code than FORTRAN for
identical inputs - looping over double subscripted
arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
GCC build triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug ada/29543] Ada produces substantially slower code than FORTRAN for identical inputs - looping over double subscripted arrays
--- Comment #1 from jeff at thecreems dot com 2006-10-22 02:02 --- Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) Source code and very simple build script for Ada and FORTRAN code capable of showing poor tree and runtime performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #8 from jeff at thecreems dot com 2006-10-22 15:50 --- (In reply to comment #7) > > No, but there is an obvious one why the Fortran version trounces the Ada > > version. Let's not compare apples with oranges. > > The adverse effect of the indirection can be alleviated though: > >N : Positive := Positive'Value (Argument (1)); >G : Ada.Numerics.Float_Random.Generator; > >type Real_Matrix is array (1..N, 1..N) of Float; >type Matrix_Access is access Real_Matrix; > >A,B,C : Matrix_Access; >Start, Finish : Ada.Calendar.Time; >Sum : Float := 0.0; > begin >A := new Real_Matrix; >B := new Real_Matrix; >C := new Real_Matrix; > That is a good approach and it significantly narrows the gap though I would argue that a general user would not see the original version as "different" than the FORTRAN version. Both of them are dynamically allocating the size at run time based on an input parameter. The FORTRAN arrays could indeed be passed to other procedures (such as matmul) that take variable sized arrays while this modified version (in its current form) could not. So, from an understanding of the internals of the compiler, I think you have a reasonable argument that the original Ada and FORTRAN were somewhat different but I think this modified version is actually further from the FORTRAN. (Though I must admit I know very little about FORTRAN 95). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
[Bug tree-optimization/29543] Poor code generated for arrays with variable bounds
--- Comment #14 from jeff at thecreems dot com 2006-10-23 23:50 --- (In reply to comment #1) > Created an attachment (id=12473) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) [edit] > Source code and very simple build script for Ada and FORTRAN code capable of > showing poor tree and runtime performance. > Note, while it does not fully close the gap, I can confirm that a large portion of this the poor performance is a regression when compared to GCC 4.0.3. The 4.0.3 is about 1/3 faster than the 4.2.0 which also corresponds to a significantly reduced number of generated instructions for the inner loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
