[Bug libstdc++/59529] New: fix experimental/string_view end-of-string edge cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59529
Bug ID: 59529
Summary: fix experimental/string_view end-of-string edge cases
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bigotp at acm dot org
Created attachment 31448
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31448action=edit
Patch and test update
Per http://isocpp.org/files/papers/N3762.html#string.view.ops, for a given
string_view sv:
stringview sv{text};
auto rv = sv.substr(sv.size());
rv should be a string view starting at sv.end() with size zero. In the current
implementation this code improperly raises std::out_of_range.
Related to this, basic_string_view constructors with length zero and a valid
str should not be re-mapped to the internal empty string.
[Bug libstdc++/59530] New: Incorrect check on string_view operator[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59530 Bug ID: 59530 Summary: Incorrect check on string_view operator[] Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bigotp at acm dot org Created attachment 31449 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31449action=edit Patch and test update Per http://isocpp.org/files/papers/N3762.html#string.view.ops, string_view's operator[](size()) is undefined, unlike basic_string_view.
[Bug libstdc++/59531] New: string_view overrun in copy operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531 Bug ID: 59531 Summary: string_view overrun in copy operation Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bigotp at acm dot org Created attachment 31450 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31450action=edit Patch and test case The terminating value for the string_view copy operation is wrong, resulting in buffer overruns.
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 --- Comment #4 from Peter A. Bigot bigotp at acm dot org 2012-08-30 19:55:41 UTC --- Thanks for the suggestion. At the time this bug was reported, REGMODE_NATURAL_SIZE was not used as the target supported only 16-bit registers, so I don't believe that macro has anything to do with the behavior I noted. The current mspgcc back-end needs to support registers that are normally considered 16-bit, but can also hold 20-bit values (which must expand to 32-bits when in memory). I believe the use is proper and necessary for this situation. However, the back-end has a large number of other patches that were required to support this architecture, and it's possible that those contribute to why it works.
[Bug middle-end/38756] 107t.ivopts introduces pointer truncation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38756
Peter A. Bigot bigotp at acm dot org changed:
What|Removed |Added
CC||bigotp at acm dot org
--- Comment #1 from Peter A. Bigot bigotp at acm dot org 2012-06-21 11:34:15
UTC ---
I confirm this in 4.7.0. It's due to rewrite_use_nonlinear_expr() not checking
whether TYPE_PRECISION(ctype) TYPE_PRECISION(utype) before doing the pointer
adjustment in ctype and converting back to utype.
Something like this fixes it in my case:
if (TYPE_PRECISION (ctype) TYPE_PRECISION (utype))
{
ctype = generic_type_for (utype);
step = fold_convert (ctype, unshare_expr (step));
}
[Bug middle-end/38756] 107t.ivopts introduces pointer truncation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38756
--- Comment #3 from Peter A. Bigot bigotp at acm dot org 2012-06-21 12:04:34
UTC ---
commit af66de00843896ad5d2980952994b31cadbf8421
Author: Peter A. Bigot pabi...@users.sourceforge.net
Date: Thu Jun 21 06:35:44 2012 -0500
Anticipatory patch for PR middle-end/38756
Do not truncate to size_type when adding the step factor to a pointer.
diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c
index 0693c21..f8372fd 100644
--- a/gcc/tree-ssa-loop-ivopts.c
+++ b/gcc/tree-ssa-loop-ivopts.c
@@ -6199,6 +6199,11 @@ rewrite_use_nonlinear_expr (struct ivopts_data *data,
step = cand-iv-step;
ctype = TREE_TYPE (step);
utype = TREE_TYPE (cand-var_after);
+ if (TYPE_PRECISION (ctype) TYPE_PRECISION (utype))
+ {
+ ctype = generic_type_for (utype);
+ step = fold_convert (ctype, unshare_expr (step));
+ }
if (TREE_CODE (step) == NEGATE_EXPR)
{
incr_code = MINUS_EXPR;
[Bug middle-end/38756] 107t.ivopts introduces pointer truncation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38756 --- Comment #5 from Peter A. Bigot bigotp at acm dot org 2012-06-21 12:24:38 UTC --- Yes, that's where it happens. Your proposal makes sense; I've just been trying to avoid changing existing behavior on normal platforms. I'll give the unconditional solution a try on the next regression suite run.
[Bug middle-end/53103] New: bug locating unsigned type for non-standard precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53103
Bug #: 53103
Summary: bug locating unsigned type for non-standard precision
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org
gcc segfaults with this code:
typedef long int __attribute__((__a20__)) int20_t;
int20_t xi;
int20_t addit () { xi += 0x54321L; }
in a back end where xi ends up in mode PSImode which is a MODE_PARTIAL_INT
with 20 bits of precision and 32-bit width.
convert() notices that, because the constant in the add expression is
SImode, there's an SImode add being truncated to a PSImode result, and
pushes the truncation down into the operands. This ends up in
convert_to_integer, which detects that the signed operation might overflow
so calls unsigned_type_for() to get the unsigned variant.
Unfortunately, this ends up in c_common_type_for_size(), which knows nothing
about PSImode, and returns an unsigned type with 32 bits of precision when
asked for one with 20 bits of precision. The expression is rewritten with
the 32-bit constant integer recast to the 32-bit unsigned integer (instead
of the 20-bit one it might have used), and infinite recursion through
convert results.
Per http://gcc.gnu.org/ml/gcc/2012-04/msg00805.html, recommendation is to
abort the optimization if the required type is not selected.
[Bug middle-end/53104] New: convert_move on MODE_PARTIAL_INT does not look for existing conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53104 Bug #: 53104 Summary: convert_move on MODE_PARTIAL_INT does not look for existing conversion Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org convert_move has special code to handle conversion to and from MODE_PARTIAL_INT. Above this code is a comment stating that targets are expected to provide conversion insns for the MODE_PARTIAL_INT modes they use. When presented with a move from HImode to PSImode, however, this code will unconditionally convert HImode to SImode, then truncate back down to PSImode. For cases where both these operations are fairly expensive, it should instead first check to see whether the target provided the desired conversion directly.
[Bug middle-end/52940] New: conversion from MODE_PARTIAL_INT uses sign extension for unsigned types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52940 Bug #: 52940 Summary: conversion from MODE_PARTIAL_INT uses sign extension for unsigned types Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org In expr.c:convert_move, when from_mode has class MODE_PARTIAL_INT the conversion is done with sign extension even for unsigned types. This has been the behavior since the code was added in 2003, but it seems like a bug.
[Bug middle-end/52919] New: shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52919 Bug #: 52919 Summary: shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org The code for SHIFT_COUNT_TRUNCATED in expmed.c:expand_shift_1 improperly uses GET_MODE_BITSIZE instead of GET_MODE_PRECISION when calculating the truncation value. This can result in failure to identify an acceptable shift operation; e.g. with a PSImode with 20 bits of precision, a shift of 20 may be requested.
[Bug middle-end/52919] shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52919 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2012-04-09 22:30:20 UTC --- Created attachment 27119 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27119 Replace GET_MODE_BITSIZE with GET_MODE_PRECISION where necessary
[Bug middle-end/52856] misuse of MODE_SIZE vice MODE_PRECISION in get_mode_bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2012-04-09 22:31:59 UTC --- Created attachment 27120 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27120 Replace GET_MODE_BITSIZE with GET_MODE_PRECISION where necessary
[Bug middle-end/52856] New: misuse of MODE_SIZE vice MODE_PRECISION in get_mode_bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 Bug #: 52856 Summary: misuse of MODE_SIZE vice MODE_PRECISION in get_mode_bounds Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org get_mode_bounds improperly uses GET_MODE_BITSIZE(mode) instead of GET_MODE_PRECISION(mode) when calculating the minimal and maximal values. This produces the wrong answer for a 20-bit PSImode, causing an ordered comparison of a PSImode integer with zero to improperly fold to a constant in the out-of-tree msp430 back-end.
[Bug c/52691] New: va_start to builtin_next_arg optimization lost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52691 Bug #: 52691 Summary: va_start to builtin_next_arg optimization lost Classification: Unclassified Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org In the commit below, the following edit was made which inverted the sense of the test, preventing the optimization from applying when it should. A ! must be inserted before builtin_decl_explicit_p. diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c index e207e23..31c31c1 100644 --- a/gcc/tree-ssa-ccp.c +++ b/gcc/tree-ssa-ccp.c @@ -2175,7 +2175,7 @@ optimize_stdarg_builtin (gimple call) case BUILT_IN_VA_START: if (!va_list_simple_ptr || targetm.expand_builtin_va_start != NULL - || built_in_decls[BUILT_IN_NEXT_ARG] == NULL) + || builtin_decl_explicit_p (BUILT_IN_NEXT_ARG)) return NULL_TREE; if (gimple_call_num_args (call) != 2) commit b9a1687032fc1afb5f4e9d8dfa775a134abe21ba Author: meissner meissner@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Oct 11 19:55:09 2011 + Convert standard builtin functions from being arrays to using a functional interface git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@179820 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug tree-optimization/50213] [4.6 Regression] Regression in space-optimized code relative to 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213 --- Comment #11 from Peter A. Bigot bigotp at acm dot org 2011-10-17 11:16:16 UTC --- Richard: Thanks for the fix. For my non-integrated target I don't need it backported to 4.6 since I have a separate way to provide the patch. As I recall, the original patch didn't apply to 4.6 cleanly due to subsequent changes to tree-ssa-forwprop.c; a patch at the fork of gcc-4_6-branch from trunk is available at: http://mspgcc.git.sourceforge.net/git/gitweb.cgi?p=mspgcc/gcc;a=commit;h=21a41ea517c2e60d3a910aca8012a2c0d57b1005
[Bug rtl-optimization/50427] IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2011-09-16 10:25:31 UTC --- Created attachment 25302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25302 Potential fix for problem As far as I can tell, IRA misses this because it doesn't detect that the back end has generated RTL with pre-assigned general-purpose hard registers. Whether this technique is valid or not, it is also used in the avr backend for the same purpose (preparing to call a support routine that does not follow the standard ABI), though in that case the use is deeper in a parallel insn. The attached patch appears to fix the problem in my situation. I'd appreciate any comments and suggestions if there's a better solution.
[Bug rtl-optimization/50427] New: IRA fails to detect conflict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50427 Bug #: 50427 Summary: IRA fails to detect conflict Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org Created attachment 25299 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25299 C source, intermediate dump files, build command Per discussion on gcc email list, this may be a bug in gcc rather than in the msp430 back-end. Any assistance in isolating it would be welcome. gcc with the msp430 back-end integrated is available at git://mspgcc.git.sourceforge.net/gitroot/mspgcc/gcc in branch master. In the msp430 back end, hard registers 4 through 15 are HImode, with adjacent register sequences used for SImode and DImode. In preparation for a library call, I'm emitting RTL that assigns values directly to reg:SI 4. Despite that, in gcc 4.5.x and 4.6.x IRA choses reg:HI 4 as the destination for a pseudo-register for a preceding assignment, and does nothing to preserve the value over the span where the register is part of an SI value. Attached is a sample program and the dumps from what appear to be relevant phases. I can provide any further details required.
[Bug rtl-optimization/50213] New: Regression in space-optimized code relative to 4.5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213
Bug #: 50213
Summary: Regression in space-optimized code relative to 4.5.x
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org
Some change between 4.5.x and 4.6.x decreased generated code quality,
especially noticeable with -Os, for the following function:
int checkTLV (unsigned char* tlv)
{
unsigned int csum;
extern unsigned int __info_segment_size;
const unsigned int* p = (const unsigned int*)(tlv + __info_segment_size);
csum = 0;
while (--p (const unsigned int*)tlv)
csum ^= *p;
csum += *p;
return 0 == csum;
}
In 4.5.2 -Os, the loop has an 11 byte body:
11 000c EB02 jmp .L2 # 52jump[length = 2]
12.L3:
13 000e 3310 xorl(%rax), %edx# 15*xorsi_1/1
[length = 2]
14.L2:
15 0010 4883E804 subq$4, %rax# 18*adddi_1/1
[length = 4]
16 0014 4839F8cmpq%rdi, %rax # 20*cmpdi_1/1
[length = 3]
17 0017 77F5 ja .L3 # 21*jcc_1 [length = 2]
while in 4.6.1 -Os the loop has a 15 byte body:
11 000b EB06 jmp .L2 # 66jump[length = 2]
12.L3:
13 000d 3350FCxorl-4(%rax), %edx # 29*xorsi_1/1
[length = 3]
14 0010 4889C8movq%rcx, %rax # 21
*movdi_internal_rex64/2 [length = 3]
15.L2:
16 0013 488D48FC leaq-4(%rax), %rcx # 57*lea_1 [length
= 4]
17 0017 4839F9cmpq%rdi, %rcx # 34*cmpdi_1/1
[length = 3]
18 001a 77F1 ja .L3 # 35*jcc_1 [length = 2]
My hypothesis is that the label L2 is preventing the pseudo registers for the
loop variable and the memory access from being merged into the same hardware
register. This is not specific to the x86 back-end: I noticed it in an
unsupported back-end, where the suboptimal register allocation causes a spill.
The current trunk (svn 178132) generates the same suboptimal code as 4.6.1.
[Bug driver/49858] New: lost ability to use driver for external language support?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858
Summary: lost ability to use driver for external language
support?
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org
The nesC compiler at http://sourceforge.net/projects/nescc/ has historically
used a host/target gcc driver to process its files by using an wrapper driver
that invokes the target gcc with a -specs option defining a suffix-spec pair
describing how to translate its source files.
The documentation at http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html suggests
that this practice, as shown below, is a legitimate use of the driver:
.nc:
perl -S nesc-compile %{_*} %{m*} %{D*U*A*} %{H} %{I*} %{undef} %{trigraphs}
%{i*} %{nostdinc} %{a*} %{g*} %{O*} %{W*} %{w} %{S} %{pedantic*} %{std*}
%{ansi} %{traditional} %{v} %{p*} %{f*}
%{!fsyntax-only:%{!fnesc-cfile=*:%{!_fnesc-cfile=*:-fnesc-tmpcfile=%g.c}}
%{S:%W{o*}%{!o*:-o %b.s}}%{!S:%{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}}}
%{fsyntax-only:-o %j} %{-param*} %i -_ASM %Y
The change in commit 171307 rejects the options formerly allowed by this spec
string:
gcc: error: unrecognized command line option ‘-_fnesc-include=nesc_nx’
The wildcard spec string %{_*} no longer allows these options. Explicitly
adding %{_fnesc-include=*} didn't work either.
Is there a mechanism by which the driver can be informed of options that it
should allow in this situation, given that the list of these options is not
known at the time the driver is compiled?
[Bug driver/49858] lost ability to use driver for external language support?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 --- Comment #2 from Peter A. Bigot bigotp at acm dot org 2011-07-27 00:38:16 UTC --- On Tue, Jul 26, 2011 at 6:31 PM, joseph at codesourcery dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-07-26 23:31:27 UTC --- On Tue, 26 Jul 2011, bigotp at acm dot org wrote: Is there a mechanism by which the driver can be informed of options that it should allow in this situation, given that the list of these options is not known at the time the driver is compiled? No. By design there is now a structured notion of options shared by the driver and cc1 and a single mechanism for option parsing, that consistently rejects unknown options rather than having them sometimes only inconsistently rejected depending on which phases of compilation are run, and that is intended in future to support multilib selection based on logical option state rather than option text, and maybe eventually disallowing options without --help text. It was a mistake that specs were ever documented in the user manual; they should be considered a purely internal interface between different parts of GCC. It is not expected that you can drop in support for new languages without at least part of that support being present when GCC is built (GNU/Linux distributors may include the minimal set of files defining specs and options for languages such as D and Pascal when they build their main GCC packages, for example, so that the driver then supports those languages even though the language compilers themselves are built separately). On one hand, I think a regression like this warrants discussion, as this removes a feature that has been supported by gcc (and arguably documented as supported) for many years. Worst, the people who depend on it are folks who are unlikely to be involved in gcc development and will not be aware of the change until after 4.7.0 comes out and their systems have to be rearchitected to work with new vendor-provided gcc installations. I only found it now because I'm updating an out-of-tree back-end (TI msp430) and most of my practical applications depend on nesC. On the other hand, I'm sympathetic to the position that specs are a matter of internal implementation feature and that the change is reasonable. If that's going to be the resolution, though, the spec files material should be moved to the internals documentation. Peter (I do not rule out that the plugin mechanism could be extended in future to allow driver plugins, that might modify the unknown option handling, but the change away from allowing arbitrary options that just happen to be matched by some spec, to having a structured notion allowing a meaningful enumeration of all supported options and their associated properties, is deliberate. It would also be reasonable to provide a way to export the properties of GCC's options for use in external wrappers to know what options take arguments. But processing options unknown to GCC is outside the intended uses of the driver at present, although you may be able to find a hack where your wrapper hides them within options known to GCC that take an argument but where the driver doesn't validate that argument in any way; -fplugin-arg-* might be the most sensible option to use.) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #12 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:15 UTC --- Created attachment 23418 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23418 Test case (requires msp430 back end) Sorry, I don't speak dejagnu well enough yet to put target test conditionals into the code; this test lives in the gcc.target/msp430 directory in my environment.
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #13 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:45:52 UTC --- Created attachment 23419 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23419 Generated code before patch applied
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #14 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:46:30 UTC --- Created attachment 23420 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23420 Generated code after patch applied
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #15 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:48:23 UTC --- Created attachment 23421 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23421 Fixes problem
[Bug middle-end/42722] move_by_pieces() incorrectly pushes structures to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722 --- Comment #16 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:50:00 UTC --- I've now taken over the msp430 back end and created the attached patch and test case. This is relative to the gcc trunk as of a couple weeks ago; still present in all releases up to that point. Sorry it doesn't show up with any other back end, but perhaps an appeal to inspection could work while we get the msp430 target ready for integration: This is the only conditional of four in the same block that does not check for data.reverse before doing its thing. It's definitely wrong.
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 --- Comment #1 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:51:24 UTC --- Created attachment 23422 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23422 Fixes problem (resubmit, lost due to collision)
[Bug middle-end/31469] move_by_pieces in expr.c function bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31469 Peter A. Bigot bigotp at acm dot org changed: What|Removed |Added CC||bigotp at acm dot org --- Comment #2 from Peter A. Bigot bigotp at acm dot org 2011-02-21 09:53:10 UTC --- (In reply to comment #1) Created attachment 23422 [details] Fixes problem (resubmit, lost due to collision) Sorry, bugzilla confused me, this attachment was intended for 42722.
[Bug driver/47236] New: Spaces introduced in option processing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47236
Summary: Spaces introduced in option processing
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: big...@acm.org
The fix to #44076 causes options passed to language drivers to be split into
two arguments, a feature not present in previous versions.
cat xspecs EOSpec
.nc: @nesc
@nesc:
echo INVOKE: %{D*U*A*}
EOSpec
echo This is TEST foo.nc
gcc -specs=xspecs -DTEST foo.nc
With versions prior to revision 163770, this would produce output including:
INVOKE: -DTEST
As of that version, it now produces:
INVOKE: -D TEST
This breaks the nesC component-based compiler used for TinyOS, and possibly
other similar languages that leverage the gcc driver. The space does not
appear to be introduced for built-in languages (viz., the parameter remains
-DTEST when passed to cpp for a C language file).
If this is intentional and to be fixed in the per-language driver, please
update the description of the specs language to describe the conditions under
which such canonicalization can occur.
[Bug rtl-optimization/47138] backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 --- Comment #4 from Peter A. Bigot bigotp at acm dot org 2011-01-02 18:33:21 UTC --- Exactly: this problem also occurs with the TI msp430 target machine description, currently maintained as a fork on the mspgcc project on sourceforge. I don't know how to provide a test case other than a tar file and patch that adds that target, and a demonstration that without the referenced change build of libgcc fails with unrecognized instruction patterns (a parallel clobber didn't get updated, and the assert at the bottom of cfgrtl.c:patch_jump_insn gets hit when redirect_jump fails on a target that isn't an exit block). On further reflection, since this is fixed in trunk and the msp430 target wouldn't be back-ported into your repository for an existing release series, I'm ok with closing this as not-worth-fixing. I did, however, want an upstream problem report on which to hang the patches that I'll be maintaining.
[Bug rtl-optimization/45235] const volatile read moved out of order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235 --- Comment #6 from Peter A. Bigot bigotp at acm dot org 2010-12-31 17:57:14 UTC --- I've been running with this since my last comment with no problems. Could this be integrated into as many of trunk, gcc-4_4-branch, and gcc-4_5-branch as possible, please? Thanks.
[Bug rtl-optimization/47138] New: backport r158175: replace dominated uses in loop-invariant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47138 Summary: backport r158175: replace dominated uses in loop-invariant Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org While updating the msp430 back-end, I've discovered that the problem fixed in trunk in revision 158175 bites me as well in 4.4.x and 4.5.x. This is a request to back-port the corresponding fix to gcc-4_4-branch and gcc-4_5-branch.
[Bug rtl-optimization/46337] dse.c:replace_inc_dec mis-use of gen_int_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46337 --- Comment #3 from Peter A. Bigot bigotp at acm dot org 2010-11-07 14:09:31 UTC --- Created attachment 22308 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22308 Test case This test case evokes the bug with the 16-bit msp430 target, which is not integrated into gcc mainline. When built with -O2, the copy from cal into tcal is converted into a series of five one-word moves. The copies for the values at word offsets 2 (first half temperature_scale) and 4 (local_modbus_addr) are apparently eliminated by some other optimization, but the copy for the last half of temperature_scale hits the dse.c code. In my case, I end up attempting to convert the value 5 to CCMode, instead of the value 2 to HIMode, resulting in an ICE in trunc_int_for_mode at explow.c:56. I wasn't able to reproduce the ICE on a different architecture, and haven't tried to check the generated code. Seems that it's pretty dependent on the back end. Hope this helps, and if not, that it's still ok to fix because it's clearly wrong.
[Bug rtl-optimization/46337] New: dse.c:replace_inc_dec mis-use of gen_int_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46337 Summary: dse.c:replace_inc_dec mis-use of gen_int_mode Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org Created attachment 22302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22302 patch equivalent to part of SVN rev 146451 The parameters to gen_int_mode in dse.c:replace_inc_dec are mis-ordered, causing an ICE if the optimization actually gets applied. This was fixed in mainline by Ian Taylor in SVN revision 146451, but apparently never made it to a 4.4.x release. Please add it to the next one.
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #11 from bigotp at acm dot org 2010-08-13 20:11 ---
(In reply to comment #9)
(In reply to comment #8)
Hm, I only can see references to symbol not to either function or variable
declaration in the documentation. Can you cite the part that makes you
think
it restricts the use to functions?
It's documented in the section on function attributes, but not listed in the
section on variable attributes. Compare 'deprecated' or 'weak', which are
listed in both places.
Is there any intention to restrict use of weakref to functions? It seems to
be exactly what I want to use to allow a translation unit to reference a
memory-mapped register by its vendor-defined name, while not making that
name a global symbol that impacts other translation units, nor providing the
actual register address until the final link phase:
static volatile uint16_t P1IN __attribute((weakref(__P1IN)));
uint16_t c3 () { return P1IN; }
with __P1IN = 0x0020; in a linker script.
Other approaches seem to require that I have a definition for __P1IN
available at the time the object file is generated, which means I'd have a
potential for conflict if a different object file happened to include a
header that gave the register a different address; or that I use:
volatile uint16_t P1IN __attribute((weak));
uint16_t c3 () { return P1IN; }
which clutters the namespace.
Heck, I'll submit a patch to gcc/doc/extend.texi that explicitly allows use
of weakref on variables if that'd help.
--
bigotp at acm dot org changed:
What|Removed |Added
CC||bigotp at acm dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug rtl-optimization/45235] const volatile read moved out of order
--- Comment #4 from bigotp at acm dot org 2010-08-11 22:54 --- I don't see that the const qualifier should be relevant: doesn't it simply indicate that the code is not permitted to write through that lvalue? (FWIW, the real code uses a memory mapped address and the const qualifier was placed on the address declaration by the chip manufacturer. I assume that a write to the location may be interpreted as a command to the hardware to self-destruct.) Given that, the existing behavior appears to be a clear violation of the requirement that volatile accesses not be re-ordered across sequence points. In concept, I like rguenth's solution (which I haven't tested), as it fits with the documented semantics of MEM_READONLY_P indicating not modified during the lifetime of the program, something that certainly can't be said of any readable volatile object. That the RTL flag is stored in a field named unchanging is a lot more clear than READONLY. I think that approach eliminates the need to muck with any of those other places where the same problem might be occurring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235
[Bug rtl-optimization/45235] New: const volatile read moved out of order
This example is reduced from hardware-specific code that uses memory-mapped
registers to control and sample a logical signal. The read of the input signal
is moved to follow the clear of the output signal, in violation of the
requirements for volatile memory access.
Reproduce with: gcc -S -O2 ira-bug.c
Examine the generated assembly code to verify the read of in has moved to
follow the second write of out within the loop body.
The presence of the const qualifier on the in variable enables the bug; if the
qualifier is removed the original order is retained.
volatile const short int in;
volatile short int out;
void func () {
short int value;
do {
out |= 2;
value = in;
out = ~2;
} while (value 1);
}
--
Summary: const volatile read moved out of order
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bigotp at acm dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235
[Bug rtl-optimization/45235] const volatile read moved out of order
--- Comment #1 from bigotp at acm dot org 2010-08-09 11:57 --- Created an attachment (id=21441) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21441action=view) fixes for assumption that readonly means constant The problem is caused by the same sort of test as was fixed in a different situation in #35729. In the attached patch, it is the change to rtanal.c:rtx_varies_p that fixes the problem. The remaining changes are plausible, but I don't know whether they're necessary. There are additional uses of MEM_READONLY_P that are also questionable, that I didn't get around to trying. I suggest a thorough review by somebody who, unlike me, knows GCC internals. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235
