install location of math-vector-fortran.h
[not subscribed to the libc-alpha list] GCC and glibc need to agree on the install location for math-vector-fortran.h. Currently it is installed into /usr/include/finclude/math-vector-fortran.h However the file is architecture specific, currently only having variants for x86_64-*-gnu, x86_64-*-gnux32, and a generic variant. This creates problems when the file is contained in a Debian package which is marked as Multi-Arch: same, also it should create problems installing the i386 and amd64 rpm's on the the same system. How to solve this issue? - The header file currently seems to be completely conditionalized. Is it safe to assume that the x86 variant is still considered empty for any other architecture? Will it stay this way? In this case this variant could be installed everywhere, or better, glibc could stop maintaining the variant at all. - Move the file to an architecture specific location. For multiarch that could be /usr/include//finclude/math-vector-fortran.h GCC would need patching to look at this location as an alternative. Are other tools need patching as well? What would be the solution for co-installable i386/amd64 packages? Thanks, Matthias
Re: install location of math-vector-fortran.h
* Matthias Klose: > [not subscribed to the libc-alpha list] > > GCC and glibc need to agree on the install location for math-vector-fortran.h. > Currently it is installed into > > /usr/include/finclude/math-vector-fortran.h > > However the file is architecture specific, currently only having > variants for x86_64-*-gnu, x86_64-*-gnux32, and a generic variant. > This creates problems when the file is contained in a Debian package > which is marked as Multi-Arch: same, also it should create problems > installing the i386 and amd64 rpm's on the the same system. How to > solve this issue? Uhm. If you want an upstream solution, you need to upstream your multi-arch patches. > - The header file currently seems to be completely conditionalized. >Is it safe to assume that the x86 variant is still considered empty >for any other architecture? Will it stay this way? In this case >this variant could be installed everywhere, or better, glibc could >stop maintaining the variant at all. I do not understand these questions. The Fortran header is the equivalent of the C header. Its contents depends on what is necessary to describe the libmvec ABI. We will only know the ABI for libmvec once there is a port for other architectures, so future evolution of the header is impossible to predict. Thanks, Florian
Re: install location of math-vector-fortran.h
On 6/8/20 1:03 PM, Florian Weimer via Gcc wrote:
> * Matthias Klose:
>
>> [not subscribed to the libc-alpha list]
>>
>> GCC and glibc need to agree on the install location for
>> math-vector-fortran.h.
>> Currently it is installed into
>>
>> /usr/include/finclude/math-vector-fortran.h
>>
>> However the file is architecture specific, currently only having
>> variants for x86_64-*-gnu, x86_64-*-gnux32, and a generic variant.
>> This creates problems when the file is contained in a Debian package
>> which is marked as Multi-Arch: same, also it should create problems
>> installing the i386 and amd64 rpm's on the the same system. How to
>> solve this issue?
>
> Uhm. If you want an upstream solution, you need to upstream your
> multi-arch patches.
they are in GCC. Please note that there is no patch yet for this header file,
so I can't upstream anything yet.
>> - The header file currently seems to be completely conditionalized.
>>Is it safe to assume that the x86 variant is still considered empty
>>for any other architecture? Will it stay this way? In this case
>>this variant could be installed everywhere, or better, glibc could
>>stop maintaining the variant at all.
>
> I do not understand these questions. The Fortran header is the
> equivalent of the C header. Its contents depends
> on what is necessary to describe the libmvec ABI. We will only know the
> ABI for libmvec once there is a port for other architectures, so future
> evolution of the header is impossible to predict.
this file currently only has lines like:
!GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')
so it shouldn't have any effect to other architectures? Or are the conditionals
explicitly done to exclude the 32bit x86 configuration?
Matthias
Re: install location of math-vector-fortran.h
* Matthias Klose:
> this file currently only has lines like:
>
> !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64')
>
> so it shouldn't have any effect to other architectures? Or are the
> conditionals explicitly done to exclude the 32bit x86 configuration?
Ah. It's the latter.
Thanks,
Florian
Re: install location of math-vector-fortran.h
On Mon, Jun 08, 2020 at 12:52:36PM +0200, Matthias Klose wrote: > GCC and glibc need to agree on the install location for math-vector-fortran.h. > Currently it is installed into > > /usr/include/finclude/math-vector-fortran.h > > However the file is architecture specific, currently only having variants for > x86_64-*-gnu, x86_64-*-gnux32, and a generic variant. This creates problems > when the file is contained in a Debian package which is marked as Multi-Arch: > same, also it should create problems installing the i386 and amd64 rpm's on > the > the same system. How to solve this issue? > > - The header file currently seems to be completely conditionalized. >Is it safe to assume that the x86 variant is still considered empty >for any other architecture? Will it stay this way? In this case >this variant could be installed everywhere, or better, glibc could >stop maintaining the variant at all. > > - Move the file to an architecture specific location. For multiarch that >could be > > /usr/include//finclude/math-vector-fortran.h > >GCC would need patching to look at this location as an alternative. >Are other tools need patching as well? What would be the >solution for co-installable i386/amd64 packages? The file should be where gfortran looks for it. For multi-arch, it is up to you, that is a Debian/Ubuntu specific thing and if you get upstreamed something into both glibc and gcc, fine. But you could also just look for where gfortran is looking for it ATM and pick up a more suitable location for glibc. For non-multiarch, I believe it works fine as is. Jakub
Re: install location of math-vector-fortran.h
On Mon, 8 Jun 2020, Matthias Klose wrote: > However the file is architecture specific, currently only having variants for > x86_64-*-gnu, x86_64-*-gnux32, and a generic variant. This creates problems > when the file is contained in a Debian package which is marked as Multi-Arch: > same, also it should create problems installing the i386 and amd64 rpm's on > the > the same system. How to solve this issue? The general principle in glibc is that installed header files contain conditionals for variants within an architecture that can be used by a single GCC installation in a multilib configuration, most often for 32-bit and 64-bit variants, so that a single set of header files can be shared between such multilibs. However, they do not generally contain conditionals for different target architectures (where "different" means different GCC ports - for example, Arm and AArch64 are different for this purpose) or target OSes, so in those cases separate sets of installed headers are needed for each architecture / OS. Although most of the architecture-specific headers are in bits/ or sys/, this isn't the case for all of them (e.g. fpu_control.h and ieee754.h, as well as the case of finclude/math-vector-fortran.h that you've noted). It would be possible to change some headers such as fpu_control.h and ieee754.h to have an architecture-independent wrapper round an architecture-specific file in bits/, but probably a separate directory such as finclude/ for Fortran files would still be appropriate. -- Joseph S. Myers jos...@codesourcery.com
Inquire a potential bug when printing out GIMPLE ASAN statements
Hello!
I am writing to report a potential bug I encountered when playing with the
GIMPLE IR. I enabled the ASan and would like to print out all ASAN_MARK
statements for the following simple code:
int main(int argc ,char **argv)
{
int stack_array[100];
stack_array[1] = 100;
stack_array[argc + 12]; // an ASan check, namely, ASAN_MARK, will
be inserted at this point
}
And I am using the following code snippet (basically derived from this
post
)
to print out all function calls, including ASAN_MARK:
if (is_gimple_call(stmt)){
tree current_fn_decl = gimple_call_fndecl(stmt);
const char* name = get_name(current_fn_decl);
cerr << " Function : " << name << " is called \n";
}
However, I note that some internal exceptions are encountered, when I
use gcc version 7.4, 8.3, and also 9.3:
test.c: In function ‘main’:
test.c:9:5: internal compiler error: Segmentation fault
9 | int main(int argc ,char **argv)
| ^~~~
0xab88bf crash_signal
../../gcc-9.3.0/gcc/toplev.c:326
0xcfc836 location_wrapper_p(tree_node const*)
../../gcc-9.3.0/gcc/tree.h:3812
0xcfc836 tree_nop_conversion
../../gcc-9.3.0/gcc/tree.c:12850
0xcfc836 tree_strip_nop_conversions(tree_node*)
../../gcc-9.3.0/gcc/tree.c:12888
0xcfc836 get_name(tree_node*)
../../gcc-9.3.0/gcc/tree.c:12559
0x7f9466d86bb7 execute
/home/shuaiw/work/sanitizer_reduction_gcc/demo/walk_gimple/walk_gimple.cc:61
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
Seeking clarification and way forward on limited scope variables.
[AMD Official Use Only - Internal Distribution Only]
Hello Everyone,
I need to have your thoughts on this.
Consider the following test case --
---
1int main(int Argc, char **Argv) {
2 int Local = 6;
3 printf("%d\n",Local);
4
5 {
6 printf("%d\n",Local);
7 int Local = 7;
8 printf("%d\n",Local);
9 }
10
11 return 0;
12 }
When compiled in debug mode with compilers including (trunk gcc and trunk
clang) and debugging with GDB at Line No.6, the following behavior is observed
Breakpoint 1, main (Argc=1, Argv=0x7fffe458) at MainScope.c:6
6 printf("%d\n",Local);
(gdb) print Local
$1 = 2102704 -- some Garbage value,
(gdb) info addr Local
Symbol "Local" is a variable at frame base reg $rbp offset 0+-24. -- This is
location of *Local* declared inside scope, but as you may notice that the
variable being referred here is from the outer scope.
This problem persists with both GDB and LLDB. Since we have entered the Lexical
Scope and when we try to print value of *Local*, it will look into the
*current scope* and fetch the value if the variable exists in scope(in case
variable doesn't exist, GDB searches for it in the outer scope).
This is regardless of whether the variable has actually came into scope(or
actually defined) at Line No. 7. Since DWARF already defined the location(on
stack) which will be valid for the lifetime of the variable, contrary to when
the variable is actually defined(or allocated) which is in this case Line No. 7.
-
0x006d: DW_TAG_lexical_block
DW_AT_low_pc (0x002016d1)
DW_AT_high_pc (0x0020170b)
0x007a: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -24)
DW_AT_name ("Local")
DW_AT_decl_file ("MainScope.c")
DW_AT_decl_line (7)
DW_AT_type (0x008a "int")
--
The DWARF specification provides the DW_AT_start_scope attribute to deal with
this issue (Sec 3.9 Declarations with Reduced Scope DWARFv5). This attribute
aims at limiting the scope of variables within the lexical scope in which it is
defined to from where it has been declared/ defined.
In order to fix this issue, we want to modify llvm so that DW_AT_start_scope is
emitted for the variable in the inner block (in the above example). This limits
the scope of the inner block variable to start from the point of its
declaration.
For POC, we inserted DW_AT_start_scope in this inner *Local* variable,
resultant dwarf after this.
-
0x006d: DW_TAG_lexical_block
DW_AT_low_pc (0x002016d1)
DW_AT_high_pc (0x0020170b)
0x007a: DW_TAG_variable
DW_AT_start_scope (0x17) -- restricted within a
subset(starting from the point of definition(specified as an offset)) of entire
ranges covered by Lex Block.
DW_AT_location (DW_OP_fbreg -24)
DW_AT_name ("Local")
DW_AT_decl_file ("MainScope.c")
DW_AT_decl_line (7)
DW_AT_type (0x0092 "int")
We also modified 'gdb' to interpret DW_AT_start_scope so that the scope of the
variable is limited from the PC where the value of DW_AT_start_scope is. If the
debugger is stopped at a point within the same lexical block but at a PC before
DW_AT_start_scope, then gdb follows the normal search mechanism of searching in
consecutive super blocks till it gets a match or it reaches the global block.
After the modification, GDB is able to correctly show the value *6* in our
example.
After incorporating changes --
Breakpoint 1, main (Argc=1, Argv=0x7fffe458) at MainScope.c:6
6 printf("%d\n",Local);
(gdb) print Local
$1 = 6 --- Value retrieved from outer scope
(gdb) info addr Local
Symbol "Local" is a variable at frame base reg $rbp offset 0+-20.
Could you guys please let us know your thoughts or suggestions on this? Was/ Is
there is an existing effort already going on to deal with this problem?
Even though location lists can be used to deal with this scenario, in my
experience, location lists are emitted at higher optimization levels, and with
the usage of location lists in this example, gdb prints out (as
expected) if it is stopped at a PC in the same lexical block but before the
point of declaration of the local variable.
Thank You,
Sourabh Singh Tomar.
