> 1
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-suse-linu
--- Comment #3 from bruno at clisp dot org 2008-03-28 22:46 ---
> you are entering a scope that has objects constructed.
Can you point out the sections in the ISO C++ standard that say that an 'if'
statement can create the scope for some objects?
--
http://gcc.gnu
--- Comment #4 from bruno at clisp dot org 2008-03-28 22:48 ---
The bug also occurs with g++ 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
--- Comment #7 from bruno at clisp dot org 2009-03-29 16:55 ---
(In reply to comment #4)
> The Fortran front-end diagnostic strings have a specific format, that is an
> extension of the C printf format. It is not the same as the
> gcc-internal-format. Thus, if you want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #6
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 49024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49024&action=edit
Test case
The only documented exa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527
--- Comment #2 from Bruno Haible ---
Created attachment 49026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49026&action=edit
Corrected test case
I see. A corrected test case is attached.
I wanted to avoid __gnu_inline__ because that's a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #8 from Bruno Haible ---
(In reply to Andrew Pinski from comment #6)
> a?-1:0 is transformed into -1 before we figure out that a is always true; an
> ordering difference.
Fortunately the GCC optimization affects only the return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93156
--- Comment #10 from Bruno Haible ---
(In reply to Jakub Jelinek from comment #9)
> So the only thing we should take from the above for the compiler is optimize
> in ccp that x*x has the second least significant bit clear.
If a compiler understa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
bruno at clisp dot org changed:
What|Removed |Added
CC||bruno at clisp dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154
Bug #: 50154
Summary: attribute printf and scanf should imply attribute
nonnull
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154
bruno at clisp dot org changed:
What|Removed |Added
Attachment #25076|0 |1
is obsolete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50021
bruno at clisp dot org changed:
What|Removed |Added
CC||bruno at clisp dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Bug #: 51793
Summary: pragma GCC optimize wrapv leads to invalid code on
Solaris
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
bruno at clisp dot org changed:
What|Removed |Added
CC||bruno at clisp dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023
--- Comment #9 from bruno at clisp dot org 2012-01-27 22:39:01 UTC ---
(In reply to comment #7)
> What happens if you have the attribute packed on the structure?
Attribute 'packed' is outside the scope of ISO C11. We're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
--- Comment #37 from Bruno Haible ---
(In reply to Rainer Orth from comment #35)
> Fixed for GCC 8.1.
Please consider comment 17:
The behaviour of a shared library also depends on whether the executable
is linked with or without values-xpg6.o. T
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 43331
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43331&action=edit
test program
The attached progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #1 from Bruno Haible ---
It works when I declare ys1, ys2, zs1, zs2 as 'volatile double' instead of
'double'. But I should not be needing to do this, because the only uses of
these 4 variables is as arguments to equalfn, which takes '
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The documentation of -fcheck-pointer-bounds in
https://gcc.gnu.org/onlinedocs/gcc-7.3.0/gcc/Instrumentation-Options.html says
- what the option does,
- what are the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190
--- Comment #5 from Bruno Haible ---
(In reply to jos...@codesourcery.com from comment #4)
> You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for
> predictable results from double arithmetic on 32-bit x86. If you do that,
>
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
GCC's optimizers apparently don't know that, for b an integer >= 0, a % b > 0
implies that a >= 0 and a % b <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Bruno Haible changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
Host|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
--- Comment #15 from Bruno Haible ---
> I think the following test case does show what Bruno was trying to prove.
Yes, the test case from comment 14 much better reflects what this bug report is
about, than the one from comment 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45433
--- Comment #4 from Bruno Haible ---
I am having the same error, even with option -C (which does not need a
-fmain=... option):
$ gcj -v -C HelloWorld.java
Using built-in specs.
COLLECT_GCC=/arch/x86-linux/gnu-inst-gcc/4.7.3/bin/gcj
Target: i68
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 41884
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41884&action=edit
Test case progra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653
--- Comment #1 from Bruno Haible ---
Created attachment 41885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41885&action=edit
Test case program, part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653
Bruno Haible changed:
What|Removed |Added
Target||sparc64-linux-gnu
--- Comment #2 from Bru
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 41886
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41886&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653
--- Comment #6 from Bruno Haible ---
> passing -fno-pie seems to be the agreed upon way out here.
My assembly code is located in a library (think at libffcall, libffi, gmp,
...).
Therefore I don't control the final linker options.
So, the only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81653
--- Comment #7 from Bruno Haible ---
And what do you think about the fact that it produces crashing code without any
warning?
Is there a chance that 'as' could emit a warning when it produces
R_SPARC_GOT22/R_SPARC_GOT10 relocations instead of th
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
g++ does not flag an error for use of attribute [[noreturn]] on a function
pointer declaration.
C++11 [dcl.attr.noreturn] says &quo
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
A mismatch regarding __attribute__((__noreturn__)) in a function pointer
initialization generates a warning in C mode, but
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The following bootstrap procedure, to build x86 (32-bit) executables of GCC on
a 64-bit (x86_64-linux-gnu) machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984
--- Comment #1 from bruno at clisp dot org ---
The error is similar to the one in bug #63507. The differences are:
- I'm not using the '--with-build-config=bootstrap-asan' option.
- It fails building the "," directo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984
--- Comment #5 from bruno at clisp dot org ---
Thanks Jakub. The ld --version and "-m elf_i386 -L /usr/lib/" trick solves it!
(I was already using the "as --32" trick.)
Another way is to define a simpler ld32 script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78984
--- Comment #7 from bruno at clisp dot org ---
(In reply to Andreas Schwab from comment #6)
> Note that if you use --with-ld, -B no longer works.
Thanks Andreas.
In fact, I've never used the -B option (except during gcc bootstrap).
Some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
bruno at clisp dot org changed:
What|Removed |Added
CC||bruno at clisp dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #3 from Bruno Haible ---
(In reply to Marek Polacek from comment #2)
> int
> fn1 (long x)
> {
> if (0)
> return __INT_MAX__ + 1;
>
> if (x || 0)
> return __INT_MAX__ + 1; /* { dg-warning "integer overflow" } */
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
--- Comment #10 from Bruno Haible ---
I confirm. I cannot reproduce the bug (neither with -O nor -O2) in GCC versions
4.2.3
4.2.4
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.4.0
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.5.0
4.5.1
4.5.2
4.5.3
4.5.4
4.
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
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=43116
--- Comment #1 from bruno at clisp dot org 2010-02-18 23:21 ---
Created an attachment (id=19918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19918&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43116
sion: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target tr
--- Comment #1 from bruno at clisp dot org 2010-03-20 13:39 ---
Created an attachment (id=20145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20145&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43454
ity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
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=43881
--- Comment #1 from bruno at clisp dot org 2010-04-24 22:49 ---
Created an attachment (id=20479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20479&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
--- Comment #3 from bruno at clisp dot org 2010-04-24 23:54 ---
When the line
static int (*safe_close) (int fd) = close;
is changed to
static int (*safe_close) (int fd) = ((void)0, close);
the warning also disappears, but then the generate code is suboptimal:
the variable safe_close
--- Comment #4 from bruno at clisp dot org 2010-04-24 23:58 ---
(In reply to comment #2)
> It is called directly because safe_close's value is replaced in the
> indirect call. Since safe_close is static and not changed in the code
> at all, it is marked as rea
--- Additional Comments From bruno at clisp dot org 2005-06-27 11:50
---
Indeed, the result is much better now, nearly optimal.
As you say, the only further optimization possible is that a better
register allocation could get rid of the
movl%edx, %esi
and
movl
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
atus: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
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=23058
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49283
Summary: pointless warning with -Wstrict-overflow
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49283
--- Comment #3 from bruno at clisp dot org 2011-06-06 20:33:07 UTC ---
(In reply to comment #2)
> [GCC] optimizes [...]
> moving the + 3 from the LHS and combining it with the constant offset
> on the RHS. That is only valid if p + 3 doe
--- Comment #1 from bruno at clisp dot org 2007-11-30 10:46 ---
Created an attachment (id=14671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14671&action=view)
source code exhibiting the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300
popl%ebp
ret
...
--
Summary: gcc 4.2.2 miscompiles code that uses global register
variables
Product: gcc
Version: 4.2.2
Status: UNCONFIRM
tatus: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.8.0
GCC host triplet:
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:01
---
Created an attachment (id=8706)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8706&action=view)
source file foo.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:01
---
Created an attachment (id=8707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8707&action=view)
source file bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21159
In function 'lisp_completion':
bug.c:291: warning: variable 'ptr1' might be clobbered by 'longjmp' or 'vfork'
--
Summary: how to force a variable into the stack?
Product: gcc
Version: 4.0.0
Status: U
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:04
---
Created an attachment (id=8708)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8708&action=view)
source file bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
ry: "clobbered by longjmp" warning ignores the data flow
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bru
--- Additional Comments From bruno at clisp dot org 2005-04-22 11:08
---
Created an attachment (id=8709)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8709&action=view)
source file bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
--- Additional Comments From bruno at clisp dot org 2005-04-22 14:14
---
I don't understand your resolution.
How can I guarantee that gcc will not put 'ptr' and 'array' into registers
where, on SPARC,
longjmp() will clobber them?
The semantics of '
--- Additional Comments From bruno at clisp dot org 2005-04-22 17:10
---
Thanks Joseph for the hint to ISO C 7.13.2.1.(3). Indeed, in the name of
portability, I'll have to
use 'volatile'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
--- Additional Comments From bruno at clisp dot org 2005-02-10 21:43
---
The warning is not correct because
1) The code snippet uses alloca() and variable-size arrays for their
respective purpose:
alloca() for storage that persists until the end of the function, and
variable
--- Additional Comments From bruno at clisp dot org 2005-02-11 13:13
---
> the warning is not the FSF's gcc, you two should have filed it with Redhat
> instead.
You're right: Current gcc CVS ("gcc version 4.0.0 20050211 (experimental)")
doesn't
sho
--- Additional Comments From bruno at clisp dot org 2004-10-11 11:55 ---
This result is even better: shorter than the previous ones, and there are
no useless moves between registers any more.
However, there are more useless moves from register to stack slot and back
from stack slot
--- Comment #1 from bruno at clisp dot org 2006-11-07 14:36 ---
It's still reproducible with gcc-4.2-20061031:
$ export OMP_NUM_THREADS=2
$ gdb a.out
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and yo
--- Comment #3 from bruno at clisp dot org 2006-11-15 13:38 ---
> Was LinuxThreads built at least --with-tls support or without?
The glibc was built with LinuxThreads without TLS. (I gave --without-tls
explicitly to the glibc build.)
> If without and libgomp has been built w
: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_6
--- Comment #2 from bruno at clisp dot org 2006-11-27 16:50 ---
You're right, it's well documented in cpp.info. I looked only in gcc.info.
--
bruno at clisp dot org changed:
What|Removed
ned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Summary: missed optimization due to bad range propagation without
-fwrapv
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot
--- Comment #87 from bruno at clisp dot org 2006-12-21 15:08 ---
The option -ffloat-store, recommended by Richard Henderson, has the effect of
decreasing the performance of floating-point operations for the entire
compilation unit. If you want a minimal fix that does not affect other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #5 from Bruno Haible ---
Nice! Thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #8 from Bruno Haible ---
> what is the reason to require that b >= 0 in all of this?
In the 1990ies there were portability problems with a%b, b < 0. ANSI C said
that the result was machine-dependent if a < 0 or b < 0. Fortunately the
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The documentation page
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html mentions "The
following built-in functions are available when -mcet or -mshstk o
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165
--- Comment #1 from Bruno Haible ---
Created attachment 49691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49691&action=edit
Test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98165
Bruno Haible changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 49808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49808&action=edit
Test case
On POSIX systems, free() can clobber the value of errno. This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396
Bruno Haible changed:
What|Removed |Added
Known to work||4.0.4, 4.1.2, 4.2.4, 4.3.6,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98396
--- Comment #4 from Bruno Haible ---
(In reply to Richard Biener from comment #3)
> But note that while free() may clobber errno the state after it is undefined
> (it's not documented to set it to any specific value). So I'd argue the
> check_er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
Bruno Haible changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51793
--- Comment #4 from Bruno Haible ---
Correction to comment #3:
It works fine on
- Solaris 11.4 (gcc 7.3.0): foo.s contains '.p2align 4,,15'
- Solaris 11 OpenIndiana (gcc 7.2.0): likewise
- Solaris 11 OmniOS (gcc 9.3.0): foo.s contains '.p2align 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100735
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30267
Bruno Haible changed:
What|Removed |Added
Known to work||10.3.0, 11.1.0, 6.5.0,
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The use of () to denote an unknown or varargs parameter list in function
declarations and function types, a language feature from K&R C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #2 from Bruno Haible ---
(In reply to Florian Weimer from comment #1)
> “()” is going to be fine when matched with an empty parameter list in a
> definition, or an empty argument list in a call. I don't think it's
> necessary to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108694
--- Comment #4 from Bruno Haible ---
(In reply to Aaron Ballman from comment #3)
OK. So, except for this unlucky (*) choice of attribution in case of a conflict
between function declaration and function definition, the
'-Wdeprecated-non-prototyp
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 54156
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54156&action=edit
test case
The attached c
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
A GCC 12.1.0 build of mine is failing with the error messages
/usr/lib/gcc-cross/i686-linux-gnu/10/../../../../i686-linux-gnu/bin/ld:
/build-loongarch64-linux/gcc-12.1.0/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105527
--- Comment #3 from Bruno Haible ---
Created attachment 52955
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52955&action=edit
Patch to document also --with-zstd-include and --with-zstd-lib
Hi Martin,
The patch you added is pretty minima
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
--- Comment #6 from Bruno Haible ---
(In reply to John David Anglin from comment #5)
> Don't include on hpux to avoid conflicting type declarations
> for mode_t. This fixes test on houx.
Why not entirely remove the '#include '? There is noth
iority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
we read: "Outside strict ISO C mode (-ansi, -std=c90, -std=c99 or -std=c11)
..."
Nowada
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
Created attachment 55839
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55839&action=edit
proposed fix
In https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builti
1 - 100 of 198 matches
Mail list logo
