[Bug target/68896] [ARM] target attribute ignored

2016-01-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68896

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Depends on||69245
 Resolution|--- |FIXED

--- Comment #3 from chrbr at gcc dot gnu.org ---
Fixed in gcc6.0 with new arm_set_current_function and target_pragma


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245
[Bug 69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on
arm-linux-gnueabihf

[Bug target/69512] ICE when using avx with i586

2016-01-27 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic, ice-checking
 Target||i596
   Priority|P3  |P1
  Known to fail||6.0

[Bug target/69512] New: ICE when using avx with i586

2016-01-27 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69512

Bug ID: 69512
   Summary: ICE when using avx with i586
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

a reduced case from gcc.target/i386/avx-vcmppd-1.c that fails instead of being
unsupported for testing with -march=i586

attached test compiled with 
runs withs -O2 -mavx  -march=i586 -m32
ICES with unrecognizable insn

extern double s1[];
extern double s2[];
extern long long e[];

void
avx_test ()
{
  int i;

  for (i = 0; i < 2; i++)
e[i] = !__builtin_isunordered(s1[i], s2[i]) && s1[i] != s2[i] ? -1 : 0;
}


I suppose that avx is not available for this combination ?, so maybe just
missing an arch incompatible option check ?

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-27 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #14 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed Jan 27 13:03:45 2016
New Revision: 232872

URL: https://gcc.gnu.org/viewcvs?rev=232872=gcc=rev
Log:
2016-01-20  Christian Bruel  <christian.br...@st.com>

PR target/69245
* config/arm/arm-c.c (arm_pragma_target_parse): Add comments.
Move arm_reset_previous_fndecl and set_target_option_current_node in
the conditional part.  Call save_restore_target_globals.
* config/arm/arm.c (arm_set_current_function):
Refactor to better support #pragma target and attribute mix.
Call save_restore_target_globals.
* config/arm/arm-protos.h (save_restore_target_globals): New function.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr69245.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2016-01-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

--- Comment #16 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jan 22 14:16:47 2016
New Revision: 232728

URL: https://gcc.gnu.org/viewcvs?rev=232728=gcc=rev
Log:
2016-01-22  Christian Bruel  <christian.br...@st.com>

PR target/68674
* expr.c (expand_expr_real_1): Reset DECL_MODE if VECTOR_TYPE_P
changed.

// testsuite
2016-01-21  Christian Bruel  <christian.br...@st.com>

PR target/68674
* gcc.target/i386/pr68674.c
* gcc.target/aarch64/pr68674.c
* gcc.target/arm/pr68674.c


Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr68674.c
trunk/gcc/testsuite/gcc.target/arm/pr68674.c
trunk/gcc/testsuite/gcc.target/i386/pr68674.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2016-01-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from chrbr at gcc dot gnu.org ---
fixed for gcc 6.0

[Bug target/68895] [ARM] ICE with target attributes

2016-01-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68895

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from chrbr at gcc dot gnu.org ---
duplicate, expand needs to know the simd type mode. Fix under discussion:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01429.html

*** This bug has been marked as a duplicate of bug 68674 ***

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2016-01-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #15 from chrbr at gcc dot gnu.org ---
*** Bug 68895 has been marked as a duplicate of this bug. ***

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |chrbr at gcc dot gnu.org

--- Comment #12 from chrbr at gcc dot gnu.org ---
Created attachment 37357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37357=edit
new arm_set_current_function implementation

A complete refactoring of arm_set_current_function. Much simpler. 

Also fixes pr68896 due to discrepancies between #pragma GCC target and
set_current_function global_options cl_target_option_restore restores.

Still want to play a little bit with it before sending it to the list.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2016-01-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #36 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jan 15 08:46:49 2016
New Revision: 232403

URL: https://gcc.gnu.org/viewcvs?rev=232403=gcc=rev
Log:
gcc
2015-01-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm-builtins.c (ARM_BUILTIN_CRYPTO_BASE): New enum tag.
(arm_init_neon_builtins_internal): Rename arm_init_neon_builtins,
(arm_init_crypto_builtins_internal): Rename arm_init_crypto_builtins.
use add_builtin_function_ext_scope instead of add_builtin_function.
(neon_set_p, neon_crypto_set_p): Remove.
(arm_init_builtins): Always call arm_init_neon_builtins and
arm_init_crypto_builtins.
(arm_expand_builtin): Check that builtins are allowed for the arch.
* config/arm/arm-protos.h (arm_init_neon_builtins): Remove prototype.
* config/arm/arm.c (arm_valid_target_attribute_tree): Remove
arm_init_neon_builtins call.

gcc/testsuite
2015-01-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* gcc.target/arm/attr-neon-builtin-fail2.c: New test.
* gcc.target/arm/lto/pr65837-attr_0.c: New test.
* gcc.target/arm/lto/pr65837_0.c: Fix skip condition and use ACLE name.


Added:
trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail2.c
trunk/gcc/testsuite/gcc.target/arm/lto/pr65837-attr_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #8 from chrbr at gcc dot gnu.org ---
Probably the same latent bug in the else part of the pragma_parse, for the case
where arm_valid_target_attribute_tree returns NULL.

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #7 from chrbr at gcc dot gnu.org ---
also it could be wrong to wait for arm_set_current_function when handling a
pragma GCC target because we could need the state in the global scope.

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #9 from chrbr at gcc dot gnu.org ---
Created attachment 37329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37329=edit
factorize restoration code

works for this case but fully untested

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #6 from chrbr at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
> The problem is we never end up setting TREE_TARGET_GLOBALS for fn2.
> From what I can gather that's TARGET_SET_CURRENT_FUNCTION's job (although
> the documentation for these things is scarce :( )
> 
> When we call arm_set_current_function for fn2 the old_tree is NULL because
> arm_pragma_target_parse will have reset arm_previous_fndecl when popping the
> target pragma.
> 
> new_tree will also be NULL because DECL_FUNCTION_SPECIFIC_TARGET for fndecl
> is only supposed to be set in the target attribute parsing code, but not the
> pragma parsing code (again, documentation here is scarce).
> 
> So we end up bypassing all the content in arm_set_current_function and not
> setting TREE_TARGET_GLOBALS which means the midend doesn't try to reset the
> optabs for fn2.
> 
> x86 gets away with this because ix86_reset_previous_fndecl besides clearing
> the previous fndecl cache also sets TREE_TARGET_GLOBALS for
> target_option_current_node.
> 
> rs6000 seems to never reset its previous fndecl (rs6000_previous_fndecl) so
> its version old_tree will always point to some tree (AFAICT).
> 
> Ugh. So for arm my thoughts are we should not exit early on the old_tree ==
> new_tree condition if both trees are NULL but rather follow the second arm
> of the if statement in arm_set_current_function where we set new_tree to
> target_option_current_code.
> 
> Hacking a prototype for that idea fixes the testcase for me.
> Christian, what do you think?

arm_reset_current_function assumes indeed that all the state switches are done,
so it would be more consistent to call restore_target_globals in
pragma_target_parse as well instead of splitting the work in 2 different
places. Maybe factorizing the common code from both ?

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37329|0   |1
is obsolete||

--- Comment #10 from chrbr at gcc dot gnu.org ---
Created attachment 37332
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37332=edit
factorize restoration code

[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

2016-01-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #37332|0   |1
is obsolete||

--- Comment #11 from chrbr at gcc dot gnu.org ---
Created attachment 37333
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37333=edit
factorize restoration code

better with the patch

[Bug target/69180] [ARM] #pragma GCC target should not warn about redefined macros

2016-01-12 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69180

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from chrbr at gcc dot gnu.org ---
fixed for gcc 6.0

[Bug target/69180] [ARM] #pragma GCC target should not warn about redefined macros

2016-01-12 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69180

--- Comment #1 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue Jan 12 15:01:12 2016
New Revision: 232276

URL: https://gcc.gnu.org/viewcvs?rev=232276=gcc=rev
Log:
PR target/69180
* config/arm/arm-c.c (arm_pragma_target_parse): Set NODE_CONDITIONAL
for __ARM_NEON_FP, __ARM_FP, _ARM_FEATURE_LDREX.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69180] New: [ARM] #pragma GCC target should not warn about redefined macros

2016-01-07 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69180

Bug ID: 69180
   Summary: [ARM] #pragma GCC target should not warn about
redefined macros
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

the line :
#pragma GCC target ("fpu=neon")

compiled with  -mfloat-abi=softfp -mfpu=neon-fp-armv8

warns with
warning: "__ARM_NEON_FP" redefined
: note: this is the location of the previous definition

breaking a few tests for compiler configured with neon-fp-armv8 as default

This warning should not be necessary as implicitly set, but should only occur
for explicit __ARM_NEON_FP user redefinition (e.g -D__ARM_NEON_FP=0)

the other macro having context sensitive values are __ARM_FP and
__ARM_FEATURE_LDREX

[Bug target/68895] [ARM] ICE with target attributes

2015-12-18 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68895

--- Comment #3 from chrbr at gcc dot gnu.org ---
Created attachment 37083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37083=edit
fix under validation

Initial patch to recompute DECL_MODE

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-18 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |chrbr at gcc dot gnu.org

--- Comment #14 from chrbr at gcc dot gnu.org ---
Created attachment 37085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37085=edit
new preliminary fix

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-18 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

--- Comment #13 from chrbr at gcc dot gnu.org ---
Created attachment 37084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37084=edit
preliminary fix

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-18 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

--- Comment #12 from chrbr at gcc dot gnu.org ---
(In reply to ktkachov from comment #8)
> (In reply to chrbr from comment #7)
> > I was suggesting in #68934 to make this code invalid and report an error.
> > Since SIMD types should not be used for declarations in NOSIMD context. But
> > I don't have a strong position about this. We might make this code work by
> > repairing the DECL_MODE depending on the usage context, but certainly less
> > practical than handle the error.
> > 
> > Other opinions ?
> > 
> > thanks
> 
> I agree about considering this code invalid.
> In the context where the variables are being declared there is no SIMD, so
> they don't really have a meaning. In the testcase if we wrap the
> declarations in a pargma like so:
> #pragma GCC push_options
> #pragma GCC target ("+simd")
> int8x8_t a, b;
> int16x8_t e;
> #pragma GCC pop_options
> 
> then we don't ICE.
> I suspect repairing DECL_MODE will be a messy affair. So unless you see a
> clean/safe way of doing this I'd propose just somehow detecting this error
> and throwing an error instead of an ICE.

I changed my mind :-) :

- The surrounding of global declaration by the #pragma is too heavy to be used.
The compiler is able to derive the type from the attribute target when using
it.

- The compiler already handle this partially:
 see the comment in stor-layout:
   /* Vector types need to re-check the target flags each time we report
   the machine mode.  We need to do this because attribute target can
   change the result of vector_mode_supported_p and have_regs_of_mode
   on a per-function basis.  Thus the TYPE_MODE of a VECTOR_TYPE can
   change on a per-function basis.  */

I'm testing a central fix in expand_expr. Will need to check on the other
targets but it fixes the case it for arm and aarch64.

patch attached for first feedback and early review.

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-17 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from chrbr at gcc dot gnu.org ---
OK invalid then.

For handling the error, see also Bug #68934 - [ARM] using simd types should be
rejected if not fpu=neon

I'll check the existing tests that use simd types in appropriate contexts (e.g
attr-neon3.c with local declarations).

[Bug target/68895] [ARM] ICE with target attributes

2015-12-17 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68895

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #2 from chrbr at gcc dot gnu.org ---
int8x8_t local decl should not be allowed in non-simd mode.

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-17 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |diagnostic,
   ||ice-on-invalid-code

--- Comment #11 from chrbr at gcc dot gnu.org ---
indeed, mine

[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon

2015-12-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

--- Comment #3 from chrbr at gcc dot gnu.org ---

> Real code does not scope simd type definitions tightly enough to make this
> feasible even if it were desirable.

there was an instance of this in Bug #68895. The second function ices while
using int8x8_t types while in vfp mode. So we should probably decide if the
code is legitimate or not (and close as invalid). And if it is how the RTL can
this bi-morphism.

The only solution I had in mind was to play with registered_builtin_types in
the lang hooks, but I agree it is not practical.

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Target|arm |arm,aarch64
   Assignee|chrbr at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
Summary|ARM attribute target neon   |ARM/AARCH64 attribute
   |internal compiler error: in |target neon internal
   |copy_to_mode_reg, at|compiler error: in
   |explow.c:595|copy_to_mode_reg, at
   ||explow.c:595

--- Comment #6 from chrbr at gcc dot gnu.org ---
This test also ICEs for aarch64 the same way

-
#include 

int8x8_t a, b;
int16x8_t e;

void
__attribute__ ((target("+simd")))
foo(void)
{
  e = (int16x8_t) vaddl_s8(a, b);
}
-
internal compiler error: in copy_to_mode_reg, at explow.c:595
   return (int16x8_t) __builtin_aarch64_saddlv8qi (__a, __b);

called with:

cc1 -quiet pr68674.c  -mcpu=cortex-a53+nosimd -O2

The reason is that DECL_MODE is been initialized to a scalar during layout_decl
since TARGET_SIMD is not set during the global initialization.

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

2015-12-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Blocks|65837   |

--- Comment #7 from chrbr at gcc dot gnu.org ---
I was suggesting in #68934 to make this code invalid and report an error. Since
SIMD types should not be used for declarations in NOSIMD context. But I don't
have a strong position about this. We might make this code work by repairing
the DECL_MODE depending on the usage context, but certainly less practical than
handle the error.

Other opinions ?

thanks


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
[Bug 65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[Bug target/68934] New: ARM using simd types should be rejected if not fpu=neon

2015-12-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

Bug ID: 68934
   Summary: ARM using simd types should be rejected if not
fpu=neon
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

the declaration:

--
#pragma GCC target ("fpu=vfp")

__simd64_int8_t b;
--

legitimately fails with

error: unknown type name '__simd64_int8_t'

However, if the type was previously created as (for instance) with


#pragma GCC target ("fpu=neon")

__simd64_int8_t a;

#pragma GCC target ("fpu=vfp")

__simd64_int8_t b;
-

then it compiles, but this is wrong for 2 reasons:

1) it's not consistent (the user doesn't know if neon types are available or
not)
2) nothing prevents "b" to be latter used in a code compiled for NEON, creating
discrepancies between modes and possible wrong code (or ICEs)

A mechanism to deactivate SIMD types in arm_set_current_function is needed.

[Bug target/68934] [ARM] using simd types should be rejected if not fpu=neon

2015-12-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68934

--- Comment #1 from chrbr at gcc dot gnu.org ---
run with cc1 -mfloat-abi=hard for a compiler configured with defaults

[Bug target/68896] [ARM] target attribute ignored

2015-12-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68896

--- Comment #2 from chrbr at gcc dot gnu.org ---
Currently not a bug, or rather implementation specified.

According to the documentation

6.61.15 Function Specific Option Pragmas

#pragma GCC target ("string"...)
...
Each function that is defined after this point is as if
attribute((target("STRING"))) was specified for that function

So here we have 

#pragma GCC target ("fpu=vfp")
...
int8x8_t __attribute__ ((target("fpu=neon"))) my

so "my" is defined as if attribute((target("fpu=vfp"))) was specified.

Now, IMHO this is not intuitive since the attribute targets has a smaller
scope, it should have a higher priority. And the doc doesn't say if the
attribute target is inserted before or after the existing ones, in case of
conflict.
so literally not a bug, but I'd like to specify the order of insertion to solve
your current issue.

[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function

2015-12-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

--- Comment #5 from chrbr at gcc dot gnu.org ---
Created attachment 37041
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37041=edit
testcase without arm_neon parts

more concise to avoid mixing the arm_neon intrinsincs

[Bug target/68895] [ARM] ICE with target attributes

2015-12-14 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68895

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
This is related to the discussion we had recently with Kyril whereas we noticed
that simd types can be used with different TARGET_VECTOR_MODE_SUPPORTED_P  due
to the TARGET_NEON dependencies. Note that the discrepancy happens here for
parms but this is also complicated for global decl for which
set_current_function doesn't switch.
looking at it

[Bug target/68896] [ARM] target attribute ignored

2015-12-14 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68896

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-14
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
confirmed. 
ok without -mfpu=neon on the command line, although the #pragma should prevail

[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function

2015-12-09 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

--- Comment #3 from chrbr at gcc dot gnu.org ---
ah yes, try without the "-mfpu=neon". 

arm-none-eabi-gcc -mcpu=cortex-a9 -mfloat-abi=hard  t.c  -S -O2

[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function

2015-12-03 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Blocks||65837
   Assignee|unassigned at gcc dot gnu.org  |chrbr at gcc dot gnu.org

--- Comment #1 from chrbr at gcc dot gnu.org ---
Found this when fixing target/65837:

builtins should have a global scope. but this unmask a few other failures,
mostly with the hooks TARGET_VECTORIZE_PREFERRED_SIMD_MODE that return wrongs
values for global variables.

The problem is that TARGET_NEON is false for global scopes decls, although the
types were known.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
[Bug 65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[Bug target/68674] New: ARM attribute target neon warning: incompatible implicit declaration of built-in function

2015-12-03 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674

Bug ID: 68674
   Summary: ARM attribute target neon warning: incompatible
implicit declaration of built-in function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

this test compiled with

cc1   -O2 test.c  -mcpu=cortex-a9 -mfloat-abi=hard -quiet -mfpu=neon

#include "arm_neon.h"

int8x8_t a, b;
int16x8_t e;

void
__attribute__ ((target("fpu=neon")))
foo(void)
{
  e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
}

ICEs with 

test.c:10:18: warning: incompatible implicit declaration of built-in function
'__builtin_neon_vaddlsv8qi'
   e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
  ^

test.c:10:7: internal compiler error: in copy_to_mode_reg, at explow.c:595
   e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
   ^~~

[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c

2015-12-03 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2015-12-3
 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
confirmed. the following ICE with default configure options

arm-none-eabi-gcc  -mfp16-format=ieee -mbig-endian -mfpu=neon-fp16
-mfloat-abi=hard ~/neon-fp16-fail.c

#include "arm_neon.h"

float16x4_t 
foo (float32x4_t arg)
{
return vcvt_f16_f32 (arg);
}

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

2015-12-01 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617

--- Comment #3 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue Dec  1 14:50:57 2015
New Revision: 231114

URL: https://gcc.gnu.org/viewcvs?rev=231114=gcc=rev
Log:
2015-12-01  Christian Bruel  <christian.br...@st.com>

PR target/68617
* config/arm/arm.opt (unaligned_access): Save.
* config/arm/arm-c.c (__ARM_FEATURE_UNALIGNED): Conditionally define.
* config/arm/arm.c (arm_option_override): Move unaligned_access setting
(arm_option_override_internal): ... here.
* config/arm/arm.h (TARGET_32BIT_P): New macro.

// testsuite
PR target/68617
* gcc.target/arm/attr-unaligned-load-ice.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/arm.opt
trunk/gcc/testsuite/ChangeLog

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

2015-12-01 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from chrbr at gcc dot gnu.org ---
fixed

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

2015-11-30 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617

--- Comment #2 from chrbr at gcc dot gnu.org ---
unaligned_access flag now depend on TARGET_32BIT, which is sensitive to the
attribute target.
Should be made Save in arm.opt and handled in override_options_internal. But
this is still not enough to make the test pass.

[Bug target/68617] New: arm ice output_operand: invalid %-code for -march=armv6k + thumb

2015-11-30 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617

Bug ID: 68617
   Summary: arm ice output_operand: invalid %-code for
-march=armv6k + thumb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb

2015-11-30 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617

--- Comment #1 from chrbr at gcc dot gnu.org ---
Created attachment 36872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36872=edit
reproduce

compiled with arm-none-eabi-gcc -Os -S -mfloat-abi=softfp 
attr-unaligned-load-ice.c -mtp=soft -march=armv6 

attr-unaligned-load-ice.c: In function 'foo':
attr-unaligned-load-ice.c:19:1: internal compiler error: output_operand:
invalid %-code
 }

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

2015-11-26 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #7 from chrbr at gcc dot gnu.org ---
fixed @r230871 with:

r230871 | jason | 2015-11-25 15:35:24 +0100 (Wed, 25 Nov 2015) | 6 lines

PR c++/68385

* tree.c (integer_zerop, integer_onep, integer_each_onep)
(integer_all_onesp, integer_minus_onep, integer_pow2p)
(integer_nonzerop, integer_truep, tree_log2, tree_floor_log2)
(real_zerop, real_onep, real_minus_onep): Remove STRIP_NOPS.

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

2015-11-26 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #8 from chrbr at gcc dot gnu.org ---


*** This bug has been marked as a duplicate of bug 68385 ***

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

2015-11-26 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68385

--- Comment #5 from chrbr at gcc dot gnu.org ---
*** Bug 68368 has been marked as a duplicate of this bug. ***

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

2015-11-17 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-11-17
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #3 from chrbr at gcc dot gnu.org ---
reopened with reduced case.

[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123

2015-11-17 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
Created attachment 36731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36731=edit
reduced case

still fails at rev 230435

just call with 
cc1plus testcase-min.ii

internal compiler error: tree check: expected integer_cst, have nop_expr in
decompose, at tree.h:5123
  13))
^

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #35 from chrbr at gcc dot gnu.org ---
Specific NEON case fixed with the attribute/pragma target support for fpu=

attribute support can now be extended for other target flags that need to be
propagated to LTO (-mcpu=, -mtune=, -munaligned-access...)

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #31 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Nov 16 08:46:42 2015
New Revision: 230404

URL: https://gcc.gnu.org/viewcvs?rev=230404=gcc=rev
Log:
2015-11-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm.c (arm_fpu_desc): Remove.
(all_fpus): Make global.
(arm_option_override): Use FPU TARGET accessors.
(arm_declare_function_name): Likewise.
* config/arm/arm.h (TARGET_VFP, TARGET_VFPD32, TARGET_VFP5)
(TARGET_VFP_SINGLE, TARGET_VFP_DOUBLE, TARGET_NEON_FP16)
(TARGET_FP16, TARGET_FMA, TARGET_FPU_ARMV8, TARGET_CRYPTO)
(TARGET_NEON): Likewise.
(all_fpus): Declare extern.
(TARGET_FPU_NAME, TARGET_FPU_MODEL, TARGET_FPU_REV)
(TARGET_FPU_REGS, TARGET_FPU_FEATURES): Define all_fpus accessors.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #32 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Nov 16 09:00:09 2015
New Revision: 230406

URL: https://gcc.gnu.org/viewcvs?rev=230406=gcc=rev
Log:
2015-11-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm-protos.h (arm_init_neon_builtins): Declare.
* config/arm/arm.c (arm_valid_target_attribute_tree): Call
arm_init_neon_builtins.
* config/arm/arm-builtins.c (arm_init_neon_builtins): Split into...
(arm_init_neon_builtins_internal)
(arm_init_crypto_builtins_internal):
Test and set neon_set_p, neon_crypto_set_p.
(neon_set_p, neon_crypto_set_p): New static booleans.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #33 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Nov 16 10:21:09 2015
New Revision: 230408

URL: https://gcc.gnu.org/viewcvs?rev=230408=gcc=rev
Log:
2015-11-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm-c.c (arm_cpu_builtins): Set or reset
__ARM_FEATURE_CRYPTO, __VFP_FP__, __ARM_NEON__
(arm_pragma_target_parse): Change check for arm_cpu_builtins.
undefine __ARM_FP.
* config/arm/arm.c (arm_can_inline_p): Check FPUs.
(arm_valid_target_attribute_rec): Handle -mfpu attribute target.
* doc/invoke.texi (-mfpu=): Mention attribute and pragma.
* doc/extend.texi (-mfpu=): Describe attribute.

2015-11-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
gcc.target/arm/lto/pr65837_0.c
gcc.target/arm/attr-neon2.c
gcc.target/arm/attr-neon.c
gcc.target/arm/attr-neon-builtin-fail.c
gcc.target/arm/attr-crypto.c


Added:
trunk/gcc/testsuite/gcc.target/arm/attr-crypto.c
trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c
trunk/gcc/testsuite/gcc.target/arm/attr-neon.c
trunk/gcc/testsuite/gcc.target/arm/attr-neon2.c
trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm.c
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #34 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Nov 16 11:20:02 2015
New Revision: 230410

URL: https://gcc.gnu.org/viewcvs?rev=230410=gcc=rev
Log:
2015-11-16  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm-c.c (arm_cpu_builtins): Conditionally set and reset
__ARM_FEATURE_FMA and __ARM_NEON_FP, __ARM_FP.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-11-13 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

--- Comment #30 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Nov 13 15:19:19 2015
New Revision: 230327

URL: https://gcc.gnu.org/viewcvs?rev=230327=gcc=rev
Log:
2015-11-13  Christian Bruel  <christian.br...@st.com>

PR target/65837
* config/arm/arm.c (arm_option_override): Move NEON check...
(arm_option_check_internal): here
(arm_file_start): Move .fpu print...
(arm_declare_function_name): here
(arm_option_print): Dump current fpu name.
* config/arm/arm.opt (arm_fpu_index): Mark Save.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.opt

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-10-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

--- Comment #6 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Oct 16 13:37:14 2015
New Revision: 228904

URL: https://gcc.gnu.org/viewcvs?rev=228904=gcc=rev
Log:
2015-10-16  Christian Bruel  <christian.br...@st.com>

PR target/67745
* config/arm/arm.h (FUNCTION_BOUNDARY): Move optimize_size condition
to:
* config/arm/arm.c (arm_option_override_internal): Call
arm_override_options_after_change_1.
(arm_override_options_after_change): New function.
(arm_override_options_after_change_1): Likewise.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): Define hook.


Added:
trunk/gcc/testsuite/gcc.target/arm/attr-align1.c
trunk/gcc/testsuite/gcc.target/arm/attr-align2.c
trunk/gcc/testsuite/gcc.target/arm/attr-align3.c
trunk/gcc/testsuite/gcc.target/arm/no-align.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/testsuite/ChangeLog

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-10-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

--- Comment #7 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Oct 16 13:52:51 2015
New Revision: 228912

URL: https://gcc.gnu.org/viewcvs?rev=228912=gcc=rev
Log:
2015-10-16  Christian Bruel  <christian.br...@st.com>

PR target/67745
* config/arm/arm.h (FUNCTION_BOUNDARY): Use FUNCTION_BOUNDARY_P.
(FUNCTION_BOUNDARY_P): New macro:
* config/arm/arm.c (TARGET_RELAYOUT_FUNCTION, arm_relayout_function): 
New hook.
* doc/tm.texi.in (TARGET_RELAYOUT_FUNCTION): Document.
* doc/tm.texi (TARGET_RELAYOUT_FUNCTION): New hook.
* gcc/target.def (TARGET_RELAYOUT_FUNCTION): Likewise.
* gcc/function.c (allocate_struct_function): Call relayout_function
hook.
* gcc/passes.c (rest_of_decl_compilation): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/function.c
trunk/gcc/passes.c
trunk/gcc/target.def

[Bug target/67880] [ARM] -fno-align-functions does not work for thumb

2015-10-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67880
Bug 67880 depends on bug 67745, which changed state.

Bug 67745 Summary: [ARM] wrong alignments when __attribute__ 
((optimize,target,align) is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-10-16 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from chrbr at gcc dot gnu.org ---
fixed at rev 228912

[Bug target/67880] New: [ARM] -fno-align-functions does not work for thumb

2015-10-07 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67880

Bug ID: 67880
   Summary: [ARM] -fno-align-functions does not work for thumb
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

void foo()
{
}

compiled with -O2 -mthumb -mno-align-functions

.text
.align  2
.global foo
.syntax unified
.code   16
.thumb_func

is aligned on 4 bytes instead of default required 2 bytes

[Bug target/67880] [ARM] -fno-align-functions does not work for thumb

2015-10-07 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67880

--- Comment #1 from chrbr at gcc dot gnu.org ---
optimize flags should not be part of the alignment ABI. 

fixed with https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02198.html

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-09-29 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
   Target Milestone|--- |6.0

[Bug target/67745] New: [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-09-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

Bug ID: 67745
   Summary: [ARM] wrong alignments when __attribute__
((optimize,target,align) is used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

alignment directives emitted by the compiler are inconsistent for ARM when
attributes target are used.

for instance this code compiled with -Os -mthumb, 

void  __attribute__ ((target ("arm")))
c(void)
{
}

emits

.text
.align  1
.global c
.syntax divided
.arm
.type   c, %function

it should have the function 'c' aligned on 2^2 bytes, not 2^1

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-09-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

--- Comment #1 from chrbr at gcc dot gnu.org ---
the problems are three folds:

- FUNCTION_BOUNDARY should not test optimize_size, that should be tested in
override_options_internal instead to be carried by
invoke_set_current_function_hook 

- FUNCTION_BOUNDARY depends on TARGET_THUMB that depends on the attribute
target. So it should be reevaluated at each function change, thus 
TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-09-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

--- Comment #2 from chrbr at gcc dot gnu.org ---
and test check optimize_function_for_speed_p (cfun)) in assemble_start_function
put an unnecessary constraint on align_functions (either from -falign-functions
or __attribute__).
We should be able to decrease alignment between functions for a target switch
in -Os, for example.

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

2015-09-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67745

--- Comment #3 from chrbr at gcc dot gnu.org ---
another example that gives suboptimal alignment:

void
__attribute__ ((optimize("Os")))
foo()
{
}

compiled with -O2 -mthumb is aligned on 2^2 instead of 2^1. -Os should remove
padding here.

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-09-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #11 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue Sep 15 13:43:17 2015
New Revision: 227795

URL: https://gcc.gnu.org/viewcvs?rev=227795=gcc=rev
Log:
2015-09-15  Christian Bruel  <christian.br...@st.com>

PR target/52144
* config/arm/arm.c (arm_option_params_internal): Remove opts parameter.
* config/arm/arm-c.c (arm_cpu_builtins): Declare static.
Remove flags parameter.
* config/arm/arm.h (TARGET_32BIT_P, TARGET_ARM_QBIT_P)
(TARGET_ARM_SAT_P, TARGET_IDIV_P, TARGET_HAVE_LDREX_P)
(TARGET_HAVE_LDREXBH_P, TARGET_HAVE_LDREXD_P, TARGET_DSP_MULTIPLY_P)
(TARGET_ARM_FEATURE_LDREX_P, TARGET_INT_SIMD_P): Redefine macros
with...
(TARGET_ARM_SAT, TARGET_IDIV, TARGET_HAVE_LDREX)
(TARGET_HAVE_LDREXBH, TARGET_HAVE_LDREXD, TARGET_ARM_FEATURE_LDREX)
(TARGET_DSP_MULTIPLY, TARGET_INT_SIMD): Redefined macros.
* gcc/config/arm/arm-protos.h (arm_cpu_builtins): Remove declaration.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-07-07 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #10 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue Jul  7 07:56:10 2015
New Revision: 225503

URL: https://gcc.gnu.org/viewcvs?rev=225503root=gccview=rev
Log:
Cleanup arch file directive.

PR target/52144
* config/arm/elf.h (TARGET_ASM_FILE_START_APP_OFF): Delete.

PR target/52144
* gcc.target/arm/flip-thumb.c: Fix scan.
* gcc.target/arm/attr_thumb.c: Test for all targets. Fix scan.
* gcc.target/arm/attr_arm.c: Test for all targets. Fix scan.
* gcc.target/arm/attr_thumb-static.c: Test for all targets.
Fix return value.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/elf.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/attr_arm.c
trunk/gcc/testsuite/gcc.target/arm/attr_thumb-static.c
trunk/gcc/testsuite/gcc.target/arm/attr_thumb.c
trunk/gcc/testsuite/gcc.target/arm/flip-thumb.c

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #8 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Jun 22 07:32:15 2015
New Revision: 224721

URL: https://gcc.gnu.org/viewcvs?rev=224721root=gccview=rev
Log:
Add -mflip-thumb for testing.

PR target/52144n
* config/arm/arm.c (add_attribute, arm_insert_attributes): New functions
(TARGET_INSERT_ATTRIBUTES): Define.
(thumb_flipper): New var.
* config/arm/arm.opt (-mflip-thumb): New switch.

PR target/52144
* gcc.target/arm/flip-thumb.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/flip-thumb.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.opt
trunk/gcc/testsuite/ChangeLog

[Bug lto/45729] -flto conflicts with -mthumb

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org
 Depends on||52144

--- Comment #4 from chrbr at gcc dot gnu.org ---
need to add __attribute__((noinline)) for f(void) to make sure it is compiled
in arm mode, otherwise it takes the mode of the caller


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
[Bug 52144] ARM should support arm/thumb function attribute to permit different
instruction sets in the same source

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from chrbr at gcc dot gnu.org ---
attribute ((thumb,arm)) should be fine for 6.0.0 r224722

[Bug target/59884] Unexpected warning pragma GCC target

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
Bug 59884 depends on bug 52144, which changed state.

Bug 52144 Summary: ARM should support arm/thumb function attribute to permit 
different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug lto/45729] -flto conflicts with -mthumb

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729
Bug 45729 depends on bug 52144, which changed state.

Bug 52144 Summary: ARM should support arm/thumb function attribute to permit 
different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-06-22 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
Bug 65837 depends on bug 52144, which changed state.

Bug 52144 Summary: ARM should support arm/thumb function attribute to permit 
different instruction sets in the same source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/66541] [5/6 Regression] r224314 causes ICE in gcc.dg/torture/pr52429.c

2015-06-19 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66541

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from chrbr at gcc dot gnu.org ---
fixed failing test with arm-cortex-linux-gnueabi. no regs

note I have the feeling that target_reinit is not always called at it should on
 execution paths when switching mode to default. However I was not able to
forge a case. IMHO this function will need rethinking when implementing fpu
target attributes

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-06-19 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #7 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jun 19 06:58:22 2015
New Revision: 224638

URL: https://gcc.gnu.org/viewcvs?rev=224638root=gccview=rev
Log:
PR target/66541
PR target/52144
* config/arm/arm.c (arm_set_current_function): Handle
explicit default options.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/66541] [5/6 Regression] r224314 causes ICE in gcc.dg/torture/pr52429.c

2015-06-19 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66541

--- Comment #2 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jun 19 06:58:22 2015
New Revision: 224638

URL: https://gcc.gnu.org/viewcvs?rev=224638root=gccview=rev
Log:
PR target/66541
PR target/52144
* config/arm/arm.c (arm_set_current_function): Handle
explicit default options.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c

[Bug target/66541] r224314 causes ICE in gcc.dg/torture/pr52429.c

2015-06-15 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66541

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-15
 CC||chrbr at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
Confirmed.

since r217659. DECL_FUNCTION_SPECIFIC_TARGET is set with
target_option_default_node.

Needs catch up with i386 ix86_set_current_function changes.

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-06-11 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #6 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Thu Jun 11 08:51:17 2015
New Revision: 224365

URL: https://gcc.gnu.org/viewcvs?rev=224365root=gccview=rev
Log:
Add ARM/thumb pragma target 

PR target/52144
* config/arm/arm-c.c (arm_cpu_cpp_builtins): Conditionally define
 macros in ...
(arm_cpu_builtins): New function.
(arm_pragma_target_parse): Call arm_cpu_builtins.
* config/arm/arm-protos.h (arm_cpu_builtins): Declare.
(arm_register_target_pragmas): Likewise.
* config/arm/arm.h (REGISTER_TARGET_PRAGMAS):
 Call arm_register_target_pragmas.
* config/arm/arm-c.c (arm_register_target_pragmas): New function.
(arm_pragma_target_parse): Likewise.

PR target/52144
* gcc.target/arm/pragma_attribute.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/pragma_attribute.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.h
trunk/gcc/testsuite/ChangeLog

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-06-10 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #5 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed Jun 10 07:50:59 2015
New Revision: 224314

URL: https://gcc.gnu.org/viewcvs?rev=224314root=gccview=rev
Log:
Add ARM/thumb attribute target

PR target/52144

* config/arm/arm.opt (THUMB, arm_restrict_it, inline_asm_unified):
Save.
* config/arm/arm-protos.h (arm_valid_target_attribute_tree): Declare.
(arm_reset_previous_fndecl, arm_change_mode_p): Likewise.
* config/arm/arm.h (SWITCHABLE_TARGET): Define.
* config/arm/arm.c (arm_reset_previous_fndecl): New functions.
(arm_valid_target_attribute_tree, arm_change_mode_p): Likewise.
(arm_valid_target_attribute_p): Likewise.
(arm_set_current_function, arm_can_inline_p): Likewise.
(arm_valid_target_attribute_rec): Likewise.
(arm_previous_fndecl): New variable.
(TARGET_SET_CURRENT_FUNCTION, TARGET_OPTION_VALID_ATTRIBUTE_P): Define.
(TARGET_CAN_INLINE_P): Define.
(arm_asm_trampoline_template): Emit mode.
(arm_file_start): Don't set unified syntax.
(arm_declare_function_name): Set unified syntax and mode.
(arm_option_override): Init target_option_default_node.
and target_option_current_node.
* config/arm/arm.md (*call_value_symbol): Set mode when possible.
(*call_symbol): Likewise.
* doc/extend.texi: Document ARM/Thumb target attribute.
* doc/invoke.texi: Likewise.

* gcc.target/arm/attr_arm.c: New test
* gcc.target/arm/attr_arm-err.c: New test
* gcc.target/arm/attr_thumb.c: New test
* gcc.target/arm/attr_thumb-static.c: New test


Added:
trunk/gcc/testsuite/gcc.target/arm/attr_arm-err.c
trunk/gcc/testsuite/gcc.target/arm/attr_arm.c
trunk/gcc/testsuite/gcc.target/arm/attr_thumb-static.c
trunk/gcc/testsuite/gcc.target/arm/attr_thumb.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h
trunk/gcc/config/arm/arm.md
trunk/gcc/config/arm/arm.opt
trunk/gcc/doc/extend.texi
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-05-26 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

--- Comment #4 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue May 26 14:06:17 2015
New Revision: 223699

URL: https://gcc.gnu.org/viewcvs?rev=223699root=gccview=rev
Log:
 2015-05-13  Christian Bruel  christian.br...@st.com

PR target/52144
* config/arm/arm.c (arm_option_check_internal)
(arm_option_params_internal): Check opts-target_flags to set macros.
(TREE_TARGET_ARM, TREE_TARGET_THUMB)
(TREE_TARGET_THUMB1, TREE_TARGET_THUMB2) Replace with...
(TARGET_ARM_P, TARGET_THUMB_P, TARGET_THUMB1_P, TARGET_THUMB2_P)
(builtin_define): Replaced with def_or_undef_macro.
* config/arm/arm.h (TREE_TARGET_ARM, TREE_TARGET_THUMB)
TREE_TARGET_THUMB1, TREE_TARGET_THUMB2) Redefine with...
(TARGET_ARM_P, TARGET_THUMB_P, TARGET_THUMB1_P, TARGET_THUMB2_P)
(TARGET_32BIT_P, TARGET_ARM_QBIT_P, TARGET_ARM_SAT_P, TARGET_IDIV_P)
(TARGET_HAVE_LDREX_P, TARGET_HAVE_LDREXBH_P, TARGET_HAVE_LDREXD_P)
(TARGET_ARM_FEATURE_LDREX_P)
(TARGET_DSP_MULTIPLY_P, TARGET_INT_SIMD_P): New macros.
(def_or_undef_macro): New function.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h

[Bug target/65283] [SH] lds fpscr not put in delay slot

2015-05-21 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65283

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #2 from chrbr at gcc dot gnu.org ---
this is a conservative limitation to avoid a ds schedule problem. 

this is because
(define_attr in_delay_slot yes,no
 (eq_attr type fpscr_toggle) (const_string no)

an old analysis (for reference) and regression test:
https://gcc.gnu.org/ml/gcc-patches/2007-01/msg00746.html

[Bug target/65283] [SH] lds fpscr not put in delay slot

2015-05-21 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65283

--- Comment #4 from chrbr at gcc dot gnu.org ---
yes it's only for the SH4A fpchg case

[Bug target/65283] [SH] lds fpscr not put in delay slot

2015-05-21 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65283

--- Comment #5 from chrbr at gcc dot gnu.org ---
ah I see, I was on the 4.8 where toggle_pr was indeed a single pattern.

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-05-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||chrbr at gcc dot gnu.org

--- Comment #3 from chrbr at gcc dot gnu.org ---
patch set posted :

(2.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01185.html
(2.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01198.html
(4/6)   https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01537.html
(5.1/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01539.html
(5.2/6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01558.html
(6  /6) https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01542.html

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-05-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Depends on||52144

--- Comment #29 from chrbr at gcc dot gnu.org ---
Extend the attribute_target thumb/arm support to -mfpu isas


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
[Bug 52144] ARM should support arm/thumb function attribute to permit different
instruction sets in the same source

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

2015-05-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Blocks||59884
 CC||joey.ye at arm dot com

--- Comment #2 from chrbr at gcc dot gnu.org ---
*** Bug 59884 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884
[Bug 59884] Unexpected warning pragma GCC target

[Bug target/59884] Unexpected warning pragma GCC target

2015-05-20 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||chrbr at gcc dot gnu.org
 Depends on||52144
 Resolution|--- |DUPLICATE

--- Comment #4 from chrbr at gcc dot gnu.org ---
#pragma GCC target relies on the target_attribute work

*** This bug has been marked as a duplicate of bug 52144 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
[Bug 52144] ARM should support arm/thumb function attribute to permit different
instruction sets in the same source

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

2015-05-19 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #27 from chrbr at gcc dot gnu.org ---

 
 Should be reproducible without LTO with
 
 int __attribute__((target(fpu=neon))) main() 
 {
 ...
 }
 
 and compiling without -mfpu=neon.
 

note that #include arm_neon.h can't be preprocessed and that the builtins are
not recognized without a global flag:

arm_neon.h:31:2: error: #error You must enable NEON instructions (e.g.
-mfloat-abi=softfp -mfpu=neon) to use arm_neon.h

A further improvement for that might be to set the attribute for all the
functions defines in  neon.h and remove the #error check.

e.g:

__extension__ static __inline float32x2_t 
__attribute__ ((__always_inline__))
__attribute__((target(fpu=neon)))
vadd_f32 (float32x2_t __a, float32x2_t __b)
{
  return (float32x2_t) __builtin_neon_vaddv2sf (__a, __b);
}

or use a #pragma target ((mfpu=neon)) region.

[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))

2015-05-18 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Target|aarch64, alpha  |aarch64, alpha,ia64

--- Comment #6 from chrbr at gcc dot gnu.org ---
yes, although the patch still not approved/applied for ia64.

https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00312.html

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

2015-05-07 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018

--- Comment #3 from chrbr at gcc dot gnu.org ---
having ld in the $(prefix)/$(triplet)/bin fixes the issue.

it seems that collect2 doesn't look for $(prefix)/bin/$(triplet)-ld as before

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

2015-05-06 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||chrbr at gcc dot gnu.org

--- Comment #1 from chrbr at gcc dot gnu.org ---
same error building arm-none-eabi multilibs

checking for library containing opendir... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[3]: *** [configure-target-libstdc++-v3] Error 1

[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))

2015-05-06 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

--- Comment #2 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed May  6 11:19:56 2015
New Revision: 222848

URL: https://gcc.gnu.org/viewcvs?rev=222848root=gccview=rev
Log:
2015-05-06  Christian Bruel  christian.br...@st.com

PR target/66015
* config/aarch64/aarch64.c (aarch64_override_options): Move
align_loops,
align_jumps, align_functions into
aarch64_override_options_after_change.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/iinline-attr-1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ (O2)))

2015-05-06 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

--- Comment #1 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed May  6 10:54:40 2015
New Revision: 222847

URL: https://gcc.gnu.org/viewcvs?rev=222847root=gccview=rev
Log:
2015-05-06  Christian Bruel  christian.br...@st.com

PR target/66015
* config/aarch64/aarch64.c (aarch64_override_options): Move
align_loops,
align_jumps, align_functions into
aarch64_override_options_after_change.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/iinline-attr-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug target/66015] New: align directives not propagated after __attribute__ ((__optimize__ (O2)))

2015-05-05 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

Bug ID: 66015
   Summary: align directives not propagated after __attribute__
((__optimize__ (O2)))
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

When attribute optimize is used, the alignment flags are not reevaluated.

Consequently, the functions are not aligned as if they were with the same
global flag

for example:
__attribute__ ((__optimize__ (O2)))
void
hooray ()
{
}

is not aligned 

The second consequence is that can_inline_edge_p fails because opts_for_fn
(caller-decl) != opts_for_fn (callee-decl)) even-though they are compiled
with the same optimization level.

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

2015-05-04 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835

--- Comment #7 from chrbr at gcc dot gnu.org ---

aarch64: Seems to exhibit the same problem than x86:
override_options_after_change doesn't restore the align flags. 

ia64: will check, chances that this exhibits the same latent bug.

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

2015-04-30 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835

--- Comment #5 from chrbr at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #1)
 The problem is that in the testcase iinline-1.c as it is in the
 testsuite, we use -fno-ipa-cp on the command line so that the
 interprocedural phase of IPA-CP is not run so that it does not
 interfere with the interprocedural stage of inlining, which however
 uses information gathered by the function body analysis of ipa-prop
 (which is invoked by both IPA-CP and inlining).  However, when we
 inspect the function specific optimizations in ipa-prop at this stage,
 we bail out if we see -fno-ipa-cp.
 
 So yes, there is a clear inconsistency, but at the same time, having
 the ability to switch off only the interprocedural part of IPA-CP is
 extremely convenient for testing how the inliner uses jump functions
 and other stuff gathered by ipa-prop.  I'll try to come up with some
 fix.

Hi Martin,

back to fixing this problem, after the initial set of patch I think the
function

static bool
ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node *node)
{
  tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node-decl);

  if (!fs_opts)
return false;
  return !opt_for_fn (node-decl, optimize) || !opt_for_fn (node-decl, 
flag_ipa_cp);
}

should always return false, and have a coherent analysis between global
optimizations and function specific optimizations, now that the ipa-inline
checks are fixed.

so testing this. seems to fix the testcase at first sight.

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

2015-04-30 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835

--- Comment #4 from chrbr at gcc dot gnu.org ---
yes, I thought that this test was target independent. tested on x86, arm, sh4.

I'll checking what happens with aarch64

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

2015-04-29 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835

--- Comment #2 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Wed Apr 29 06:52:23 2015
New Revision: 222559

URL: https://gcc.gnu.org/viewcvs?rev=222559root=gccview=rev
Log:
2015-04-29  Christian Bruel  christian.br...@st.com

PR target/64835
* config/i386/i386.c (ix86_default_align): New function.
(ix86_override_options_after_change): Call ix86_default_align.
(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New hook.
(ix86_override_options_after_change): New function.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/iinline-attr.c
trunk/gcc/testsuite/gcc.target/i386/iinline-attr-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/64835] New: -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

2015-01-28 Thread chrbr at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835

Bug ID: 64835
   Summary: -fno-ipa-cp is inconsitently supported when attributes
optimize or target are used
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org

Created attachment 34606
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34606action=edit
testcase

When using the target attributes on ARM, all ipa/inline tests that use
-fno-ipa-cp fails. Althought the target attribute should have no impact on
-fno-ipa-cp.

This is a more general issue with the DECL_FUNCTION_SPECIFIC_OPTIMIZATION macro
test which is used both for the target attributes and the optimize attributes. 

This can be observed with the attached test on i386. Compiled with -O3
-fno-early-inlining -fno-ipa-cp

indeed
ipa_proc.c::ipa_func_spec_opts_forbid_analysis_p as a explicit test for
-fno-ipa-pc, and none is checked for the global optimisation level.

-
   tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node-decl);

   if (!fs_opts)
 return false;
   return !opt_for_fn (node-decl, optimize) || !opt_for_fn (node-decl,
flag_ipa_cp);
-

it seems that to be consistent, we shoud apply the same test if no
specific_optimiaation. something linke:

   if (!fs_opts)
-return false;
+return !optimize || !flag_ipa_cp;

however then a few tests are failing . e.g iinline-1.c. because they force
-fno-ipa-cp. Strangly those tests test that inlining is performed so the
-fno-ipa-cp is weird as the logic seems to be inversed.

  1   2   3   >