GCC 11.2.1 Status Report (2021-07-28)

[Richard Biener]

Status
==

The GCC 11.2.0 tarballs have been generated and uploaded and the
GCC 11 branch is again open for regression and documentation fixes.


Quality Data


Priority  #   Change from last report
---   ---
P1  
P2  262   +   2
P3  104   +   8
P4  206
P5   24
---   ---
Total P1-P3 366   +  10
Total   596   +  10


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-July/236836.html

GCC 11.2 Released

[Richard Biener]

The GNU Compiler Collection version 11.2 has been released.

GCC 11.2 is a bug-fix release from the GCC 11 branch containing important
fixes for regressions and serious bugs in GCC 11.1 with more than 95 bugs
fixed since the previous release.

This release is available from the WWW and FTP servers listed here:

 https://sourceware.org/pub/gcc/releases/gcc-11.2.0/
 https://gcc.gnu.org/mirrors.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: tree decl stored during LGEN does not map to a symtab_node during WPA

[Richard Biener via Gcc]

On Thu, Jul 22, 2021 at 4:33 PM Erick Ochoa  wrote:
>
> >
> > But the addresses are at LGEN time?
>
> The following is what runs at WPA time
>
> unsigned long pid = streamer_read_uhwi (&ib);
> unsigned long id = streamer_read_uhwi (&ib);
> lto_symtab_encoder_t encoder = file_data->symtab_node_encoder;
> cgraph_node *cnode =
> dyn_cast(lto_symtab_encoder_deref(encoder, id));
> logger ("%s %ld %ld %p\n", cnode->name (), pid, id, cnode);
>
> > Note the nodes are actually
> > streamed to different instances by input_symtab, then decls are merged
> > (lto_symtab_merge_decls), then I think the IPA
> > pass summaries are read in (to different unmerged instances!), _then_
> > the symtab merging process starts (lto_symtab_merge_symbols).
> > I think the last step eventually calls the cgraph/varpool removal hook
> > IPA passes registered.
>
> Ah, so what you are saying is that during the read_summary stage they
> will still be different, but during execute or
> write_optimization_summary (), will they be finally merged? I think
> maybe the terminology of LGEN/WPA/LTRANS should be expanded to be
> lgen_gen, lgen_write, lwpa_read, lwpa_exec/lwpa_write, ltrans_read,
> ltrans_exec?
>
> So, just to be a bit more concrete, when initializing the
> ipa_opt_pass_d instance one has to write functions which will be
> called by a parent process. Normally I see the following comments with
> them:
>
> generate_summary
> write_summary
> read_summary
> write_optimization_summary
> read_optimization_summary
>
> and finally there's the execute function that gets called.
>
> I am doing the following:
>
> generate_summary, /* generating pid */
> write_summary /* generating id and writing pid and id */
> read_summary /* reading and printing the info I told about */
> write_optimization_summary /* nothing yet */
> read_optimization_summary /* nothing yet */
> execute /* nothing yet */
>
> And I think these correspond to the following "LGEN/WPA/LTRANS" stages
>
> 1. lgen (multiple processes) generate_summary
> 2. lgen (multiple process) write_summary
> 3. wpa (single process) read_summary
> 4. wpa (single process) execute
> 5. wpa? (single process?) write_optimization_summary
> 6  ltrans (multiple processes) read_optimization_summary
>
>
> And you are telling me that cgraph_node and varpool_nodes will have
> the same address only after the beginning of the execute stage but not
> before that?
>
> Is the above correct?
>
> 
>
> I did try printing cnode->name() during execute and it segfaulted, so
> perhaps those function bodies where merged to something else? Note,
> that some names were successfully printed out. I'm wondering, can I
> use the function lto_symtab_encoder_deref during execute? I think this
> is unlikely... because in the past I've tried to use
> lto_symtab_encoder_encode during generate_summary and it caused
> segfaults. I'll still give it a try.
>
> Perhaps this is still a bit of progress? But now I'm wondering, if I
> can't use lto_symtab_encoder_deref and the nodes were indeed merged,
> do some of the varpool_node* I saved during read_summary are pointing
> to random memory? How am I able to tell which ones survived?

As said there are modification hooks and there's likely one missing for
your case (merge-A-and-B or at least B removal).

> 
>
> >
> > It might be that you need a replace hook to do what you want, I think
> > that for example IPA CP encodes references to global vars aka &global
> > as IPA_REF and those are transparently re-written.
> >
> > As said, I think it can be made work but the details, since this is the
> > first IPA pass needing this, can be incomplete infra-structure-wise.
> >
> > Basically you have summaries like
> >
> >  'global = _3'
> >
> > where the  should eventually be implicit and the constraints
> > grouped into constraints generated from the respective function body
> > and constraints generated by call stmts (not sure here), and constraints
> > for global variable init.  But for the above constraint the point is to
> > make the 'global' references from different LGEN units the same by
> > some means (but not streaming and comparing the actual assembler name).
> >
>
> I'll need some more time to read through how ipa-cp encodes references
> to global variables. Thanks for the suggestion!
>
> I don't really follow the paragraph that details what you think my
> summaries look like. I'm thinking that for
>
> global = _3
>
> global is a variable? and _3 states that it is an SSA variable
> in function 1? I think that can be a possible notation. I prefer to
> just use integers.
>
> What do you mean by implicit?

the  should be implicit, the data can just contain '3'.  With the
assumption that you have a set of constraints recorded for each
function definition (which then naturally only refers to SSA vars in this
function).

> But the idea is to essentially "compile" down all
> variables/functions/locals/ssa/etc into integers. And have the program
> represented as integers and relation of integer

Re: A value number issue

[Richard Biener via Gcc]

On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock  wrote:
>
> Richard,
>
> OK, all that I've gotten so far out of the dump file is
> that the name of "_920" is just something sccvn concocted
> and wasn't something I accidentally caused.
>
> That still leaves me with the question of what is going on.
>
> Here's all the interesting bits of the dumpfile concerning
> dedangled_864:
>
> :
> dedangled_865 = *bea_43 + 64
> dedangled_863 = *bea_43 + 128
> dedangled_864 = *bea_43 + 64
> dedangled_866 = *bea_43 + 128
> dedangled_867 = dedangled_863
> dedangled_867 = dedangled_865
> dedangled_868 = dedangled_864
> dedangled_868 = dedangled_866
> :
> Equivalence classes for indirect node id 160 "dedangled_865": pointer 84, 
> location 0
> Equivalence classes for indirect node id 161 "dedangled_863": pointer 85, 
> location 0
> Equivalence classes for indirect node id 162 "dedangled_864": pointer 86, 
> location 0
> :
> dedangled_865 = { ESCAPED NONLOCAL }
> dedangled_863 = { ESCAPED NONLOCAL }
> dedangled_864 = { ESCAPED NONLOCAL }
> dedangled_866 = { ESCAPED NONLOCAL }
> dedangled_867 = { ESCAPED NONLOCAL }
> dedangled_868 = { ESCAPED NONLOCAL }
> :
> Value numbering store MEM[(int64_t *)&net + 608B] to _59
> Setting value number of .MEM_123 to .MEM_123 (changed)
> Value numbering stmt = dedangled_865 = bea_43->tail;
> Setting value number of dedangled_865 to dedangled_865 (changed)
> Making available beyond BB36 dedangled_865 for value dedangled_865
> Value numbering stmt = dedangled_863 = bea_43->head;
> Setting value number of dedangled_863 to dedangled_863 (changed)
> Making available beyond BB36 dedangled_863 for value dedangled_863
> Value numbering stmt = dedangled_864 = bea_43->tail;
> Inserting name _920 for expression (struct node.reorg.reorder *) dedangled_865

this means that the earlier dedangled_865 = bea_43->tail; somehow did not
produce a value that was considered OK but it was close enough so VN
remembers the expression (struct node.reorg.reorder *) dedangled_865
as known result, using _920 as value.  _920 should be then inserted during
elimination.

I'm not sure what your actual problem is - you can see in eliminate_stmt
how we deal with such values:

  /* If there is no existing usable leader but SCCVN thinks
 it has an expression it wants to use as replacement,
 insert that.  */
  tree val = VN_INFO (lhs)->valnum;
  vn_ssa_aux_t vn_info;
  if (val != VN_TOP
  && TREE_CODE (val) == SSA_NAME
  && (vn_info = VN_INFO (val), true)
  && vn_info->needs_insertion
  && vn_info->expr != NULL
  && (sprime = eliminate_insert (b, gsi, val)) != NULL_TREE)
eliminate_push_avail (b, sprime);


> Setting value number of dedangled_864 to _920 (changed)
> Making available beyond BB36 dedangled_864 for value _920
> Value numbering stmt = dedangled_866 = bea_43->head;
> :
> Value numbering stmt = dedangled_868 = PHI  dedangled_866(37)>
> Setting value number of dedangled_868 to dedangled_868 (changed)
> :
> Setting value number of dedangled_363 to _920 (changed)
> dedangled_864 is available for _920
> Value numbering stmt = _896 = dedangled_363 == dedangled_873;
> dedangled_864 is available for _920
> (the last line repeats many times)
> :
> Value numbering stmt = _881 = dedangled_363 == dedangled_875;
> dedangled_864 is available for _920
> (the last line repeats many times)
> :
> Value numbering stmt = _880 = _881 & _891;
> dedangled_864 is available for _920
> dedangled_864 is available for _920
> dedangled_864 is available for _920
> dedangled_864 is available for _920
> :
> Setting value number of dedangled_313 to _920 (changed)
> dedangled_864 is available for _920
> Value numbering stmt = _904 = dedangled_313 == dedangled_873;
> dedangled_864 is available for _920
> (the last line repeats many times)
> :
> Value numbering stmt = _442 = _11 & _904;
> dedangled_864 is available for _920
> Match-and-simplified _11 & _904 to _904
> :
> Value numbering stmt = if (_442 != 0)
> dedangled_864 is available for _920
> :
> Making available beyond BB36 dedangled_863 for value dedangled_863
> Value numbering stmt = dedangled_864 = bea_43->tail;
> Setting value number of dedangled_864 to _920
> Making available beyond BB36 dedangled_864 for value _920
> Value numbering stmt = dedangled_866 = bea_43->head;
> :
> Making available beyond BB38 dedangled_867 for value dedangled_867
> Value numbering stmt = dedangled_868 = PHI  dedangled_866(37)>
> Setting value number of dedangled_868 to dedangled_868
> :
> Setting value number of dedangled_363 to _920
> dedangled_864 is available for _920
> Value numbering stmt = _896 = dedangled_363 == dedangled_873;
> dedangled_864 is available for _920
> (the last line repeats many times)
> :
> Value numbering stmt = _881 = dedangled_363 == dedangled_875;
> dedangled_864 is available for _920
> (the last line repeats many times)
> :
> (a bunch more of the "dedangled_864 is 

Re: GCC 11.2 Released

[Geoffrey S. Knauth]

Thank you!

On Wed, Jul 28, 2021, at 03:40, Richard Biener wrote:
> The GNU Compiler Collection version 11.2 has been released.
> 
> GCC 11.2 is a bug-fix release from the GCC 11 branch containing important
> fixes for regressions and serious bugs in GCC 11.1 with more than 95 bugs
> fixed since the previous release.
> 
> This release is available from the WWW and FTP servers listed here:
> 
>  https://sourceware.org/pub/gcc/releases/gcc-11.2.0/
>  https://gcc.gnu.org/mirrors.html
> 
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
> 
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
> 
> -- 
> If you have a working or partly working program that you'd like
> to offer to the GNU project as a GNU package,
> see https://www.gnu.org/help/evaluation.html.


-- 
Geoffrey S. Knauth | https://knauth.org/gsk

Re: daily report on extending static analyzer project [GSoC]

[Ankur Saini via Gcc]

AIM For Today: 

- Make the anlalyzer evaluate the vfunc calls by creating enodes and eedges 
  representing the call. 

- Make the analyzer not treat such calls as call to "unknown function"

---
PROGRESS :

- After the analyzer sucessfully found which funcitons to call ( thanks to 
  functions from ipa-devirt.c ), All that was left was it to create enodes and 
  eedges for analyzeing such calls for which I took the same aproach I used to 
  detect and analyzer calls via function pointers. 

- now the analyzer was sucessfully decting and analyzing the calls via 
  functions pointers, but due to some reason it was still not giving out 
  analysis reports for such calls. 

- After a bit of digging, I found out that analyzer was also treating such 
  calls as " call to unknown funcitons " and in case of such calls, analyzer 
  plays safe by resetting all of the state-machine state for the values that 
  are reachable by the function call, to avoid false reports. ( it was also 
  mentioned in a previous discussions 
 on the list)

- I fixed the porblem by simply updating exploded_node::on_stmt () by setting
  the value of "unknown_side_effects" ( a boolean which is set true when
  analyzer thinks executing a gimple stmt would cause some side effects, and 
  acts conservatively for such cases ) to "false" when gimple call stmt is a 
  polymorphic call. Some thing like this, at the end of the definition of 
  exploded_node::on_stmt (): -

File: {src-dir}/gcc/analyzer/engine.cc
1246: /* If the statmement is a polymorphic call then assume 
1247:there are no side effects.  */
1248: gimple *call_stmt = const_cast(stmt);
1249: if (gcall *call = dyn_cast (call_stmt))
1250: {
1251:   function *fun = this->get_function();
1252:   cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (call);
1253:   if ((e && e->indirect_info) && (e->indirect_info->polymorphic))
1254: unknown_side_effects = false;
1255: }
1256: 
1257:   on_stmt_post (stmt, state, unknown_side_effects, &ctxt);
1258: 
1259:   return on_stmt_flags ();

- After this the analyzer was working as expected for virtual function calls on
  all of the examples I created. 

- Let's take example of the following program ( the same program which was
  mentioned in proposal, for which analyzer was giving out a false positive )

File: test.cpp
01: #include 
02: 
03: struct A
04: {
05: virtual int foo (void) 
06: {
07: return 42;
08: }
09: };
10: 
11: struct B: public A
12: {
13: int *ptr;
14: void alloc ()
15: {
16: ptr = (int*)malloc(sizeof(int));
17: }
18: int foo (void) 
19: { 
20: free(ptr);
21: return 0;
22: }
23: };
24: 
25: int test()
26: {
27: struct B b, *bptr=&b;
28: b.alloc();
29: bptr->foo();
30: return bptr->foo();
31: }
32: 
33: int main()
34: {
35: test();
36: }
37: 
( godbolt link of the above code (https://godbolt.org/z/n17WK4MxG) )

for the same porgram, the analyzer now generates the following warning message :

warning: double-‘free’ of ‘b.B::ptr’ [CWE-415] [-Wanalyzer-double-free]
   20 | free(ptr);
  | ^
  ‘int test()’: events 1-2
|
|   25 | int test()
|  | ^~~~
|  | |
|  | (1) entry to ‘test’
|..
|   28 | b.alloc();
|  | ~
|  ||
|  |(2) calling ‘B::alloc’ from ‘test’
|
+--> ‘void B::alloc()’: events 3-4
   |
   |   14 | void alloc ()
   |  |  ^
   |  |  |
   |  |  (3) entry to ‘B::alloc’
   |   15 | {
   |   16 | ptr = (int*)malloc(sizeof(int));
   |  | ~~~
   |  |   |
   |  |   (4) allocated here
   |
<--+
|
  ‘int test()’: events 5-6
|
|   28 | b.alloc();
|  | ~~~^~
|  ||
|  |(5) returning to ‘test’ from ‘B::alloc’
|   29 | bptr->foo();
|  | ~~~
|  |  |
|  |  (6) calling ‘B::foo’ from ‘test’
|
+--> ‘virtual int B::foo()’: events 7-8
   |
   |   18 | int foo (void)
   |  | ^~~
   |  | |
   |  | (7) entry to ‘B::foo’
   |   19 | {
   |   20 | free(ptr);
   |  | ~
   |  | |
   |  | (8) first ‘free’ here
   |
<--+
|
  ‘int test()’: events 9-10
|
|   29 | bptr->foo();
|  | ~^~
|  |  |
|  |  (9) returning to ‘test’ from ‘B::fo

[RISCV] RISC-V GNU Toolchain Biweekly Sync-up call (July 29, 2021)

[吴伟]

Hi all,

There is an agenda for tomorrow's meeting. If you have topics to
discuss or share, please let me know and I can add them to the agenda.


Agenda:

1. Discuss the Vector Calling Convention.
2. Status update of implementation for unratified extensions.
3. Open Discussion
4. (optional) Status update of RISC-V Lab / CI Infrastructure.

Wei Wu - PLCT Lab is inviting you to a scheduled Zoom meeting.

Topic: RISC-V GNU Toolchain Biweekly Sync-up

Join Zoom Meeting
https://zoom.com.cn/j/89393600951?pwd=ZFpWMkZ6Tm1TbUFXT1hZZjZZMHhRQT09

Meeting ID: 893 9360 0951
Passcode: 899662

BEIJING, China
11:00pThu, Jul 29 2021
12:00aFri, Jul 30 2021

PDT/PST, Pacific Daylight Time (US)
8:00aThu, Jul 29 2021
9:00aThu, Jul 29 2021

LONDON, United Kingdom, England
4:00pThu, Jul 29 2021
5:00pThu, Jul 29 2021

-- 
Best wishes,
Wei Wu (吴伟)

Re: A value number issue

[Gary Oblock via Gcc]

Richard,

Here is more on the actual failure.

>From the pre pass dump:

:
Inserted _975 = (struct node.reorg.reorder *) dedangled_865;
Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;



EMERGENCY DUMP:

void master.constprop ()
{
  :
  unsigned long _974;
  struct node.reorg.reorder * _975;

  :
   [local count: 4422246]:
  _58 = MEM[(int64_t *)&net + 608B];
  _59 = _58 + 1;
  MEM[(int64_t *)&net + 608B] = _59;
  dedangled_865 = bea_43->tail;
  dedangled_863 = bea_43->head;
  _975 = (struct node.reorg.reorder *) dedangled_865;
  dedangled_864 = bea_43->tail;
  dedangled_866 = bea_43->head;
  if (red_cost_of_bea_42 > 0)
goto ; [59.00%]
  else
goto ; [41.00%]
  :
--
In tree-ssa-sccvn.c at about line 6000 or so there is
this sequence:

  if (!useless_type_conversion_p (TREE_TYPE (lhs),
  TREE_TYPE (sprime)))
{
  /* We preserve conversions to but not from function or method
 types.  This asymmetry makes it necessary to re-instantiate
 conversions here.  */
  if (POINTER_TYPE_P (TREE_TYPE (lhs))
   && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (lhs
sprime = fold_convert (TREE_TYPE (lhs), sprime);
  else
gcc_unreachable ();
}

We reach the gcc_unreachable because:

lhs = dedangled_864, TREE_TYPE(lhs) = unsigned long
sprime = _975, TREE_TYPE(sprime) = struct node.reorg.reorder *

I've got to ask why does the _975 have that type?
The ssa var dedangled_865 is an unsigned long.
If I knew why this happens then, hopefully, I can adjust
the GIMPLE I create to avoid this situation...

Question, would have including all references to denangled_865
in the pre pass dump helped you answer this? By the way, I couldn't
find a spot where dedangled_865 or any of its phi related uses
(a use of x where x <- phi<... denanged_865..> and so on recursively)
was converted to struct node.reorg.reorder *.

Gary



From: Richard Biener 
Sent: Wednesday, July 28, 2021 3:40 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A value number issue

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock  wrote:
>
> Richard,
>
> OK, all that I've gotten so far out of the dump file is
> that the name of "_920" is just something sccvn concocted
> and wasn't something I accidentally caused.
>
> That still leaves me with the question of what is going on.
>
> Here's all the interesting bits of the dumpfile concerning
> dedangled_864:
>
> :
> dedangled_865 = *bea_43 + 64
> dedangled_863 = *bea_43 + 128
> dedangled_864 = *bea_43 + 64
> dedangled_866 = *bea_43 + 128
> dedangled_867 = dedangled_863
> dedangled_867 = dedangled_865
> dedangled_868 = dedangled_864
> dedangled_868 = dedangled_866
> :
> Equivalence classes for indirect node id 160 "dedangled_865": pointer 84, 
> location 0
> Equivalence classes for indirect node id 161 "dedangled_863": pointer 85, 
> location 0
> Equivalence classes for indirect node id 162 "dedangled_864": pointer 86, 
> location 0
> :
> dedangled_865 = { ESCAPED NONLOCAL }
> dedangled_863 = { ESCAPED NONLOCAL }
> dedangled_864 = { ESCAPED NONLOCAL }
> dedangled_866 = { ESCAPED NONLOCAL }
> dedangled_867 = { ESCAPED NONLOCAL }
> dedangled_868 = { ESCAPED NONLOCAL }
> :
> Value numbering store MEM[(int64_t *)&net + 608B] to _59
> Setting value number of .MEM_123 to .MEM_123 (changed)
> Value numbering stmt = dedangled_865 = bea_43->tail;
> Setting value number of dedangled_865 to dedangled_865 (changed)
> Making available beyond BB36 dedangled_865 for value dedangled_865
> Value numbering stmt = dedangled_863 = bea_43->head;
> Setting value number of dedangled_863 to dedangled_863 (changed)
> Making available beyond BB36 dedangled_863 for value dedangled_863
> Value numbering stmt = dedangled_864 = bea_43->tail;
> Inserting name _920 for expression (struct node.reorg.reorder *) dedangled_865

this means that the earlier dedangled_865 = bea_43->tail; somehow did not
produce a value that was considered OK but it was close enough so VN
remembers the expression (struct node.reorg.reorder *) dedangled_865
as known result, using _920 as value.  _920 should be then inserted during
elimination.

I'm not sure what your actual problem is - you can see in eliminate_stmt
how we deal with such values:

  /* If there is no existing usable leader but SCCVN thinks
 it has an expression it wants to use as replacement,
 insert that.  */
  tree val = VN_INFO (lhs)->valnum;
  vn_ssa_aux_t vn_info;
  if (val != VN_TOP
  && TREE_CODE (val) == SSA_NAME
  && (vn_info = VN_INFO (val), true)
  && vn_info->needs_insertion
  && vn_info->expr != NULL
  && (sprime = eliminate_insert (b, gsi, val)) != NULL_TREE)
e

How to detect user uses -masm=intel?

[unlvsur unlvsur via Gcc]

Any GCC macro that can tell the code it is using the intel format’s assembly 
instead of at&t??

Sent from Mail for Windows 10

Re: How to detect user uses -masm=intel?

[Andrew Pinski via Gcc]

On Wed, Jul 28, 2021 at 6:41 PM unlvsur unlvsur via Gcc  wrote:
>
> Any GCC macro that can tell the code it is using the intel format’s assembly 
> instead of at&t??

Inside the inline-asm you can use the alternative.
Like this:
cmp{b}\t{%1, %h0|%h0, %1}

This is how GCC implements this inside too.

Thanks,
Andrew

>
> Sent from Mail for Windows 10
>

RE: How to detect user uses -masm=intel?

[unlvsur unlvsur via Gcc]

Do not quite understand. Can you show me an example??

Sent from Mail for Windows 10

From: Andrew Pinski
Sent: Wednesday, July 28, 2021 21:43
To: unlvsur unlvsur
Cc: gcc@gcc.gnu.org
Subject: Re: How to detect user uses -masm=intel?

On Wed, Jul 28, 2021 at 6:41 PM unlvsur unlvsur via Gcc  wrote:
>
> Any GCC macro that can tell the code it is using the intel format’s assembly 
> instead of at&t??

Inside the inline-asm you can use the alternative.
Like this:
cmp{b}\t{%1, %h0|%h0, %1}

This is how GCC implements this inside too.

Thanks,
Andrew

>
> Sent from 
> Mail
>  for Windows 10
>

RE: How to detect user uses -masm=intel?

[unlvsur unlvsur via Gcc]

What I mean is that what macro GCC sets when it compiles -masm=intel


Int main()
{
#ifdef /*__INTEL_ASM*/
printf(“intel”);
#else
printf(“at&t”);
#endif
}

Sent from Mail for Windows 10

From: Andrew Pinski
Sent: Wednesday, July 28, 2021 21:43
To: unlvsur unlvsur
Cc: gcc@gcc.gnu.org
Subject: Re: How to detect user uses -masm=intel?

On Wed, Jul 28, 2021 at 6:41 PM unlvsur unlvsur via Gcc  wrote:
>
> Any GCC macro that can tell the code it is using the intel format’s assembly 
> instead of at&t??

Inside the inline-asm you can use the alternative.
Like this:
cmp{b}\t{%1, %h0|%h0, %1}

This is how GCC implements this inside too.

Thanks,
Andrew

>
> Sent from 
> Mail
>  for Windows 10
>

Re: How to detect user uses -masm=intel?

[Hongtao Liu via Gcc]

On Thu, Jul 29, 2021 at 10:49 AM unlvsur unlvsur via Gcc
 wrote:
>
> What I mean is that what macro GCC sets when it compiles -masm=intel
>
>
> Int main()
> {
> #ifdef /*__INTEL_ASM*/
> printf(“intel”);
> #else
> printf(“at&t”);
> #endif
> }
not fully understand what you're seeking, probably you're looking for
ASSEMBLER_DIALECT.

cut from i386.c
---
void
ix86_print_operand (FILE *file, rtx x, int code)
{
  if (code)
{
  switch (code)
{
case 'A':
  switch (ASSEMBLER_DIALECT)
{
case ASM_ATT:
  putc ('*', file);
  break;

case ASM_INTEL:
  /* Intel syntax. For absolute addresses, registers should not
be surrounded by braces.  */
  if (!REG_P (x))
{
  putc ('[', file);
  ix86_print_operand (file, x, 0);
  putc (']', file);
  return;
}
  break;
--

> Sent from Mail for Windows 10
>
> From: Andrew Pinski
> Sent: Wednesday, July 28, 2021 21:43
> To: unlvsur unlvsur
> Cc: gcc@gcc.gnu.org
> Subject: Re: How to detect user uses -masm=intel?
>
> On Wed, Jul 28, 2021 at 6:41 PM unlvsur unlvsur via Gcc  
> wrote:
> >
> > Any GCC macro that can tell the code it is using the intel format’s 
> > assembly instead of at&t??
>
> Inside the inline-asm you can use the alternative.
> Like this:
> cmp{b}\t{%1, %h0|%h0, %1}
>
> This is how GCC implements this inside too.
>
> Thanks,
> Andrew
>
> >
> > Sent from 
> > Mail
> >  for Windows 10
> >
>


-- 
BR,
Hongtao