->
Re: dict slice in python (translating perl to python)
gcc-bugs
<-- Thread -->
<-- Date -->
Re: dict slice in python (translating perl to python)
B
Wed, 10 Sep 2008
Hi, viсtim.
I write yоu beсausе I рut а malwаre оn thе web раgе with pоrn whiсh you have
visited.
My virus grabbеd аll yоur реrsоnаl info аnd turnеd оn your саmеra which
captured thе process оf your оnаnism. Just аfter thаt thе soft saved your
соntаct list.
I will delete thе соmpromising vidеo a
;, state, BRACKETS);
break;
default: ;
}
printf("State %d btw GENERAL %d\n", state, GENERAL);
}
printf("If you see this then something is really wrong.\n");
exit(4);
}
int main() {
//These don't seem to matter don't concern yourself with them
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@odd-e.com
Target Milestone: ---
This bug is a similar bug as an earlier reported in clang:
https://bugs.llvm.org/show_bug.cgi?id=15541
When having the overloaded new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #2 from Bas Vodde ---
Oh wow, does this mean that it is the choice of the compiler to actually call
an overloaded operator new ?
That is interesting. Thanks.
I'd still consider it highly surprising behavior, at least it was for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #4 from Bas Vodde ---
The newCalled to true in the example was the simplest way to show the behavior.
This bug came up in a open source project called CppuTest. This has the
functionality to detect memory leaks and does so by overlo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #5 from Bas Vodde ---
In the case we found this, it mostly uses the overload for accounting and thus
it doesn't cause a serious problem ('just' a test failure).
If you use the overloaded new/delete for providing your own memory mana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #9 from Bas Vodde ---
Hi Jonathan,
You are right, I was drawing much too many conclusions there. I should have
waited with that comment until I slept :) Sorry for that. And it has been a
while since I read the proposal, it has been
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@odd-e.com
G++ on MacOsX acts different when enabling the new c++11 related to operator
new overloads. If I compile the following code:
#include "stdlib.h"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
--- Comment #3 from Bas Vodde ---
Thanks for the comments. I understand the problems in implementing a compiler,
when this is also unclear in the language itself.
Whatever is decided related to this, it would probably be a good idea to give a
be
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@miller-mohr.de
Hi,
when I try to compile the code below I receive an internal compiler error. The
idea of the test case is to have a base class with a type-bound
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450
--- Comment #5 from b...@miller-mohr.de ---
(In reply to janus from comment #4)
> (In reply to janus from comment #2)
> > Draft patch which fixes the error (not regtested):
>
> Does regtest cleanly.
Hi,
just wanted to say thanks
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@miller-mohr.de
Created attachment 31470
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31470&action=edit
Error messages from gfortran 4.9.0
Hi,
this is a fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59450
--- Comment #9 from b...@miller-mohr.de ---
Hi,
verified that the ICE is gone in gcc version 4.9.0 20131217 (experimental).
Thanks a lot. However, there is still a problem. As it is no longer an ICE I
filed a new bug 59547
Cheers
Marcus
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.gier...@b-tu.de
Target Milestone: ---
On x86-64 all versions of gcc compile a sequentially consistent atomic store as
'mov + mfence'. Both clang and icc on the
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b...@michael-lossin.de
Target Milestone: ---
> cat x.cc
#include
struct A
{
int value = 42;
A & inc() { ++value; return *this; }
};
int main()
{
{
A a;
std::cout << A(a).inc().value <
Please resolve the following gcc / g++ compiler error in
/usr/include/c++/3.2.3/bits/fstream.tcc
In file included from /usr/include/c++/3.2.3/fstream:576,
/usr/include/c++/3.2.3/bits/fstream.tcc: In member function `virtual
_Traits::pos_type std::basic_filebuf<_CharT,
_Traits>::seekoff(_Traits::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544
Frédéric Leroy changed:
What|Removed |Added
CC||frederic.le...@b-com.com
--- Comment
--- Comment #8 from burnus at net-b dot de 2006-04-27 08:09 ---
Subject: Re: gfortran: Warn/abort when format in write
does not fit passed arguments
(In reply to comment #7)
> Tobias, I hope this is what you were looking for. I don't really
think we need
> a compile
--- Comment #5 from francois at b-powers dot be 2009-02-19 13:10 ---
Any update on this bug ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38479
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91841
Bernard B changed:
What|Removed |Added
CC||b-gccbugzilla@largestprime
--- Comment #5 from burnus at net-b dot de 2010-03-03 16:59 ---
Subject: Re: [4.5 Regression] Missing array temp for DT
with pointer component
On 03/03/2010 04:53 PM, Paul Richard Thomas wrote:
> Yet another in the series :-) I hope that it is the last...
>
S
--- Comment #6 from burnus at net-b dot de 2006-10-22 21:03 ---
See http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01086.html for a preliminary
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24790
The following code is miscompiled when using -m64 (=ppc64) target:
const static double a = 1.0;
const static double *b = (double*)&a - 1;
&b[1] should be &a, but it's not - there is an additional offset of 0x1
--
Summary: miscompiled initialization of a
--- Comment #1 from inbox at b-q-c dot com 2006-06-28 20:44 ---
Created an attachment (id=11774)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11774&action=view)
test case - returns 0 on success or 1 when miscompiled
gcc -m64 -o gcc64bug gcc64bug.c
Inspection of the a and
--- Comment #2 from inbox at b-q-c dot com 2006-06-28 20:47 ---
The original description should state that there is an additional offset of
0x1 (it said 0x1 instead).
Also this bug is reproducible with earlier version of gcc such as 4.0.1 as
supplied by Apple.
--
http
--- Comment #3 from inbox at b-q-c dot com 2006-06-28 20:50 ---
Created an attachment (id=11775)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11775&action=view)
output of gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28196
--- Comment #2 from b dot gunreben at web dot de 2005-11-09 07:07 ---
Another testcase, fails with gcc -O2 -c, same compiler as above:
typedef long
(*bla)(int *node);
static long F2(void *tree, long blk, bla after_node_func)
{
long call_result = 0;
int *node;
if (call_result
g
ReportedBy: b dot gunreben at web dot de
GCC host triplet: hppa2.0-suse-linux
GCC target triplet: hppa2.0-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
--- Comment #1 from b dot gunreben at web dot de 2007-07-25 08:20 ---
Created an attachment (id=13971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13971&action=view)
testcase x.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32889
--- Comment #2 from b dot gunreben at web dot de 2007-07-25 08:26 ---
just to add some more information:
# gcc -v
Using built-in specs.
Target: hppa2.0-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
r 2
--
Summary: Compilation error while compiling DynCommon.cpp
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
Repor
--- Comment #1 from pinakee dot b at xius dot com 2007-09-18 05:08 ---
Created an attachment (id=14217)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14217&action=view)
The file is where the compilation error is coming.
The attachment is the file where the compilation e
--- Comment #2 from pinakee dot b at xius dot com 2007-09-18 07:05 ---
Created an attachment (id=14218)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14218&action=view)
The attachment is the zip of preprocessed file of the source file.
Since the file size was more th
d of -O2.
Adding preprocessed dcigettext.i, to reproduce, run
gcc -O2 -c dcigettext.i
--
Summary: can't find a register in class 'R1_REGS' while reloading
'asm'
Product: gcc
Version: 4.3.0
Status: UNCONFIR
--- Comment #1 from b dot gunreben at web dot de 2008-02-14 13:28 ---
Created an attachment (id=15148)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15148&action=view)
preprocessed dcigettext.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Bug #: 56715
Summary: Explicit Reg Vars are being ignored for consts when
using g++
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
--- Comment #2 from Goswin von Brederlow 2013-03-25
00:07:19 UTC ---
(In reply to comment #1)
> const is a bit special in C++, it can be used as part of a const integer
> expression which is what is happening here.
How does that make it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56715
Goswin von Brederlow changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #20 from Goswin von Brederlow ---
So it's been a year since my last comment. Is this dead or is someone still
working on it? It would be a nice addition to gcc.
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Build: arm-none-eabi
I have a uint64_t free running counter with a frequenzy of 1Mhz and I want to
print
Severity: enhancement
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
The online docs do not mention what version of the compiler they document. When
something
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
https://gcc.gnu.org/onlinedocs/gccint/Collect2.html says when collect2 is used
it generates a temporary file listing the constructors and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699
--- Comment #4 from Goswin von Brederlow ---
Yes, a simple statement like that was exactly what I had in mind.
: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I'm building a bare-metal kernel for a Raspberry Pi 2 (armv7) in c++. At some
point this failed with "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199
--- Comment #2 from Goswin von Brederlow ---
That fixes it. Isn't it a gcc bug though not to detect that itself?
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: arm-none-eabi
I&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65252
--- Comment #2 from Goswin von Brederlow ---
As long as it's only one C/C++ file that works. But if one has multiple files
then -fno-lto would optimize less. I was thinking of a more general case than
mine.
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
CC: goswin-v-b at web dot de
Created attachment 34911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34911&a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65262
--- Comment #2 from Goswin von Brederlow ---
The linker script is only there because the default script combines all .text.*
into one hiding the effect. One could use different section names that the
default script does not combine and work witho
--- Additional Comments From b dot gunreben at web dot de 2005-07-19 16:50
---
I did some more tests and it looks like --disable-checking also disables the
bug. At least --enable-checking was enough to reproduce it. My latest
configuration with this bug was
Configured with
sed source.
--
Summary: internal compiler error: in simplify_subreg
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
Reporte
--- Comment #1 from b dot gunreben at web dot de 2010-06-18 15:32 ---
Created an attachment (id=20939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20939&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy
rgn.c:2549
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
CC: gcc-bugs at gcc dot gnu do
--- Additional Comments From b dot gunreben at web dot de 2005-04-20 14:13
---
Created an attachment (id=8688)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8688&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21122
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot gunreben at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: hppa-suse-linux-gnu
GCC host triplet: hppa-suse-linux-gnu
GCC target triplet: hppa-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
--- Additional Comments From b dot gunreben at web dot de 2005-04-20 14:28
---
Created an attachment (id=8689)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8689&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
--- Additional Comments From b dot gunreben at web dot de 2005-04-22 08:01
---
I just tested on a compiler without additional patches at all. The version is
g++ (GCC) 4.0.0 20050415, means CVS from april 15th. I still get the same bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #13 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #12)
> (In reply to Goswin von Brederlow from comment #11)
> > I think the design is fundamentally lacking in the following points:
> >
> > 1. interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #15 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #14)
> (In reply to Goswin von Brederlow from comment #13)
> > > > Secondly why pass error_code as argument if is already on the stack and
> > > > could be accessed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66960
--- Comment #17 from Goswin von Brederlow ---
(In reply to H.J. Lu from comment #16)
> (In reply to Goswin von Brederlow from comment #15)
>
> > > No. We only do it for data pushed onto stack by CPU.
> >
> > I was thinking of something like:
>
itical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: b dot krumboeck at rewe-group dot at
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
--- Comment #1 from b dot krumboeck at rewe-group dot at 2007-03-07 12:33
---
Created an attachment (id=13161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13161&action=view)
example code to reproduce the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31069
--- Comment #3 from b dot krumboeck at rewe-group dot at 2007-03-07 15:27
---
Oh, you're right! Thank you!
I tried to debug for 3 days, without success.
Linux, HPUX, GCC 4.X and GCC 3.4.2, .
You are a hero!
Once again, thank you very much.
PS: Sorry for wasting your time.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
GCC build triplet: x86_64-linux
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2008-11-22
13:33 ---
Created an attachment (id=16748)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16748&action=view)
Minimal testcase
Compile with amd64 compiler without optimizations and run it.
Expected: Nu
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2008-11-23
21:11 ---
Patch seems to fix the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2008-12-02
09:08 ---
Created an attachment (id=16806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16806&action=view)
testcase
Testcase that should return '1 2 3 4 5 6 7', but on my computer retur
tedBy: m dot b dot lankhorst at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38366
--- Comment #3 from grant dot b dot edwards at gmail dot com 2009-01-05
19:40 ---
I've just run across the exact same problem using 3.4.4 to build an arm-elf
3.2.1 cross-compiler on Cygwin. Building the same exact same compiler using
3.4.6 on Linux works fine, so it appears
combination with -Os
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
GCC build triplet: i6
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2006-07-26
17:42 ---
Created an attachment (id=11949)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11949&action=view)
The source mentioned in description
Source that won't compile
--
http://gcc.gnu.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: riki--b at hotmail dot it
Target Milestone: ---
Created attachment 50621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50621&action=edit
Preprocessed sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127
--- Comment #2 from Riccardo Brugo ---
(In reply to Iain Sandoe from comment #1)
> I think that this issue is already fixed in the released 10.3 branch and in
> master (will shortly become GCC11). Please could you try one of those?
>
> $ ./gcc
NCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: paulg-b at web dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc
By: m dot b dot lankhorst at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
ng float arguments incorrectly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot b dot lankhorst at gmail dot com
G
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2010-04-23
18:38 ---
Created an attachment (id=20474)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20474&action=view)
testcase
testcase that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43869
--- Comment #4 from m dot b dot lankhorst at gmail dot com 2010-04-25
14:41 ---
Created an attachment (id=20483)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20483&action=view)
Patch that fixes the testcase
It appears that SSE_REGPARM_MAX will change based on ix86_c
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Trying to access a pointer cast from an integer literal gives a out of bounds
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #29 from Goswin von Brederlow ---
(In reply to Jakub Jelinek from comment #26)
> That is nonsense. The amount of code in the wild that relies on (type
> *)CONSTANT
> working is insane, you can't annotate it all. And it has worked f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
--- Comment #38 from Goswin von Brederlow ---
(In reply to Jonathan Wakely from comment #34)
> (In reply to Goswin von Brederlow from comment #29)
> > There is no garantee in the C standard that '(type *)CONSTANT' will actually
> > point to the h
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
In the embedded and micro controller world memory mapped registers are very
common. They can be declared as external object and fudged
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
I'm trying to compute (a*a)%n for uint64_t types on x86_64 using "gcc -O2 -W
-Wall" like this:
#include
#include
uint64_t sqrmod(uint64_t a, uint64_t n) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105521
--- Comment #3 from Goswin von Brederlow ---
(In reply to Andrew Pinski from comment #1)
> This requires having a, 64bit/32bit (and 128bit/64bit) pattern really. So
> this is both a middle-end issue and a target issue.
>
> Note there might be a
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goswin-v-b at web dot de
Target Milestone: ---
Running "gcc-12.1 -std=c++20 -O2 -W -Wall" on
#include
constinit int t = std::lcm(50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #2 from Goswin von Brederlow ---
I know the patch doesn't work yet, the static_asserts aren't constexpr. But
hopefully it gives someone enough of an idea to fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105844
--- Comment #3 from Goswin von Brederlow ---
Created attachment 53082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53082&action=edit
Working patch for detecting UB
This will abort if the arguments are too large instead of static_assert,
us: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2008-11-17
20:15 ---
Subject: Re: [4.4 regression] #elif breaks
Yes, I should have read the #36320 text more carefully. I merely
noticed that its empty #elif cannot expand to anything correct, while
my example can (and
UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40530
[This is both a C and C++ bug report, not sure how to classify that.]
int a[256];
int A(char c) { return a[c]; } // C and C++ warnings, OK.
int D(void) { return a['%'];} // Spurious C++ warning, no C warning
int B(void) { return a['å'];} // C++ warning, mis
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-10-14
17:06 ---
Subject: Re: Issues with -Wchar-subscripts
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29455
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-10-14
17:52 ---
Subject: Re: Issues with -Wchar-subscripts
Sorry about the empty answer.
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning there
--- Comment #5 from h dot b dot furuseth at usit dot uio dot no 2006-10-17
12:49 ---
Subject: Re: Issues with -Wchar-subscripts
pinskia at gcc dot gnu dot org writes:
> 'a' in C is not of the type char but instead int so not warning
> there is correct really.
How
oduct: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i686-pc-linux-gnu
GCC ho
--- Comment #22 from h dot b dot furuseth at usit dot uio dot no
2007-08-20 22:45 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
manu at gcc dot gnu dot org writes:
> But it seems that the current policy of GCC is to not assume that such
> fun
1 - 100 of 116 matches
Mail list logo
