--- Additional Comments From giovannibajo at libero dot it 2005-03-02
21:24 ---
Can you provide a link to the discussion in the avr-gcc list?
--
What|Removed |Added
--- Additional Comments From kgardas at objectsecurity dot com 2005-03-02
21:25 ---
Subject: Re: [4.0/4.1 Regression] 8% C++ compile-time
regression in comparison with 3.4.1 at -O1 optimization level
I agree with Giovanni that both #17278 and #13776 are fixed from MICO
compile-time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
21:27 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 13776 depends on bug 17278, which changed state.
Bug 17278 Summary: [4.0/4.1 Regression] 8% C++ compile-time regression in
comparison with 3.4.1 at -O1 optimization level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
What|Old Value |New Value
--- Additional Comments From giovannibajo at libero dot it 2005-03-02
21:28 ---
OK let's close this as fixed then. Many thanks to the hard work of the whole
GCC team!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
--- Additional Comments From giovannibajo at libero dot it 2005-03-02
21:32 ---
I gave a quick look at this and I can't find anything that is not already
fixed, especially after Karel's last results. Also having a bug with 85
comments is a good way to make developers run, so let's
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-02
21:36 ---
I think this is correct behavior. Without inheritance, the struct is POD, so
different rules apply.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19968
--- Additional Comments From kcook at gcc dot gnu dot org 2005-03-02 21:41
---
Created an attachment (id=8314)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8314action=view)
Proposed fix to bug
This is the proposed patch based on the fix for PR 17222 that rth's patch later
When recog_for_combine fails to recognize a pattern as-is, it re-tries
with the clobbers stripped away. When it eventually fails, and the
caller try_combine tries to split the pattern, the clobbers are
gone, thus causing combine failures for bridge splitters that need
these clobbers.
patch is
--
What|Removed |Added
BugsThisDependsOn||20291
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17652
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--
What|Removed |Added
Summary|g++ generates incomplete|With optimization,
|debug information for given |generating incomplete debug
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
21:49 ---
Works for me, so closing.
--
What|Removed |Added
Status|WAITING
As reported by Ranjit Mathew on [EMAIL PROTECTED]:
On an *uninstalled GCC* testsuite run, I get a FAIL
on the testcase:
-- 8 --
Executing on host: /home/ranmath/src/gcc/build/gcc/xgcc -B/home/ranmath/src/gcc/
build/gcc/
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
21:50 ---
This is not a bug as I explained.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
21:50 ---
This is not a bug as I explained.
The point is that .jar contain more infromation than what is included in the
shared library which gcj
needs to be able to produce the shared library.
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
21:51 ---
Confirmed, also on powerpc-darwin without an installed gcj.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2005-03-02 21:54
---
Correct. The class without inheritance doesn't need a constructor
since objects of this type can be initialized using a brace-enclosed
list. The class with inheritance is not POD, so it can't be initialized
--- Additional Comments From ericw at evcohs dot com 2005-03-02 22:01
---
Link to discussion on avr-gcc-list:
http://lists.nongnu.org/archive/html/avr-gcc-list/2005-02/msg00220.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20288
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-02
22:06 ---
The recog.c / recog.h part of the patch has been committed as part
of another patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00133.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
--- Additional Comments From bonniot at users dot sf dot net 2005-03-02
22:11 ---
Submitting the mauve testcases, with a classpath patch on the way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
In:
namespace hide {
int k;
}
namespace {
int i;
namespace hide {
int j;
}
}
void F(int) {}
int main() {
F(i);
F(hide::j);
}
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:16: error: `hide' has not been
--- Additional Comments From berndtrog at yahoo dot com 2005-03-02 22:20
---
Alex,
please attach the preprocessed file (*.i*) that triggers the bug, generated by
adding -save-temps to the complete compilation command.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
--- Additional Comments From berndtrog at yahoo dot com 2005-03-02 22:29
---
Update:
with this patch to $TARGET/libada/Makefile
RTS_DIR:=$(strip $(subst \,/,$(shell gnatls -v | grep adalib )))
-gnattools-cross: gnatlib
+gnattools-cross:
$(MAKE) -C $(GCC_DIR)/ada
-dispatch -shared -Wl,Bsymbolic -o jdtcore.jar.so \
jdtcore.jar
I've uploaded a copy of jdtcore.jar (built by itself (ecj)) to here:
http://overholt.ca/jdtcore.jar
$ gcj --version
gcj (GCC) 4.1.0 20050302 (experimental)
--
Summary: ia64 gcj failures
Product: gcc
--- Additional Comments From berndtrog at yahoo dot com 2005-03-02 22:44
---
I can confirm this for gcc-4.0.0-20050228
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19684
--- Additional Comments From berndtrog at yahoo dot com 2005-03-02 22:59
---
I can't send whole file because it is some intellectual property.
If you can't post the preprocessed sources because they're proprietary code,
then try to create a small file that triggers the same problem.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-02
23:01 ---
Confirmed, this is invalid code as the namespace hide is ambiguous but the
diagnostic is just plainly
bogus. Related to both PR 100 and bug 12272.
--
What|Removed
--- Additional Comments From bangerth at dealii dot org 2005-03-02 23:03
---
This is indeed a diagnostic problem: the access is ambiguous, but instead
of saying so gcc chooses to mention that there is no such name at all. This
happens in many places, and I believe that there must be
--- Additional Comments From schlie at comcast dot net 2005-03-02 23:07
---
(In reply to comment #0)
[The follow emphasis is Atmel's from the data-sheet]:
On the AVR to do a 16-bit write, *THE HIGH BYTE MUST BE WRITTEN BEFORE THE
LOW
BYTE*. For a 16-bit read, THE LOW BYTE MUST BE
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-02 23:09
---
The bug goes away with -Os -floop-optimize2, it is just the old loop optimizer
that doesn't handle this properly. It seems to me that loop.c really can't
do its job correctly if it doesn't detect where the
--- Additional Comments From a dot plot at nettaxi dot com 2005-03-02
23:10 ---
Subject: Re: unrecognizable insn
Well, I'll do this.
--
Best regards,
Alexmailto:[EMAIL PROTECTED]
Wednesday, March 2, 2005, 5:59:21 PM, you wrote:
baydc --- Additional
--
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20290
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-03-02
23:15 ---
As for 4.1, I hope we will get rid of the old loop optimizer.
I will check what can be done in 4.0.
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-03-02
23:18 ---
Waiting for reduced testcase
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From dje at gcc dot gnu dot org 2005-03-02 23:23
---
GCC 3.4 requires that it can build and run an application in every multilib
variant for which it tries to build a target library. This technically is not
necessary, but that is the way it currently works. You
--- Additional Comments From giovannibajo at libero dot it 2005-03-02
23:24 ---
(merging bugzilla conflicts...)
--
What|Removed |Added
BugsThisDependsOn|
In:
templatetypename T, int n
voidthru(T (arr)[n]) {}
int a0[] = {};
int a1[] = {0};
int main() {
thru(a1);
thru(a0);
}
you get:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `int main()':
foo.cc:9: error: no matching function for call to `thru(int[0u])'
I think zero is
When I compile (avr-gcc -Os -c -mmcu=at90s2313) this:
void SIG_PIN_CHANGE0 (void) __attribute__ ((signal)); void SIG_PIN_CHANGE0
(void)
{
(*(volatile unsigned char *)((0x12) + 0x20)) |= 1;
}
I get:
SIG_PIN_CHANGE0:
0: 1f 92 pushr1
2: 0f 92 pushr0
--- Additional Comments From pcarlini at suse dot de 2005-03-02 23:52
---
I have trouble considering this comment *wrong*: according to 17.4.1.2/4, it's
generally true for all the C++ headers for C library facilities that ... the
declarations and definitions (except for names which are
When #pragma GCC visibility push is used on builtin functions, it may
not be properly handled if #pragma GCC visibility pop is missing.
--
Summary: #pragma GCC visibility isn't properly handled for
builtin functions
Product: gcc
Version: 4.0.0
--- Additional Comments From hjl at lucon dot org 2005-03-03 00:05 ---
Created an attachment (id=8315)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8315action=view)
A testcase
/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-4.0/build-x86_64-linux/gcc/
--- Additional Comments From pcarlini at suse dot de 2005-03-03 00:15
---
... but the real problem with your code is that C++ does *not* have zero length
arrays... See 8.5.1/4 and note 91, in particular.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20295
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
00:26 ---
Yes this is invalid code. Reduced testcase:
int a0[] = {};
--
What|Removed |Added
This was discovered on gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-110)
and verified still an issue in gcc version 3.3.3 configured with ../gcc-
3.3.3/configure having thread model:posix.
We discovered this issue in combatting an issue with binary reproducibility.
Some early questions
--
What|Removed |Added
CC||neroden at gcc dot gnu dot
||org
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
01:03 ---
Subject: Bug 20277
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-03 01:03:37
Modified files:
gcc: ChangeLog
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
01:06 ---
Subject: Bug 20277
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-03 01:06:15
Modified files:
gcc:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
01:17 ---
Fixed already in 3.4.0 and above.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-03
01:21 ---
Subject: Bug 20277
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-03-03 01:20:52
Modified files:
gcc:
--- Additional Comments From amodra at bigpond dot net dot au 2005-03-03
01:22 ---
Fixed on all active branches
--
What|Removed |Added
Status|NEW
--- Additional Comments From andrewhutchinson at cox dot net 2005-03-03
01:57 ---
This is almost certainly caused by code peepholes doing last minute optimisation
of the code just before the assembler is generated.
Prior to that, all RTL instructions have a length (in 16 bit words)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
02:43 ---
This is a target bug. Either a binutils one which I really doubt it, or a
back-end bug which looks more
likely.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
02:44 ---
(In reply to comment #4)
The recog.c / recog.h part of the patch has been committed as part
of another patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00133.html
Yes this also caused a regression on
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
02:51 ---
Any news?
--
What|Removed |Added
Last reconfirmed|2004-12-02 02:13:25 |2005-03-03
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-12-02
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-03
03:07 ---
This has no been fixed on the mainline. I think PRE has changed to not to
produce these dead phis.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:04 ---
Oops, didn't mean to pick this one up, at least for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:07 ---
Doh, nevermind, too many open tabs, I guess :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:42 ---
Subject: [PR c++/20103] failure to gimplify constructors for addressable types
In the reduced testcase from the bug report, included in the patch
file below, we fail to gimplify the CONSTRUCTOR created for
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-03
07:51 ---
Subject: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs
When passing an lvalue cond_expr to a function taking a reference that
binds directly to either operand of ?:, we'd fail
101 - 164 of 164 matches
Mail list logo
