[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #23 from Nick Clifton  ---
Hi Guys,

>> But, as you have just discovered, (r5 + 12) is not 64-bit aligned...
> 
> But from ARMv7 onwards it only has to be 4-byte aligned, which it is.  And 
> this
> code was build for cortex-a9, which is ARMv7-a.

Ok, so this is a simulator bug.

Aldy - these easiest thing for now would be to unilaterally relax the alignment
test in Handle_Store_Double and see if that allows you to get further with your
tests.

(But yes, I agree, a reduced testcase would be a much better help than all this
mucking about in the simulator).

Cheers
  Nick

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #21 from Nick Clifton  ---
Hi Aldy,

>>> instruction. :-(  Looking at the code in Handle_Store_Double() in 
>>> sim/arm/armemu.c, I think that the reason is probably because the address
>>> for the store is not double word aligned.  Which leads me to wonder,
>>> what value is stored in r5 when the STRD instruction is being executed ?


>> => 0x8c24 : strdr2, [r5, #12]
>> (gdb) info reg r5
>> r5 0x1b6e8  112360

>> ...which is 64 bit aligned.

But, as you have just discovered, (r5 + 12) is not 64-bit aligned...

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #20 from Nick Clifton  ---
Hi Aldy,

>>> for the store is not double word aligned.  Which leads me to wonder,
>>> what value is stored in r5 when the STRD instruction is being executed ?
>>
>> 1: x/i $pc
>> => 0x8c24 : strdr2, [r5, #12]
>> (gdb) info reg r5
>> r5 0x1b6e8  112360

>> ...which is 64 bit aligned.

Hmm, curious.  OK - my next recommendation would be to add some printf()s
to the simulator to find out a) if Handle_Store_Double() really is being
called, or if the abort is happening somewhere else.  Plus, if it is being
called, then b) where inside that function the abort is happening.  Maybe
the store operations are triggering a memory access failure.

Cheers
  Nick

[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028

--- Comment #11 from Nick Clifton  ---
Hi Richard,

> If the backend doesn't support mixing of -msingle-float/-mno-single-float
> within a compilation unit then this will only work if the user didn't mix TUs
> with conflicting setting at link-time.  So the following will not be diagnosed
> but will instead have conflicting IL accepted silently with your
> patch (with unknown effect):
> 
>> gcc -c t1.c -flto -msingle-float
>> gcc -c t2.c -flto -mdouble-float
>> gcc t1.o t2.o -flto

But even without the patch, if the user does the above, but leaves out
the final -flto then the problem will still not be diagnosed:

 gcc -c t1.c -flto -msingle-float
 gcc -c t2.c -flto -mdouble-float
 gcc t1.o t2.o 

That is, unless the linker detects and reports this problem.  Which it does.
There are tags recorded in the build notes which specify the precision of
floating point used, and the linker will complain if these do not match.

So, since the linker will report conflicts there is no need for the LTO 
compiler to do so.   Especially when, as this bug report shows, it gets
the warning wrong under some circumstances.

So I still think that my patch is viable.  Comments ?

Cheers
  Nick

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518

--- Comment #13 from Nick Clifton  ---
Hi Aldy,


> pc: 8ca4, instr: e1c520fc
> pc: 4, instr: ea00089b
> 
> I took a peek at the executable being run with "/my-arm-build/objdudump -D
> the-executable.exe", and I see we are failing in 
> initialise_monitor_handles(). 
> This suggests we're failing during the start-up code:

> 8ca4:   e1c520fcstrdr2, [r5, #12]
> 
> It seems that last store is corrupting things and making us jump to a PC of
> 4???

Address 4 is the "undefined instruction" vector.  If the simulator thinks
that the instruction is illegal/unknown then it will branch to address 4
and start executing from there.  (Or else it loads the value stored at 
address 4 and starts executing from that address.  I forget which).

So, this basically means that the simulator does not like that STRD 
instruction. :-(  Looking at the code in Handle_Store_Double() in 
sim/arm/armemu.c, I think that the reason is probably because the address
for the store is not double word aligned.  Which leads me to wonder,
what value is stored in r5 when the STRD instruction is being executed ?




> Am I running the simulator correctly?

Yes.

>  Does it require a special flag for
> cortex-a9?  

No.

> Is the cortex-a9 CPU even handled by the simulator?

Yes.

> Should I run the dejagnu tests with -mcpu= or whatever, or is the
> --with-cpu=cortex-a9 configury flag enough?

Be paranoid - add the option. :-)


> Does the arm newlib/libgloss/whatever code have instructions that aren't
> handled by the GDB simulator?

No.  Well not in the assembler parts of it.  The possible exception to this
are the memory manipulation functions (memcpy, strlen ,etc) in newlib/libc/
sys/arm/ which tend to be very tightly coded, and will often be updated to 
take advantage of new instructions as they are added to the ISA.

Of course the C parts of these libraries might use unsupported instructions
if gcc generates them.  But if you have configured gcc correctly (and I think
that you have) then this should not be an issue.

Cheers
  Nick

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

--- Comment #31 from Nick Clifton  ---
Hi Alexander,

> Nick, can you please post the patch to gcc-patches too, to avoid confusing
> future people who wouldn't be able to find the explanation of the patch in the
> archives?
> (did you get approval for this patch offline?)

Oh foo - no I did not.  I will post to gcc-patches now.  If approval is
forthcoming quickly then I will leave things as they are.  Otherwise I will
revert my patch and wait for proper authorisation.  Sorry about mucking up.

Cheers
   Nick

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69012

--- Comment #18 from Nick Clifton  ---
Hi Bernd,

> I am still unsure, if we shouldn't also do something like this,
> to prevent any remaining possibility for a further regression:

> +  /* Don't change the frame info after reload completed.  */
> +  if (reload_completed)
> +return;

Actually that might not be a bad idea.  Or maybe, to be even more paranoid, we
should check that a post-reload frame computation matches the last pre-reload
frame computation.  Hmm, maybe that is going to far.

Anyway I like your patch idea, but I cannot approve it.  Maybe the MIPS
maintainers will like it...

Cheers
   Nick

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

--- Comment #11 from Nick Clifton  ---
Hi Marek,

> You need to sign in with your @gcc.gnu.org address.

Doh!  Totally forgot about that.  Thanks!

Cheers
   Nick

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #14 from Nick Clifton  ---
Created attachment 37275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37275=edit
Use SFmode variant of DFmode builtin vector types when -fshort-doubles is
enabled.

Hi Guys,

  I recently created and posted a patch for PR 55113 which also fixes this PR. 
(Patch attached here for easy reference).

  One reviewer however has suggested that a better solution would be to disable
-fshort-double option entirely:

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01900.html

  I am not of the best way to proceed.  Any suggestions ?

Cheers
  Nick

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60410

--- Comment #15 from Nick Clifton  ---
Sorry I meant:

  I am not sure of the best way to proceed.
   

[Bug target/43052] [4.9/5/6 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #32 from Nick Clifton  ---
Is this PR still a problem ?

I tried building the testcase from comment #1 today and found the memcmp is
being called even at -O3.  The run times are approximately the same for -O3 and
-O0 as well.

Cheers
  Nick

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770

--- Comment #8 from Nick Clifton  ---
Patch applied.  (Unfortunately I cannot close this BZ...)

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770

--- Comment #5 from Nick Clifton  ---
Created attachment 37099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37099=edit
Initialise the t_icode field of the sri structure created by copy_cost.

Hi Markus,

  Please could you try out the uploaded patch.

  I am currently running regression tests, but if it passes, and it works for
you, then I will submit it for review.

Cheers
  Nick

[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795

--- Comment #4 from Nick Clifton  ---
Hi David,

> Bother; I have another patch for this I was about to post, which is
> bootstrapping right now

Oops - sorry for treading on your toes!

Cheers
   Nick

[Bug bootstrap/67598] [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67598

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  ---
(In reply to Arseny Solokha from comment #2)
> Fixed during the last week, as of 6.0.0-alpha20151122 snapshot (in r230440,
> apparently).

If it is fixed, please could you close this PR ?

Cheers
  Nick

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #8 from Nick Clifton  ---
Created attachment 37079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37079=edit
Convert to unsigned before shifting

(In reply to Jakub Jelinek from comment #7)
> The question is about the others, but it has been so long that the 
> locations are all useless.

I have just checked.  The only problems that still remain are in
libiberty/regex.c.

The uploaded patch fixes this problem.  I plan to submit it for review after
running a few more regression tests.

[Bug ipa/66764] [6 Regression] ICE in analyze_function() on AIX

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Hi David,

> Analyzing compilation unit

I am unable to reproduce this ICE.  What command line options were being used
when it happened ?

Cheers
  Nick

[Bug target/68770] [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Markus,

  How do I reproduce this ?  IE please could you upload a testcase to
demonstrate this problem.

Cheers
  Nick

[Bug testsuite/68913] [6 Regression] gcc.dg/lto/pr61886 FAILs

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68913

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
Created attachment 37086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37086=edit
Provide weak version of __fread_chk

It seems to me that we could solve this problem by providing our own definition
of __fread_chk.  It does not have to work, since this is a link test, and the
real purpose of the test is to check that __fread_chk_warn is not referenced at
link time.

So I plan on submitting the uploaded patch after a few more local checks.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #5 from Nick Clifton  ---
Created attachment 37064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37064=edit
Define MAKE_DECL_ONE_ONLY for cygming targets

Hi Guys,

  I think that this patch should resolve the problem, although I do not have
the means to test it locally.

  The issue I believe is not that the ming32 definition of bind_local_p is
wrong, but rather than G++ thinks that it cannot make the decl weak even though
bind_local_p says that it should.  By defining MAKE_DECL_ONE_ONLY we allow G++
to make the decl weak and so the compilation works.  Well that is the theory at
least...

  If someone could test out this patch I would be very grateful.

Cheers
  Nick

[Bug c++/68795] [6 Regression] Use of uninitialised value of size 8 in cp_parser_postfix_expression (parser.c:6831)

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68795

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Created attachment 37066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37066=edit
Always set a location for the closing parenthesis in
cp_parser_parenthesized_expression_list

Hi Guys,

  This patch fixes the problem, although it may not be the best way to resolve
the bug.

  The problem is that cp/parser.c:cp_parser_postfix_expression assumes that
cp_parser_parenthesized_expression_list always sets a value for the location of
the closing parenthesis, even if there is an error in the parsing.  This
location is then passed to make_location and on down until it is eventually
used in libcpp/line-map.c:location_adhoc_data_hash.  This is where valgrind
detects the unitinialised use.  (Although it reports the location as being
somewhere else).

  The uploaded patch makes cp_parser_parenthesized_expression_list set a
default, unknown, location for the closing parenthesis first, and then later on
it can be overridden with the correct location if one is found.  This means
that all callers of cp_parser_parenthesized_expression_list can now assume that
the closing parenthesis location will be set.  An alternative patch would be to
make cp_parser_parenthesized_expression_list set the location to unknown only
if it cannot find the location, or to just modify cp_parser_postfix_expression
so that it initialises the location to unknown before calling
cp_parser_parenthesized_expression_list.

Cheers
  Nick

[Bug rtl-optimization/68304] [6 Regression] FAIL: gcc.c-torture/compile/950612-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (internal compiler error)

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68304

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi John,

  I just tried to reproduce this using the current (r231159) sources and I
could not.  Ie the test compiled without problems.  Perhaps this bug has
already been fixed ?

Cheers
  Nick

[Bug preprocessor/68638] [6 Regression] ICE in linemap_macro_map_lookup

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton  ---
Hi Martin,

  I tried to reproduce this problem using the latest (r231159) sources bug
could not.  I tried both an x86_64-pc-linux-gnu toolchain and an mep-elf
toolchain.  Is it possible that this bug has already been fixed ?

Cheers
  Nick

[Bug c++/67702] [4.9/5/6 Regression] Internal compiler error: Segmentation fault

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67702

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton  ---
Created attachment 36826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36826=edit
Workaround

This patch avoids the problem.  Not sure if it is the correct fix though. 
There is a comment in mangle.c:decl_mangling_context() which says "template
type parms have no mangling context." and it is this which is causing
write_template_prefix() to crash - it assumes that there is always a context
available.  But maybe template type parameters should never be passed to
template_write_prefix ?

[Bug target/54882] build fails for rl78-elf building libstdc++

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54882

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton  ---
I just tried building the toolchain with r230800 and it worked without any
problems...

[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758

Nick Clifton  changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #5 from Nick Clifton  ---
Ping ?

The patch works for us, and fixes a problem that a customer was having, so we
would really like to see it checked in.

Cheers
  Nick

[Bug rtl-optimization/66156] [msp430] wrong code generated with -O2 -mlarge (zero extension HI - SI)

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66156

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton nickc at redhat dot com ---
Hi Ronald,

  What's going on is that this is a reload bug.  Reload wants to extend r42
into r43 (or rather r12 into r10) and it is assuming that the zero_extendhisi
pattern will do this.  Unfortunately it does not, it only extends in place, and
so an extra move is required to make the conversion complete.  Reload generates
this extra move, but of course it is too late, r13 has already been clobbered.

  Not being a reload guru, I have decided to take the easy way out and extend
the zero_extendhisi2 pattern so that it can cope with moving the value whilst
extending it.  This works, although it does still leave a potential bug in
reload for other targets.  But for now it is the simplest solution.  So I am
going to apply this patch to the msp430 sources.  Please let me know if you
have any problems with it.

Cheers
  Nick

Index: gcc/config/msp430/msp430.md
===
--- gcc/config/msp430/msp430.md (revision 223348)
+++ gcc/config/msp430/msp430.md (working copy)
@@ -588,10 +588,12 @@
 ;; patterns.  Doing these manually allows for alternate optimization
 ;; paths.
 (define_insn zero_extendhisi2
-  [(set (match_operand:SI 0 nonimmediate_operand =rm)
-   (zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0)))]
+  [(set (match_operand:SI 0 nonimmediate_operand =rm,r)
+   (zero_extend:SI (match_operand:HI 1 nonimmediate_operand 0,r)))]
   msp430x
-  MOV.W\t#0,%H0
+  @
+  MOV.W\t#0,%H0
+  MOV.W\t%1,%L0 { MOV.W\t#0,%H0
 )

 (define_insn zero_extendhisipsi2

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton nickc at redhat dot com ---
Created attachment 35373
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35373action=edit
Use %lx/%ld to print long types

Hi Guys,

  Here is a patch to fix this problem.  The bug is that in a couple of places
the microblaze backend is using %llx to print out the value of a long type.  On
a 64-bit host this does not matter, but compiling on a 32-bit host the result
is extra garbage digits in the output.

Cheers
  Nick

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649

--- Comment #5 from Nick Clifton nickc at redhat dot com ---
Created attachment 35379
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35379action=edit
this time with a %0xlx

Hi Guys,

  *sigh* this has not been my day.  The previous two patches both had a small
thinko in them - I was printing a hex value into the assembler file without a
preceeding 0x prefix...  Doh.  So, a third attempt at the patch is attached.

Cheers
  Nick

[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649

--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Created attachment 35376
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35376action=edit
Patch resend

Darn - apparently the previous version of this patch suffered from TAB/space
corruption.  So here is a resend of the patch

[Bug target/65052] ICE in c6x-uclinux target when building libgcc

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052

--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Created attachment 35123
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35123action=edit
Disable the generation of real_jump insns

This patch works around the problem by disabling the generation of the
real_jump insns.  I am not enough of a C6X expert to determine why these
instruction patterns are not working, but they are definitely part of the
problem.

[Bug target/64407] xstormy16-elf: ICE in simplify_const_unary_operation, at simplify-rtx.c:1730

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64407

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
This is fixed in the mainline sources.  I have not tracked where though.

Cheers
  Nick

[Bug target/64408] fr30-elf ICE in extract_insn, at recog.c:2202

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64408

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Fixed by:

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00247.html

[Bug target/64027] inefficient handling of msp430 byte operands

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Hi Peter,

  I have applied a patch to the linker:

https://sourceware.org/ml/binutils/2015-01/msg00090.html

  This will transform the 4-byte BR instructions into 2-byte JMP instructions,
which the code size issue you raised as point 2.

Cheers
  Nick

[Bug target/64160] msp430 code generation error adding 32-bit integers

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160

--- Comment #6 from Nick Clifton nickc at redhat dot com ---
Hi Ulrich,

  if (reg_overlap_mentioned_p (operands[3], operands[7])
  || reg_overlap_mentioned_p (operands[3], operands[8]))
FAIL;

Thanks - that is indeed a better solution to the bug.

 B.t.w. is there a particular reason why the target-specific msp430_subreg is
 needed instead of the usual operand_subword?


I am not sure.  According to the comments in msp430.c it is because;
Simplify_gen_subreg() doesn't handle memory references the way we need it to
below, so we use this function for when we must get a valid subreg in a
'natural' state.  I think that this is all connected with the fact that for
the MSP430 in large mode, pointers are 20-bits long, and that this tends to
confuse gcc.

Cheers
  Nick

[Bug target/64160] msp430 code generation error adding 32-bit integers

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Created attachment 34232
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34232action=edit
Proposed patch

Hi Peter,

  Please try out this patch and let me know what you think.

Cheers
  Nick

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010

--- Comment #9 from Nick Clifton nickc at redhat dot com ---
Hi Ulrich,

  Thanks - ypur patch does work, and it is certainly better than mine.  Will
you be applying it to the gcc mainline sources ?  (And maybe the 4.9 branch as
well ?)

Cheers
  Nick

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Created attachment 34168
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34168action=edit
Patch for reload to avoid using argument regiesters when reloading a call insn

[Bug rtl-optimization/64010] [msp430-elf] struct function dereference clobbers parameter passed to function

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010

--- Comment #3 from Nick Clifton nickc at redhat dot com ---
Hi Alex,

  This appears to be a reload bug.  Before reload we have:

(call_insn 12 (call:HI (mem:HI (mem:HI (plus:HI (reg:HI R14)
(const_int 2
   (const_int 0)) 

  After reload this becomes:

(insn 17 (set (reg:HI R14)
  (mem:HI (plus:HI (reg:HI R14)
   (const_int 2)
(call_insn 12 (call:HI (mem:HI (reg:HI R14))
   (const_int 0)))

  The uploaded patch fixes this but, not being a reload expert, I am not sure
if this is the correct way to solve the problem.  It also seems suspicious that
if this is a generic reload problem, then why has it not been reported and
fixed before now ?

[Bug target/63901] msp430 multilib must distinguish mhwmult

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901

--- Comment #4 from Nick Clifton nickc at redhat dot com ---
Hi Peter,

 In mspgcc, TI provided a CSV file that listed every device along with all
 its characteristics.  This is still present in the GCC header bundle TI
 provides.  This in turn was processed to produce a specs fragment that
 provided rules to default all the -m* flags from a specific -mmcu= value.

Could the tool that converted the CSV file into a spec fragment be altered so
that it produces the relevent -mhwmult= option based upon an MCU input ?  Ie
would it be possible to provide the users with a tool that takes an MCU name,
reads in the CSV file and outputs the correct -mhwmult option ?  Somthing like: 

  msp430-elf-gcc `gen-hwmult-opt -mmcu=foo` 

If the tool was stand-alone then it would not need to be updated when the CSV
file changes, and it could work with any CSV file, old or new.

Cheers
  Nick

PS. I have applied the patch to the newlib sources so that at least that part
of the problem is resolved for now.

[Bug target/63901] msp430 multilib must distinguish mhwmult

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton nickc at redhat dot com ---
Created attachment 33997
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33997action=edit
Built newlib with -mhwmult=none

[Bug target/63901] msp430 multilib must distinguish mhwmult

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Hi Peter,

  The whole hardware multiply selection thing is a bit of a mess...

  The uploaded patch should resolve the problem for now by building newlib with
software multiply enabled.

  In the long term we ought to work out a way to enable multilib versions of
newlib based upon the hardware multiply supported.  The problem with that is
that multilib selection is based solely upon the command line options used
which means that a list of all known MSP430 MCU types would probably have to be
built into the specs - a bad idea that will fail as soon as a new MCU type is
created.

Cheers
  Nick

[Bug target/63709] msp430 Y constraint generates unacceptable constant in large mode

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63709

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #1 from Nick Clifton nickc at redhat dot com ---
Hi Peter,

  Sorry - this was a snafu in the assembler.  Its range checking of 20-bit
immediates was not quite right.  This is now fixed however so please update
your master binutils sources and try again.

Cheers
  Nick

PS.  The patch is also in the 2.25 branch...

[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc

[nickc at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #6 from Nick Clifton nickc at redhat dot com ---
Created attachment 33562
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33562action=edit
Patch to fix typo in sync.md

This bug is due to a typo in the sync.md file.  I will be applying the uploaded
patch to fix it shortly.

[Bug target/60602] gcc.c-torture/compile/pr28865.c FAILs on Solaris 9/SPARC

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60602

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Hi Rainer,

  Given that the 2.9 target is deprecated, do we really care about this problem
?

  Also - when I tried to assemble the file you uploaded I had no problems. 
This was using gas built from today's FSF mainline binutils sources, but I also
tried a version built from the 2.24 sources and the 2.23 sources - they all
worked.

Cheers
  Nick

[Bug target/57232] wcstol.c:213:1: internal compiler error

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57232

--- Comment #17 from Nick Clifton nickc at redhat dot com ---
Hi Alex,

   if (reg != hard_frame_pointer_rtx  fixed_regs[REGNO (reg)])
  cselib_preserve_cfa_base_value (val, REGNO (reg));

This works for the RX port - thanks!

Cheers
   Nick

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507

--- Comment #3 from Nick Clifton nickc at redhat dot com ---
Hi Ilya,

  I have now checked my patches in.  If you use the latest (development) FSF
sources for GCC and the binutils you should see that correct parsing of the
-mmcu command line option and the correct display of the MSP430 architecture
variant.

Cheers
  Nick

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507

--- Comment #1 from Nick Clifton nickc at redhat dot com ---
Created attachment 30910
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30910action=edit
Fix objdump output

Proposed patch to fix objdump output

[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507

--- Comment #2 from Nick Clifton nickc at redhat dot com ---
Created attachment 30916
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30916action=edit
Add parsing of known MSP430 MCU types

I am currently testing this patch to see if it introduces any regressions into
the gcc testsuite...

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35294



Nick Clifton nickc at redhat dot com changed:



   What|Removed |Added



 CC||nickc at redhat dot com



--- Comment #18 from Nick Clifton nickc at redhat dot com 2013-01-28 15:09:52 
UTC ---

I have checked in a modified version of serowk's patch to the 4.7 branch.  The

modification was to produce an error message in the cases where the modes do

not match, and to allow for the automatic forcing of constants into registers

for those builtins that do not accept immediates as their third operand.



Cheers

  Nick

[Bug target/55351] can't build libgcc for -m5-compact variant in SH64

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55351



--- Comment #1 from Nick Clifton nickc at redhat dot com 2012-11-19 16:01:36 
UTC ---

Created attachment 28732

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28732

Fixes to allow libgcc to build for the sh64-linux target



I am no SH expert, so this patch may well be wrong.  But it does allow libgcc

to built (for all supported multilibs) for the sh64-linux target.



There seem to be three problems:



  1. As reported in this PR, the sdivsi3 function is being built for the

L_div_table target when it clearly uses instructions that are not supported by

the target SH variant.  I have assumed that this is a mistake and so stopped

the function from being built for the m5-compact multilib.



  2. The udiv_qrnnd_16 function is not being built.  It is built for non-Linux

Sh targets, so I have assumed that it is an oversight and added it to the list

of functions to build.



  3. The m5-media64 and m5-media64-nofpu multilibs need the linker to support a

shlefl64_linux emulation.  The linker does not do this, so I have suppressed

all multilibs based on these options.

[Bug target/54661] mcore_output_movedouble: operation on ‘memexp’ may be undefined

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54661



--- Comment #2 from Nick Clifton nickc at redhat dot com 2012-10-09 08:39:03 
UTC ---

This was due to a silly typo, now fixed.

[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306

--- Comment #1 from Nick Clifton nickc at redhat dot com 2012-08-19 07:10:01 
UTC ---
Created attachment 28049
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28049
Remove offending #endif

[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306

--- Comment #3 from Nick Clifton nickc at redhat dot com 2012-08-19 07:13:25 
UTC ---
Hi Daniel,

  Thanks for catching this.  It was a snafu, corrected with the obvious fix you
suggested.

Cheers
  Nick

[Bug target/53187] ICE in arm_select_dominance_cc_mode

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53187

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton nickc at redhat dot com 2012-05-03 07:44:12 
UTC ---
Hi Jakub,

  I have tested the patch - it works and there are no regressions in the gcc
testsuite.  Thus I am happy to approve the ARM specific parts of the patch (for
the mainline and the 4.7 branch).

Cheers
  Nick

[Bug debug/51377] New: ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377

 Bug #: 51377
   Summary: ICE when generating debug info for targets with
multiple pointer sizes
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@redhat.com


Created attachment 25966
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25966
Source for test case

This is a follow up to a problem first reported here:

http://gcc.gnu.org/ml/gcc/2011-11/msg00397.html

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377

--- Comment #1 from Nick Clifton nickc at redhat dot com 2011-12-01 10:44:57 
UTC ---
Created attachment 25967
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25967
Test for mixed pointer modes in the assertion.

[Bug debug/51377] ICE when generating debug info for targets with multiple pointer sizes

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51377

--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-12-01 10:54:35 
UTC ---
[Darn - hit return too early].

When compiling for a target that supports multiple pointer sizes (eg s390)
generating debug information can trigger an ICE in the compiler:

  % s390-gcc -c -g -O2 -m64 fred.i
  fred.i: In function 'bar':
  fred.i:37:1: internal compiler error: in expand_debug_locations, at
cfgexpand.c:3687

The insn looks like this:

  (debug_insn 6 5 7 2 (var_location:SI temp$union_field$ptr_field (scratch))
fred.i:31 -1 (nil))

but the debug expression associated with it looks like this:

  (debug_expr:DI D#1)

The problem, I believe, is in the assertion at line 3687, not the debug
expression itself.  The expression has been created by converting the gimple
for the right hand side of the assignment on line 31 of fred.i:

arg_1(D)-bytes

into tree form.  This conversion chooses DImode since that is the default
pointer mode on this particular target.  The fact that this expression is then
cast to an SImode pointer is irrelevant - the expression itself is a DImode
pointer expression.

I have uploaded a proposed patch for this problem, based on an original patch
created by DJ, but tweaked a little bit by me.  It extends the assetion in
expand_debug_locations() to allow for the fact that pointer expressions might
use multiple modes.

Cheers
  Nick

[Bug c++/49777] for c++ code, without -g option, cannot generate PIC *.so library.

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49777

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #3 from Nick Clifton nickc at redhat dot com 2011-10-13 09:59:53 
UTC ---
Hi Kun,

  I am unable to reproduce this problem. :-(

  Can I check a couple of things:  How was the toolchain that you are using
configured ?  I assumed that it was basically like this:

  --target=arm-linux-gnueabi --with-arch=armv7-a

  Secondly were you using the 4.5.1 point release or the latest 4.5 branch
sources ?  I was using the latter, so maybe this is a case of bug which has
already been fixed ?

Cheers
  Nick

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801

--- Comment #10 from Nick Clifton nickc at redhat dot com 2011-10-10 13:33:45 
UTC ---
Hi Paulo,

  This should be fixed now.

Cheers
  Nick

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801

--- Comment #4 from Nick Clifton nickc at redhat dot com 2011-10-06 14:21:57 
UTC ---
Created attachment 25430
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25430
workaround for bb live register checking problem

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801

--- Comment #5 from Nick Clifton nickc at redhat dot com 2011-10-06 14:25:16 
UTC ---
Hi Paulo,

  Thanks for the step by step guide.  I can now reproduce the problem.

  It looks to me like a generic problem in the live register analysis code. 
Which is a but beyond my debugging capabilities, so I have uploaded a simple
workaround to avoid the issue.  Please note, this is definitely a workaround,
not a patch, so use it at your discretion.  In the meantime I will continue to
investigate and see if I can get my head around the df-core.c code.

Cheers
  Nick

[Bug middle-end/49801] df_live_verify_transfer_functions fails with to use of CC_REGNUM and checking enabled in rx backend

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com

--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-10-04 09:08:57 
UTC ---
Hi Paulo,

  Is this bug still reproducible for you ?

  I tried building an rx-elf toolchain from the current 4.6 branch sources and
I could not reproduce the problem...

Cheers
  Nick

[Bug middle-end/49899] New: ICE when redeclaring a static function as weak

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899

   Summary: ICE when redeclaring a static function as weak
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ni...@redhat.com


Created attachment 24862
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24862
Proposed patch and new testcase

If an already defined static function is redefined as being both public and
weak, the compiler generates an ICE:

% cat test.c
static long foo (void) { return 0; }
long foo (void)  __attribute__((weak));

% gcc test.c
test.c:1:12: internal compiler error: in function_and_variable_visibility,
at ipa.c:408

The uploaded patch is an attempt to fix this by adding a check into
varasm.c:merge_weak().  I was not sure however whether the redeclaration is an
error, or if it should be honoured and the function made non-static.

[Bug target/49403] v850e-elf: incompatible pointer type (near initialization for ‘targetm.memory_move_cost’)

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49403

--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-06-14 15:32:13 
UTC ---
Fixed in mainline.

[Bug target/49402] Duplicate use of v850.opt

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49402

--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-06-14 15:32:49 
UTC ---
Fixed in mainline.

[Bug target/48897] mn10300.c:extract_bundle’: error: variable ‘s’ set but not used

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48897

Nick Clifton nickc at redhat dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Nick Clifton nickc at redhat dot com 2011-05-09 09:03:20 
UTC ---
The variable was left over from an attempt to simplify the code.  It is not
needed and so I have checked in the obvious patch to remove it.

[Bug target/48899] enum conversion initializing global_options_init.x_iq2000_tune

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48899

--- Comment #2 from Nick Clifton nickc at redhat dot com 2011-05-09 10:07:20 
UTC ---
I have checked in a patch to initialise the iq2000_tune variable, thus
eliminating the warning.

[Bug target/46432] v850-elf --enable-werror-always build fails

[nickc at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46432

--- Comment #3 from Nick Clifton nickc at redhat dot com 2010-11-15 12:37:35 
UTC ---
Hi Joern,

 FWIW, following the GNU coding standard advice on 'swallowing the semicolon'
 avoids the warning:

I think that it would be better to just delete the definitions.  They 
are bogus; the v850 does not currently support profiling, so it will be 
cleaner to just remove them.  At patch that does this is pre-approved.

Cheers
   Nick

[Bug target/45000] RX signed extened unsigned char or short return value.

[nickc at redhat dot com]

--- Comment #3 from nickc at redhat dot com  2010-07-28 13:55 ---
Created an attachment (id=21338)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21338action=view)
Force functions that return small unsigned values to use zero-extension


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000

[Bug target/45000] RX signed extened unsigned char or short return value.

[nickc at redhat dot com]

--- Comment #4 from nickc at redhat dot com  2010-07-28 14:05 ---
Hi Kazuhiro-san,

 If the func() is external function, output code is the following.
  bsr_func
  mouv.B r1, r1
 If the return value is zero exteneded,
 movu.B r1, r1 code can be removed.

Not really.  The problem is that the compiler cannot guarantee the behaviour of
the func function, since it is external to the compilation unit.  It might not
actually return an unsigned byte value.


 Is the explanation san integer conversion rank?

I am not sure what you mean here.  The simplest thing that I can say is that
the code produced by gcc is what is required by the ISO C99 standard.  If the
RX ABI requires a different behaviour then it is not compatible with the ISO
C99 standard.

That said I have uploaded a patch which offers a compromise.  It makes
functions which return small unsigned values insert a zero-extend instruction
into their epilogues.  This is less efficient than the change that you were
requesting (using MOVU.B to load the value from memory in the first place), but
it does mean that the code produced by gcc will work both with other code
produced by gcc and with code produced by Renesas's own compiler.

May I also suggest that you contact Matt Newsome matt.news...@renesas.com at
Renesas who is also concerned with this particular problem.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000

[Bug target/45000] RX signed extened unsigned char or short return value.

[nickc at redhat dot com]

--- Comment #1 from nickc at redhat dot com  2010-07-22 09:42 ---
Hi Kazuhiro-san,

This is not a bug, it is the expected behaviour.

 What is happening is that the return value from func() is being promoted to
signed int (and not unsigned int as you might expect).  Thus since the
MOV.B instruction performs a sign extension it is a sufficient instruction for
the load operation.

 Note - if you try using the result of calling func() then you will see a zero
extension being performed.  Eg:

 int bar (int a) { return a  func(); }

results in:

   mov.L   #_uA, r14
   movu.B  [r14], r14
   cmp r1, r14
   sclt.L  r1
   rts

with inlining, or:

   push.l  r7
   mov.L   r1, r7
   bsr _func
   movu.B  r1, r1
   cmp r7, r1
   sclt.L  r1
   rtsd#4, r7-r7

without.

Cheers
 Nick Clifton

PS. See section 6.3.1.1 of the ISO C99 standard for more information about this
behaviour


-- 

nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000

[Bug c/44438] New: ISO C99 6.7.4p3 not obeyed in C99 mode

[nickc at redhat dot com]

Section 6.7.4 paragraph 3 of the ISO C99 standard states that:

An inline definition of a function with external
linkage ... shall not contain a reference to an identifier with
internal linkage.

GCC has code to check for this condition, but it does not work in C99 mode.

Reproduce by:

  % cat iso-c99-test.c
  static int a = 7;
  extern inline int foo (void) { return a; }
  int main (void) { return foo (); }

  % gcc -c iso-c99-test.c
  iso-c99-test.c:2:39: warning: 'a' is static but used in inline function 'foo'
which is not static [enabled by default]

  % gcc -c -std=c99 iso-c99-test.c
  %


-- 
   Summary: ISO C99 6.7.4p3 not obeyed in C99 mode
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44438

[Bug target/39601] xstormy16 target broken, cannot build newlib

[nickc at redhat dot com]

--- Comment #1 from nickc at redhat dot com  2009-04-14 15:14 ---
Created an attachment (id=17633)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17633action=view)
Do not assume that comparisons with small integers will always produce a short
branch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601

[Bug target/39601] xstormy16 target broken, cannot build newlib

[nickc at redhat dot com]

--- Comment #2 from nickc at redhat dot com  2009-04-14 15:15 ---
Hi Paolo

  I am going to apply the uploaded patch to fix this problem.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #14 from nickc at redhat dot com  2009-03-11 16:09 ---
Created an attachment (id=17439)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17439action=view)
Document the FR30 target options


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #15 from nickc at redhat dot com  2009-03-11 16:09 ---
Hi Guys,

  I have checked in a patch to add documentation for the FR30 target options.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #17 from nickc at redhat dot com  2009-03-11 16:57 ---
Created an attachment (id=17441)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17441action=view)
Add descriptions of MCore options


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug target/5362] Undocumented target options

[nickc at redhat dot com]

--- Comment #18 from nickc at redhat dot com  2009-03-11 16:59 ---
Hi Guys,

  I have checked in a patch to add descriptions of the MCore options.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5362

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #3 from nickc at redhat dot com  2008-11-10 13:49 ---
Hi Guys,

  I have uploaded a potential patch for the problem.  It fixes the testcase
originally provided and does not introduce any regressions into the g++
testsuite for an i686-pc-linux-gnu toolchain.  

That's the good news.  The bad news is that I am not sure if the patch will be
acceptable since I am not a C++ expert.  The problem I believe is that the
status of the cp_id_kind enum which is computed by
cp_parser_postfix_dot_deref_expression() when it is parsing A::get is not
passed back to cp_parse_primary_expression() which is currently parsing
(p-A::get).  So it goes with its default value, which allows overloading of
virtual functions, and so the wrong member function is selected.

The patch attempts to fix this problem by allowing the cp_id_kind enum computed
in cp_parser_postfix_dot_deref_expression to be passes back, via a long chain
of intermediary functions, to cp_parser_primary_expression.  My concern is that
I am not familiar enough with the C++ parser to tell if the patch breaks some
other parser requirement.  (One that is not tested by the g++ testsuite).

So - is this patch acceptable ?

Cheers
  Nick


-- 

nickc at redhat dot com changed:

   What|Removed |Added

 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #4 from nickc at redhat dot com  2008-11-10 16:22 ---
Created an attachment (id=16645)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16645action=view)
Testcase for the bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #5 from nickc at redhat dot com  2008-11-10 16:22 ---
Oops - almost forgot - the bug needs a testcase for the g++ testsuite, so I
have uploaded a patch to add that as well.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug c++/37862] Parenthesised indirection alters class member access

[nickc at redhat dot com]

--- Comment #2 from nickc at redhat dot com  2008-11-10 13:36 ---
Created an attachment (id=16644)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16644action=view)
Allow postfix parser to pass cp_id_kind information back to the primary parser


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug c++/37862] New: Parenthesised indirection alters class member access

[nickc at redhat dot com]

Hi Guys,

Compiling and then executing this program:
#include stdio.h

class A {
public:
 virtual void get() { printf (A\n); }
};
class B:public A {
public:
 virtual void get() { printf (B\n); }
};
class C:public B {
};
int main (void)
{
 C c;
 C* p = c;

 p-A::get();
 (p-A::get)();

 return 0;
}

Results in:

  A
  B

Being displayed, rather than:

  A
  A

As far as I can tell the parentheses around the class member access should not
change anything.

Cheers
  Nick


-- 
   Summary: Parenthesised indirection alters class member access
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #45 from nickc at redhat dot com  2008-10-07 11:37 ---
Created an attachment (id=16475)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16475action=view)
Enable -fno-common with -msse for Cygwin/Mingw


-- 

nickc at redhat dot com changed:

   What|Removed |Added

  Attachment #16458|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #46 from nickc at redhat dot com  2008-10-07 11:38 ---
Hi Brian,

 IMHO, we should just have gcc automatically enable -fno-common on PE if
 SSE is enabled.  That's what the MS tools do, AFAICT.

Something like the newly uploaded patch ?

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #44 from nickc at redhat dot com  2008-10-07 10:57 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

sherpya at netfarm dot it wrote:
 I mean that with -fno-common alignment works, even with non patched 4.2, my
 question is due to the fact that it's not so clear for me what no-common does

-fno-common stops uninitialized variables declared in C and C++ programs 
from being treated in the same way as common variables declared in 
FORTRAN programs.

 and adding -fno-common what are side effects?

Essentially there are two side effects:  The first is that you will get 
a link time error if you declare the same uninitialized variable twice 
in two different source files, without using the 'extern' keyword on one 
of them.  eg:

   % cat foo.c
   int a;

   % cat bar.c
   int a;
   int main (void) { return 0; }

   % gcc foo.c bar.c

   % gcc -fno-common foo.c bar.c
   multiple definition of `a'

This is often a problem with badly written header files which declare 
variables without using 'extern'.  eg:

   % cat header.h
   int a;

   % cat foo.c
   #include header.h
   int a;

   % cat bar.c
   #include header.h
   int main (void) { return 0; }

   % gcc -fno-common foo.c bar.c
   multiple definition of `a'

The other side-effect, and the one that is more interesting for our 
purposes, is that it forces uninitialised variables to be placed into 
the .bss section.  This is important because symbols in the PE/COFF file 
format do not have an alignment attribute of their own.  Instead the 
alignment is inherited by the containing section, with the maximum 
alignment of any symbol inside a section being taken as the section's 
alignment as a whole.  Symbols are placed inside the section on suitably 
aligned boundaries, so that providing that the section itself is placed 
on an alignment boundary everything will work.  eg:

   % cat foo.c
   int normal_align;
   int aligned_16 __attribute__((aligned(16)));

   % gcc -fno-common -c foo.c
   % objdump --syms foo.o
   [  8](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x _normal_align
   [  9](sec 3)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0010 _aligned_16

   Note how the 'aligned_16' variable starts at an offset of
   0010 from the start of section 3, whereas 'normal_align'
   starts at an offset of .  Ie there is a gap of 12
   bytes from offset 0004 to 000f.

   % objdump -h foo.o
   Idx Name  Size  VMA   LMA File off  Algn
   2 .bss  0020        2**4

   Note that the .bss section has been given an alignment of 2^4.
   This is because it contains 'aligned_16'.  If that variable had
   not been declared then the .bss section would have been given
   its default alignment of 2^2.

   Also note that section numbering differs between the two uses
   of objdump.  Ie (sec 3) in the objdump --syms output refers
   to the third declared section which is the section with an
   index of 2 in the objdump -h output.

   % cat bar.c
   int a;

   % gcc -fno-common bar.c foo.o
   % nm a.exe
   00402000 B _a
   00402020 B _aligned_16
   00402010 B _normal_align

   So after linking 'aligned_16' still has a 16-bit alignment
   because of the 2^4 alignment of the .bss section in the foo.o
   object file.

The reason that all of this is important is that when common variables 
are stored in a PE/COFF object file they are not assigned to any 
section.  Since only sections, not symbols, have an alignment attribute 
in PE/COFF object files, any alignment requirements of common symbols 
are lost.  This is what has been causing the problems that you have 
experienced.  eg:

   % cat foo.c
   int normal_align;
   int aligned_16 __attribute__((aligned(16)));

   % gcc -c foo.c
   % objdump --syms foo.o
   [ 8](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _normal_align
   [ 9](sec 0)(fl 0x00)(ty 0)(scl 2)(nx 0) 0x0004 _aligned_16

   Note how the variables are assigned to (sec 0) which does not
   exist and that there is no field or flag specifying the alignment
   for either of them.

You may ask why common variables are not assigned to the .bss section. 
The reason is that if there are multiple declarations of the same 
variable and all but one of which are common, then the non-common 
declaration takes precedence.  eg:

   % cat foo.c
   int a;

   % cat bar.c
   int a = 1;

   % gcc foo.c bar.c
   % nm a.exe
   00402000 D _a

Ie the 'a' variable has been placed in the .data section and not the 
.bss section, despite the fact that it was declared uninitialised in 
foo.c.

So common variables are not assigned to a section until the final link 
takes places.  If there are no non-common definitions of a variable to 
specify where they should be placed then they are assigned to the .bss 
section, but by then it is too late - the alignment requirements of the 
symbol have been lost.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #33 from nickc at redhat dot com  2008-10-06 12:43 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

Hi,

 http://people.netfarm.it/~sherpya/gcc/info.7z

Just a quick check: If you build with -fno-common does the executable 
then work ?

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #35 from nickc at redhat dot com  2008-10-06 16:43 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

Hi sherpya,

 --- Comment #34 from sherpya at netfarm dot it  2008-10-06 14:13 ---
 $ nm ffmpeg_g.exe |grep ff_cos_16
 00dd84e0 B _ff_cos_16
 00de04c0 B _ff_cos_16384
 
 except snow and svq1 tests, crashing because of bugs in tree opts on win32
 sse code is working fine

As I suspected.  The PE/COFF file format does not provide for specifying 
the alignment of commons.

Hmm, I wonder if gcc should complain if it finds aligned commons with 
COFF backends or if we should try to generate a GNU extension to the 
COFF format.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #37 from nickc at redhat dot com  2008-10-06 17:24 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

Hi,

 so how with -fno-common can make aligned work?

Hang on - I thought that you had said that when ffmpeg_g.exe was built 
with -fno-common that it worked, modulo some (completely separate) tree 
optimization bugs.  Is that not right ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #39 from nickc at redhat dot com  2008-10-06 18:16 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3


 yes alignment works, and even my test align program with 4.2 without patches
 gives correct alignment to local and global symbols

OK, so when you said:

  so how with -fno-common can make aligned work?

did you really mean:

  so how without -fno-common can make aligned work?

In which case the answer is - I do not know.  The problem is that the 
PE/COFF file format does not support aligned commons.  We could try to 
create an extension to the format to support them, but that would be 
non-standard.  Another possibility would be to turn any common symbol 
with an alignment attribute into a weak symbol instead.  This would work 
(I think, I have not tried it), provided that there are no other 
definitions of the same symbol with a different size.  Which would 
possibly cause problems with FORTRAN programs but it is unlikely to be 
an issue with C/C++ programs.

Another possibility is to modify the linker so that when it is placing 
common symbols into the .bss section of the output executable every 
symbol is aligned to the maximum alignment specified for any of the .bss 
sections of any input object file.  This would probably waste huge 
amounts of space in the .bss section (for large programs anyway) but it 
ought to work.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #31 from nickc at redhat dot com  2008-10-04 08:27 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3


 the patch looks ok but unfortunately does not always solves the problem,
 something in the chain misalignes the symbol
 This does not happen always but in some circumstances :(

Possibly a linker bug.  Could you investigate some more ?  For example 
what alignment does the .bss section have in the object file and in the 
executable ?

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #28 from nickc at redhat dot com  2008-10-03 16:52 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

Hi Danny,

 This test case:
 t1.c:(.text+0x5): undefined reference to `_i' 

Hmm, I cannot reproduce this, however...

 .comm   _i, 0  size of i[0]

I did drop the code to handle (size == 0) because I was not sure why it 
was there.

 I suspect we need to add this bit, or similar, back in
 -  rounded = size ? size : 1;

How about this third revision of the patch ?

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #29 from nickc at redhat dot com  2008-10-03 16:54 ---
Created an attachment (id=16458)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16458action=view)
Revised patch which handles (size == 0)


-- 

nickc at redhat dot com changed:

   What|Removed |Added

  Attachment #16425|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #24 from nickc at redhat dot com  2008-09-30 14:05 ---
Subject: Re:  [cygming] Invalid alignment for SSE store
 to .comm data generated with -O3

 a printf in the code for ff_cos_16 causes the compiler to align the var,
 but at this point it crashes in another place using sse code

So, does this mean that the align patch is working, but that there is 
some other bug that is preventing some sse code from working ?  If so 
then I can formally submit the align patch for approval.

Cheers
   Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #13 from nickc at redhat dot com  2008-09-29 14:13 ---
Created an attachment (id=16425)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view)
Revised patch with correct section switching


-- 

nickc at redhat dot com changed:

   What|Removed |Added

  Attachment #16303|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #14 from nickc at redhat dot com  2008-09-29 14:16 ---
Hi Guys,

  I am not able to reproduce the build problems that were reported with the
first version of my patch, but then again I do not have a native cygwin build
system or a system in which I can bootstrap mingw32.  I think that Brian may
well be right however in that the patch is behaving badly when it manually
switches into the .bss section.  I have uploaded a revised version of the patch
which uses the correct gcc function to perform the section switch, so please
can anyone who is interested give this new patch a run.

Cheers
  Nick


-- 

nickc at redhat dot com changed:

   What|Removed |Added

 CC||nickc at redhat dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #8 from nickc at redhat dot com  2008-09-12 15:52 ---
Created an attachment (id=16303)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16303action=view)
Implement alignment for non-local commons


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #9 from nickc at redhat dot com  2008-09-12 15:54 ---
Hi Brian,

  Please could you try out the uploaded patch which is an implementation of
your idea to add an extra alignment directive when emitting commons.  It seems
to work for the test case you gave, but I have not yet run it through a full
rebuild and retest cycle...

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216

[Bug target/31110] Problem while compiling gcc for mn10300-elf

[nickc at redhat dot com]

--- Comment #9 from nickc at redhat dot com  2008-03-28 08:43 ---
Hi Jeff,

  Thanks - I have checked the patch in.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110