64-poky-linux-gcc -O1 -fsanitize=address -fno-omit-frame-pointer -o
> > > test test.c"
> > >
> > > *AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131
> > > "((kSpaceBeg)) == ((address_range.Init(TotalSpaceSize,
> > > PrimaryAllocator
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
c.hodg...@pdconsultantsuk.co.uk
(generated from a.gr...@privateinvestigators
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
Domain wasson.ltd has exceeded the max defers and failures per
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
Domain gsjj.ma has exceeded the max defers and failures per hour
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
Domain wasson.ltd has exceeded the max defers and failures per
(__builtin_inff ())
| ^~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:512: _divhc3.o] Error 1
Should we do #undef INFINITY in libgcc2.c? change all of the uses of
INFINITY to something else?
Thanks,
Andrew
>
> Build state: failed comp
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error.
The following address failed:
thomasinacu...@att.net:
SMTP error from remote server for RCPT TO command, host
'm trying to studing the automatic vectorization optimization in GCC,
> > but I found one case that SLP vectorizer failed to do such things.
> >
> > Here is the sample code: (also a simplification version of a function
> > from the 625/525.x264 source code in SPEC CPU 2017)
&g
On Sat, May 25, 2024 at 3:08 PM Hanke Zhang via Gcc wrote:
>
> Hi,
> I'm trying to studing the automatic vectorization optimization in GCC,
> but I found one case that SLP vectorizer failed to do such things.
>
> Here is the sample code: (also a simplification version of a
Hi,
I'm trying to studing the automatic vectorization optimization in GCC,
but I found one case that SLP vectorizer failed to do such things.
Here is the sample code: (also a simplification version of a function
from the 625/525.x264 source code in SPEC CPU 2017)
void pixel_sub_wxh(int16_t
Hi,
I am facing the issue on enabling sanitizers for gcc on aarch64 linux.
The issue was observed with the following command :-
"aarch64-poky-linux-gcc -O1 -fsanitize=address -fno-omit-frame-pointer -o
test test.c"
*AddressSanitizer: CHECK failed: sanitizer_allocator_primary64.h:131
&q
Am 24.05.23 um 11:28 schrieb Richard Biener:
On Tue, May 23, 2023 at 1:25 PM Georg-Johann Lay wrote:
This error pops up in the testsuite for avr.
As far as I understand, this is due to target-specific optimization like
in avr-common.cc:
{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_pr
On Tue, May 23, 2023 at 1:25 PM Georg-Johann Lay wrote:
>
> This error pops up in the testsuite for avr.
>
> As far as I understand, this is due to target-specific optimization like
> in avr-common.cc:
>
> { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_prologues, NULL, 1 },
> { OPT_LEVELS_1
This error pops up in the testsuite for avr.
As far as I understand, this is due to target-specific optimization like
in avr-common.cc:
{ OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_mgas_isr_prologues, NULL, 1 },
{ OPT_LEVELS_1_PLUS, OPT_mmain_is_OS_task, NULL, 1 },
// Stick to the "old" plac
n the rest of
> > > the subject line
> > >
> > > Buildbot (Sourceware): gcc - failed configure (failure) (master)
> >
> > They convey as much additional information as does (automated) colorful
> > syntax highlighting, or (manual) source code line indentation: &
在 2023-01-31 21:13, Thomas Schwinge 写道:
Hi!
On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran
wrote:
Does the skull and crossbones convey anymore info than the rest of
the subject line
Buildbot (Sourceware): gcc - failed configure (failure) (master)
They convey as much additional
Hi!
On 2023-01-30T14:50:08-0800, Steve Kargl via Fortran
wrote:
> Does the skull and crossbones convey anymore info than the rest of
> the subject line
>
> Buildbot (Sourceware): gcc - failed configure (failure) (master)
They convey as much additional information as doe
On 1/30/23 5:46 AM, Sam James wrote:
On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote:
Hi Steve,
Please remove the skull and cross bones in the subject line.
This is a sourceware project so I've CC'd the buildbot mailing list where we
discuss
these matters.
Does the emoji bother yo
r special character in one's name - which is
> pretty common in parts of the world like Central Europe?
umlaut and other special chars can trigger spam filters.
Whitelisting is used for those that matter.
Does the skull and crossbones convey anymore info than the rest of
the subject line
On 30.01.23 23:07, Gerald Pfeifer wrote:
Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets
to /dev/null?
Sending mail with special graphics in Subject lines is what spammers do,
to attract special attention. (And no, umlauts are not included :-).
So, If I ever happen t
On Mon, 30 Jan 2023, Steve Kargl via Gcc wrote:
> Bingo. In the case of non-[a-zA-Z] characters in the
> Subject (or Fromi or To) line, the spam folder is normally
> named /dev/null.
Hmm, so any digit, parenthesis, or bracket in the Subject, and mails gets
to /dev/null?
Or having an umlaut or o
On Mon, Jan 30, 2023 at 03:46:30PM +0100, Thomas Koenig wrote:
> On 30.01.23 14:52, Mark Wielaard wrote:
> > Hi Steve,
> >
> > On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
> > > Please remove the skull and cross bones in the subject line.
> >
> > That is the default "hazard symbo
On 30.01.23 14:52, Mark Wielaard wrote:
Hi Steve,
On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
Please remove the skull and cross bones in the subject line.
That is the default "hazard symbol" buildbot uses if a build turns from
success to failure. If you have a better suggest
Hi Steve,
On Sun, 2023-01-29 at 22:27 -0800, Steve Kargl via Gcc wrote:
> Please remove the skull and cross bones in the subject line.
That is the default "hazard symbol" buildbot uses if a build turns from
success to failure. If you have a better suggestion you might want to
contact upstream htt
> On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote:
Hi Steve,
> Please remove the skull and cross bones in the subject line.
This is a sourceware project so I've CC'd the buildbot mailing list where we
discuss
these matters.
Does the emoji bother you, or is it the skull and crossbones sp
On Sun, Jan 29, 2023 at 07:49:35PM +, Sam James via Fortran wrote:
>
>
> > On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote:
> >
> > I had this show up today. I have no idea what this is about.
> >
> > Please advise.
> >
>
> Sorry Jerry, false positive -- something went wrong with
> the b
> On 29 Jan 2023, at 19:36, Jerry D via Gcc wrote:
>
> I had this show up today. I have no idea what this is about.
>
> Please advise.
>
Sorry Jerry, false positive -- something went wrong with the builder. Disregard.
We're still setting things up there.
> Jerry
Best,
sam
signature.asc
On Sun, Jan 29, 2023 at 2:37 PM Jerry D via Fortran wrote:
>
> I had this show up today. I have no idea what this is about.
>
> Please advise.
I assume the buildbot thinks that
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8011fbba7baa46947341ca8069b5a327163a68d5
broke the build, but I fail to se
I had this show up today. I have no idea what this is about.
Please advise.
Jerry
Forwarded Message
Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
Date: Sun, 29 Jan 2023 19:31:23 +
From: buil...@sourceware.org
To: Jerry DeLisle
A new
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
> gcc@gcc.gnu.org
>(generated from g...@gnu.org)
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
(generated from g...@gnu.org)
host gcc.gnu.org [2620:52:3:1:0
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
gcc@gcc.gnu.org
host gcc.gnu.org [8.43.85.97]
SMTP error from remote mail
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of
its recipients. This is a permanent error. The following address(es)
failed:
Reason:
multiple delivery attempts failed
--- The header of the original message is
ow of nothing relevant that has changed on the sourceware side.
sign_and_send_pubkey: signing failed: agent refused operation
mse...@gcc.gnu.org: Permission denied (publickey).
fatal: Could not read from remote repository.
The usual advice is to run % ssh -vv gcc.gnu.org alive
and report the ssh
gt; >>
> >>> Is this a transient glitch or has something changed recently that I
> >>> need to make some adjustments for?
> >>
> >> I know of nothing relevant that has changed on the sourceware side.
> >>
> >>> sign_and_send_pubk
e you logging in from the same workstation with access to the same
set of ssh private keys?
Is this a transient glitch or has something changed recently that I
need to make some adjustments for?
I know of nothing relevant that has changed on the sourceware side.
sign_and_send_pubkey: signing f
On Mon, Jun 1, 2020 at 3:33 PM Martin Sebor via Gcc wrote:
> So it sounds like you wouldn't expect the "agent refused operation"
> error either, and it's not just a poor error message that I should
> learn to live with. That makes me think I should try to figure out
> what's wrong. I think the ~
On 6/1/20 1:53 PM, Frank Ch. Eigler wrote:
Hi -
~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner.
Everything works fine if I add my key by running ssh-add. What's
not so great is the errors I get when I forget to do that: "agent
refused operation?"
Yeah, there is something odd o
h access to the same
> >>> set of ssh private keys?
> >>
> >> Yes.
> >>
> >>>
> >>>> Is this a transient glitch or has something changed recently that I
> >>>> need to make some adjustments for?
> >>>
> >
Hi -
> ~/.ssh/known_hosts exists and ~/.ssh is rwx only by the owner.
> Everything works fine if I add my key by running ssh-add. What's
> not so great is the errors I get when I forget to do that: "agent
> refused operation?"
Yeah, there is something odd on your side. Maybe your ssh client is
side.
sign_and_send_pubkey: signing failed: agent refused operation
mse...@gcc.gnu.org: Permission denied (publickey).
fatal: Could not read from remote repository.
The usual advice is to run % ssh -vv gcc.gnu.org alive
and report the ssh level error.
"agent refused operation" sounds li
make some adjustments for?
> >
> > I know of nothing relevant that has changed on the sourceware side.
> >
> >> sign_and_send_pubkey: signing failed: agent refused operation
> >> mse...@gcc.gnu.org: Permission denied (publickey).
> >> fatal: Could not re
ivate keys?
Yes.
Is this a transient glitch or has something changed recently that I
need to make some adjustments for?
I know of nothing relevant that has changed on the sourceware side.
sign_and_send_pubkey: signing failed: agent refused operation
mse...@gcc.gnu.org: Permission d
ging in from the same workstation with access to the same
> set of ssh private keys?
>
> > Is this a transient glitch or has something changed recently that I
> > need to make some adjustments for?
>
> I know of nothing relevant that has changed on the sourceware side.
>
ent glitch or has something changed recently that I
> need to make some adjustments for?
I know of nothing relevant that has changed on the sourceware side.
> sign_and_send_pubkey: signing failed: agent refused operation
> mse...@gcc.gnu.org: Permission denied (publickey).
> fata
git pull from the GCC and Glibc repos is failing for me with the error
below. It worked fine last week and I haven't made any changes to my
ssh keys.
Is this a transient glitch or has something changed recently that I
need to make some adjustments for?
sign_and_send_pubkey: signing f
On Thu, 7 Nov 2019 at 07:52, Ajumal Abdul Majeed wrote:
>
> Hi,
> I was trying to build GCC and "make all" is failing. Please find the
> config.log below and kindly help me to rectify this issue.
Please use the correct mailing list i.e. gcc-help
https://gcc.gnu.org/lists.html
When you send an em
5 or later
configure:6020: gcc -o conftest -g -O2 -lisl -lmpc -lmpfr -lgmp
conftest.c -lisl -lgmp >&5
conftest.c:10:10: fatal error: isl/schedule.h: No such file or directory
#include
^~~~
compilation terminated.
configure:6020: $? = 1
configure: failed progra
error: C compiler cannot create executables
See `config.log' for more details.
Makefile:11774: recipe for target 'configure-target-libbacktrace' failed
make[1]: *** [configure-target-libbacktrace] Error 1
make[1]: Leaving directory '/export2/src/gcc-8.0.0/gcc-8.0.0_build'
nfigure: error: in
> `/export2/src/gcc-8.0.0/gcc-8.0.0_build/nvptx-none/libbacktrace':
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> Makefile:11774: recipe for target 'configure-target-libbacktrace' failed
> make[1]:
#x27;:
configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:11774: recipe for target 'configure-target-libbacktrace' failed
make[1]: *** [configure-target-libbacktrace] Error 1
make[1]: Leaving directory '/export2/src/gcc-8.0.0/gcc-8.0.0
On 03/17/2017 05:51 PM, Jim Wilson wrote:
On 03/17/2017 04:12 PM, Jim Wilson wrote:
I have access to a fast box that isn't otherwise in use at the moment so
I'm taking a look. r246225 builds OK. r246226 does not. So it is
Bernd's combine patch. A little experimenting shows that the compare
d
On 03/17/2017 04:12 PM, Jim Wilson wrote:
I have access to a fast box that isn't otherwise in use at the moment so
I'm taking a look. r246225 builds OK. r246226 does not. So it is
Bernd's combine patch. A little experimenting shows that the compare
difference is triggered by the use of -gtogg
On 03/17/2017 03:28 PM, Jeff Law wrote:
On 03/17/2017 03:31 PM, Andrew Pinski wrote:
On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt
wrote:
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
On 03/17/2017 03:31 PM, Andrew Pinski wrote:
On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote:
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt wrote:
> On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
>>
>> One of the following revision caused a bootstrap comparison failure on
>> aarch64-linux-gnu:
>> r246225
>> r246226
>> r246227
>
>
> Can you help narrow that down?
I can though I don't want
On 03/17/2017 12:47 PM, Bernd Schmidt wrote:
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
I'm provisioning an aarch64 system now.
jeff
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
Bernd
: Friday, March 17, 2017 11:00 AM
To: Pinski, Andrew
Subject: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267
--
rm -f stage_current
make[3]: Leaving directory
'<http://toolchain-releases.caveonetworks.com:
W dniu 2016-10-07 o 11:15, Richard Biener pisze:
> On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
>> Hello.
>> I just starting their adventure with the GNU GCC.
>> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
>> In an environment Msys2 under Windows 10.
>> Configuration
W dniu 2016-10-07 o 11:15, Richard Biener pisze:
> On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
>> Hello.
>> I just starting their adventure with the GNU GCC.
>> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
>> In an environment Msys2 under Windows 10.
>> Configuration
On Fri, Oct 7, 2016 at 10:17 AM, Marcin Noga wrote:
> Hello.
> I just starting their adventure with the GNU GCC.
> Successfully compiled binutils and gcc 6.2.0 for FR30-elf target.
> In an environment Msys2 under Windows 10.
> Configuration binutils:
>
> ../../src/binutils-2.27/configure --target=
when it shouldn't.
# FreeBSD 6.1 mkdir -m -p sets mode of existing directory.
ls_ld_tmpdir=`ls -ld "$tmpdir"`
case $ls_ld_tmpdir in
d-?r-*) different_mode=700;;
d-?--*) diff
From a diagnostics point-of-view, neither version is quoted:
c/c-parser.c: error_at (assert_loc, "static assertion failed: %E", string);
cp/semantics.c: error ("static assertion failed: %s",
To be "quoted", it would need to use either %q or %<%>. Note t
On 13/07/16 14:26, Thomas Schwinge wrote:
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static as
On 07/13/2016 07:26 AM, Thomas Schwinge wrote:
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static as
Hi!
I had recently noticed that given:
#ifndef __cplusplus /* C */
_Static_assert(0, "foo");
#else /* C++ */
static_assert(0, "foo");
#endif
..., for C we diagnose:
[...]:2:1: error: static assertion failed: "foo&quo
On Fri, Nov 21, 2014 at 7:23 AM, Markus Trippelsdorf
wrote:
> On 2014.11.21 at 16:16 +0100, Toon Moene wrote:
>> See: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02259.html
>>
>> What's not in the log file sent to gcc-results:
>
> See: http://thread.gmane.org/gmane.comp.gcc.patches/327449
>
On 2014.11.21 at 16:16 +0100, Toon Moene wrote:
> See: https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg02259.html
>
> What's not in the log file sent to gcc-results:
See: http://thread.gmane.org/gmane.comp.gcc.patches/327449
--
Markus
with -fPIC
/dev/shm/wd4296/ccFei5Gg.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:409: recipe for target 'libcc1.la' failed
make[3]: *** [libcc1.la] Error 1
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 2
Hello.
After updating gcc from 4.7.3 to 4.7.4 on our illumos distribution
(OpenIndiana Hipster) I can't longer compile clang.
Compilation fails with
llvm[5]: Compiling CIndexCodeCompletion.cpp for Release+Asserts build (PIC)
llvm[5]: Linking Release+Asserts executable clang-check (without sym
On 7 August 2013 14:10, David Edelsohn wrote:
> The same error occurs on AIX because the tests are run without pthreads.
We moved the thread to the libstdc++ list, where I pointed out that
is missing the "#pragma GCC system_header" that
would suppress the warnings.
The same error occurs on AIX because the tests are run without pthreads.
- David
On Wed, Aug 7, 2013 at 6:22 AM, Bin.Cheng wrote:
> Hi,
> I spotted case ext/headers.cc failed on arm-none-eabi with below information:
>
> In file included from
> /home/build/work/gcc-build/arm-no
Hi,
I spotted case ext/headers.cc failed on arm-none-eabi with below information:
In file included from
/home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0,
from
/home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3
>> >>
>
> ...
>
>> >>
>> >> But when I do the test for a case with a little change, it is failed to
>> >> generate MAX_EXPR in phiopt1.
>> >> The failed case2 :
>> >> int foo(short a ,short b)
>> >> {
>&
Hi,
On Sun, Nov 04, 2012 at 09:32:48PM -0800, Handong Ye wrote:
> On Sun, Nov 4, 2012 at 2:13 PM, Martin Jambor wrote:
> > On Sat, Nov 03, 2012 at 09:01:53AM +, Yangyueming wrote:
> >> Hi, all
> >>
...
> >>
> >> But when I do the test for
nt D.2094;
>>
>> :
>> a_9 = MAX_EXPR ;
>> D.2094_5 = (int) a_9;
>> return D.2094_5;
>>
>> }
>>
>> But when I do the test for a case with a little change, it is failed to
>> generate MAX_EXPR in phiopt1.
>> The failed case
I know it , thanks.
-邮件原件-
发件人: Martin Jambor [mailto:mjam...@suse.cz]
发送时间: 2012年11月5日 6:14
收件人: Yangyueming
抄送: gcc@gcc.gnu.org
主题: Re: [help]failed to generate PHI NODE in esra pass.
Hi,
On Sat, Nov 03, 2012 at 09:01:53AM +, Yangyueming wrote:
> Hi, all
>
> I do the re
}
>
> It is successed in pass phiopt1(-O2 with gcc 4.7.0). The MAX_EXPR can be
> generated.
>
> foo (short int a, short int b)
> {
> int D.2094;
>
> :
> a_9 = MAX_EXPR ;
> D.2094_5 = (int) a_9;
> return D.2094_5;
>
> }
>
> But when
int D.2094;
:
a_9 = MAX_EXPR ;
D.2094_5 = (int) a_9;
return D.2094_5;
}
But when I do the test for a case with a little change, it is failed to
generate MAX_EXPR in phiopt1.
The failed case2 :
int foo(short a ,short b)
{
int c;
if (a < b)
a = b;
c = *(int *)&a;
retu
2012/4/26 Peter A. Felvegi:
> On 04/23/2012 08:20 PM, Jonathan Wakely wrote:
>>
>> Please check it's not http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926
>> first
>
> Hello,
>
> it seems to be the same issue, quite dated, though.
Yes, we have a number of long-standing bugs to do with
access-check
On 04/23/2012 08:20 PM, Jonathan Wakely wrote:
On 23 April 2012 18:48, Ian Lance Taylor wrote:
"Peter A. Felvegi" writes:
Should I file a bug report?
Yes, please. Thanks.
Please check it's not http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 first
Hello,
it seems to be the same issue, q
On 23 April 2012 18:48, Ian Lance Taylor wrote:
> "Peter A. Felvegi" writes:
>
>> Should I file a bug report?
>
> Yes, please. Thanks.
Please check it's not http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 first
"Peter A. Felvegi" writes:
> Should I file a bug report?
Yes, please. Thanks.
Ian
Hello,
clang gave an error on a code that compiled with gcc so far. The reduced
test case is:
8<8<8<8<---
class V;
struct E
{
E(const V& v_);
char* c;
V* v;
int i;
};
class V
{
private:
union {
char* c;
struct {
V* v;
int i;
};
};
};
E::E(const V& v_) :
c(v_.c), // line 25
On 09/08/2011 05:38 PM, Jonathan Wakely wrote:
>
> the pdf size is 4MB. maybe that is the problem.
Please use some common sense before forwarding a 100KB message to the
mailing list, where it gets sent to hundreds of people. It would only
have taken you a few seconds to remove the base64-enco
On 8 September 2011 10:00, Xiangfu Liu wrote:
> On 09/08/2011 12:11 PM, Joe Buck wrote:
>>
>> On Wed, Sep 07, 2011 at 08:08:01PM -0700, Xiangfu Liu wrote:
>>>
>>> > Hi
>>> >
>>> > I got the pdf file. and I also sent out the papers by postal mail.
>>> > where is the pdf file I should send to?
>>
On 09/08/2011 12:11 PM, Joe Buck wrote:
On Wed, Sep 07, 2011 at 08:08:01PM -0700, Xiangfu Liu wrote:
> Hi
>
> I got the pdf file. and I also sent out the papers by postal mail.
> where is the pdf file I should send to?
>
> I have tried:
> copyright-cl...@fsf.org ass...@gnu.org
>
> and
On Wed, Sep 07, 2011 at 08:08:01PM -0700, Xiangfu Liu wrote:
> Hi
>
> I got the pdf file. and I also sent out the papers by postal mail.
> where is the pdf file I should send to?
>
> I have tried:
>copyright-cl...@fsf.org ass...@gnu.org
>
> and I don't know Donald R. Robertson's email addres
On Mon, 22 Aug 2011, Toon Moene wrote:
After studying this a bit more, I almost convinced this is due to the upgrade
of Debian Testing I did at 12:15 UTC, Sunday the 21st of August.
Apparently, the install of libc6-2.13-16 does some evil things to the
/usr/include/bits directory ...
Ah, the
On 08/21/2011 08:19 PM, Toon Moene wrote:
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02361.html
The configure line is:
../gcc/configure \
--prefix=/tmp/lto \
--enable-languages=c++ \
--with-build-config=bootstrap-lto \
--with-gnu-ld \
--disable-multilib \
--disable-nls \
--with-arc
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg02361.html
The configure line is:
../gcc/configure \
--prefix=/tmp/lto \
--enable-languages=c++ \
--with-build-config=bootstrap-lto \
--with-gnu-ld \
--d
On 25 May 2011 06:29, Toon Moene wrote:
> See: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg02723.html
>
> The failure is caused by this (from
> ../x86_64-unknown-linux-gnu/libgcc/config.log):
>
> configure:3246: checking for suffix of object files
> configure:3268: /home/toon/compilers/obj-t/.
See: http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg02723.html
The failure is caused by this (from
../x86_64-unknown-linux-gnu/libgcc/config.log):
configure:3246: checking for suffix of object files
configure:3268: /home/toon/compilers/obj-t/./gcc/xgcc
-B/home/toon/compilers/obj
-t/./gcc/ -
Mingjie Xing wrote:
> 2011/2/18 Fu, Chao-Ying :
> > I think your analysis is correct. We should just delete
> mips_order_regs_for_local_alloc()
> > in mips.c and delete ADJUST_REG_ALLOC_ORDER in mips.h.
> > Then, 3 accumulators can be used in dspr2-MULT.c and
> dspr2-MULTU.c now. Thanks!
>
> /
2011/2/18 Fu, Chao-Ying :
> I think your analysis is correct. We should just delete
> mips_order_regs_for_local_alloc()
> in mips.c and delete ADJUST_REG_ALLOC_ORDER in mips.h.
> Then, 3 accumulators can be used in dspr2-MULT.c and dspr2-MULTU.c now.
> Thanks!
/* ADJUST_REG_ALLOC_ORDER is a ma
Chung-Lin Tang wrote:
> I analyzed this testcase regression a while earlier; the
> direct cause of
> this is due to mips_order_regs_for_local_alloc(), which now serves as
> MIPS' ADJUST_REG_ALLOC_ORDER macro.
>
> The mips_order_regs_for_local_alloc() function seems to be written for
> the old loc
1 - 100 of 272 matches
Mail list logo
