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,
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
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
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=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
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=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
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
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
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
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
: 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
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
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
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 #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 #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.
: 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=91841
Bernard B changed:
What|Removed |Added
CC||b-gccbugzilla@largestprime
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
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
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 <
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.
;, 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
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
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:
>
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 #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
Goswin von Brederlow changed:
What|Removed |Added
CC||goswin-v-b at web dot de
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.
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
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
: 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
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
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=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.
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=65199
--- Comment #2 from Goswin von Brederlow ---
That fixes it. Isn't it a gcc bug though not to detect that itself?
: 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 "
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
: 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 #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
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=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: 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=56715
Goswin von Brederlow changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resol
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
Bug #: 56715
Summary: Explicit Reg Vars are being ignored for consts when
using g++
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFI
--
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
--- 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
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 #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
--- 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
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 #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
By: m dot b dot lankhorst at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42079
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
--- 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
--- 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
--- 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 #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-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
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 #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
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
Severity: minor
Priority: P3
Component: c
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 host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
->
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
--- Comment #1 from h dot b dot furuseth at usit dot uio dot no 2008-07-21
11:36 ---
Subject: Re: New: Please report #pragma GCC poison" location
Sorry about the empty report. Anyway:
The warning
a.c:2:5: attempt to use poisoned "foo"
is not intelligle if on
t gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887
(-1)/2 overflow warnings
Product: gcc
Version: 4.2.2
Status: 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 do
--- 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
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 #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
--- 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
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 #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
--- 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
--- 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
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
not functioning under Interix 3.5
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j dot b dot o dot s dot martens at tue
--- 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.
--- 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
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
t"
va_end(ap);
}
--
Summary: Please warn about va_start(ap, invalid)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu do
--- Comment #1 from h dot b dot furuseth at usit dot uio dot no 2007-01-13
18:40 ---
The warning is a bit misleading,
"function might be possible candidate for 'printf' format attribute"
means the _calling_ function might be such a candidate, not the function
bein
--- Comment #3 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:31 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
I just noticed another doc bug:
> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
That page says:
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-19
11:27 ---
Subject: Re: -fno-inline-functions does not work, and doc bugs
pinskia at gcc dot gnu dot org writes:
> You want -fno-inline-functions-called-once which was added in 4.2.0
> IIRC (...)
ONFIRMED
Severity: normal
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 host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
--- Comment #2 from h dot b dot furuseth at usit dot uio dot no 2006-12-03
15:49 ---
Subject: Re: [4.0/4.1 Regression] while(__builtin_expect()) pessimizes loop
pinskia at gcc dot gnu dot org writes:
> Fixed for 4.2.0:
> (...)
> Status|UN
.254s
user0m0.252s
sys 0m0.001s
--
Summary: while(__builtin_expect()) pessimizes loop
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot
D
Severity: minor
Priority: P3
Component: c
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 host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30054
--- Comment #7 from h dot b dot furuseth at usit dot uio dot no 2006-10-24
08:20 ---
Subject: Re: Issues with -Wchar-subscripts
gdr at integrable-solutions dot net writes:
> The absence of warning in C is OK -- literal characters have type int
> in C.
Yes, but see previous co
--- 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
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 #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
--- 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 #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
[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 #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.
1 - 100 of 116 matches
Mail list logo
