Re: Re: About -fasan-shadow-offset option

[tao.z...@amlogic.com]

Dear Martin Liška

Thanks for your research. I have resolved this problem by pass a ddrsize 
paramters when build and cacluate the offset used by -fasan-shadow-offset 
according that parameter. 



Thanks!
B.R.
tao.z...@amlogic.com
 
Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋

 
发件人： Martin Liška
发送时间： 2022-11-26 00:23
收件人： tao.z...@amlogic.com; gcc
抄送： Jakub Jelinek
主题： Re: About -fasan-shadow-offset option
 
[ EXTERNAL EMAIL ]
 
On 11/16/22 10:01, tao.z...@amlogic.com wrote:
> Dear gcc:
> 
 
Hello.
 
Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would 
be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated 
-fasan-shadow-offset.
 
Cheers,
Martin
 
> I am developing a address sanitiser tools for u-boot. Basically refers 
> compile options from kernel side. But there is a problem that I must set 
> -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will 
> use 0x10 as default value for shadow offset and caused boot failed 
> because this value is too large.
> The problem is uboot do not have a fixed memory layout as kernel. 
> Basically it will relocate to end of DDR size and running at that memory 
> space. Usually memory map for uboot is virt=phys and there are lots of 
> drivers do not do address translate for dma based on this mapping. But ddr 
> size are different on each platform. So it's hard to handle shadow offset at 
> this scenario.
> My point is that can gcc add an option like -fasan-shadow-symbol=, 
> here  is a global variable and implementors can configure it's value 
> based on platforms ddr size/malloc buffer size during initialize stage and 
> this variable can be used for shadow address calculation during runtime. This 
> may be more fitable compared than a fixed value during compile stage.  And is 
> there any other options to help my problem?
> Waiting for your response asap.
>  Thanks.
> 
> 
> 
> Thanks!
> B.R.
> tao.z...@amlogic.com
>  
> Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
> 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
> 
 

gcc-11-20221125 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20221125 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20221125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 55e5ef55a0eee1cb329754f30889d93567daae18

You'll find:

 gcc-11-20221125.tar.xz   Complete GCC

  SHA256=43fb62fe69ef9bb65e7910ef6103c6b1c1f3953dec0ff5b6bff9476806dd6c3c
  SHA1=c0e8b397b6d3a22c70422bec1d9c0ea84bc33590

Diffs from 11-20221118 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
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.

Re: Can't build Ada

[Iain Sandoe]

Hi Paul,

> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc  wrote:
> 
> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>> 
>>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
>>> 
>>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
>>> wrote:
 
 I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
 precise) to build Ada, starting with the latest (2020) release of Gnat 
 from Adacore.
>>> 
>>> Are you building a cross compiler or a native compiler?
>>> If you are building a cross, you need to bootstrap a native compiler first.
>> 
>> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
>> aarch64-darwin.
> 
> You have to build a x86_64-darwin compiler first with the same sources
> as you are building for aarch64-darwin.

So .. 
1/ if you are on arm64 Darwin, 
  - the first step is to bootstrap the compiler using Rosetta 2 and the 
available x86_64 gnat.

2/ if you are on x86_64 Darwin…
  - the first step is to bootstrap the compiler using the available x86-64 gnat.

then...
  - then you can build a cross to aarch64 using that just-build compiler.
  - then you can do a native cross (target==host!=build) using that, which will 
give you a usable native compiler for arm64 ..

(2 is what I was doing all the way through the development - until I recently 
got an arm64 machine)..

I know that Rosetta 2 bootstrap worked a few days ago …

BTW: the final step “native cross” can be a bit tricky in terms of configure 
line - since some configure steps cannot (in general) run the tools on the 
“foreign” host - so that you might need to specify the linker version (we don’t 
have the option to do —with-ld64=NN.MM yet, but there is code that cares about 
the version of ld64.. so)

>> But in any case, how does that relate to the error messages I got?  They 
>> don't seem to have anything to do with missing compilers, but rather with 
>> the use of language features too new for the available (downloadable) Gnat.
> 
> From https://gcc.gnu.org/install/prerequisites.html:
> "In order to build a cross compiler, it is strongly recommended to
> install the new compiler as native first, and then use it to build the
> cross compiler. Other native compiler versions may work but this is
> not guaranteed and *will typically fail with hard to understand
> compilation errors during the build."
> 
> I added the emphasis but yes this is all documented correctly.

thanks for the reminder!

cheers
Iain

Re: Can't build Ada

[Alexandre Oliva via Gcc]

On Nov 25, 2022, Paul Koning via Gcc  wrote:

> They don't seem to have anything to do with missing compilers, but
> rather with the use of language features too new for the available
> (downloadable) Gnat.

The gnat1 front-end requires some of the Ada runtime (libgnat)
components.  They get built as part of cross builds, so that the
compiler itself uses the features present in the runtime.

For bootstrapping purposes, stage1's gnat builds in a
less-runtime-demanding mode, that gets linked with the runtime of the
compiler used to build stage1, and that is then used to build the
runtime and later stages.

With this arrangement, the runtime components used by the compiler
itself may rely on language features that the build compiler doesn't
offer, at the cost of requiring cross builds to use a compiler that
supports those features.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: Can't build Ada

[NightStrike via Gcc]

On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc  wrote:
> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

Generally speaking, the reason is that with a normal compiler build,
where build = host = target, gcc can build itself and then run the
newly built self to build the language runtimes.  So if you're using
gcc 5 to build gcc 12, you're actually not using gcc 5 for all that
much.  The new gcc 12 is used to build for instance libX.  With a
cross compiler, it's possible that the build != host, and so you can't
use the newly built GCC in your build environment to build the
language runtimes.  For instance, say your cross compiler is hosted on
Windows, but you are building it on Linux.  You can't run the newly
built gcc 12, so you have to use the original gcc 5 instead.  That's
why you have to start with a new native compiler, and then use that to
build the cross compiler.

Re: Can't build Ada

[Iain Sandoe]

Hi Paul,

> On 25 Nov 2022, at 20:08, Paul Koning via Gcc  wrote:
> 
>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
>> 
>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>>> 
>>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
>>> precise) to build Ada, starting with the latest (2020) release of Gnat from 
>>> Adacore.
>> 
>> Are you building a cross compiler or a native compiler?
>> If you are building a cross, you need to bootstrap a native compiler first.
> 
> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
> aarch64-darwin.

you are building a cross then.

> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

Building a cross GNAT requires that the build compiler is from the same sources 
as the cross - so, as Andrew says, you need to bootstrap the current sources on 
x86_64 and then use that compiler to build the cross to aarch64.  I’m not sure 
exactly where this constraint is mentioned .. but, nevertheless, it is a 
constraint.

FWIW: I have not done this for a few weeks (using my arm64 prototype branch) 
but it was working fine then.

Iain

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>
>
>
> > On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> >
> > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
> > wrote:
> >>
> >> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> >> precise) to build Ada, starting with the latest (2020) release of Gnat 
> >> from Adacore.
> >
> > Are you building a cross compiler or a native compiler?
> > If you are building a cross, you need to bootstrap a native compiler first.
>
> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
> aarch64-darwin.

You have to build a x86_64-darwin compiler first with the same sources
as you are building for aarch64-darwin.

>
> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

>From https://gcc.gnu.org/install/prerequisites.html:
"In order to build a cross compiler, it is strongly recommended to
install the new compiler as native first, and then use it to build the
cross compiler. Other native compiler versions may work but this is
not guaranteed and *will typically fail with hard to understand
compilation errors during the build."

I added the emphasis but yes this is all documented correctly.

Thanks,
Andrew Pinski

>
> paul
>
>

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> 
> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>> 
>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
>> precise) to build Ada, starting with the latest (2020) release of Gnat from 
>> Adacore.
> 
> Are you building a cross compiler or a native compiler?
> If you are building a cross, you need to bootstrap a native compiler first.

I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
aarch64-darwin.

But in any case, how does that relate to the error messages I got?  They don't 
seem to have anything to do with missing compilers, but rather with the use of 
language features too new for the available (downloadable) Gnat.

paul

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> precise) to build Ada, starting with the latest (2020) release of Gnat from 
> Adacore.

Are you building a cross compiler or a native compiler?
If you are building a cross, you need to bootstrap a native compiler first.

Thanks,
Andrew Pinski

>
> It fails for several reasons.  One is that two source files use [ ] for array 
> initializer brackets when ( ) is apparently supposed to be used instead.  
> Once I fix that, I get a pile of messages I don't know what to do about:
>
> s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
> s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
> s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
> s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
> s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
> s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
> s-widthu.ads:93:11: run-time library configuration error
> s-widthu.ads:93:11: file s-imgint.ads had parser errors
> s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
> compilation abandoned
> make[2]: *** [ada/contracts.o] Error 1
>
> Given that the current open source Gnat is from 2020, so (apparently) it 
> doesn't support Ada 2020 features, how is someone supposed to build the 
> current GCC?  I looked in the prerequisites listing on the webpage, but it 
> says that the Gnat that is built on GCC 5.1 is sufficient.  That seems to be 
> wrong; the GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.
>
> paul
>

Can't build Ada

[Paul Koning via Gcc]

I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
precise) to build Ada, starting with the latest (2020) release of Gnat from 
Adacore.

It fails for several reasons.  One is that two source files use [ ] for array 
initializer brackets when ( ) is apparently supposed to be used instead.  Once 
I fix that, I get a pile of messages I don't know what to do about:

s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
s-widthu.ads:93:11: run-time library configuration error
s-widthu.ads:93:11: file s-imgint.ads had parser errors
s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
compilation abandoned
make[2]: *** [ada/contracts.o] Error 1

Given that the current open source Gnat is from 2020, so (apparently) it 
doesn't support Ada 2020 features, how is someone supposed to build the current 
GCC?  I looked in the prerequisites listing on the webpage, but it says that 
the Gnat that is built on GCC 5.1 is sufficient.  That seems to be wrong; the 
GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.

paul

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Gavin Ray via Gcc]

> Unfortunately not: even fairly simple-looking C++ code can generate extra CFG
edges relating to exception-handling ... making the output essentially useless.

Ahh, I had figured the answer might be something like this. Thanks for
confirming. At least from the small codebase I have, swapping from C -> C++ when
compiling preserves all -fanalyzer warnings except for the ones from custom
malloc() attributes, so that's nice.

I won't count on the analyzer being able to do a stellar job though, so I'll
take what I can get =)

> I'm hoping to spend a good chunk of the GCC 14 development cycle working on
> adding C++ support

That's awesome! I hope you'll write some on these changes again -- I really
enjoyed reading your article on the state of Static Analysis in GCC 12 and your
LPC presentation.

I believe that's where I learned about the SARIF exporter, which with the VS
Code extension is just beyond cool!

> The analyzer makes use of the "malloc", "nonnull" and "const" function
attributes. It does make use of the "access" attribute, but only within
-Wanalyzer- tainted-size, for the case where the size param of the access is
attacker-controlled.

Ahh okay, thanks. I currently don't run the taint analysis, as this app is a
database a-la Postgres/SQLite built as a learning exercise/hobby so it's not so
much of a concern.

> the first [[gnu::malloc]] here is redundant, as it's implied by
> [[gnu::malloc(HeapPage_free, 1)]].

Good to know, ty -- it may be useful to modify the 'attribute' docs for these,
because currently it shows combined usage and phrases it as:

"Independently, the form of the attribute with one or two arguments associates
deallocator as a suitable deallocation function..."

__attribute__ ((malloc, malloc (fclose, 1))) FILE* fdopen (int, const char*);

On a related note, the "fd" analyzers warn: "fd may not be valid" but don't
clarify what "valid" means.

I found the DOT diagrams in the analyzer source and it turns out that the key is
to check "if (fd >= 0)". Maybe this could be added to the "fd" analyzer
warnings/info, too?



Anyways, sorry to drone on. I think that the GCC Static Analyzer and the LLVM
Dataflow Analysis Framework are vital for the the evolution of safety and
developer experience in authoring C/C++

Big thanks to all involved and it's exciting to watch the shortlog & follow the
progress from the sidelines =)

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[David Malcolm via Gcc]

On Wed, 2022-11-23 at 20:49 -0500, Gavin Ray via Gcc wrote:
> Hey all, just a few questions about the fantastic GCC Static
> Analyzer:

Hi!

> 
> - It's stated that support for C++ vs C is very limited. Does this
> apply if
>   you're writing C++ that is very similar-looking to C and uses few
> of C++'s
>   advanced features?

Unfortunately not: even fairly simple-looking C++ code can generate
extra CFG edges relating to exception-handling, which -fanalyzer
currently doesn't understand at all, making the output essentially
useless.  And that's just one issue...

Strictly speaking I have added some *very* minimal regression tests in
C++ to our test suite, but on anything beyond the most trivial example
it's likely to run into a known issue.  I'm tracking some of these
known issues here:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110
but the C++ support is currently so minimal that it's probably not yet
worth filing extra bugs against that tracker :-/

I'm hoping to spend a good chunk of the GCC 14 development cycle
working on adding C++ support, with the aim of being able to analyze
GCC itself ("eating my own dog food"), so I hope this situation will
improve greatly then.

> 
> - I noticed that in C++, the "gnu::malloc" attributes don't seem to
> report
>   "warning: leak of 'xxx_alloc()' [CWE-401] [-Wanalyzer-malloc-
> leak]", is
> this
>   normal?

In theory they should; but you could be running into issues with the
analyzer not fully understanding the control flow graph.

> 
> - Is it worthwhile to spend time annotating your method signatures
> with
>   attributes like "malloc" and "access"? Do these aid the -fanalyzer
> passes?

The analyzer makes use of the "malloc", "nonnull" and "const" function
attributes.

It does make use of the "access" attribute, but only within -Wanalyzer-
tainted-size, for the case where the size param of the access is
attacker-controlled (and the taint checker is currently off by default,
even with -fanalyzer).

But like I said, don't expect these to work on C++ code yet.

> 
> For instance:
> 
> [[gnu::malloc]] [[gnu::malloc(HeapPage_free, 1)]]

IIRC, the first [[gnu::malloc]] here is redundant, as it's implied by
[[gnu::malloc(HeapPage_free, 1)]].

> [[gnu::returns_nonnull]]
> struct HeapPage* HeapPage_alloc();
> 
> [[gnu::access(read_write, 1, 3)]]
> struct RecordID
> HeapPage_insert_record(struct HeapPage* page, const char* record,
>    uint32_t record_length);
> 
> That's quite a significant bit of annotation-noise tacked on to the
> function, so
> I wanted to be sure it's worth the investment!

Maybe in GCC 14 onwards, but it definitely won't be worth it at the
moment.

Hope this is helpful
Dave

> 
> Thank you =)
> Gavin Ray
> 

Re: About -fasan-shadow-offset option

[Martin Liška]

On 11/16/22 10:01, tao.z...@amlogic.com wrote:
> Dear gcc:
> 

Hello.

Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would 
be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated 
-fasan-shadow-offset.

Cheers,
Martin

> I am developing a address sanitiser tools for u-boot. Basically refers 
> compile options from kernel side. But there is a problem that I must set 
> -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will 
> use 0x10 as default value for shadow offset and caused boot failed 
> because this value is too large.
> The problem is uboot do not have a fixed memory layout as kernel. 
> Basically it will relocate to end of DDR size and running at that memory 
> space. Usually memory map for uboot is virt=phys and there are lots of 
> drivers do not do address translate for dma based on this mapping. But ddr 
> size are different on each platform. So it's hard to handle shadow offset at 
> this scenario.
> My point is that can gcc add an option like -fasan-shadow-symbol=, 
> here  is a global variable and implementors can configure it's value 
> based on platforms ddr size/malloc buffer size during initialize stage and 
> this variable can be used for shadow address calculation during runtime. This 
> may be more fitable compared than a fixed value during compile stage.  And is 
> there any other options to help my problem?
> Waiting for your response asap.
>  Thanks.
> 
> 
> 
> Thanks!
> B.R.
> tao.z...@amlogic.com
>  
> Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
> 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
> 

Re: Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

[Iain Sandoe]

Hi Pete,

> On 25 Nov 2022, at 10:36, Peter Dyballa via Gcc  wrote:

> On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories 
> behind, created by dsymutil:
> 
>   checking for build system preprocessor... rm: conftest.dSYM: is a 
> directory
>   checking for build system executable suffix... rm: conftest.dSYM: is a 
> directory
>   checking whether build system compiler is ANSI... rm: conftest.dSYM: is 
> a directory
>   checking for build system compiler math library... rm: conftest.dSYM: 
> is a directory
> 
> Building GCC 10.3 with MacPorts the configure scripts produce 178 such 
> reports (and more than 11,000 checking lines without complaint). (The 
> relation is worse when building smaller software packages.)

I agree it’s an irritation (although not a show-stopper, so other things are 
higher priority right now on my list).

> Is it possible to replace the simple "rm" with "rm -r", at least on darwin, 
> the macOS/Mac OS X? Or create a special macro to be used when dsymutil gets 
> involved?

It is likely to be possible, where the configure tests can be modified in the 
GCC sources.

The best course of action is to take them one by one and see where the 
configure source comes from, go to that source and modify the rm (hopefully, 
conditionally on *-*-darwin*) to deal with this.  If the source of the problems 
is primarily libtool.m4 … then we do make local modifications, but now that 
(libtool) is maintained again we should look into how much we can sync with 
upstream.

I’m happy to review patches (if they are macOS/darwin-specific, then I can even 
approve them).

Iain

> 
> --
> 
> Greetings
> 
>  Pete
> 
> Every instructor assumes that you have nothing else to do except study for 
> that instructor's course. 
>   – Fourth Law of Applied Terror
> 

Re: Please, really, make `-masm=intel` the default for x86

[David Brown]

On 25/11/2022 07:39, LIU Hao via Gcc wrote:
I am a Windows developer and I have been writing x86 and amd64 assembly 
for more than ten years. One annoying thing about GCC is that, for x86 
if I need to write I piece of inline assembly then I have to do it 
twice: one in AT&T syntax and one in Intel syntax.



The AT&T syntax is an awkward foreign dialect, designed originally for 
PDP-11 and spoken by bumpkins that knew little about x86 or ARM. No 
official Intel or AMD documentation ever adopts it. The syntax is 
terrible. Consider:


    movl $1, %eax  ; k; moves $1 into EAX
   ; but in high-level languages we expect '%eax = $1',
   ; so it goes awkwardly backwards.

If this looks fine to you, please re-consider:

   cmpl $1, %eax
   jg .L1  ; does this mean 'jump if $1 is greater than %eax'
   ; or something stupidly reversed?

If CMP still looks fine to you, please consider how to write VFMADD231PD 
in AT&T syntax, really.



I have been tired of such inconsistency. For God's sake, please 
deprecate it.





You can have all the personal preferences or prejudices you want, but 
that won't change the fact that AT&T syntax was the standard x86 
assembly from long before Intel thought of making their own syntax, and 
it is here to stay.  No one is going to deprecate it, remove it, or 
change any defaults.



#include 

int main(void)
{
int temp=0;

asm
(   ".intel_syntax noprefix"
"mov %0, 1"
".att_syntax"
: "=r"(temp)
:   /* no input*/
);
printf("temp=%d\n", temp);
}


A use feature that could be added to gcc, perhaps, would be a way to let 
the user specify the assembler dialect as part of the "asm" statement:


asm __attribute__((masm = "intel")) ( ... )

The idea with this is that it would issue the requested ".intel_syntax 
noprefix" or ".att_syntax" at the start of the assembly, and the 
appropriate directive to return to normal syntax at the end - adjusting 
according to the "-masm" setting for the compilation.  This would, I 
think, let people write the assembly once in the syntax they choose, and 
have it work smoothly regardless of which syntax is chosen for compilation.

Re: Please, really, make `-masm=intel` the default for x86

[Richard Biener via Gcc]

On Fri, Nov 25, 2022 at 1:03 PM LIU Hao via Gcc  wrote:
>
> 在 2022/11/25 17:32, Jakub Jelinek 写道:
> > So just use -masm=intel yourself and don't force it on others.
> >
> > Other people are familiar with AT&T syntax rather than Intel syntax,
> > in fact, as history shows, Intel syntax is a second class citizen that often
> > takes years to fix up for new instructions.  The memory size prefixes for
> > certain vector instructions are complete lottery and has been changed by the
> > assembler over time.
> >
> > And more importantly, various valid sources aren't really compilable at all
> > with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some 
> > details.
> >
>
> Well, if that's your decision, fair enough. I can maintain my own 
> distribution.
>
> Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any 
> issues so far.

it would be also possible to at a configure time choice, or one driven
by config.gcc (thus
*mingw* could default to intel syntax if they like).

Richard.

>
> [1]
> https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch
>
>
> --
> Best regards,
> LIU Hao
>

Re: Please, really, make `-masm=intel` the default for x86

[LIU Hao via Gcc]

在 2022/11/25 17:32, Jakub Jelinek 写道:

So just use -masm=intel yourself and don't force it on others.

Other people are familiar with AT&T syntax rather than Intel syntax,
in fact, as history shows, Intel syntax is a second class citizen that often
takes years to fix up for new instructions.  The memory size prefixes for
certain vector instructions are complete lottery and has been changed by the
assembler over time.

And more importantly, various valid sources aren't really compilable at all
with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.



Well, if that's your decision, fair enough. I can maintain my own distribution.

Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any 
issues so far.


[1] 
https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

[Peter Dyballa via Gcc]

Hello!

On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories behind, 
created by dsymutil:

checking for build system preprocessor... rm: conftest.dSYM: is a 
directory
checking for build system executable suffix... rm: conftest.dSYM: is a 
directory
checking whether build system compiler is ANSI... rm: conftest.dSYM: is 
a directory
checking for build system compiler math library... rm: conftest.dSYM: 
is a directory

Building GCC 10.3 with MacPorts the configure scripts produce 178 such reports 
(and more than 11,000 checking lines without complaint). (The relation is worse 
when building smaller software packages.)

Is it possible to replace the simple "rm" with "rm -r", at least on darwin, the 
macOS/Mac OS X? Or create a special macro to be used when dsymutil gets 
involved?

--

Greetings

  Pete

Every instructor assumes that you have nothing else to do except study for that 
instructor's course. 
– Fourth Law of Applied Terror

Re: Please, really, make `-masm=intel` the default for x86

[Iain Sandoe]

> On 25 Nov 2022, at 09:11, LIU Hao via Gcc  wrote:
> 
> 在 2022/11/25 16:50, Marc Glisse 写道:
>> On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
>>> I am a Windows developer and I have been writing x86 and amd64 assembly for 
>>> more than ten years. One annoying thing about GCC is that, for x86 if I 
>>> need to write I piece of inline assembly then I have to do it twice: one in 
>>> AT&T syntax and one in Intel syntax.
>> The doc for -masm=dialect says:
>> Darwin does not support ‘intel’.
>> Assuming that's still true, and even with Mac Intel going away, it doesn't 
>> help.
> 
> Did you mean 'Darwin' instead of 'macOS'?
> 
> The first-class C and C++ compiler for macOS is Clang anyway; even the thing 
> named 'gcc' is effectively Clang.

Darwin, OS X, PureDarwin, macOS (Intel) all default to AT&T
(as does clang on the platform - I am not even sure if Intel syntax is 
supported for macOS/Darwin there either).
.. we can be 100% sure that any Intel syntax support is (at least almost) 
completely untested.

NOTE that the GCC gfortran (and Ada) remain the tools of choice on macOS (and 
they also need the assembler).

It would be pretty difficult to change the default; if GCC changed, I’d only 
end up patching the Darwin port to default to AT&T .. perhaps a solution for 
the Windows port is to patch it locally to default to Intel?

Iain

> 
> 
> -- 
> Best regards,
> LIU Hao
> 

William Loan Firm

[Josiah Mask via Gcc]

Awesome method just for you https://bit.ly/3ADHsha


 With gratitude,William Loan Firm

Re: Please, really, make `-masm=intel` the default for x86

[Jakub Jelinek via Gcc]

On Fri, Nov 25, 2022 at 02:39:41PM +0800, LIU Hao via Gcc wrote:
> I am a Windows developer and I have been writing x86 and amd64 assembly for
> more than ten years. One annoying thing about GCC is that, for x86 if I need
> to write I piece of inline assembly then I have to do it twice: one in AT&T
> syntax and one in Intel syntax.

So just use -masm=intel yourself and don't force it on others.

Other people are familiar with AT&T syntax rather than Intel syntax,
in fact, as history shows, Intel syntax is a second class citizen that often
takes years to fix up for new instructions.  The memory size prefixes for
certain vector instructions are complete lottery and has been changed by the
assembler over time.

And more importantly, various valid sources aren't really compilable at all
with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.

Jakub

Re: Please, really, make `-masm=intel` the default for x86

[Jonathan Wakely via Gcc]

On Fri, 25 Nov 2022 at 09:16, LIU Hao via Gcc  wrote:
>
> 在 2022/11/25 16:50, Marc Glisse 写道:
> > On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:
> >
> >> I am a Windows developer and I have been writing x86 and amd64 assembly 
> >> for more than ten years.
> >> One annoying thing about GCC is that, for x86 if I need to write I piece 
> >> of inline assembly then I
> >> have to do it twice: one in AT&T syntax and one in Intel syntax.
> >
> > The doc for -masm=dialect says:
> >
> >  Darwin does not support ‘intel’.
> >
> > Assuming that's still true, and even with Mac Intel going away, it doesn't 
> > help.
> >
>
> Did you mean 'Darwin' instead of 'macOS'?

Darwin is the name used in the GNU target triplet. It's an older name
than macOS, which was previously called OS X.

> The first-class C and C++ compiler for macOS is Clang anyway; even the thing 
> named 'gcc' is
> effectively Clang.

And? GCC still works there. As a Windows developer I'm surprised to
hear you suggesting that only the default system compiler matters.
Should GCC stop supporting Windows?

Re: Please, really, make `-masm=intel` the default for x86

[LIU Hao via Gcc]

在 2022/11/25 16:50, Marc Glisse 写道:

On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:

I am a Windows developer and I have been writing x86 and amd64 assembly for more than ten years. 
One annoying thing about GCC is that, for x86 if I need to write I piece of inline assembly then I 
have to do it twice: one in AT&T syntax and one in Intel syntax.


The doc for -masm=dialect says:

 Darwin does not support ‘intel’.

Assuming that's still true, and even with Mac Intel going away, it doesn't help.



Did you mean 'Darwin' instead of 'macOS'?

The first-class C and C++ compiler for macOS is Clang anyway; even the thing named 'gcc' is 
effectively Clang.



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

Re: Please, really, make `-masm=intel` the default for x86

[Marc Glisse via Gcc]

On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:

I am a Windows developer and I have been writing x86 and amd64 assembly for 
more than ten years. One annoying thing about GCC is that, for x86 if I need 
to write I piece of inline assembly then I have to do it twice: one in AT&T 
syntax and one in Intel syntax.


The doc for -masm=dialect says:

Darwin does not support ‘intel’.

Assuming that's still true, and even with Mac Intel going away, it doesn't 
help.


--
Marc Glisse

Re: Please, really, make `-masm=intel` the default for x86

[LIU Hao via Gcc]

在 2022/11/25 15:48, Dave Blanchard 写道:

While I sympathize with the desire to get rid of crud (and I agree that AT&T 
syntax is crud), as stated above it wouldn't really make a practical difference. 
For distro maintainers it would likely break some/many older packages which assumed 
the old default behavior, thus requiring a number of patches. Usually not a big 
deal in and of itself (though it can be if the build system for that package is 
particularly junky), but when you consider there are so many packages including GCC 
always deprecating and changing things, it adds up to a lot of work to keep up with 
it all.



I hope that, if we decide to make Intel syntax the default since GCC 14, then such crud will be 
eventually got rid of since GCC 24. OTOH, if we don't do that, we would have to live with it forever.



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature