Removing an output file when test case has terminate
I want to add a test case to the gfortran testsuite for PR 65563. If all goes right, running the test case will a) terminate the program with an error message (to be checked for) b) create a file, which needs to be cleaned up after the test case is run. a) is clear, but how do I do b)? I haven't found anything in the list of dg-final actions for this. (Due to the specifics of the test case, I also cannot name my file "foo.mod" and let the automatic module cleanup do the job for me :-) Any ideas? Thomas
Re: Removing an output file when test case has terminate
On Sun, Mar 29, 2015 at 2:28 PM, Thomas Koenig wrote:
> I want to add a test case to the gfortran testsuite for PR 65563.
> If all goes right, running the test case will
>
> a) terminate the program with an error message (to be checked for)
>
> b) create a file, which needs to be cleaned up after the test case
>is run.
>
> a) is clear, but how do I do b)? I haven't found anything in the
> list of dg-final actions for this. (Due to the specifics of the test
> case, I also cannot name my file "foo.mod" and let the automatic module
> cleanup do the job for me :-)
>
> Any ideas?
What I did for PR 64770, were the testcase created a file
"pr64770test.dat", was to add a line
! { dg-final { remote_file build delete "pr64770test.dat" } }
to the end of the testcase. See gfortran.dg/open_new_segv.f90 for the
whole testcase.
Don't know if this is the correct way to do it, but it seems to work.
--
Janne Blomqvist
Re: Removing an output file when test case has terminate
Hi Janne,
> ! { dg-final { remote_file build delete "pr64770test.dat" } }
did the trick. It is not mentioned in the docs, though.
Thanks!
Thomas
Re: Removing an output file when test case has terminate
On 03/29/2015 04:50 AM, Janne Blomqvist wrote:
On Sun, Mar 29, 2015 at 2:28 PM, Thomas Koenig wrote:
I want to add a test case to the gfortran testsuite for PR 65563.
If all goes right, running the test case will
a) terminate the program with an error message (to be checked for)
b) create a file, which needs to be cleaned up after the test case
is run.
a) is clear, but how do I do b)? I haven't found anything in the
list of dg-final actions for this. (Due to the specifics of the test
case, I also cannot name my file "foo.mod" and let the automatic module
cleanup do the job for me :-)
Any ideas?
What I did for PR 64770, were the testcase created a file
"pr64770test.dat", was to add a line
! { dg-final { remote_file build delete "pr64770test.dat" } }
to the end of the testcase. See gfortran.dg/open_new_segv.f90 for the
whole testcase.
Don't know if this is the correct way to do it, but it seems to work.
You can also try:
open(10, status="scratch")
It will be deleted when closed. Also on failed test, instead of calling abort,
use STOP 500 or similar. STOP will close files.
Jerry
__attribute__ aligned could be more efficient
Hello everyone,
Consider the following program.
#include
#include
struct foo1 { char s[80]; };
struct foo2 { char s[80]; } __attribute__ ((aligned (64)));
struct bar1 { struct foo1 f; int i; };
struct bar2 { struct foo2 f; int i; };
#define P(arg) printf("sizeof(" #arg ") = %u\n", (unsigned)sizeof(arg))
int main(void)
{
P(struct foo1);
P(struct foo2);
P(struct bar1); printf("offset=%u\n", (unsigned)offsetof(struct bar1, i));
P(struct bar2); printf("offset=%u\n", (unsigned)offsetof(struct bar2, i));
return 0;
}
$ gcc -O3 -Wall align.c
$ ./a.out
sizeof(struct foo1) = 80
sizeof(struct foo2) = 128
sizeof(struct bar1) = 84
offset=80
sizeof(struct bar2) = 192
offset=128
I didn't expect sizeof(struct bar2) to be 192.
gcc lays out bar2 like this:
foo2(80) padding(48) i(4) padding(60)
But it seems (to me) that gcc could fit the "int" field in the
first padding, to save space:
foo2(80) i(4) padding(44)
Is there a way to "cancel" the alignment request for foo2
in the bar2 definition? This doesn't work:
struct bar3 {
struct foo2 f __attribute__ ((aligned (4)));
int i;
} __attribute__ ((aligned (64)));
Regards.
Re: __attribute__ aligned could be more efficient
Mason writes: > Hello everyone, > > Consider the following program. This mailing list is about the development of gcc, for user questions please use gcc-h...@gcc.gnu.org instead. > gcc lays out bar2 like this: > foo2(80) padding(48) i(4) padding(60) struct foo2 has size 128, not 80. The padding is part of the type. > But it seems (to me) that gcc could fit the "int" field in the > first padding, to save space: > > foo2(80) i(4) padding(44) Structure members cannot overlap. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: __attribute__ aligned could be more efficient
On 29/03/2015 17:35, Andreas Schwab wrote: > Mason wrote: > >> Consider the following program. [snip] > > This mailing list is about the development of gcc, for user questions > please use gcc-h...@gcc.gnu.org instead. Thanks, I will re-send my original message to gcc-help. Please be aware that the general tone of your answer could be perceived as somewhat aggressive and peremptory. Regards.
Q.: inconsistent (?) warnings about functions called through non-compatible types
Hi,
why does gcc (4.4.7 and 4.8.2) sometimes warn and sometimes not warn
when undefined behavior is invoked when making illegal function
pointer conversions?
For instance, consider the code below:
-
/* Tested with gcc 4.4.7 and 4.8.2 */
#include
#include
bool boolFunctionThatReturnsFalse() { return false; }
typedef int (*intFunction)(void);
int
main()
{
/* no warning here, just undefined behavior */
intFunction f = (intFunction) boolFunctionThatReturnsFalse;
if ( f() )
printf("true\n");
else
printf("false\n");
/* gcc warns and emits abort code */
if ( ((intFunction) boolFunctionThatReturnsFalse) () )
printf("true\n");
else
printf("false\n");
}
---
Why does assigning boolFunctionThatReturnsFalse to a variable f after
the cast, instead of directly dereferencing it, silence the compiler's
warnings?
Thanks.
- Godmar
ps: I would like to see the warning, of course, since casting a bool
returning function to an int returning function is undefined behavior.
Re: Q.: inconsistent (?) warnings about functions called through non-compatible types
Godmar Back writes: > ps: I would like to see the warning, of course, since casting a bool > returning function to an int returning function is undefined behavior. The cast itself is ok, the undefined behavior only occurs when calling it without casting back. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Q.: inconsistent (?) warnings about functions called through non-compatible types
On Sun, Mar 29, 2015 at 3:26 PM, Andreas Schwab wrote:
> Godmar Back writes:
>
>> ps: I would like to see the warning, of course, since casting a bool
>> returning function to an int returning function is undefined behavior.
>
> The cast itself is ok, the undefined behavior only occurs when calling
> it without casting back.
>
Thanks. I'm a bit confused then what constitutes defined & undefined behavior.
The actual situation I encountered is best described by this example:
--
/* Tested with gcc 4.4.7 and 4.8.2 -m32 */
#include
#include
bool boolFunctionThatReturnsFalse() {
// I'm faking this here, but a real 'bool' function could
// place 0x100 in $eax when meaning to return false.
register bool r asm("%eax");
asm("mov $0x100, %eax");
return r;
}
typedef int (*intFunction)(void);
int
main()
{
if ( boolFunctionThatReturnsFalse() )
printf("true\n");
else
printf("false\n");
intFunction f = (intFunction) boolFunctionThatReturnsFalse;
if ( f() )
printf("true\n");
else
printf("false\n");
}
--
(I'm faking the return value of boolFunctionThatReturnsFalse here, but
I have observed this behavior in actual code.)
Is this defined or undefined behavior that my problem invokes?
- Godmar
Re: Q.: inconsistent (?) warnings about functions called through non-compatible types
On 29 March 2015 at 19:32, Godmar Back wrote: > Why does assigning boolFunctionThatReturnsFalse to a variable f after > the cast, instead of directly dereferencing it, silence the compiler's > warnings? Because the cast itself is OK, and the call that results in undefined behaviour is separate from the cast. The compiler is not smart enough to see that in the call f() the value of f is not really an intFunction. In the second case the compiler knows for a fact that the function being called does not have the correct type, because the cast and the call are part of the same expression.
gcc-5-20150329 is now available
Snapshot gcc-5-20150329 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150329/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 221765 You'll find: gcc-5-20150329.tar.bz2 Complete GCC MD5=9f441fb8fff99e09079aa36ae26f07ed SHA1=fbff26ef9eb2a9df5bea167316f57cc6772ec039 Diffs from 5-20150322 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
