https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #9 from Peter A. Bigot ---
I haven't used msp430 for several years. Nobody's followed up after the patch
was merged, so I'd be ok with closing it. If there's still a problem it's
probably a different bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59703
--- Comment #3 from Peter A. Bigot pab at pabigot dot com ---
It also works for me on released 4.9.2; presumably it was fixed prior to 4.9.0
release as the date of the report suggests I was using trunk gcc at the time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #5 from Peter A. Bigot pab at pabigot dot com ---
Thanks, Ulrich: that's a better explanation of what makes me uncomfortable with
that part of the machine description.
We have a complex split pattern that's the sole user
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #3 from Peter A. Bigot pab at pabigot dot com ---
Comment on attachment 34232
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34232
Proposed patch
I don't trust that the term nonsubreg is being used correctly in that predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #6 from Peter A. Bigot pab at pabigot dot com ---
The alternative patch (using find_reg_fusage) does fix the problem in my
reproducing test case and in a real application. Thank you.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
This program:
struct adjustment {
unsigned long duration;
};
unsigned long read_clock ();
int dosomething (struct adjustment * ap, unsigned long v);
int doit (struct adjustment * ap)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
--- Comment #7 from Peter A. Bigot pab at pabigot dot com ---
I don't know if https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160 is related;
it appears to be a similar problem affecting a value returned in multiple
registers. It's present both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64010
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
CC||pab at pabigot
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027
--- Comment #1 from Peter A. Bigot pab at pabigot dot com ---
The following program:
int request();
int release();
unsigned char execute (unsigned char arg);
unsigned char safe_execute (unsigned char arg)
{
int rc;
unsigned char rs = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
--- Comment #5 from Peter A. Bigot pab at pabigot dot com ---
Yes, that could work. msp430mcu in mspgcc days did a lot more than specs
fragments; if interested see the relevant material (BSD-3-Clause) is in the
msp430mcu repository at:
https
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
The msp430-elf target currently implements integer multiplication by calls to a
function that invokes the hardware peripheral by loading peripheral registers
and reading results. The functions
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
Code generated with -mmcu=msp430fr5969 results in calls to the default hardware
multiplier, which is not the correct solution for this MCU. Other MCUs may
also be missing. See https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63954
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63901
--- Comment #3 from Peter A. Bigot pab at pabigot dot com ---
But it's already bad, because you have the list of MCUs hard-coded into the
compiler source, which is a lot worse than doing through the specs.
It's really unfortunate that somebody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59558
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
CC||pab at pabigot
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
The msp430 target has an option -mhwmult that is used to select among emulated
and hardware-assisted multiplication capabilities. Because this option does
not contribute to the selection of multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63709
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
Building trunk gcc at SVN 217005 produces the following from make all-target:
# If this is the top-level multilib, build all the other
# multilibs.
/tmp/gcc/./gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #7 from Peter A. Bigot pab at pabigot dot com ---
DEAR PEOPLE FROM THE FUTURE:
The problem is that OpenEmbedded used target-specific flags to build the
libraries, but did not ensure that the compiler was configured to default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #2 from Peter A. Bigot pab at pabigot dot com ---
Thanks. The compiler and libstdc++ are built using Yocto's standard recipe for
the beaglebone. Obviously there's something wrong with it; what that would be
is not obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100
--- Comment #4 from Peter A. Bigot pab at pabigot dot com ---
It's not obvious to me:
beaglebone[98]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-poky
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
gcc 4.9.1 bootstrap on an ARM hard-float system (TI AM3358 Cortex-A8 beaglebone
using Yocto: arm-poky-linux-gnueabi) fails with:
/home/pab/build/./gcc/xgcc -B/home/pab/build/./gcc/
-B/usr/local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099
--- Comment #2 from Peter A. Bigot pab at pabigot dot com ---
Created attachment 33296
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33296action=edit
config.log from failed build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099
--- Comment #3 from Peter A. Bigot pab at pabigot dot com ---
$ ../gcc-4.9.1/configure --enable-languages=c,c++ --prefix=/usr/local/gcc
Hopefully the attached config.log will have more useful information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099
--- Comment #4 from Peter A. Bigot pab at pabigot dot com ---
If you mean how did OpenEmbedded configure the compiler that's being used for
the bootstrap, that's an uglier question that I can't really answer since it's
got various patches
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
Created attachment 33297
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33297action=edit
reproducing code
The attached program built on the target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62099
Peter A. Bigot pab at pabigot dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
The code below generates this diagnostic with gcc 4.8.2 and 4.9.0:
llc[127]$ /usr/local/gcc/bin/g++ -std=c++11 -c using.cc
using.cc:21:30: error: ‘string_type’ is not a class, namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59681
--- Comment #3 from Peter A. Bigot pab at pabigot dot com ---
But also note [dcl.type.simple] p4:
The type denoted by decltype(e) is defined as follows:
— if e is an unparenthesized id-expression or an unparenthesized class member
access (5.2.5
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
In this commit
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/parser.c?r1=197248r2=197247pathrev=197248
the first diff (line 4109 of c/parser.c) fixed a problem where
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pab at pabigot dot com
Created attachment 31555
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31555action=edit
Reproducing code
The attached program uses tricks to produce a user
33 matches
Mail list logo
