to sync filedescriptor on
force() invocation
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin
to 32-bit target
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benny at ammitzboell-consult dot dk
GCC build triple
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-02-25 14:09
---
Created an attachment (id=15224)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15224&action=view)
Test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-02-25 14:13
---
Created an attachment (id=15225)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15225&action=view)
Output from arm-gcc -c -dr main.c (32-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-02-25 14:14
---
Created an attachment (id=15226)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15226&action=view)
Output from arm-gcc -c -dM main.c (32-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-02-25 14:21
---
Created an attachment (id=15227)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15227&action=view)
Output from arm-gcc -c -dr main.c (64-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #7 from benny at ammitzboell-consult dot dk 2008-02-25 14:22
---
Created an attachment (id=15228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15228&action=view)
Output from arm-gcc -c -dM main.c (64-bit host)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35295
--- Comment #8 from benny at ammitzboell-consult dot dk 2008-02-25 14:27
---
Added test program and RTL output from 32-bit host and 64-bit host. Note the
difference in the const_int lines:
[EMAIL PROTECTED]:~/src/kuss$ diff /home/bla/Desktop/main.c.01.rtl
/home/bla/Desktop/main.c.01
--- Comment #9 from benny at ammitzboell-consult dot dk 2008-02-25 14:31
---
(In reply to comment #2)
> As when you say bigger do you mean the assembly is different sizes? Or do you
> mean the actually text/data sections are bigger in the object file?
>
The assembly is bigg
--- Comment #11 from benny at ammitzboell-consult dot dk 2008-02-25 16:02
---
(In reply to comment #10)
> At first this looks like a target issue. Can you check if a still maintained
> GCC version is still affected? That would be 4.2.3 for example.
>
Since print-rtl.c
--- Comment #12 from benny at ammitzboell-consult dot dk 2008-02-28 08:18
---
We have now tried the 4.2.3 version of gcc and it generates the same assembler
code (objdump -d) for the example here on both the 32-bit and the 64-bit host.
The RTL is still different though, so it seems
++
Assignee: unassigned at gcc dot gnu.org
Reporter: isj-bugzilla at i1 dot dk
Target Milestone: ---
In the reduced code below the constructor
Value::Value(std::vector > const&)
calls itself in the generated code leading to stack overflow. There is no such
recursive call in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88816
--- Comment #3 from Ivan Skytte Jørgensen ---
Ohhh...! Thank you for the explanation.
That was not at all obvious to me. It would be great if GCC detected it and
warned "brace-initializing a std:vector with a single std::vector may not do
what y
etPackage() returns null
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at egholm-nielsen dot dk
CC: gcc
--- Comment #13 from benny at ammitzboell-consult dot dk 2008-05-20 07:32
---
Ok, we have verified that this bug is not present when using a 4.2.3 arm
toolchain.
--
benny at ammitzboell-consult dot dk changed:
What|Removed |Added
--- Comment #14 from benny at ammitzboell-consult dot dk 2008-05-20 07:33
---
Verified on gcc 4.2.3
--
benny at ammitzboell-consult dot dk changed:
What|Removed |Added
FIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benny at ammitzboell-consult dot dk
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-uclibc
--- Comment #1 from benny at ammitzboell-consult dot dk 2008-06-13 12:59
---
Created an attachment (id=15762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15762&action=view)
C test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #2 from benny at ammitzboell-consult dot dk 2008-06-13 13:00
---
Created an attachment (id=15763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15763&action=view)
C++ test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #3 from benny at ammitzboell-consult dot dk 2008-06-13 13:00
---
Created an attachment (id=15764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15764&action=view)
test.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #4 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15765&action=view)
test.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #5 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15766&action=view)
testcpp.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #6 from benny at ammitzboell-consult dot dk 2008-06-13 13:01
---
Created an attachment (id=15767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15767&action=view)
testcpp.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36527
--- Comment #7 from benny at ammitzboell-consult dot dk 2008-06-16 09:10
---
test.c also fails with gcc 3.4.6 - testcpp.cpp however works with gcc 3.4.6.
--
benny at ammitzboell-consult dot dk changed:
What|Removed |Added
--- Comment #8 from benny at ammitzboell-consult dot dk 2008-06-19 14:07
---
Works on gcc 4.3.1
--
benny at ammitzboell-consult dot dk changed:
What|Removed |Added
: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benny at ammitzboell-consult dot dk
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: arm-linux-uclibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36697
redefinition errors
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ch at csh-consult dot dk
CC: gc
--- Additional Comments From ch at csh-consult dot dk 2005-01-17 21:01
---
Thanks Andrew. Is the memory problem also fixed?
I created a simpler example. 100 equal .c files each containing:
static void mainX() {}
where X varies from 1 to 1. This gives me a slightly different
iling multiple files at a
time
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ch at csh-consult d
--- Additional Comments From ch at csh-consult dot dk 2005-01-18 22:32
---
Yes I have, but I was lazy and wrote it in C#. I've put them up for download
here: http://212.242.245.122/100files.tar.gz (2.5MB)
There is also the command to invoke gcc (run.bat)
No -O flag is
--- Additional Comments From ch at csh-consult dot dk 2005-01-19 13:06
---
Does this mean that there is a limit to how many files you can compile at a
time (due to limited memory)? Can't the garbage collector run between each
compilation?
--
http://gcc.gnu.org/bug
ouble
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjj at ifk dot sdu dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35873
--- Comment #1 from hjj at ifk dot sdu dot dk 2008-04-08 16:47 ---
(In reply to comment #0)
> --> gfortran -malign-double test.f; a.out # ERROR: Segmentation violation
> --> gfortran test.f; a.out # OK
Fix of typo (gcc instead of gfortran)
--
http://gcc.gnu.
--- Comment #3 from hjj at ifk dot sdu dot dk 2008-04-08 18:50 ---
I don't understand how you can call it not a bug when a flag (no matter that it
changes the ABI) makes valid fortran code not work
It did work under earlier versions of gfotran.
--
hjj at ifk dot sdu d
--- Comment #4 from gbarnt at student dot dtu dot dk 2009-03-23 17:22
---
Created an attachment (id=17522)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17522&action=view)
Patch adding -Wl,-R,[dir] to --with-gmp/mpfr(-lib)?
Patch that adds linker flags "-Wl,-R,[
--- Comment #5 from gbarnt at student dot dtu dot dk 2009-03-23 17:23
---
Sadly my skills with bugzilla's haven't improved. I meant to have the following
accompany the patch above:
This issue is also present on an x86_64 red hat linux in gcc-4.3.3.
Usage of --with-gmp
--- Comment #6 from gbarnt at student dot dtu dot dk 2009-03-23 18:38
---
(From update of attachment 17522)
Sorry, too much copy-paste in the patch... re-uploading a new patch that does
not break --with-(gmp|mpfr)-lib.
--
gbarnt at student dot dtu dot dk changed:
What
--- Comment #7 from gbarnt at student dot dtu dot dk 2009-03-23 18:42
---
Created an attachment (id=17524)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17524&action=view)
Same as previous - except for the -lib error.
This patch replaces my old patch and does not br
--- Comment #2 from lfn dot privat at mail dot dk 2009-04-02 15:54 ---
(In reply to comment #1)
> This is correct behavior as MyType is not in the namespace so Read is not
> found
> after the call. If you want Read to be found, you can put it in the same
> namespace as
--- Comment #4 from lfn dot privat at mail dot dk 2009-04-03 09:41 ---
Thanks for clarifying how the compiler works. Actually this was the kind of
answer detail level I was looking for in the first place to find some kind of
work around to the problem.
Now, I assume that your answer
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandmann at daimi dot au dot dk
GCC build triplet: i386-redhat-linux
GCC host triplet: i386
--- Comment #1 from sandmann at daimi dot au dot dk 2009-04-18 17:32
---
Created an attachment (id=17654)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17654&action=view)
program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808
--- Comment #3 from sandmann at daimi dot au dot dk 2009-04-22 17:03
---
Why not? If not using the return value is a bug, then it's also a bug if it
isn't used after being passed through a statement expression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39808
--- Comment #10 from gbarnt at student dot dtu dot dk 2009-05-01 09:01
---
In reply to #9:
I have tried to build gcc with and without my own patch on our solaris
machines. While both of them fails they fail at the same place (namely
configuration of [arch]/libgcc trying to figure out
--- Additional Comments From tlm at daimi dot au dot dk 2005-07-19 17:02
---
(In reply to comment #1)
> The first testcase is fixed in 4.0.0. (Though there is a regression on the
mainline). I have not looked
> into the full testcase.
There have not been more reactions on th
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sandmann at daimi dot au dot dk
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=34384
--- Comment #1 from sandmann at daimi dot au dot dk 2007-12-07 22:00
---
Created an attachment (id=14709)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14709&action=view)
Program using struct returns and parameters
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34384
--- Comment #3 from sandmann at daimi dot au dot dk 2007-12-16 22:29
---
[EMAIL PROTECTED] ~]$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
overloads (in same namespace) requires forward
declarations
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
s simple elimination - works with manual
unroll
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tlm at daimi dot au dot dk
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21827
--- Additional Comments From tlm at daimi dot au dot dk 2005-05-31 05:38
---
(In reply to comment #1)
The first testcase is fixed in 4.0.0. (Though there is a regression on the
mainline). I have not looked into the full testcase.
(In reply to comment #2)
> I was not goint to cl
--- Additional Comments From tlm at daimi dot au dot dk 2005-05-31 20:45
---
(In reply to comment #1)
> The first testcase is fixed in 4.0.0. I have not looked
> into the full testcase.
Installed gcc 4.0.0 (a bit hard with the current version)
OK - I was wrong before (so ple
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: rene.jacobsen at deic dot dk
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Created attachment 49714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49714&action=edit
Code that p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98215
--- Comment #1 from rene.jacobsen at deic dot dk ---
Created attachment 49715
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49715&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98215
--- Comment #2 from rene.jacobsen at deic dot dk ---
Created attachment 49716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49716&action=edit
nvptx preprocessed source
mary: error: unrecognizable insn
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgen dot moth at uni
--- Additional Comments From jorgen dot moth at uni-c dot dk 2005-02-02
14:07 ---
To avoid the compiler error it helps to move the last "return(result" outside
the curly brackets of the last else statement (literally removing the pair of
curly brackets of the else statem
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sjh at schilling dot dk
Target Milestone: ---
Created attachment 57491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57491&action=edit
The test application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #1 from Søren Jæger Hansen ---
Created attachment 57492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57492&action=edit
Preprocessed output (gzipped to fit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #8 from Søren Jæger Hansen ---
I get all this, and thanks for quick processing. Still I think it's a bit odd
that -std=c++* and -std?=gnu++* gives different results, but I assume there's a
good reason for that.
We'll be using -std=g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #10 from Søren Jæger Hansen ---
-fexcess-precision=fast it is for now then, thanks again for fast feedback.
: unassigned at gcc dot gnu.org
Reporter: pto at linuxbog dot dk
Target Milestone: ---
I have worked a lot with clang and gcc compilers for many years, with focus on
C and C++.
It we take something really simple
int f()
{
int x = 1;
return x;
}
and compile with Gcc 13.2 - all fine
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rv at rasmusvillemoes dot dk
Target Milestone: ---
I was a bit surprised to learn that a semi-obvious bug like
memcmp(counter2, counter2, 16)
is not flagged by -Wtautological-compare. The optimizer certainly knows that
the
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorgen dot moth at uni-c dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
--- Comment #1 from jorgen dot moth at uni-c dot dk 2007-01-18 11:54
---
Created an attachment (id=12918)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12918&action=view)
readelf.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dk.1995-fast at yandex dot ru
Target Milestone: ---
Following code produces link-time error in new version of GCC.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
201 - 266 of 266 matches
Mail list logo
