Karamursel / KOCAELi - YALOVA arasinda, yalova-izmit otoyoluna 150 metre
mesafede ACELE SATILIK 700 metre kare arsa uzerinde 300 metre kare uzerine
kurulu 4 katli bina.
6 daire, 2 dukkan, catida 2 oda ve teras, deniz ve dag manzarali, otel,
pansiyon, yurt, hastane icin elverisli, depr
friendly reminder
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-bugs@gcc.gnu.org
Domain shankarelectricals.com has exceeded the max emails 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:
bou...@powweb.com
(generated from orientat...@huntadventures.ca)
There is no
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:
bou...@homestead.com
(generated from stepha...@stratfordccc.org)
There is no
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:
bou...@homestead.com
(generated from no-re...@homefixcyprus.com)
There is no
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:
danstein...@gmail.com
SMTP error from remote mail server after end of data
follows -
553 5.3.5 [127.0.0.1] config error: mail loops back to me (MX problem?)
554 5.3.5 Local configuration error
550 5.1.1 postmaster... User unknown
Reporting-MTA: dns; mail57c45.carrierzone.com
Received-From-MTA: DNS; cpe-et001203.cust.jaguar-network.net
Arrival-Date: Tue, 19 May 2015 08:41:31
The following message to was undeliverable.
The reason for the problem:
5.1.1 - Bad destination email address 'reject'
Reporting-MTA: dns; esa4.sitel.iphmx.com
Final-Recipient: rfc822;kate.spedding@sitel.co.uk
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp; 5.1.1 - Bad des
The original message was received at Tue, 19 May 2015 13:41:24 +0100
from localhost.localdomain [127.0.0.1]
- The following addresses had permanent fatal errors -
(reason: 550 5.7.1 Error: content rejected)
- Transcript of session follows -
... while talking to antispam
Your email with the subject "adjustment reminder " was NOT delivered to
ak...@jennison.com because it contains an attachment that cannot be verified by
the Jennison mail server and therefore was NOT delivered. The email is being
held on our servers and will be released once the rec
follows -
553 5.3.5 [127.0.0.1] config error: mail loops back to me (MX problem?)
554 5.3.5 Local configuration error
550 5.1.1 postmaster... User unknown
Reporting-MTA: dns; mail61c45.carrierzone.com
Received-From-MTA: DNS; cpe-et001203.cust.jaguar-network.net
Arrival-Date: Tue, 19 May 2015 08:41:14
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed permanently:
* karaughm...@chello.sk
Reporting-MTA: dns; edge02.upcmail.net [192.168.14.72]
Received-From-MTA: dns; gnu.org [85.31.195.58]
Arrival-Date: Tue, 19 May 2015 1
-in.l.google.com.:
>>> DATA
<<< 552-5.7.0 This message was blocked because its content presents a potential
<<< 552-5.7.0 security issue. Please visit
<<< 552-5.7.0 http://support.google.com/mail/bin/answer.py?answer=6590 to
review our
<<< 552 5.7.0 mess
This message was created automatically by the mail system (ecelerity).
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:
>>> qaqf6k84.6297...@bm-eng.com (after RCPT TO): 550-5.1.1 The emai
The following email message was blocked by an email content filter because it
may contain executable files. If you believe the message is business related,
please forward the blocked message to the Helpdesk Mailbox and request that the
message be released, or remove any inappropriate language
Not delivered to: [EMAIL PROTECTED]
user agent unavailable
Original-Envelope-Id: in*vsnl*rfc987;41859fb972e5000mimey2k
X400-Content-Identifier: 041101080017+053
Reporting-MTA: x400; /ADMD=VSNL/C=IN
DSN-Gateway: smtp; terminator1.vsnl.net.in
Final-Recipient: rfc822;
[EMAIL PROTECTED]
Actio
Not delivered to: [EMAIL PROTECTED]
bad address
Original-Envelope-Id: in*vsnl*rfc987;419ee9ca43a5000mimey2k
X400-Content-Identifier: 041120122258+053
Reporting-MTA: x400; /ADMD=VSNL/C=IN
DSN-Gateway: smtp; terminator1.vsnl.net.in
Final-Recipient: rfc822;
[EMAIL PROTECTED]
Action: failed
D
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-bugs@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 failed:
dennis.drisc...@verizon.net:
SMTP error from remote server for TEXT command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105512
Gerrit Albrecht changed:
What|Removed |Added
CC||m...@gerrit-albrecht.de
--- Comment #
rsion: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rilium at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38173
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickols_k at mail dot ru
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38310
--- Comment #1 from nickols_k at mail dot ru 2008-11-28 18:20 ---
Created an attachment (id=16791)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16791&action=view)
preprocessed input which causes ICE with -ftree-parallelize-loop=4
--
http://gcc.gnu.org/bugzilla/show_
normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: resume755 at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38501
--- Comment #1 from resume755 at mail dot ru 2008-12-12 01:42 ---
Created an attachment (id=16896)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16896&action=view)
demo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38501
--- Comment #4 from ivmai at mail dot ru 2009-06-25 10:31 ---
Bug confirmed in mingw-w64 gcc v4.5.0 (32-bit target).
Bug also observed in MinGW gcc v3.4.5 and v4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: comm_wolf at mail dot ru
GCC build triplet: i386-pc-mingw
GCC host triplet: i386-p
--- Comment #1 from comm_wolf at mail dot ru 2009-08-02 11:04 ---
Created an attachment (id=18285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18285&action=view)
Preprocessed sample source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40939
--- Comment #3 from comm_wolf at mail dot ru 2009-08-02 11:38 ---
Ok. I'll try it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40939
--- Comment #5 from comm_wolf at mail dot ru 2009-08-02 17:52 ---
Thanks for your advise.
After gcc recompilation (according to the currently trunk state) error was
disappeared. It seems like there is a bug in 'lambda' branch sources.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #13 from hidden_peak at mail dot ru 2005-11-27 16:41 ---
This is really bug in glibc: __cxa_finalize don't call all registered handlers
in case of NULL argument (glibc 2.2.5 has this bug, but 2.3.2 already not).
But nevertheless, the problem still present at plat
--- Comment #14 from hidden_peak at mail dot ru 2005-11-27 16:48 ---
Created an attachment (id=10348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10348&action=view)
__cxa_atexit and __cxa_finalize that work correctly
cxa.c contain code with __cxa_atexit and __cxa_finali
--- Comment #16 from hidden_peak at mail dot ru 2005-11-27 17:40 ---
Thanks for explanation. Link to this issue:
http://www.codesourcery.com/cxx-abi/abi.html#dso-dtor (for archive/reference
purposes).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24189
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28539
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28543
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bigwad at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28586
ty: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28588
nt32_t -> uint16_t without warrnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dushistov at ma
--- Comment #2 from dushistov at mail dot ru 2007-02-03 21:15 ---
(In reply to comment #1)
> I think this has already been fixed on the trunk with the new -Wconversion
> behaviors:
> http://gcc.gnu.org/wiki/NewWconversion
>
Thaks for reply,
I hope to see this feature in
P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hidden_peak at mail dot ru
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=31007
--- Comment #1 from hidden_peak at mail dot ru 2007-03-01 12:30 ---
> (instead of 7fff 7fff)
Correct should be fff and fff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31007
--- Comment #3 from hidden_peak at mail dot ru 2007-03-01 14:48 ---
~((1ULL << 63ULL) >> 3ULL):
( 0001 << 63) -> 8000 (unsigned!)
(8000 >> 3 ) -> f000 (due to sign bit)
~(f000 )
--- Comment #5 from hidden_peak at mail dot ru 2007-03-01 15:05 ---
Do you mean this treatment: ~((1ULL << 63ULL) >> 3ULL) -> ~(1ULL << 60ULL) ->
efff ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31007
--- Comment #6 from hidden_peak at mail dot ru 2007-03-01 15:11 ---
> Shifting unsigned numbers doesn't replicate the sign bit.
unsigned ui3 = ~((1 << 31) >> 3);
printf( "%x\n", ui3 );
give me wrong result fff ?
--
hidden_peak at mail do
--- Comment #7 from hidden_peak at mail dot ru 2007-03-01 15:13 ---
My mistake. Sorry.
--
hidden_peak at mail dot ru changed:
What|Removed |Added
Status
--- Comment #38 from hidden_peak at mail dot ru 2007-03-05 14:53 ---
(In reply to comment #37)
>
> Can I reproduce it on Linux?
>
May be comment #21 help you?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
tion in gcc/unwind-pe.h
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bland at mail dot ru
http://gcc.gnu.org/bugz
--- Comment #2 from bland at mail dot ru 2007-03-15 06:00 ---
I did not say that is bad. That is wrong and produces annoying warning.
Which can easily turn into error when reused in -Werror clean code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31180
: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mail at sebastianbauer dot info
GCC build triplet: x86_64
GCC host triplet: x86_64
GCC target triplet: x
--- Comment #1 from mail at sebastianbauer dot info 2007-03-21 07:14
---
Created an attachment (id=13240)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13240&action=view)
The simple test source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31291
--- Comment #2 from mail at sebastianbauer dot info 2007-03-21 07:15
---
Created an attachment (id=13241)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13241&action=view)
The output of the compiler invocation and the executable.
--
http://gcc.gnu.org/bugzilla/show_bug
NCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cyberflex at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32774
--- Comment #2 from cyberflex at mail dot ru 2007-07-16 09:42 ---
(In reply to comment #1)
> I think this was fixed in 4.3 by using the Eclipse source compiler.
>
Well, thnks.
This just need to be verified.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32774
o Ctrl+C SIGQUIT
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cyberflex at mail dot ru
GCC host triplet: arm_le, x86 -
--- Comment #2 from cyberflex at mail dot ru 2007-08-28 16:43 ---
(In reply to comment #1)
> Can you post a fully self contained test case? If I can easily reproduce it,
> I
> will try to fix it.
>
Test case is to be following, but reproducing looks like to be a bit t
--- Comment #6 from cyberflex at mail dot ru 2007-08-29 10:16 ---
(In reply to comment #4)
> Created an attachment (id=14129)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14129&action=view) [edit]
> Test case that works.
>
> With the new "Test case
--- Comment #7 from cyberflex at mail dot ru 2007-08-30 09:34 ---
Problem is reproducible, but it likely should be posted to other list.
It looks that behaviour of particular utility "rfcomm" is such specific that
it not only ignores some signals but also forks one mor
--- Comment #8 from cyberflex at mail dot ru 2007-08-30 09:34 ---
Created an attachment (id=14139)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14139&action=view)
test.java
test.java to run with bt_connect.bash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #9 from cyberflex at mail dot ru 2007-08-30 09:35 ---
Created an attachment (id=14140)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14140&action=view)
script bt_connect.bash
script to use with 14139: test.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #10 from cyberflex at mail dot ru 2007-08-30 09:36 ---
Created an attachment (id=14141)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14141&action=view)
one more helper script bt_param.bash
helper script for 14139: test.java
--
http://gcc.gnu.org/b
--- Comment #11 from cyberflex at mail dot ru 2007-08-30 09:41 ---
It looks that the fact that, rfcomm in some situations are killed when shell
script called with Proces.destroy() and in some situations don't
misleded me.
Also the strace shows that rfcomm sleep inside accept system
--- Comment #13 from cyberflex at mail dot ru 2007-08-31 09:42 ---
(In reply to comment #12)
> Does GCJ's behavior differ from Sun's in this test?
>
Well.. tried that (jdk1.6 i386)
Answer is: at this point NOT. So this is "not an issue"
But while performing
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: _kirpichev_ at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33374
--- Comment #1 from _kirpichev_ at mail dot ru 2007-09-10 07:45 ---
Created an attachment (id=14182)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14182&action=view)
test programm
This example is compiled incorrectly by gcc 4.1.2 with -O2 flag.
But all works fine if we
--- Comment #2 from _kirpichev_ at mail dot ru 2007-09-10 07:53 ---
Created an attachment (id=14183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14183&action=view)
Correct and incorrect assembler dumps.
>From incorrect dump we can see where segmentation fau
--- Comment #4 from _kirpichev_ at mail dot ru 2007-09-10 08:53 ---
There is no core dump with -fno-strict-aliasing.
But, our code is used by others who can not set this option.
Should code compiled without -fno-strict-aliasing produce core dump?
In my opinion, the best way is produce
ch is null reference!
--
Summary: GCC Allows null-references in C++
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #1 from rarut at mail dot ru 2008-09-11 11:45 ---
Generally reference members when used like this seem to behaive like pointers:
- have default constructor (making null reference)
- store garbage when when left uninitialized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
;
extern int feof (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern int ferror (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern void clearerr_unlocked (FILE *__stream) __attribute__ ((__nothrow__));
extern int feof_unlocked (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern int ferror_unlocked (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern void perror (__const char *__s);
# 1 "/usr/include/bits/sys_errlist.h" 1 3 4
# 27 "/usr/include/bits/sys_errlist.h" 3 4
extern int sys_nerr;
extern __const char *__const sys_errlist[];
# 823 "/usr/include/stdio.h" 2 3 4
extern int fileno (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern int fileno_unlocked (FILE *__stream) __attribute__ ((__nothrow__)) ;
# 842 "/usr/include/stdio.h" 3 4
extern FILE *popen (__const char *__command, __const char *__modes) ;
extern int pclose (FILE *__stream);
extern char *ctermid (char *__s) __attribute__ ((__nothrow__));
# 882 "/usr/include/stdio.h" 3 4
extern void flockfile (FILE *__stream) __attribute__ ((__nothrow__));
extern int ftrylockfile (FILE *__stream) __attribute__ ((__nothrow__)) ;
extern void funlockfile (FILE *__stream) __attribute__ ((__nothrow__));
# 912 "/usr/include/stdio.h" 3 4
# 4 "test.c" 2
void f(const char* str1, const char* str2)
{
const char* fmt = "Something is: %s, and something another is: %s\n";
const size_t buff_len = strlen(fmt) + strlen(str1) + strlen(str2) + 1;
char* buff = (char*)malloc(buff_len);
sprintf(buff, fmt, "Str1", "str2");
free(buff);
}
int main()
{
return 0;
}
--
Summary: Incorrect argument checking for printf: "format not a
string literal, argument types not checked", where it
can be checked
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rilium at mail dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
--- Comment #1 from rilium at mail dot ru 2008-10-31 02:11 ---
Created an attachment (id=16593)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16593&action=view)
Preproccessed file test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37975
normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvovsd at mail dot ru
GCC host triplet: openSuse 10.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rvovsd at mail dot ru
GCC host triplet: openSuse 10.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34893
--- Comment #3 from rvovsd at mail dot ru 2008-01-21 14:43 ---
This case is similar to the bug 31047
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047).
There Andrew Pinski wrote (comment 4):
>14.6.4.2/1 says this is invalid code.
>For a function call that depends on a te
6_64-pc-mingw32/libstdc++-v3/include/tr1_impl/type_traits:248:
error: redefinition of 'struct std::is_function<_Res ()(_ArgTypes ..., ...)>'
/usr/portage/local/overlays/build/x86_64-pc-mingw32/libstdc++-v3/include/tr1_impl/type_traits:231:
error: previous definition of 'struct std
--- Comment #3 from css20 at mail dot ru 2009-04-11 21:09 ---
> Are you sure your entire compiler is up to date, not just the library?
No.. it was not lasest snapshot (20090331).
> We solve this by setting up in gcc's source tree a symbolic link "winsup"
>
--- Comment #4 from css20 at mail dot ru 2009-04-12 08:50 ---
First tests of Win64 compiler.. simple source file test.c was created:
#include "windows.h"
int main(int argc, char **argv)
{
MessageBox(NULL, "test", "test", MB_OK);
}
E:\temp\test>gcc t
--- Comment #5 from css20 at mail dot ru 2009-04-12 19:35 ---
I see this bug in compiler driver is already known
(http://sourceforge.net/forum/forum.php?thread_id=3091795&forum_id=723797), it
works only with "-O0". I can't found report about this bug in databa
--- Comment #7 from css20 at mail dot ru 2009-04-13 08:11 ---
> Please make sure, that you have in your gcc source root directory the symbolic
> link "winsup" pointing to your prefix directory. Secondly, make sure you have
> the symbolic link "mingw" in you
--- Comment #9 from css20 at mail dot ru 2009-04-13 15:48 ---
> Do you use for native toolchain an fresh initialized directory?
> Which version of toolchain you are using (especially header-set)?
> Do you use --prefix and --with-sysroot options?
I use directory with mingw-6
--- Comment #10 from css20 at mail dot ru 2009-04-13 18:06 ---
I try to build gcc with latest CRT from svn (revision 764) - build is OK. It
seems, snapshot from sourceforge download page(November 15, 2008) not
compatible with gcc 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Hi, gcc crashes given the following example, while clang compiles normally.
$ cat 1.cpp
template struct X {};
namespace Nested {
template int f1(X... a);
int a1 = f1(X(), X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93642
Egor Suvorov changed:
What|Removed |Added
CC||egor_suvorov at mail dot ru
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: akobets at mail dot ru
Target Milestone: ---
gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu1)
Test file:
===
void test()
{
}
===
Buld:
i686-linux-gnu-gcc -c -fno-PIC -mno-mmx -mno-sse -O2 -fomit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95112
--- Comment #2 from Alexander Kobets ---
Yes, that it.
I am not sure, that CF must be enabled by default, at your discretion.
Thank you.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
The following test case fails to compile in C++11 mode:
#include
#include
#include
void foo()
{
typedef std::istream_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304
fsmoke changed:
What|Removed |Added
CC||fsmoke at mail dot ru
--- Comment #6 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63359
andysem at mail dot ru changed:
What|Removed |Added
CC||andysem at mail dot ru
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
Currently, __atomic_thread_fence(seq_cst) on x86 and x86-64 generates mfence
instruction. A dummy atomic instruction (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #2 from andysem at mail dot ru ---
gcc 10.1 only optimizes __atomic_store_n(seq_cst) to xchg, but not the fence.
Also, consider applying the same optimization to __sync_synchronize().
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
ARMv8.3-RCPC extension adds new ldapr[b/h] instructions for Load-AcquirePC
semantics that better matches C++ memory order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #5 from andysem at mail dot ru ---
> Please also read [1] why we avoid -4(%%esp).
I believe, memcheck would complain because the value at -4(%%rsp) would be
uninitialized. This is unfortunate. The workaround could be to initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
--- Comment #6 from andysem at mail dot ru ---
Also, I think (%%rsp) can be rather far from the top of the stack if the stack
frame is large. This may mean it's less likely to be in data cache. Having a
dummy variable ensures that it is clo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117
fsmoke changed:
What|Removed |Added
CC||fsmoke at mail dot ru
--- Comment #4 from
: unassigned at gcc dot gnu.org
Reporter: Khram at mail dot ru
Target Milestone: ---
Memmove has a mistake. Need like this:
char* memmove( char *A, char *B, int L )//! странности из GCC-10.1
{ char *res=A; if( A>B )while( L-->0 )*A++=*B++; else
{ A+=L; B+=L; while(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337
--- Comment #13 from andysem at mail dot ru ---
I think, this inliner change needs to be reverted. People expect -O2 to produce
decently optimized binaries, and starting with gcc 10.x it doesn't deliver. -O3
traditionally enabled optimiza
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
g++ crashes on the following code, while clang++ compiles successfully:
$: cat s.cpp
struct A {};
template
struct B
{
A a;
friend decltype(a);
};
int
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Please consider the following code. Clang++ compiles it successfully, while g++
fails:
$: cat s.cpp
struct a{};
template struct b {
using c=a;
};
class B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445
Alexander Karzhenkov changed:
What|Removed |Added
CC||karzh at mail dot ru
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445
--- Comment #4 from Alexander Karzhenkov ---
r269667 concerns initializing an object from prvalue.
Here we have `Target` being initialized from lvalue if type `Source`.
What we can consider as being initialized from prvalue is the argument of co
1 - 100 of 1044 matches
Mail list logo
